Управление хранилищем Dataverse в приложениях для управления финансами и операциями

Поскольку организации ускоряют процесс цифровой трансформации, способность эффективно управлять данными становится стратегической бизнес-задачей. С развитием приложений на базе искусственного интеллекта и рабочих процессов на базе Copilot предприятия генерируют и потребляют данные с беспрецедентной скоростью. Эти данные подпитывают инновации, обеспечивают персонализированный опыт и способствуют принятию важных решений — но только если они управляются и хранятся разумно.

Чтобы удовлетворить меняющиеся потребности бизнеса, организациям необходимо принять проактивную стратегию управления хранением данных. Это гарантирует ответственное обращение с данными, которые больше не требуются для повседневной работы, освобождая ресурсы для высокоэффективных рабочих нагрузок, снижая операционные трудности и обеспечивая соответствие требованиям нормативных требований и аудита.

С технической точки зрения эффективное управление хранилищем в Dataverse и Dynamics 365 повышает производительность системы, улучшает экономическую эффективность и обеспечивает соблюдение политик долгосрочного хранения (LTR). Обе платформы предлагают инструменты и возможности автоматизации, позволяющие организациям управлять хранилищами.

Внедряя стратегии, описанные в этой статье, предприятия могут сократить накладные расходы на поддержку, упростить соблюдение требований и извлечь большую выгоду из своих бизнес-приложений, превратив хранилище из ограничения в конкурентное преимущество.

Ключевые преимущества

Эффективное управление хранением данных в Dataverse и Dynamics 365 обеспечивает ряд ключевых преимуществ, которые решают распространенные проблемы клиентов и повышают общую эффективность работы.

  • Повышенное соответствие LTR: эффективное управление хранилищем гарантирует, что данные хранятся в соответствии с политиками LTR. Это не только помогает соблюдать нормативные требования, но и обеспечивает сохранность критически важных данных и доступность их при необходимости.

  • Повышение производительности: оптимизируя управление хранилищем, организации могут значительно повысить производительность своих систем. Эффективное распределение и управление хранилищем сокращают задержки и повышают скорость извлечения данных, что обеспечивает более плавные и быстрые операции.

  • Повышение эффективности затрат: эффективное управление хранением данных позволяет организациям сосредоточиться на ценных данных за счет оптимизации и наведения порядка в хранилище. Сохраняя только самое необходимое, предприятия могут оптимизировать использование своих ресурсов хранения, что приведет к более разумному использованию ресурсов и экономически эффективному масштабированию.

Фон

По мере роста организаций и оцифровки большей части своих операций объем бизнес-данных, хранящихся в таких системах, как Dataverse и Dynamics 365, неуклонно увеличивается. Сюда входят не только активные транзакционные данные, но и исторические записи, которые необходимо сохранять для целей аудита, регулирования или обеспечения непрерывности бизнеса. Со временем такое накопление может привести к снижению производительности, увеличению эксплуатационных расходов и росту затрат на хранение, особенно когда данные, которые больше не используются активно, остаются на высокопроизводительных уровнях хранения.

Четко определенная стратегия управления хранилищем помогает организациям решать эти проблемы путем выявления данных, которые можно архивировать, очищать или перемещать в менее затратное хранилище, оптимизированное для чтения. Это важно для сценариев обеспечения соответствия, когда данные должны оставаться неизменными, иметь ограниченный доступ и быть доступными только для чтения, например, финансовые записи, журналы аудита или нормативные документы. Обеспечение надлежащего хранения таких данных без ущерба для производительности действующих систем является ключевым требованием для многих предприятий.

Используя инструменты и стратегии, доступные на обеих платформах, организации могут лучше контролировать объемы своего хранилища, сократить ненужное потребление и гарантировать, что критически важные для соответствия требованиям данные обрабатываются надлежащим образом.

В этой статье описываются практические подходы к управлению хранением данных, которые помогают клиентам привести свои методы хранения данных в соответствие с потребностями бизнеса и нормативными требованиями. Это повышает производительность системы, снижает эксплуатационные расходы и обеспечивает бескомпромиссное выполнение нормативных требований.

Почему мы храним данные

Чтобы выбрать и оптимизировать правильную схему хранения данных, важно проанализировать причины и цели, для которых мы храним данные.

Оперативные данные

В бизнес-приложениях операционные данные используются для отслеживания продаж, финансовых операций или действий в цепочке поставок.

К этим данным необходимо получать доступ в режиме реального времени, поддерживая клиентские и внутренние операционные процессы, которые регистрируют детальные действия, такие как взаимодействие с клиентами, заказы или операции с запасами.

Со временем оперативные данные могут перейти от активного использования к нечастому использованию. Данные могут потребоваться в режиме, близком к реальному времени, чтобы помочь клиенту с заказом или при обращении в службу поддержки. Например, рассмотрим следующие сценарии:

  • Клиент размещает заказ, в то же время другой клиент, который некоторое время не взаимодействовал с компанией, размещает заказ.
  • Каждый размещенный и отправляемый заказ постоянно просматривается. Существуют также заказы, на которые распространяется трехлетняя гарантия, и которые могут потребовать обращения за поддержкой и возврата средств.

Это может привести к возникновению потребностей в оперативном доступе к данным, таких как:

  • Менее одного года активного доступа к данным.
  • Менее трех лет редко используемых данных.
  • Более трех лет данные не подвергались оперативному доступу.

Поскольку оперативное хранение данных осуществляется в режиме реального времени, оно обходится относительно дорого по сравнению с другими типами хранения, поэтому для определения стратегий хранения важно понимать, когда требуется оперативный доступ к данным, а когда нет.

Операционная интеграция

Как специализированная категория операционного использования, данные могут требовать репликации между несколькими операционными системами, включая такие шаблоны, как:

  • Банковское дело : Управление взаимоотношениями с клиентами для взаимодействия с клиентами на передовой и репликации в несколько банковских систем. Например, у вас есть текущие счета, кредитные карты, ипотека и системы проверки кредитоспособности.
  • Производство : Система управления взаимоотношениями с клиентами для приема заказов на передовой и система управления ресурсами предприятия для управления цепочками поставок.
  • Действия полиции в чрезвычайных ситуациях : Управление взаимоотношениями с клиентами для взаимодействия с гражданами и диспетчерские системы для полицейских управлений предлагают управление развертыванием.

В этих случаях, хотя каждая система может иметь уникальные данные, которые она отслеживает, часто существуют общие основные данные, которые необходимо передавать между системами и синхронизировать, что приводит к необходимости интеграции.

Данные аудита

Обычно компания несет нормативную ответственность за хранение данных в течение длительных периодов времени (например, в среднем семь лет) для целей аудита (как внутреннего, так и внешнего), например, для поддержки финансового аудита, раскрытия информации регулирующим органам или проверки на предмет мошенничества.

Эти данные обычно охватывают как данные, необходимые для оперативных целей, так и данные, которые больше не нужны, поскольку это позволяет просматривать весь набор данных из одного места.

Данные аналитики

Организациям необходимо оценивать и анализировать состояние своего бизнеса. Им необходимо измерять и сравнивать статистические данные за определенный период времени, охватывающие несколько или все части бизнеса.

Большие периоды и широта данных, на основе которых может проводиться этот анализ, приводят к необходимости копирования оперативных данных в специализированные аналитические инструменты. Это позволяет избежать влияния сложной аналитики на производительность операционных систем, а также позволяет проводить анализ наборов данных, выходящих за рамки периода, для которого данные необходимы для операционной деятельности. Например, вам может потребоваться сравнить данные за семь лет, а не за один-два года. Однако различные аналитические потребности могут потребовать хранения полных данных или охватывать только данные, хранящиеся в операционных системах.

Аналитические данные обычно позволяют объединять данные из разных частей бизнеса и из разных систем.

Поток данных

Данные этих типов обычно со временем переходят от оперативных данных к транзакционным или историческим данным, как показано на следующем рисунке.

Поток данных.

Различные типы хранения

Dataverse типы хранения

Dataverse организует хранилище в три основные категории, каждая из которых имеет свои сценарии использования и особенности тарификации.

Тип хранилища Описание Распространенные варианты использования
Хранение базы данных Сохраняет структурированные данные в таблицах — стандартных и пользовательских. Бизнес-записи, метаданные, отношения и конфигурации
Файловое хранилище Сохраняет вложения и двоичные данные. Вложения электронной почты, изображения, документы, загруженные через Power Apps
Хранение журналов Сохраняет журналы аудита и журналы трассировки плагинов. Отслеживание изменений, аудит, диагностика и соответствие требованиям

Типы хранилищ финансовой и операционной платформы

Хранилище финансовых и операционных данных управляется отдельно, но все больше интегрируется в Power Platform экосистему. Включает в себя следующие типы хранилищ.

Тип хранилища Описание Распространенные варианты использования
Оперативное хранилище базы данных Основные транзакционные данные по финансам, цепочке поставок, кадрам и т. д. Записи в главной книге, инвентарь, заказы клиентов
Хранилище для управления документами Большие двоичные объекты (BLOB-объекты), хранящиеся в хранилище BLOB-объектов Azure Счета, квитанции, скан-документы
Журналы телеметрии и диагностики Системные журналы и данные телеметрии Мониторинг производительности, диагностика проблем.

Сценарии общего и интегрированного хранения

  • Хранилище с двойной записью данных

    • Обеспечивает синхронизацию в реальном времени между Dataverse и приложениями для финансов и операций.
    • Требуется тщательное управление ролями и мощностями, чтобы избежать дублирования или чрезмерного использования.

  • Долгосрочное удержание (LTR)

    • Перемещает исторические данные в управляемое озеро данных (MDL).
    • Сокращает использование основного хранилища, сохраняя при этом соответствие требованиям и доступ к аналитике.
    • Интегрируется с:
      • Быстрый поиск (Dataverse-собственный поиск)
      • OneLake (аналитика на базе Fabric)
      • Synapse Link (специальная аналитика озер)

Как ваши данные растут со временем

По мере того как организации масштабируют использование Dataverse финансовой и операционной платформы Dynamics 365, рост объема данных становится одновременно признаком успеха и стратегической задачей. То, что начинается как небольшой транзакционный набор данных, может быстро превратиться в сложную многоуровневую структуру данных. В этом разделе рассматриваются пять основных факторов роста объемов данных и их влияние на хранение, производительность и управление.

Использование хранилища данных для оперативных данных

Чтобы получить доступ к ценной информации из операционных систем, многие организации используют Azure Synapse Link, OneLake или экспорт данных для копирования данных из Dataverse финансовых и операционных приложений в аналитическую систему. Помимо поддержки расширенных отчетов и рабочих нагрузок ИИ, он также вводит:

  • Избыточное хранилище на операционном и аналитическом уровнях

    Данные часто дублируются между операционной и аналитической средами. Такая избыточность увеличивает общее потребление ресурсов хранилища и может привести к более высоким затратам, особенно если исторические данные хранятся неограниченное время в обеих системах.

  • Дублирование схемы и накладные расходы на управление версиями

    Чтобы поддерживать согласованность между системами, организации должны реплицировать изменения схемы (например, новые поля и переименованные столбцы) как на операционном, так и на аналитическом уровнях. Это усложняет управление данными и увеличивает риск смещения схемы, что может привести к сбою последующих отчетов или моделей.

  • Увеличение объема сохранения исторических данных для анализа тенденций

    Аналитические системы обычно хранят данные в течение более длительных периодов времени для поддержки анализа тенденций, прогнозирования и нормативной отчетности. Несмотря на всю ценность такого долгосрочного хранения, оно может привести к раздуванию наборов данных, если не использовать надлежащие стратегии архивирования и многоуровневого хранения.

Хранилище данных имеет важное значение для аналитики, но без политик жизненного цикла оно может увеличить объем хранилища вдвое или втрое.

Использование поиска по данным

Такие функции, как Dataverse поиск, индексация Copilot и поиск по релевантности, требуют индексации больших объемов структурированных и неструктурированных данных. Эти индексы часто:

  • Использование хранилища журналов и базы данных

    Поисковые индексы хранятся как в журнале, так и в базе данных. По мере того, как все больше таблиц и полей помечаются как доступные для поиска, размер индекса пропорционально увеличивается. Это может существенно повлиять на общее использование хранилища, особенно в средах с большими объемами записей или частыми изменениями схемы.

  • Сохранять даже неиспользуемые или устаревшие таблицы

    Даже если определенные таблицы устарели или больше не используются активно, связанные с ними поисковые индексы могут сохраняться, если только они не будут явно удалены. Это приводит к ненужному потреблению ресурсов хранилища и может усложнить планирование емкости.

  • Часто дублируются в разных средах, таких как среда разработки, тестирования и производства.

    Поисковые индексы обычно реплицируются в средах разработки, тестирования и производства. Хотя это обеспечивает единообразие поведения поиска, это также увеличивает объем хранилища, особенно когда среды часто клонируются или обновляются.

Поиск повышает удобство использования и готовность к использованию искусственного интеллекта, но раздувание индекса является скрытым фактором, способствующим перерасходу ресурсов хранилища.

Включение регистрации данных

Журналы аудита, журналы трассировки подключаемых модулей и телеметрия имеют решающее значение для соответствия, отладки и мониторинга. Однако обратите внимание на следующие моменты:

  • Хранилище журналов растет линейно с использованием и количеством пользователей.

    Данные журнала растут пропорционально:

    • Количество пользователей и уровень их активности
    • Объем транзакций и интеграций
    • Сложность бизнес-логики, такой как подключаемые модули и рабочие процессы

    В средах с высокой нагрузкой это может привести к быстрому расширению таблиц журналов, израсходовав при этом квоты как базы данных, так и хранилища журналов.

  • Параметры хранения по умолчанию часто бывают слишком щедрыми, например 90 дней и более.

    По умолчанию многие функции ведения журнала сохраняют данные в течение длительных периодов времени, например 90 дней и более. Хотя это и обеспечивает долгосрочную прослеживаемость, это может привести к ненужному потреблению памяти, особенно если журналы активно не просматриваются и не экспортируются.

  • Формируемые системой журналы оплачиваются клиентом в Dataverse.

    В Dataverse, журналы, созданные системой, включая журналы аудита и журналы трассировки подключаемых модулей, учитываются при подсчете объема хранилища, выделенного клиенту. Это означает, что без надлежащих стратегий очистки или экспорта вырубка леса может напрямую способствовать перерасходу ресурсов на хранение и увеличению расходов на лицензирование.

Ведение журналов не подлежит обсуждению для регулируемых отраслей, но должно сочетаться со стратегиями хранения и экспорта, такими как Azure Monitor или Log Analytics.

Наличие нескольких копий производственной среды

Для поддержки разработки, тестирования, обучения и устранения неполадок клиенты часто создают «песочницы» или клонированные среды. Каждая копия:

  • Воспроизводит полный объем данных и индексов.
  • Могут включать неочевидные зависимости, такие как поисковые индексы, журналы аудита и метаданные.
  • Редко моется после использования.

Неконтролируемое разрастание сред является одной из основных причин роста затрат на хранение и его усложнения. Ключевыми факторами сдерживания являются политика управления и автоматизация.

Оптимизация запросов к данным

По мере того как растут объемы данных, а скорость отклика приложений становится критически важной, клиенты и независимые поставщики программного обеспечения часто применяют различные методы оптимизации запросов для повышения производительности в Dataverse и Dynamics 365. Эти стратегии особенно распространены в сценариях, требующих большой отдачи от отчетности, аналитики и интеграции.

Для повышения производительности клиенты и независимые поставщики программного обеспечения часто создают:

  • Пользовательские индексы и материализованные представления

    Они используются для ускорения выполнения запросов путем предварительного вычисления объединений или агрегаций. Они полезны в сценариях, включающих сложные фильтры или большие наборы данных.

  • Денормализованные таблицы для отчетности

    Чтобы упростить отчетность и снизить сложность запросов, разработчики часто создают упрощенные версии реляционных данных. Эти таблицы уменьшают необходимость в соединениях во время выполнения и повышают производительность панели мониторинга.

  • Кэширование слоев или агрегатов

    Часто используемые данные иногда предварительно агрегируются или кэшируются в промежуточных таблицах или внешних хранилищах для снижения нагрузки на первичную базу данных.

Хотя они улучшают реакцию, они также:

  • Увеличить использование хранилища

    Каждый уровень оптимизации вводит больше структур данных, будь то копия существующих данных в денормализованном формате, предварительно вычисленное представление или таблица кэша. Эти структуры часто дублируют данные, которые уже хранятся в другом месте, что приводит к увеличению общего объема хранилища. В средах со строгими квотами на хранение или моделями лицензирования на основе затрат, такими как Dataverse, это может быстро перерасти в излишки, которых можно было бы избежать.

  • Могут стать бесполезными по мере развития приложений

    По мере развития приложений некоторые артефакты оптимизации могут больше не использоваться в активных отчетах, панелях мониторинга или интеграциях. Эти покинутые объекты продолжают занимать место в хранилище и могут даже замедлить работу системы, например, во время резервного копирования или индексирования, если их не идентифицировать и не удалить. Без регулярных проверок они могут накапливаться незаметно, подрывая тот самый прирост производительности, для поддержки которого они были созданы.

Оптимизация запросов имеет важное значение для масштабирования, но ее необходимо сбалансировать с гигиеной хранения и настройкой на основе телеметрии.

Индексы и их влияние на хранение

Индексы необходимы для повышения производительности запросов и использования быстрого поиска данных в больших наборах данных. Как в Dataverse, так и в приложениях Dynamics 365 для Finance and Operations индексы автоматически создаются для первичных ключей и полей, к которым часто обращаются в запросах, а также можно определить другие пользовательские индексы для поддержки конкретных бизнес-сценариев.

Хотя индексы имеют решающее значение для производительности, они также оказывают непосредственное влияние на потребление хранилища, что часто недооценивается при проектировании решения.

Как индексы потребляют хранилище

  • Физическое дублирование данных: каждый индекс хранит копию индексированных столбцов вместе с указателями на соответствующие строки. Чем больше индексированных столбцов и строк, тем больше размер индекса.

  • Рост с ростом объема данных: по мере роста базовой таблицы растет и индекс. В средах с высоким уровнем транзакций индексы могут быстро расти, особенно в больших денормализованных таблицах или в таблицах с частыми вставками и обновлениями.

  • Несколько индексов на таблицу: часто одна таблица имеет несколько индексов, например, для поиска, фильтрации, сортировки и соединений. Каждый последующий индекс увеличивает совокупный объем хранилища.

  • Поисковые индексы в Dataverse: такие функции, как Dataverse поиск и индексация Copilot, создают специализированные индексы, охватывающие несколько полей и таблиц. Они хранятся в таблице DataverseSearch и могут занимать значительный объем пространства, особенно при использовании в нескольких средах, таких как среды разработки, тестирования и производства.

  • Системно-сгенерированные индексы: некоторые индексы создаются платформой автоматически, например для полей поиска или взаимосвязей. Они могут сохраняться, даже если связанные с ними таблицы устарели, если только они явно не удалены.

Последствия хранения

  • Увеличение хранилища базы данных и журналов: Индексы увеличивают использование хранилища как базы данных, так и журналов, что может повлиять на стоимость лицензирования в Dataverse.
  • Дублирование среды: при копировании или обновлении среды все индексы дублируются, что увеличивает использование хранилища в средах разработки, тестирования и производства.
  • Накладные расходы на обслуживание: Индексы необходимо обновлять по мере изменения данных, что может увеличить задержку записи и потребление ресурсов.

Влияние синхронизации на стороне сервера на хранилище

Синхронизация на стороне сервера Dataverse позволяет осуществлять бесшовную интеграцию электронных писем, встреч и задач между Microsoft Exchange и Dataverse. Хотя это повышает производительность и автоматизацию, это также способствует потреблению ресурсов хранения следующими способами.

  • Создание записи об активности: каждое синхронизированное электронное письмо или встреча генерируют запись об активности в Dataverse, которая включает метаданные, содержимое тела сообщения и, возможно, вложения.
  • Хранилище вложений: если вложения не фильтруются и не выгружаются, они сохраняются непосредственно в Dataverse, что увеличивает использование хранилища.
  • Соответствие требованиям и хранение: Организации, использующие синхронизацию на стороне сервера для отслеживания соответствия требованиям, могут сохранять больше данных, чем необходимо, что еще больше увеличивает объем хранилища.
  • Защищённое содержимое: Даже электронные письма, защищённые с помощью Purview, несмотря на ограниченную видимость содержимого, всё равно создают записи-заполнители, которые занимают место.

Чтобы справиться с этим воздействием, предприятиям следует внедрить политику хранения, рассмотреть возможность разгрузки вложений и регулярно отслеживать объемы записей о деятельности.

Как мне управлять постоянно растущим хранилищем?

Независимо от того, сталкиваетесь ли вы уже с нехваткой места в хранилище или стремитесь ее избежать, управление ростом данных в Dataverse финансовой и операционной платформе Dynamics 365 требует продуманного подхода на основе политик. В этом разделе описываются две стратегические точки входа: реактивное восстановление и проактивное управление.

Возможны два сценария:

  1. Вы хотите заблаговременно применять лучшие практики управления хранилищем и избегать высоких затрат в будущем.
  2. Вы уже находитесь в ситуации, когда необходимо сократить объем и стоимость хранилища.

Применяйте лучшие практики для управления размером хранилища и расходами

Сценарий 1: Вы хотите заранее применять лучшие практики управления хранилищем

Если вы еще не находитесь в кризисном режиме, сейчас самое время применить инструменты и методы для проактивного управления хранилищем.

Настройте аналитику для ваших данных

По мере роста организаций растет и потребность в извлечении аналитической информации из операционных данных без ущерба для производительности основных бизнес-приложений. Microsoft предлагает несколько способов организации аналитики данных Dataverse и Dynamics 365 Finance and Operations за счет интеграции с вашим собственным озером данных или хранилищем.

Вот два эффективных варианта, которые стоит рассмотреть:

Вариант 1. Использование Azure Synapse Link — собственное озеро

Azure Synapse Link позволяет подключить Dataverse напрямую к собственному Azure Data Lake или рабочему пространству Synapse. Это позволяет практически в реальном времени реплицировать оперативные данные в аналитическую среду, без написания сложных ETL-конвейеров.

Преимущества:

  • Используйте расширенную аналитику и модели искусственного интеллекта на основе реальных или приближенных к реальным данных.
  • Избегайте влияния на производительность ваших производственных систем.
  • Используйте знакомые инструменты, такие как T-SQL, Spark или Power BI для создания отчетов.

Пример использования: Розничная компания использует Synapse Link для анализа поведения покупателей в разных регионах, объединяя Dataverse данные управления взаимоотношениями с клиентами с внешними рыночными данными в своем собственном озере.

Вариант 2. Используйте OneLake – единую аналитику с Microsoft Fabric

OneLake, входящее в состав Microsoft Fabric, предоставляет единое пространство озера данных, в котором можно хранить и анализировать данные из нескольких источников, включая Dataverse, а также приложения для финансов и операций, без дублирования данных.

Преимущества:

  • Централизованное хранилище для всех аналитических рабочих нагрузок.
  • Встроенная интеграция с Power BI, Synapse и службами ИИ.
  • Упрощенное управление и безопасность во всех доменах данных.

Пример использования: Финансовая компания использует OneLake для консолидации операционных данных из финансовых и операционных приложений и Dataverse с внешними экономическими показателями, что позволяет моделировать риски в режиме реального времени и создавать информационные панели для руководителей. Благодаря этому вы сможете отделить операционные данные от основных систем и реализовать масштабируемую и экономичную аналитику, экспортируя эти данные в их собственные аналитические среды, без дублирования рабочих нагрузок или снижения производительности.

Инструменты и методы для сокращения объема памяти

Dataverse предлагает несколько встроенных инструментов и стратегий, помогающих администраторам эффективно управлять хранилищем и поддерживать производительность системы.

Dataverse

Управление данными с помощью политик управления

  • Начните с сред и таблиц, которые используют больше всего хранилища.
  • Используйте политики повторяющегося управления для прогнозируемого роста данных вместо того, чтобы полагаться только на однократную очистку.
  • Протестируйте критерии удаления и хранения в изолированной среде, прежде чем использовать их в продуктивной среде.
  • Регулярно просматривайте результаты политики и сбои.
  • Добавьте емкость хранилища, если необходимые данные не могут быть удалены или перемещены в долгосрочное хранение.

Очистка окружающей среды и данных

  • Удалить неиспользуемые среды: Вы можете удалить среду, чтобы освободить место для хранения и удалить персональную информацию (PII).
  • Задания массового удаления: Вы можете удалить следующие данные одновременно:
    • Устаревшие данные или данные, не имеющие отношения к бизнесу.
    • Ненужные тестовые или демонстрационные данные.
    • Данные, ошибочно импортированные из других систем.

Оптимизация файлов и таблиц

Долгосрочное хранение (LTR) и архивирование

Оптимизация поискового индекса

  • Уменьшить объем поиска Dataverse: Вы можете уменьшить объем хранилища, выполнив все действия, описанные в разделе Сведения о хранилище Dataverse на основе емкости.
  • Уменьшите размер таблицы DataverseSearch: Таблица DataverseSearch — это совокупное хранилище, используемое Dataverse индексом поиска. Она включает данные из всех доступных для поиска, извлечения и фильтрации полей таблиц, которые вы проиндексировали для своей среды. Вы можете уменьшить размер таблицы, удалив столбцы поиска, столбцы просмотра и условия фильтрации для одной или нескольких таблиц. Вы можете выключить поиск Dataverse, чтобы удалить все проиндексированные данные.
Приложения для управления финансами и операциями

Приложения для финансов и операций предоставляют гибкие возможности управления хранилищем в производственных и изолированных средах.

Управление окружающей средой

  • Ограничьте количество полных производственных копий: вы можете сократить общее потребление хранилища финансовыми и операционными приложениями, удалив полные производственные копии в изолированных средах. Например, если у вас есть пять копий рабочих сред в песочнице, потребление хранилища рассчитывается как сумма данных рабочей среды и пяти ее копий в песочнице.
  • Обрезка данных в изолированных средах: Обрезка данных в изолированной среде позволяет сократить общий объем хранилища. Для очистки данных в «песочнице» вы можете воспользоваться приведенными ниже методами.
    • Процесс восстановления выполняет операции открытия и обрезки
    • Написать T-SQL
    • Написать X++
  • Выполнение копирования без транзакций между средами: Копирование среды для финансовых и операционных приложений традиционно включало полное дублирование базы данных, включая конфигурацию, основные данные и транзакции, что, хотя и полезно для отладки, значительно увеличивает потребление хранилища как в финансах, так и в операциях, а также Dataverse.

Пользовательская очистка и управление журналами

  • При необходимости напишите пользовательские процедуры очистки: Вы можете написать пользовательские процедуры очистки, необходимые вашему бизнесу для очистки нежелательных данных.
  • Избегайте хранения журналов: вы можете переместить SysDatabaseLog в менее транзакционную базу данных, чтобы уменьшить общий объем хранилища.

Архивное и долгосрочное хранение

Встроенные процедуры очистки

  • Процедуры очистки: в Dynamics 365 Finance и Dynamics 365 Supply Chain Management процедуры очистки доступны в различных модулях. В разделе «Процедуры очистки» представлен обзор процедур, доступных в настоящее время. После копирования базы данных «песочницы» заблаговременно запустите эти процедуры очистки, чтобы удалить ненужные таблицы, такие как история партий, журналы и история розничных транзакций. Удалите устаревшие или неактуальные данные.
  • Архивирование данных о транзакциях по кредитным картам: описывает задание по архивированию, которое может помочь освободить место в базе данных путем архивирования токенов платежей по кредитным картам. Dynamics 365 Commerce

Уменьшить размер хранилища и затраты

Сценарий 2: Вы уже находитесь в ситуации, когда необходимо сократить объем хранилища и его стоимость.

Оцените, что занимает место в хранилище

  • Используйте центр администрирования Power Platform и отчеты о хранилище Finance and Operations, чтобы определить таблицы, типы файлов и журналы с наибольшим потреблением хранилища.
  • Используйте телеметрию, если она доступна, чтобы соотнести использование с конкретными приложениями, пользователями или бизнес-подразделениями.

Расставьте приоритеты среди кандидатов на уборку

  • Сосредоточиться на:
    • Промежуточные таблицы и таблицы интеграции, например буферы двойной записи
    • Журналы аудита: сохраняйте их в своем собственном хранилище.
    • Неиспользуемые среды или песочницы
    • Потерянные метаданные и поисковые индексы
    • Удалите то, что вам не нужно, например, массовое удаление.

Используйте Synapse Link и OneLake для аналитической отчетности

  • Экспортируйте аналитические данные в Synapse Link.
  • Используйте OneLake для доступа к сохраненным данным и бизнес-данным для целей отчетности и аналитики.

Применить долгосрочное удержание (LTR)

  • Перемещайте исторические данные в управляемое озеро данных (MDL) с использованием политик LTR.
  • Поддерживайте доступ к поиску и аналитике через Quick Find, Synapse Link или OneLake.

Случаи использования

Варианты использования управления хранением данных в Dataverse финансовых и операционных средах имеют решающее значение для оптимизации пространства базы данных, повышения производительности системы и соответствия нормативным требованиям. Ниже приведены некоторые типичные сценарии, демонстрирующие, как можно применять эти стратегии:

  • Управление ростом исторических данных

    • Сценарий: Компания работает в Dynamics 365 уже несколько лет и накопила большие объемы исторических транзакций и вложений.
    • Действие: Внедрить долгосрочные стратегии хранения для сохранения неактивных данных, уменьшения размера первичной базы данных и обеспечения соответствия требованиям аудита.

  • Хранение данных в соответствии с требованиями

    • Сценарий: Регулируемый отраслевой клиент должен хранить финансовые или клиентские данные в течение семи-десяти лет в защищенном от несанкционированного доступа формате.
    • Действие: Используйте LTR для сохранения неизменяемых данных, доступных только для чтения, в соответствии с юридическими и нормативными требованиями, сохраняя при этом компактность бизнес-данных без ущерба для аналитики и отчетности.

  • Оптимизация индекса поиска и Copilot

    • Сценарий: поиск Dataverse и индексация Copilot включены во всех средах, включая неиспользуемые таблицы.
    • Действие: Проведите аудит полей поиска и отключите индексацию для малозначимых или устаревших таблиц. Контролируйте размер таблицы DataverseSearch и оптимизируйте конфигурации для уменьшения объема хранилища журналов и базы данных.

  • Управление аудитом и телеметрией

    • Сценарий: Журналы трассировки подключаемых модулей и журналы аудита быстро растут, занимая место в хранилище и влияя на производительность.
    • Действие: Экспортируйте журналы во внешние системы, например Azure Monitor, и автоматизируйте очистку старых записей, чтобы поддерживать видимость, не раздувая хранилище.

  • Интеграция хранилищ данных и аналитики

    • Сценарий: Организация реплицирует операционные данные в Azure Synapse или OneLake для аналитики, что приводит к дублированию хранилища.
    • Действие: Используйте инкрементный экспорт, применяйте фильтры и избегайте полной репликации наборов данных, чтобы минимизировать избыточность и при этом получать ценную информацию.

  • Сокращение излишков хранения

    • Сценарий: Клиент получает уведомление о превышении своей Dataverse квоты хранения, что приводит к непредвиденным расходам.
    • Действие: Используйте отчеты об использовании емкости, чтобы выявить таблицы с наибольшим потреблением ресурсов, очистить устаревшие среды и удалить неиспользуемые вложения или журналы. Рассмотрите возможность перемещения холодных данных (обычно исторических или редко используемых записей) на более дешевые уровни хранения.

  • Оптимизация производительности в больших таблицах

    • Сценарий: Критически важные бизнес-процессы замедляются из-за больших таблиц.
    • Действие: Архивация старых записей, очистка системных заданий, например AsyncOperationBase и WorkflowLogBase.

  • Управление жизненным циклом окружающей среды

    • Сценарий: Среды разработки и тестирования клонируются из производственной среды, дублируя все данные и индексы.
    • Действие: Очистите среды песочницы после обновления, отключите ненужную индексацию поиска и удалите тестовые данные, чтобы сократить избыточное потребление хранилища. Удалите неиспользуемые песочницы, чтобы сэкономить место.

Примеры

Пример 1: Сокращение излишков хранилища за счет очистки индекса

Профиль клиента: Глобальная производственная компания, использующая Dynamics 365 для приложений управления цепочками поставок, финансами и операциями.

Задача: Клиент столкнулся с непредвиденным переизбытком места на складе и снижением производительности в своей производственной среде. Расследование показало, что многочисленные пользовательские индексы и материализованные представления, созданные на раннем этапе внедрения, больше не используются, но по-прежнему занимают значительный объем памяти.

Решение: Команда провела ежеквартальный аудит всех пользовательских индексов и удалила те, на которые не ссылаются активные запросы или отчеты. Они также внедрили политику управления для проверки новых запросов на индексирование перед развертыванием.

Исход:

  • Сокращение хранилища базы данных на 28%.
  • Производительность запросов повышена на 15%.
  • Избежал прогнозируемых $12,000 в год других расходов на хранение.

Пример 2: Архивирование исторических данных для достижения целей соответствия и производительности

Профиль клиента: Компания, предоставляющая финансовые услуги, использующая Dataverse и Dynamics 365 для регистрации клиентов и управления их делами.

Задача: Компании необходимо хранить записи о клиентах более семи лет, чтобы соответствовать нормативным требованиям, но растущий объем неактивных данных замедлял активные рабочие процессы и увеличивал затраты на хранение.

Решение: Клиент реализовал стратегию долгосрочного хранения, используя возможности Dataverseархивирования. Неактивные записи были перемещены на оптимизированный с точки зрения затрат уровень хранения, доступный только для чтения, в то время как активные данные остались в высокопроизводительном хранилище.

Результат:

  • Архивировано более 1,2 миллиона записей.
  • Уменьшен размер первичной базы данных на 40%.
  • Обеспечивается полная контролируемость и соблюдение политик хранения.

Пример 3: Оптимизация поисковых индексов в разных средах

Профиль клиента: Розничная организация с несколькими Dataverse средами, включая среды разработки, тестирования и производства, поддерживающая решение по управлению взаимоотношениями с клиентами на базе Copilot.

Задача: Поисковые индексы использовались во всех средах, включая неиспользуемые таблицы и тестовые данные. Это привело к раздутию таблиц DataverseSearch и ненужному потреблению хранилища.

Решение: Команда пересмотрела поля поиска и прекратила использование индексации для некритических таблиц в средах разработки и тестирования. Они также автоматизировали очистку индекса во время обновления окружения.

Результат:

  • Уменьшено хранилище поискового индекса на 35%.
  • Время обновления окружения увеличено на 20%.
  • Снижено общее использование хранилища журналов и баз данных.

Пример 4: Использование экспорта данных для аналитики без дублирования хранилища

Профиль клиента: Поставщик медицинских услуг, использующий Dynamics 365 Dataverse для взаимодействия с пациентами и выставления счетов.

Задача: Аналитической группе требовался доступ к оперативным данным для анализа тенденций и моделирования с помощью ИИ, но дублирование данных в отдельном хранилище увеличивало затраты на хранение и сложность.

Решение: Клиент использовал Azure Synapse Link с инкрементным экспортом и многоуровневым хранилищем в OneLake. Они сохранили только необходимые аналитические данные и применили политику хранения для управления исторической глубиной.

Результат:

  • Возможность аналитики в реальном времени без влияния на операционные системы.
  • Сокращение избыточного хранения на 45%.
  • Улучшенное управление жизненным циклом аналитических данных.

Заключение

Эффективное управление хранилищем имеет решающее значение для поддержания производительности системы и оптимизации использования ресурсов в средах Dynamics 365. Процедуры очистки и архивные задания, описанные в этой статье, представляют собой надежные решения для освобождения ценного пространства базы данных и оптимизации операций. Используя такие инструменты, как LTR и аналогичные методы, клиенты могут решать распространенные проблемы хранения данных и создавать устойчивые методы управления данными. Более того, реальные примеры демонстрируют эффективность этих подходов, предлагая понимание их практического применения. Внедрение этих стратегий позволяет организациям заблаговременно управлять своими потребностями в хранении данных и повышать общую эффективность.

Ссылки

Очистка хранилища в Dataverse:

Очистка хранилищ в сфере финансов и операций:

Емкость хранилища:

  • Последнее обновление: