Блог

В настоящее время у меня есть пять контейнеров Cosmos DB, каждый из которых содержит ~ 800 тыс. документов (и растет). Размеры документов сильно различаются в диапазоне от 1 до 40 КБ. Пользователь использует базу данных очень мало, возможно, 200-500 запросов в день с использованием id primary key. Дизайн ключа раздела каждого контейнера — это, по сути, модуль идентификатора до 100 логических разделов.

Причина, по которой я не использую id в качестве ключа раздела, заключается в том, что существует несколько запросов между разделами. В частности, в одном контейнере выполняется около 100 запросов в день с использованием поля, для которого ключ раздела неизвестен. Кроме того, один контейнер индексируется ежечасно с помощью Azure Search, который ищет все измененные документы с помощью _ts . Кроме того, три контейнера участвуют в ежевечернем процессе (в разное время), с помощью которого каждый отдельный (частичный) документ загружается в процесс приема полностью отдельной системы, в которой изменения могут быть обнаружены и обновлены обратно в контейнер.

Краткое описание текущего макета контейнера:

 Container 1
- About 800K documents and partition key is 100 modulus of id
- About 200-500 lookups a day using id   partition key
- About 100 lookups a day using a field for which partition key is unknown
- Indexed hourly by Azure Search
- Nightly every partial document is downloaded and potentially upserted
 

 Container 2
- About 800K documents and partition key is 100 modulus of id
- About 200-500 lookups a day using id   partition key
- Nightly every partial document is downloaded and potentially upserted
 

 Container 3
- About 800K documents and partition key is 100 modulus of id
- About 200-500 lookups a day using id   partition key
- Nightly every partial document is downloaded and potentially upserted
 

 Container 4
- About 800K documents and partition key is 100 modulus of id
- About 200-500 lookups a day using id   partition key
 

 Container 5
- About 100K documents and partition key is 100 modulus of id
- About 200-500 lookups a day using id   partition key
 

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

Моя главная проблема заключается в том, что я хочу убедиться, что мои большие запросы сосредоточены только на разделах, содержащих интересующие документы. Каждый существующий контейнер уже распределен по 100 логическим разделам, и поскольку существующий запрос является контейнерным (он получает все документы) Мне не нужно было беспокоиться о разветвлении. Но теперь, если все контейнеры объединены, я хочу, чтобы запросы были нацелены только на те разделы, которые мне интересны, чтобы сканирование не касалось разделов, которые меня не интересуют. Единственными вариантами, о которых я думал до сих пор, являются:

 1) Keep the existing 100 logical partition design per "container" (namespace
   of documents) and have the queries use "IN" to target all 100 partitions.
- Unfortunately range like STARTSWITH on partition key will not prevent fan-out.
- Having so many partition keys in an "IN" clause may make the query very
  long and I don't know of the consequences of that. In my test it seems to work
  fine -- the query length just adds about 10 to 20 RUs onto the query.
- If there are no problems with large queries, this probably would just work
  fine and keep good performance.
 

 2) Have one logical partition per "container" (namespace of documents).
- Because of low usage performance is probably still acceptable.
- May exceed permitted document size per-container.
 

 3) Have two-ten logical partitions and have the queries use "IN"
- This makes the "IN" usage of #1 more palettable.
- Won't have the look-up performance of #1, but better than #2.
- Logical containers are still very large.
 

 4) Just deal with the fan out and having high-RU queries.
- Database may be unusable at some points during the night.
- The Azure Search _ts-based queries don't seem to have much impact on the
  performance.
 

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

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