@Satangelus

NoSql vs Реляционные СУБД. Как правильно выбрать СУБД, чтобы потом не было мучительно больно?

В рамках проекта выбираю СУБД.В начальной стадии проекта предполагается хранение данных документов, что по идее склоняет чашу весов в пользу NoSQL, но потом появится немножко математики, обороты, остатки и т.д. В дальнем прицеле веб-сервис, который будет синхронизироваться с приложением.

Что лучше выбрать, что потом не было мучительно больно в доработке(разработке)? Реляционные таблицы или NoSql?
а) для декстопа?
б) для сайта?
  • Вопрос задан
  • 125 просмотров
Пригласить эксперта
Ответы на вопрос 4
inoise
@inoise
Solution Architect
Пока у вас нет хайлоада - выбирайте то что знаете лучше. Поверьте, лучше работать с привычным иструментом, чем набивать шишки в новом
Из моих предпочтений:
- Если у вас предполагается структуризация данных и связи то SQL без вариантов
- Если у вас базовые аналитические запросы то SQL, но если данных станет овердофига то посмотрите на NoSQL ColumnBased
- Для кэшированных данных NoSQL Key-Value
- Если у вас микросервисная архитектура то я бы советовал смотреть больше на NoSQL DocumentType
Ответ написан
POS_troi
@POS_troi
СадоМазо Админ, флудер, троль.
данных документов

Вы-же понимаете что это очень размытое понятие? То что в той-же монге оперируют сущностью "документ" это ещё ни очём не говорит для принятия решения в пользу монги :)

В том-же постгресе уже давно завезли JSONb и там можно математику.

Для себя изучал этот вопрос и то-же смотрел в сторону NoSQL БД, у меня данные в которых в принципе много неизвестных типов и их количество (финансовая аналитика), в результате натянул это всё на реляционную модель.
А вот в чём NoSQL сгодилась, так это как кэш аналитических итогов - что-бы не грузить постгрес одними и теми-же запросами.
Ответ написан
@AlexHell
Юзайте SQL базу с которой знакомы, т.е можете конфиг настроить, подтюнить, производительность замерьте и все будет быстро. На счет NoSQL - вообще сомнительная наработка как по мне, все можно в SQL, с prepared statement если на парсинг SQL времени много (только по рез-там тестов).
Ответ написан
@stratosmi
https://youtu.be/SNzOZKvFZ68
Подробно разжевано на конкретном примере Postgres vs Mongo, когда есть преимущество у NoSQL, а когда у реляционных.
В частности JSONB (с автоматической индексацией) в PostgreSQL дает куда как лучший способ хранения документов, чем у Mongo, при этом без требований наличия обязательной схемы данных, которую требует обычно реляционная СУБД.
Полнотекстовый поиск также имеется в реляционных.

Таким образом, остается, что у NoSQL есть только 2 достоинства:

1) Когда структура данных крайне простая, типа key-value. То нечего городить этот сложный огород, что в РСУБД.
2) Когда у вас имеются десятки реплицирующихся серверов. NoSQL с их нестрогой консистентностью eventually "когда-нибудь потом все наши реплецирующиеся будут содержать одинаковую информацию" - реплицируется проще с учетом указанного ограничения.

Соответственно РСУБД имеют преимущества:

1) Строгость обработки транзакций. В том числе и на кластере из многих серверов. Чего NoSQL как правило недоступно, собственно потому NoSQL и быстрее.
2) Скорость работы, если все ваши данные тщательно описаны и входят в схему.

Вывод:

На 1-2-3 серверах реплицирующихся (не путать с шардингом) PostgreSQL вполне себе отлично работает. Плюс дает надежность.
На 50 серверах реплицирующихся (горизонтальное масштабирование на огромном проекте) - куда как проще будет работать NoSQL.
Ответ написан
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через TM ID
Похожие вопросы