Cosmos DB минимальные перегородки - PullRequest
Новая
       26

Cosmos DB минимальные перегородки

1 голос
/ 08 июля 2019

У нас есть сценарий IoT с Azure Event Hub в качестве нашей службы приема данных. Наша предлагаемая архитектура заключается в том, что у нас есть захват событий (окно = 15 минут) в EH, и в конце мы используем службы пакетной службы Azure для обработки захваченных данных.дневных / периодических интервалов в течение дня и затем хранить в холодильнике (капли / озеро данных).Мы также хотим иметь конвейер Event Hub -> Function App -> Cosmos DB, для мгновенных запросов, которые могут быть недоступны при подходе захвата событий (поскольку они не будут мгновенными). Что касается хранения cosmos db,мы планируем иметь ttl = 24/48 часов.Теперь проблема в том, что если мы выберем раздел с deviceId и выше ttl, мы не будем эффективно использовать этот раздел (максимум = 10 ГБ), и у нас будет несколько разделов, что повлияет на стоимость.Итак, мой вопрос заключается в том, какие другие стратегии (другие механизмы БД / разбиения) мы можем использовать для оптимизации (основная проблема - экономическая эффективность) хранения базы данных?

  1. Коллекция пробных одиночных разделов - бесполезно при переходе на устройства более высокого масштаба
  2. Разделение по времени (час / минуты), это будет означать модель предоплаты,что не желательно

1 Ответ

2 голосов
/ 08 июля 2019

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

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

  1. Количество разделов в базе данных Cosmos напрямую не влияет на ценообразование. Это косвенно влияет на это, потому что после того, как в вашей системе будет храниться МНОЖЕСТВО данных, Cosmos создаст больше физических разделов, которые в свою очередь имеют минимальное количество RU / s, необходимое для каждого из них.
  2. Размер данных так мало влияет на цену, что он незначителен.
...