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

Question

[Satangelus]

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

Что лучше выбрать, что потом не было мучительно больно в доработке(разработке)? Реляционные таблицы или NoSql?
а) для декстопа?
б) для сайта?

Comments

[d'Ivan]

А что представляет из себя "хранение данных документов", подробнее?

Answer 1

[Иван Шумов]

Пока у вас нет хайлоада - выбирайте то что знаете лучше. Поверьте, лучше работать с привычным иструментом, чем набивать шишки в новом
Из моих предпочтений:
- Если у вас предполагается структуризация данных и связи то SQL без вариантов
- Если у вас базовые аналитические запросы то SQL, но если данных станет овердофига то посмотрите на NoSQL ColumnBased
- Для кэшированных данных NoSQL Key-Value
- Если у вас микросервисная архитектура то я бы советовал смотреть больше на NoSQL DocumentType

Answer 2

[ТыжСисАдмин]

данных документов

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

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

Для себя изучал этот вопрос и то-же смотрел в сторону NoSQL БД, у меня данные в которых в принципе много неизвестных типов и их количество (финансовая аналитика), в результате натянул это всё на реляционную модель.
А вот в чём NoSQL сгодилась, так это как кэш аналитических итогов - что-бы не грузить постгрес одними и теми-же запросами.

Comments

[AlexHell]

Расскажите каким образом NoSQL как кэш вам сгодился, и для этого postgres (или любой другой SQL бд) не подошел? Допустим в postgres вы могли бы сделать спец таблицу с данными итогов, и кидать к нему запросы.. и даже если на разбор одних и тех же строковых SQL запросов по вашим тестам получилось бы - долго, всегда можно сделать prepared statement и сохранить его, и потом обращатьс ябез перепарсинга SQL. А для еще большей скорости кэша никакие NoSQL скорей не дадут прироста скорости больше чем InMemory (tarantool / или даже что самописное)

Answer 3

[AlexHell]

Юзайте SQL базу с которой знакомы, т.е можете конфиг настроить, подтюнить, производительность замерьте и все будет быстро. На счет NoSQL - вообще сомнительная наработка как по мне, все можно в SQL, с prepared statement если на парсинг SQL времени много (только по рез-там тестов).

Answer 4

[managrib]

Разжевано где у кого преимущества:
Postgres vs Mongo / Олег Бартунов