Ключевой проблемой моделирования данных является балансирование потребностей приложения, характеристик производительности ядра базы данных и шаблонов извлечения данных. При разработке моделей данных всегда учитывайте использование данных приложением (то есть запросы, обновления и обработка данных), а также внутреннюю структуру самих данных.
Шаблон проектирования в целом - это абстрактное, многократно используемое решение часто встречающейся проблемы в данном контексте или варианте использования. Как разработчик моделей mongoDB вы должны знать эти концепции моделирования и использовать их в каждом проекте для конкретного варианта использования.
В этой статье я расскажу об общих проблемах, решаемых каждым шаблоном, а затем - внутри каждой концепции - исследую примеры и варианты использования, чтобы показать преимущества каждого решения моделирования.
Разделы:
- Шаблон атрибута
- Расширенный эталонный шаблон
- Шаблон подмножества
- Вычисленный шаблон
# 1 # Шаблон атрибута:
# Проблема:
Представьте, что у вас есть много продуктов, каждый из которых имеет свои собственные характеристики, учитывая следующие два продукта:
product1 : { "_id": ObjectId("5c5348f5be09bedd4f196f18"), "title": "", "date_acquisition": ISODate("2021-12-25T00:00:00.000Z"), "description": "", "brand" : "",color :"", size:"", "container":"", "sweetener":"" }product2 : { "_id": ObjectId("5c5348f5be09bedd4f196f18"), "title": "", "date_acquisition": ISODate("2021-12-25T00:00:00.000Z"), "description": "", "brand" : "",capacity:"", "input":"", "output":"" }
В приложении мы хотим иметь все продукты, в которых:
- емкость ниже 3000, а выход равен 5V
- или цвет красный
- или размер «100 x 70 x 50»
Чтобы сделать это быстрее, мы должны создать индекс по цвету, размеру, емкости и выходу; больше полей, больше индексов, таким образом, повторяющаяся задача может привести к беспорядку при масштабировании базы данных.
#Solution:
По этой причине «шаблон атрибута» предлагает сгруппировать эти поля в один массив пар ключ-значение.
В качестве примера применим этот узор к product2:
product2 : { "_id": ObjectId("5c5348f5be09bedd4f196f18"), "title": "", "date_acquisition": ISODate("2021-12-25T00:00:00.000Z"), "description": "", "brand" : "","specs" : [ { "k" : "capacity" , "v": "1000" }, { "k" : "output" , "v": "5V"}, { "k" : "input" , "v" : "..." } ]}
На данный момент можно создать только индексы на «specs.k» и «specs.v».
# Общие варианты использования:
- Шаблон атрибута хорошо подходит для схем с наборами полей, имеющими один и тот же тип значения, например списками дат.
- Это также хорошо работает, когда речь идет о характеристиках продуктов (пример выше). Некоторые товары, например одежда, могут иметь размеры, выраженные в малых, средних или больших размерах. Другие продукты той же коллекции могут быть выражены в объеме и т. Д.
# Заключение:
Шаблон атрибута упрощает индексацию и нацеливание на множество похожих полей в документе.
# 2 # Шаблон расширенной ссылки:
# Проблема:
Вам снятся кошмары о длинных и сложных SQL-запросах, выполняющих слишком много соединений?
Даже если вы перешли с реляционной модели с 10 таблицами в табличной базе данных на модель с 3 коллекциями в MongoDB, вы все равно можете выполнять множество запросов, которые должны объединять данные из разных коллекций.
Конечно, ваши запросы MongoDB нигде не будут такими сложными, как в SQL.
В мире больших данных все, что вы делаете слишком часто, может стать помехой для вашей работы.
# Решение:
А теперь пора представить шаблон отсутствия физических соединений.
Идея этого шаблона состоит в том, чтобы встроить отношения «один ко многим» с одной стороны или отношения «многие к одному» со стороны многих.
Чтобы решить, какая коллекция должна быть внутри другой, вы должны учитывать фокус вашего приложения при запросе вашей базы данных. Если фокус находится на стороне «Многие», вы должны перенести одну сторону на сторону «Многие».
Подсказка: вы можете расширить только ту часть, к которой вам нужно часто присоединяться.
Что ж, давайте возьмем пример приложения для электронной коммерции, в котором нам нужно объединить клиентов и их заказы, чтобы получить адрес доставки.
Применяя расширенный ссылочный шаблон, мы должны продублировать следующие атрибуты в коллекции заказов:
- страна
- город
- почтовый индекс
- улица
- Номер дома
В результате коллекция заказов теперь будет иметь объект Order_location с полями выше:
# Общие варианты использования:
- Расширенный эталонный шаблон используется в приложениях реального времени, где имеет значение одно физическое соединение.
- Также используется в приложениях для аналитики и каталогов.
# Заключение:
Решение свести к минимуму объединение и поиск в вашем приложении увеличивает его производительность, особенно когда повторяющиеся поля неизменяемы.
Подсказка: если повторяющиеся поля видоизменяются, вам следует обрабатывать обновления, и этот шаблон может не подходить лучше всего.
# 3 # Подмножество паттернов:
# Проблема:
MongoDB пытается оптимизировать использование ОЗУ, загружая в память только необходимые документы с диска через ОЗУ.
Когда свободной памяти больше нет, он удаляет страницы, содержащие документ, в котором он больше не нуждается, чтобы освободить место для дополнительных документов, которые нужно обработать в данный момент.
Этот механизм позволяет использовать аппаратную конфигурацию, в которой ОЗУ меньше общего размера данных на диске.
Пока размер вашего рабочего набора умещается в ОЗУ, вы получаете хорошую производительность.
Рабочий набор относится к объему пространства, занимаемому документами, и частям индексов, к которым часто обращаются.
Либо, если вы попадете в ситуацию, когда рабочий набор больше, чем ОЗУ, документы, которые нужны постоянно, могут не поместиться в памяти, поэтому сервер часто отбрасывает документы и выполняет обратную загрузку с диска.
Этот процесс постоянного извлечения документов, которые должны оставаться в памяти, - это плохо, очень плохо.
# Решение:
Чтобы справиться с этой проблемой, вы должны либо добавить больше ОЗУ, масштабировать с помощью сегментирования, либо уменьшить размер вашего рабочего набора.
Последнее решение может быть достигнуто путем рассмотрения шаблона подмножества, который фокусируется на разделении коллекции на 2 коллекции: наиболее и наименее используемую часть документа.
Мы можем уменьшить размер рабочего набора при обработке объединений в отношениях «многие-ко-многим» или «один-ко-многим», дублируя часто используемые атрибуты на наиболее часто используемой стороне (расширенный эталонный шаблон).
Простым примером может служить следующий документ из коллекции фильмов:
В большинстве случаев пользователи хотят видеть лучших актеров и лучшие отзывы, а не всех их. Идеальное решение - оставить только самые используемые поля и переместить другие в отдельную коллекцию:
# Общие варианты использования:
- Список отзывов или комментариев к статье.
- Список актеров в фильме.
# Заключение:
В результате применения шаблона подмножества наш рабочий набор будет быстрее извлекать дополнительные документы, поскольку они будут меньше, но тот факт, что вы разбиваете документы на две части и дублируете некоторую информацию, означает, что базе данных потребуется немного больше места на диске.
Однако это не большая проблема, так как это пространство намного дешевле оперативной памяти.
# 4 # Расчетный паттерн:
# Проблема:
Вы можете обнаружить, что повторяете одни и те же математические операции, операции сворачивания или разветвления, которые представляют собой своего рода вычисления / преобразования, если их повторение может привести к очень плохой производительности.
В системах с большими данными выполнение одних и тех же вычислений снова и снова очень дорого и требует большого количества ресурсов ЦП.
# Решение:
Решение состоит в том, чтобы выполнить вычисление и сохранить результат в соответствующем документе и коллекции. Если вам нужно повторить вычисления или вы хотите иметь возможность повторить их, просто сохраните их исходные коды.
В качестве примера мы хотим рассчитать общую сумму платежей, выполненных в нашем магазине с самого начала. Если вы считаете, что для вас достаточно агрегирования суммы в долларах, вам следует рассмотреть этот шаблон, чтобы избежать вычислений каждый раз, когда обрабатывается новый платеж.
Чтобы справиться с этим, мы добавим новую коллекцию вычислений (например, total_amount_payments), как только у нас будет новый платеж, мы должны обновить сумму внутри.
В этом случае операция записи лучше, чем чтение всех документов снова и снова.
# Общие варианты использования:
- Частые запросы фреймворка агрегации.
- IOT (Интернет вещей).
- Поиск событий.
# Заключение:
Вычисляемый шаблон позволяет снизить нагрузку на ЦП, когда приложение требует многократного вычисления данных.
Если вы дойдете до конца, надеюсь, вам понравилось это введение в мир шаблонов проектирования для MongoDB.
Все еще хотите узнать больше?
Вот несколько полезных ресурсов [ссылки ниже :)]
Ресурсы :
Https://university.mongodb.com/
Https://www.mongodb.com/blog/post/building-with-patterns-a-summary
Первоначально опубликовано на https: // brightshine.io 16 марта 2021 г.
