MongoDB- Соединение ключа осколка с использованием трех значений

Question

Я создаю коллекцию, в которой хранится объект JSON с использованием MongoDB. Я застрял в части Шардинга. У меня есть идентификатор дела, идентификатор клиента и место для каждой записи в коллекции

Идентификатор случая - это 10-значное число (только номер и отсутствие алфавитов).

CustomerID - это комбинация имени клиента и идентификатора случая.

Местоположение - значение 2dsphere, и я ожидаю местоположение разных различных значений.

В дополнение к этому у меня есть имя клиента и описание случая к записи. Все мои поисковые запросы имеют критерии поиска: идентификатор случая, идентификатор клиента или местоположение.

Учитывая этот сценарий, могу ли я создать составной ключ на основе всех этих трех значений (CaseID, CustomerID и location). Я считаю, что это дает высокую мощность и легко извлекает записи.

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

Спасибо за ваше время и дайте мне знать, если вам нужна любая информация

Answer 1

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

Предполагая, что вы на самом деле нужно шард, ваш выбор ключа шарда должен быть основан на следующих критериях:

1. Cardinality - выбрать ключ осколка, который не ограничивается небольшим числом возможных значений , так что MongoDB может равномерно распределять данные между осколками в вашем кластере.
2. Напиши дистрибутив - выберите ключ осколка, который равномерно распределяет операции записи между осколками в кластере, чтобы ни один осколок не стал узким местом.
3. Query изоляции - выберите ключ осколка, который включен в ваши самые частые запросы, так что эти запросы могут быть эффективно перенаправлены на один целевой осколок, который хранит данные, в отличие от передачи на все осколки.

Вы упомянули, что все ваши запросы содержат идентификатор случая, идентификатор клиента или местоположение, но не описывали ваши варианты использования. В качестве примера давайте предположим, что ваши наиболее частые запросы к:

• извлечь случай клиента
• получить все случаи для данного клиента

В таком случае, кандидат ключ хороший осколок будет быть составным осколочным ключом (имя, caseID) в этом порядке (и соответствующий составной индекс).Учитывайте, соответствует ли это критериям вышеприведенный критерий:

1. Мощность - каждый документ имеет различное значение для ключа осколка, поэтому мощность отличная.
2. Пишущие распределительные шкафы для всех клиентов распределены по всем осколкам.
3. изоляции Запрос:
   • Чтобы получить конкретный случай, имя и caseID должны быть включены в запрос. Этот запрос будет перенаправлен на конкретный осколок, содержащий документ.
   • Чтобы получить все случаи для данного клиента, укажите имя в запросе. Поэтому этот запрос включает в себя префикс ключа осколка, а также будет эффективно маршрутизироваться только к конкретным осколкам (сторонам), которые содержат документы, соответствующие запросу.

Обратите внимание, что вы не можете использовать геопространственной индекс как часть ключевого индекса осколка (как описано here). Тем не менее, вы можете создать и использовать геопространственный индекс в закрытой коллекции, если используете другие поля для ключа осколка. Так, например, с помощью вышеуказанного ключа осколка:

• геопространственный запрос, который также включает имя клиента, будет ориентирован на соответствующие осколки.
• геопространственный запрос, который не включает имя клиента, будет передаваться по всем осколкам (запрос «разброс/сбор»).

Дополнительную документацию по ключевым вопросам осколков можно найти here.