Блог

Я создаю доказательство концепции для микросервиса, который будет запрашивать базу данных Cosmos. Эта база данных будет содержать значительные объемы данных, отобранных из тысяч баз данных SQL. Каждая база данных SQL представляет собой сайт с a siteId , и каждая запись имеет a uniqueref (которая уникальна в пределах этого сайта, но не глобально). Идея Cosmos DB состоит в том, чтобы хранить документы, содержащие все биты данных, которые может запрашивать очень широкая функция поиска (я думаю, что есть что-то вроде 25 возможных условий поиска). Тем не менее, около 82% всех поисковых запросов выполняются в uniqueref одиночку (пользователю не нужно выбирать siteId , поскольку они уже будут эффективно авторизованы на своем собственном сайте и не смогут выполнять поиск на других). Это, наряду с другими 7 комбинациями терминов, охватывает около 97,5% всех поисковых запросов.

Причина, по которой мы рассматриваем Cosmos, заключается в том, что базы данных SQL велики, а их структура не является оптимальной, что означает, что эти поиски загружают 10 или даже 100 тысяч строк данных из нескольких таблиц, чтобы объединить их в памяти (принудительные внешние ключи не включены из-за неоптимальногопроектные решения) для возврата, возможно, только одной строки данных. К сожалению, мы не можем изменить базы данных SQL.

Я пытаюсь решить, что будет хорошим ключом раздела в Cosmos? uniqueref Не гарантируется, что он вообще глобально уникален, что означает, что он сам по себе бесполезен, если я правильно понял документы, поскольку у вас будут десятки тысяч логических разделов, в которых может быть от 1 до 3000 записей.

Объем данных на сайт сильно варьируется: у некоторых может быть относительное количество записей, возможно, пару тысяч или меньше, а у некоторых может быть 100 тысяч, поэтому siteId кажется, что точка доступа к физическому разделу ждет своего часа, как если бы у нас было 3000 сайтов, тогда это 3000 логических разделов, яподумайте, с очень переменными объемами данных в них, если я не неправильно понял, как возникают горячие точки

Другая возможность — синтезировать ключ, скажем, siteId из, и uniqueref , как я считаю, это популярный способ попытаться равномерно распределить данные. Во всех случаях мы можем включить siteId поиск, и в 82% случаев мы можем включить uniqueref , чтобы затем мы могли автоматически создавать и добавлять синтетический ключ. Оставшиеся 18% или около того запросов, вероятно, будут более требовательными к пропускной способности, но это, вероятно, все же лучше, чем очень значительные затраты ресурсов SQL Server, связанные с этими поисками. Проблема в том, что у меня, как у очень наглядного ученика, возникают проблемы с визуализацией того, как это будет распределять данные! Комбинация siteId и uniqueref , вероятно, будет не столько разбросом значений, сколько уникальными значениями.

Размер документа может варьироваться, но, вероятно, в среднем от 1,5 до 2,5 КБ. Я пока не знаю максимального количества документов на сайт, но оно все равно будет расти, и я не думаю, что мы пока достигли отметки в 4 миллиона для какого-либо одного сайта, что будет где-то около 10 ГБ для разделов. Я не уверен, насколько это влияет или должно влиять на мой выбор ключа.

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