В каких случаях лучше использовать NoSQL, а в каких SQL?

Question

[source2003]

Пользовался NoSQL и SQL, почувствовал разницу, но до сих пор не могу понять в каких проектах какую БД лучше использовать.
Был бы признателен за ссылку на статью или развёрнутый ответ, чтобы в будущем я мог при проектировании проекта сразу определится с выбором базы данных.

Answer 1

[Клёвый Админ]

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

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

Comments

[source2003]

Спасибо за развёрнутый и понятный ответ.

А что если мне очень хочется использовать NoSQL, чтобы получить побольше опыта, а таблицы более-менее связаны между собой, следовательно описывать связи я буду выше, не проиграю ли я в производительности? Или проиграю, но совсем незначительно?

[Клёвый Админ]

source2003: проиграть в производительности системы по сравнению с классическим SQL с одним активным master'ом очень сложно =) а вот проиграть в скорости разработки можно и существенно =)

[source2003]

Евгений Быченко: Понял, спасибо еще раз)

[Клёвый Админ]

source2003: совсем забыл. Не забывайте про индексы в таблицах. Логика их организации лежит на плечах программиста, когда как в SQL (некоторые реализации) делают индексы сами (или же они легко настраиваются). Потому поисковые операции по NoSQL таблицам могут проигрывать аналогичным на SQL именно из-за не оптимальности или отсутствия индексов.

Лучше советуйтесь о выборе типа БД исходя из конкретной задачи с человек погружённым в предметную область.

Answer 2

[Станислав Макаров]

Вот вам развёрнутый ответ.

Пользовался NoSQL и SQL

Не могли вы пользоваться NoSQL, вы пользовались какой-то конкретной моделью данных и конкретной СУБД.

какую БД лучше использовать

Ни NoSQL ни SQL это ни БД, ни СУБД.

Был бы признателен за ссылку на статью или развёрнутый ответ, чтобы в будущем я мог при проектировании проекта сразу определится с выбором базы данных.

В формате "ответ на Тостере" невозможно сравнить существующие сейчас модели данных и уж тем более дать советы по выбору СУБД. Начните с другого: оставьте историко-маркетологический термин "NoSQL" в стороне и начните с рассмотрения реальных моделей данных и их популярных реализаций:
- колоночная СУБД;
- хранилище "ключ-значение";
- документно-ориентированная БД;
- графовая БД;

Comments

[source2003]

Спасибо за полезные ссылки.

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

[Станислав Макаров]

source2003 вы работали с конкретными СУБД, а не с СУБД "NoSQL" и "SQL". Было бы логично указать, с чем вы работали. Если SQL-базы еще более менее похожи друг на друга, то по термину "NoSQL" вообще непонятно, что вы делали - то ли в Монге хранили JSON-документы, то ли пользовались time-series базами, то ли кэшировали запросы в каком-нибудь Redis. Вот это я вам и хотел сказать. Тут одних key-value СУБД столько уже, что целую таблицу можно составлять, не говоря уже о других базах под грифом "NoSQL"

Если слегка преувеличить, ваш вопрос звучит как "Я пользовался стулом (SQL) и другой мебелью (NoSQL). Почувствовал разницу, но до сих пор не могу понять, когда лучше пользоваться стулом, а когда - прочей мебелью". Слишком уж много всего входит в понятие "прочая мебель".

Answer 3

[Евгений]

NoSql это только какие-нибудь логи хранить, всё остальное для веба обычно имеет реляцию.

Comments

[Клёвый Админ]

очень спорно =))

Answer 4

[sim3x]

Используй постгрес
PostgreSQL — свободная объектно-реляционная система управления базами данных (СУБД)

И не морочь нам голову

Если у тебя на проекте заведется менеджер, которому понадобилась монга, на проект, больший чем сайт-визитка / лендинг, то советую потихоньку искать работу, тк проект завалят

Answer 5

[romy4]

NoSql можно кеш страниц или чего-то готового

Comments

[Клёвый Админ]

эээмм, ооочень спорно =) А вот если я захочу документы похранить, например?

[romy4]

Евгений Быченко: что спорно?

[Клёвый Админ]

romy4: спорное утверждение, не описывающие что же всё таки можно хранить в NoSQL, а что нет. А если у меня что-то "не готовое" я не могу его положить в Nosql? Вот это и спорно.

[romy4]

Евгений Быченко: нет. вы можете хранить там все, что захочется. но лишь в немногих случаях это принесёт пользу, а не головную боль

[Клёвый Админ]

romy4: Роман, головная или иная боль - это трудозатраты. Вопрос лежал в области применимости. Если отвечать на него, то NoSQL применим там же где применим любой другой подход к хранения данных. Ваше же изначальное утверждение говорит о том, что данная технология (или набор технологий, подход, наывайте NoSQL как угодно) применим лишь, цитирую "кеш страниц" и "чего-то готового", что звучит как минимум странно. Я бы посоветовал изучить матчасть. https://www.google.ru/search?ie=UTF-8&hl=ru&q=%D0%...

[romy4]

Евгений Быченко: мне безразлично. я бы не применял это ни для чего иного, кроме документов, потому что реляционную логику эмулировать в своём коде — изначально ущербная идея как по производительности, так и чревата багами. А всё равно все веб проекты сводятся к реляционной логике.

веб проекты не используют map/reduce (кроме редких извращений), а специализированные задачи по анализу данных не относятся напрямую к веб проектам, и к данному топику

[Клёвый Админ]

romy4: у скуля есть жесткие ограничения по производительности на запись. Если вы с ними не сталкивались - это хорошо, но ваша практика - это не вся разработка, не весь софт и не все области применения. Бывают задачи (например diadoc.ru) где на реляционной БД вообще никак.

[romy4]

> у скуля есть жесткие ограничения по производительности на запись.
та не раз. но дело всегда решается оптимизацией записи. рефакторинг из статуса сделано рукожопо в стасус сделано красиво. плюс кластеризация.

@ifaustrue> так diadoc.ru — это ж документы
> я бы не применял это ни для чего иного, кроме документов

у нас nosql применяется в бигдата

[romy4]

Евгений Быченко ответ выше

[Клёвый Админ]

romy4: а расскажите мне как вы кластеризируете на запись? Очень интересно было бы взглянуть. Вы придумали хитрый алгоритм active\active мастера?

>>@ifaustrue> так diadoc.ru — это ж документы
Нуууу, ну наверное это можно так назвать, но вообще то это хитрый xml =) Плюс так то там вся логика не только в том чтобы xml' ечки из папки в папку перекладывать, в общем видимо раз вы не в никли в сайт, то и рассказывать безсмысленно.

В общем если вам нечего сказать про тему шардирования записи, то и разговор бессмысленный получается. Видимо мы с вами по разному погружены в тему и технологии.
Да и баг дата, я бы на вашем месте употреблял осторожно. Если они у вас реально дата, это ещё не значит что биг.

[romy4]

Евгений Быченко: вы занимаетесь быстрой выборкой данных, я по большей части аналитикой, так что да, в разные темы и разный стек технологий.