Какие преимущества у NoSQL?

Question

[ezayka]

Не могу понять. Ну если хочется, то сериализуй данные и храни в MySQL той же, как в Mongo DB...

Comments

[sim3x]

noSQL - memcahe, redis
NotOnlySQL - PostgreSQL

Простой совет - не используйте монгу

Answer 1

[stratosmi]

Преимущества и недостатки реляционной PostgreSQL vs MongoDB
https://youtu.be/SNzOZKvFZ68

Вкратце:
Преимущества PostgreSQL - полноценные транзакции, хорошо работает со сложными запросами.
Недостатки PostgreSQL - плохо работает при горизонтальном масштабировании на большом кластере.
Преимущества MongoDB - хорошо ведет себя при горизонтальном масштабировании , быстро работает на простых запросах.
Недостатки MongoDB - плохо поддерживает целостность данных в кластере, обеспечивает корректность данных не на любой момент времени не на любом сервере, плохо делает запросы по разного вида документам (разным таблицам)

Ранее у MongoDB было еще преимущество в schemaless, но с появлением JSONB у PostgreSQL этого преимущества у Монги больше нет.

Применять Монгу для неважных данных вторичной значимости, где нужно масштабирование по кластеру.
Применять PostgreSQL на важных данных (например, финансовых).

Comments

[ezayka]

а на практике. Если проект высоконагруженный, то использовать лучше монгу. Но если в проекте есть финансовые транзакции, то здесь уже SQL? Т.е. на практике реализуются проекты, в которых одновременно работают 2 подхода?

[bask]

ezayka, да.
Две БД разных типов часто используют, чтобы эффективно решать каждый тип задач теми инструментами, что лучше для этого подходят.
Критичные к целостности и не критичные по скорости выполнения решают реляционными БД. Не критичные к целостности, но критичные по скорости - нереляционными

[stratosmi]

ezayka,

Если проект высоконагруженный, то использовать лучше монгу.

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

[sim3x]

Преимущества MongoDB - хорошо ведет себя при горизонтальном масштабировании , быстро работает на простых запросах.

ага, хорошо https://events.yandex.ru/lib/talks/2325/

Answer 2

[Евгений]

Если кратко, то NoSQL - это все то, что не SQL. То, что не подходит под нотацию реляционной модели.

NoSQL решение может быть выгодно, когда нет необходимости следовать определеной схеме(таблицы, связи, типы данных и тд). Мы не думаем о предварительной настройке структуры, нормализации отношений; данные могут быть легче изменены, мигрированы и тд. Но взамен там появляются проблемы с ACID и прочими вещами, которые легче соблюдать в SQL - решениях.

Answer 3

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

Нет у них преимущества, они банально для других целей

Answer 4

[Алексей Черемисин]

Вообще-то noSQL бывает сильно разный, заточенный под совершенно разные задачи, которые очень плохо натягиваются на обычный SQL с его транзакциями, логированием, индексацией, и системой запросов.

Приведу несколько примеров, где noSQL выигрывает в разы. Причем, во всех задачах можно извратиться и на обычном SQL.

Представим задачу хождения по графам для анализа социальных взаимоотношений. На SQL мы получим пару десятков таблиц, или возьмем графовую базу данных.

Задача сбора и агрегации (обыкновенные счетчики) - можно взять и SQL, но обычно тут не нужны транзакции и связанные с этим накладные расходы, поэтому берем тарантул, редис или каффака.

Задача полнотекстового поиска по документам - решать ее на SQL, не очень приятное занятие, возьмем например солр/эластик/сфинкс.

Задача хранения объектов - на SQL ее тоже решать часть не с руки, особенно, когда структура самих объектов сильно расширяется. Возьмем монгу.

Задача хранения логов временных рядов с агрегацией - тут с SQL просто швах! Возьмем influxdb или clickhouse.

При этом, у SQL очень часто есть серьезный недостаток в масштабировании, что легко решается в noSQL.

Ах, да, очень часто ставят рядом и SQL и noSQL, и данные разбрасывают в разные базы по конкретным задачам.

Comments

[Antony Tkachenko]

Что-то мне кажется что вы сравнивание теплое с мягким (как минимум про полнотекстовый поиск)

[Алексей Черемисин]

Antony Tkachenko, все относительно. По отдельным полям таблицы в SQL проблем нет, но вот по всему документу сразу (по всем связанным полям нескольких таблиц)?!

Answer 5

[Decadal]

ну если так хочется то сериализуйте и храните)

инструменты одного и того же класса интересны тем, что решают одну и ту же задачу. И если вы использовали всегда один инструмент, то может быть непонятно, зачем все остальные.
Но, знаете, от того, что вы в наборе отверток используете чаще всего одну конкретную - все остальные не перестают быть нужными.
Mongodb используется для высоконагруженных проектов.