Я создаю доказательство концепции для микросервиса, который будет запрашивать базу данных Cosmos. Эта БД будет содержать значительные объемы данных, взятых из тысяч баз данных SQL. Каждая база данных SQL - это сайт с siteId, а каждая запись имеет uniqueref (это уникально на этом сайте , но не глобально). Идея Cosmos DB состоит в том, чтобы хранить документы, которые содержат все биты данных, которые может запросить очень широкая поисковая функция (я думаю, что есть что-то вроде 25+ возможных поисковых терминов). Тем не менее, около 82% всех поисковых запросов выполняются только uniqueref (пользователю не нужно выбирать siteId, поскольку они уже будут эффективно зарегистрированы на своем собственном сайте и не смогут выполнять поиск других). Это, наряду с еще 7 комбинациями терминов, охватывает около 97,5% всех поисков.
Причина, по которой мы смотрим на Cosmos, заключается в том, что базы данных SQL имеют большой размер и их структура скорее не оптимальна, что означает, что эти поиски загружают десятки или даже сотни тысяч строк данных из нескольких таблиц, чтобы объединить их в память (без принудительных внешних ключей является одним из неоптимальных проектных решений), чтобы вернуть, возможно, только одну строку данных. К сожалению, мы не можем изменить базы данных SQL.
То, что я пытаюсь решить, это то, что может стать хорошим ключом раздела в Космосе? uniqueref вовсе не гарантированно является глобально уникальным, то есть он сам по себе бесполезен, если я правильно понял документы, поскольку у вас будут десятки тысяч логических разделов, в которых может быть от 1 до 3000 записей. ,
Количество данных на сайт сильно варьируется: у некоторых может быть относительно небольшое количество записей, возможно, несколько тысяч или меньше, а у некоторых может быть сотня тысяч, поэтому siteId ощущается как горячая точка физического раздела, ожидающая своего появления как если бы у нас было 3000 сайтов, то это 3000 логических разделов, я думаю, с очень переменным количеством данных в них, если только я неправильно понял, как возникают горячие точки
Другая возможность - синтезировать ключ, скажем, из siteId и uniqueref, так как я считаю, что это популярный способ попытаться равномерно распределить данные. Во всех случаях мы можем включить siteId в поиск, а в 82% случаев мы можем включить uniqueref, чтобы затем мы могли безболезненно создать и добавить синтетический ключ. Оставшиеся 18% или около того запросов, вероятно, будут более требовательными к пропускной способности, но это, вероятно, все же лучше, чем очень значительные затраты ресурсов SQL Server, которые генерируют эти поиски. Проблема в том, что, как очень визуальный ученик, у меня возникают проблемы с визуализацией, как это будет распространять данные! Сочетание siteId и uniqueref, скорее всего, будет не столько разбросом значений, сколько уникальными значениями.
Размер документа может быть разным, но в среднем он может составлять от 1,5 КБ до 2,5 КБ. Я еще не знаю максимальное количество документов на сайт, но оно все равно будет расти, и я не думаю, что мы пока достигли отметки в 4 миллиона для какого-либо одного сайта, что будет где-то около 10 ГБ для разделов. Я не уверен, насколько это влияет или должно повлиять на мой выбор ключа.
Мой опыт работы с Космосом ограничен, поэтому я не уверен, как поступить. Должен ли я использовать уникальное значение, значение, которое имеет неравномерное распределение данных, или значение, которое может быть не уникальным, но может иметь огромный разброс значений?