Дизайн Схемы MongoDB - Много маленьких документов или меньше больших документов?
Фон
Я моделирую преобразование от нашей базы данных RDBMS до MongoDB. При денормализовывании кажется, как будто у меня есть два варианта, тот, который приводит ко многим (миллионы) меньших документов или того, который приводит к меньше (сотни тысяч) больших документов.
Если бы я мог бы дистиллировать его вниз к простому аналогу, это было бы различие между набором с меньшим количеством Клиентских документов как это (в Java):
class Customer {
private String name;
private Address address;
// each CreditCard has hundreds of Payment instances
private Set<CreditCard> creditCards;
}
или набор со многими, многими Платежными документами как это:
class Payment {
private Customer customer;
private CreditCard creditCard;
private Date payDate;
private float payAmount;
}
Вопрос
MongoDB разработан для предпочтения многих, многих маленьких документов или меньшего количества больших документов? Ответ главным образом зависит, на каких запросах я планирую выполнение? (т.е. Сколько кредитных карт делает клиента X, имеют? по сравнению с Каким было средней суммой все клиенты, заплаченные в прошлом месяце?)
Я озирался много, но я не спотыкался ни в какие лучшие практики схемы MongoDB, которые помогут мне ответить на свой вопрос.
1 ответ
Вам определенно нужно будет оптимизировать для запросов, которые вы делаете.
Вот мое лучшее предположение, основанное на вашем описании.
Вы, вероятно, захотите знать все кредитные карты для каждого клиента, поэтому держите массив из них в объекте клиента. Вы также, вероятно, захотите иметь ссылку клиента для каждого Платежа. Это позволит сохранить Платежный документ относительно небольшим.
Объект Payment автоматически будет иметь свой собственный идентификатор и индекс. Вероятно, вы также захотите добавить индекс в ссылку клиента.
Это позволит Вам быстро искать Платежи Клиента, не сохраняя каждый раз весь объект Клиента.
Если вы хотите ответить на такие вопросы, как «Какова была средняя сумма, которую все клиенты заплатили в прошлом месяце», вы вместо этого захотите карту / уменьшение для любого значительного набора данных. Вы не получаете этот ответ «в режиме реального времени». Вы обнаружите, что хранение «ссылки» на Клиента, вероятно, достаточно хорошо для этих сокращений карт.
Итак, чтобы ответить на ваш вопрос напрямую: Предназначена ли MongoDB для того, чтобы предпочитать много, много небольших документов или меньше больших документов?
MongoDB предназначен для быстрого поиска индексированных записей. MongoDB очень хорошо находит несколько иголок в большом стоге сена. MongoDB не очень хорош в поиске большинства иголок в стоге сена. Поэтому сопоставьте свои данные вокруг наиболее распространенных вариантов использования и напишите задания map/reduce для более редких вариантов использования.