Разработка для изменения данных

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

Оптимизация производительности операций вставки, обновления и удаления

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

Следующие шаблоны в разделе "Шаблоны для разработки таблиц" позволяют оптимизировать производительность операций вставки, обновления и удаления.

Обеспечение согласованности хранимых сущностей

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

Следующие шаблоны в разделе Шаблоны для разработки таблиц предназначены для управления согласованностью.

  • Шаблон вторичного индекса внутри раздела — хранение нескольких копий каждой сущности с помощью различных значений RowKey (в одном разделе) для выполнения быстрых и эффективных операций поиска и активации альтернативных порядков сортировки с помощью различных значений RowKey.
  • Шаблон вторичного индекса в разных разделах — хранение нескольких копий каждой сущности с помощью различных значений RowKey в отдельных разделах или отдельных таблицах для выполнения быстрых и эффективных операций поиска и активации альтернативных порядков сортировки с помощью различных значений RowKey.
  • Шаблон для согласованных транзакций — обеспечение согласованного поведения в рамках границ раздела или границ системы хранения с помощью запросов Azure.
  • Шаблон сущностей индекса — поддержка сущностей индекса для выполнения эффективных операций поиска, возвращающих списки сущностей.
  • Шаблон денормализации — объединение связанных данных в одной сущности для извлечения необходимых данных с помощью одного точечного запроса.
  • Шаблон для рядов данных — хранение целых рядов данных в одной сущности для сокращения количества выполняемых запросов.

Сведения о транзакциях группы сущностей см. в этом разделе.

Использование эффективных запросов в разработке для эффективных изменений

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

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

  • Шаблон составного ключа — использование составных значений RowKey для предоставления клиенту возможности выполнять поиск связанных данных с помощью одного точечного запроса.
  • Шаблон для заключительного фрагмента журнала — извлечение n сущностей, недавно добавленных в раздел, с помощью значения RowKey , выполняющего сортировку по дате и времени в обратном порядке.