🌚 Не только реляционные, но и NoSQL: как мы используем MongoDB
Вообще, основная БД на проекте у на PostgreSQL 👩💻 ("Surprise Motherfucker", кто бы мог догадаться?), однако для пары сервисом у нас также подключена MongoDB 👩💻, там у нас всего несколько таблиц коллекций и в частности у нас там хранятся данные по парковкам.
Кратко про отличия:
🟡PostgreSQL (реляционная модель): Данные структурированы, разложены по таблицам со строгой схемой. Связи между таблицами обеспечиваются внешними ключами. Работа строится на языке SQL и операциях JOIN.
🟡MongoDB (NoSQL): Данные хранятся в виде гибких JSON-подобных документов в коллекциях. Схема может быть динамической, нет строгих связей, упор делается на вложение данных и денормализацию (кстати, про нормализацию у меня был пост вот тут, кому интересно).
В чем преимущество хранения данных в MongoDB? Прежде чем отвечать на этот вопрос, хочется уточнить, что определенная модель данных для парковок у нас есть и в Postgre, но конкретно в рамках данного микросервиса, который интегрируется с одним открытым API с данными о парковках, удобнее было сделать Mongo:
1️⃣ Все данные — это фактически просто JSON, практически в том же виде, в каком мы получаем данные по API;
2️⃣ Легкое моделирование иерархических данных: структура типом парковки, адресом и координатами в рамках одного документа. В реляционной БД соответственно потребуется несколько таблиц, которые нужно будет джоинить;
3️⃣ Производительность при чтении. Это пункт, вытекающий из предыдущего. Для получения всех данных о парковке мы делаем один запрос по _id;
4️⃣ Встроенная геопространственная поддержка. Легко работать с GeoJSON (вообще в Postgre тоже можно и это не сложно с помощью расширений, таких как PostGIS, но я все-таки добавлю это в плюс для Монги). В рамках одной фичи я вообще хотел бы тут реализовать определение отношения координаты к обрасти (полигону координат) через 2dsphere для MongoDB, но это пока планы на будущее;
5️⃣ Шардинг из коробки: возможность горизонтального масштабирования за счет шардирования без дополнительных активностей.
Конечно, использовать везде MongoDB не получится и реляционные БД еще долго будут оставаться основным способом хранения данных. Недостатки NoSQL модели (конкретно Монги):
1️⃣ Отсутствие Join. Да-да, я чуть выше указал, что нам не нужно использовать джоины в Монге ввиду некоторых ее преимуществ... Но иногда почти всегда они все-таки нужны, чтобы связывать данные из разных таблиц. Тут же, чтобы связать данные из двух коллекций, нам нужно будет сделать два отдельных запроса;
2️⃣ Избыточность данных. С одной стороны, здорово, что все данные об одной парковке у нас в рамках одной записи, с другой стороны в рамках каждой записи у нас есть, например, информация о категории парковки.
3️⃣ Всякие технические ограничения в виде проблем с консистентностью, ограничением транзакций, неполной поддержкой ACID. Все это делает Монгу недопустимой к использованию во всяких бухгалтерских, финансовых, платежных и других требовательных к транзакционности системах (объединил все в один пункт, чтобы не писать много).
Попробую сделать какой-нибудь вывод: MongoDB отлично подходит для определенных сценариев (Каталоги, Документ-ориентированные данные и т.д.), но важно понимать ее ограничения и правильно оценивать требования проекта.
#SystemAnalysis #БазыДанных #MongoDB #PostgreSQL #NoSQL #Архитектура #BusinessAnalysis #системныйанализ
Вообще, основная БД на проекте у на PostgreSQL 👩💻 ("Surprise Motherfucker", кто бы мог догадаться?), однако для пары сервисом у нас также подключена MongoDB 👩💻, там у нас всего несколько таблиц коллекций и в частности у нас там хранятся данные по парковкам.
Кратко про отличия:
🟡PostgreSQL (реляционная модель): Данные структурированы, разложены по таблицам со строгой схемой. Связи между таблицами обеспечиваются внешними ключами. Работа строится на языке SQL и операциях JOIN.
🟡MongoDB (NoSQL): Данные хранятся в виде гибких JSON-подобных документов в коллекциях. Схема может быть динамической, нет строгих связей, упор делается на вложение данных и денормализацию (кстати, про нормализацию у меня был пост вот тут, кому интересно).
В чем преимущество хранения данных в MongoDB? Прежде чем отвечать на этот вопрос, хочется уточнить, что определенная модель данных для парковок у нас есть и в Postgre, но конкретно в рамках данного микросервиса, который интегрируется с одним открытым API с данными о парковках, удобнее было сделать Mongo:
1️⃣ Все данные — это фактически просто JSON, практически в том же виде, в каком мы получаем данные по API;
2️⃣ Легкое моделирование иерархических данных: структура типом парковки, адресом и координатами в рамках одного документа. В реляционной БД соответственно потребуется несколько таблиц, которые нужно будет джоинить;
3️⃣ Производительность при чтении. Это пункт, вытекающий из предыдущего. Для получения всех данных о парковке мы делаем один запрос по _id;
4️⃣ Встроенная геопространственная поддержка. Легко работать с GeoJSON (вообще в Postgre тоже можно и это не сложно с помощью расширений, таких как PostGIS, но я все-таки добавлю это в плюс для Монги). В рамках одной фичи я вообще хотел бы тут реализовать определение отношения координаты к обрасти (полигону координат) через 2dsphere для MongoDB, но это пока планы на будущее;
5️⃣ Шардинг из коробки: возможность горизонтального масштабирования за счет шардирования без дополнительных активностей.
Конечно, использовать везде MongoDB не получится и реляционные БД еще долго будут оставаться основным способом хранения данных. Недостатки NoSQL модели (конкретно Монги):
1️⃣ Отсутствие Join. Да-да, я чуть выше указал, что нам не нужно использовать джоины в Монге ввиду некоторых ее преимуществ... Но иногда почти всегда они все-таки нужны, чтобы связывать данные из разных таблиц. Тут же, чтобы связать данные из двух коллекций, нам нужно будет сделать два отдельных запроса;
2️⃣ Избыточность данных. С одной стороны, здорово, что все данные об одной парковке у нас в рамках одной записи, с другой стороны в рамках каждой записи у нас есть, например, информация о категории парковки.
3️⃣ Всякие технические ограничения в виде проблем с консистентностью, ограничением транзакций, неполной поддержкой ACID. Все это делает Монгу недопустимой к использованию во всяких бухгалтерских, финансовых, платежных и других требовательных к транзакционности системах (объединил все в один пункт, чтобы не писать много).
Попробую сделать какой-нибудь вывод: MongoDB отлично подходит для определенных сценариев (Каталоги, Документ-ориентированные данные и т.д.), но важно понимать ее ограничения и правильно оценивать требования проекта.
#SystemAnalysis #БазыДанных #MongoDB #PostgreSQL #NoSQL #Архитектура #BusinessAnalysis #системныйанализ