Чем именно, когда и где NoSQL-решения предпочтительнее традиционных SQL?

Question

[Jazzist]

Ищутся конкретные ответы на поставленный вопрос. Чтобы прувы и примеры хотя-бы достоверно прогугливались.

Дисклеймер — интересуют только свободные решения.

Спасибо!

Answer 1

[biduin]

Например при составлении сложных каталогов.
Представьте например каталог market.yandex.ru

Есть товар и есть его параметры. Привязывать всё ко всему — не целесообразно. Холодильникам ненужна цветность сканирования, а сканерам не нужен параметр количество сменных ножей.

В noSQL это делается элементарно. В RSQL все ненужные поля будут пустовать, либо будет «неповоротливая» сложная в обслуживании связь многие-ко-многим.

Comments

[Григорий Перетяка]

Тоже, интересует этот вопрос. А можно в таком NOSQL случае сделать выборку сканеров с определенной цветностью? Или все, что в базе представлено не SQL только ключ-значение?

[1nd1go]

@Peretyaka, строится индекс по сложному ключу типа {холодильник, цвет}, дальше по полученным ключам можно сократить выборку до зеленых холодильников

[Jazzist]

То есть вы хотите сказать, что внешние ключи «многие ко многим» с NoSQL делать чем-то удобнее, чем на SQL? А пример можете привести?

[1nd1go]

@Jazzist, имхо, там несколько другой подход. В Couch или Mongo вы тупо кладете описание вашего объекта с нужными полями. Далее делаете индекс по нужным полям. Если в объекте поля нету, то его не будет и в выборке. Join'ы делать туго, проще сделать стуктуру хранения объектов так, чтобы они не требовались.

Answer 2

[CKOPOBAPKuH]

мне больше sql-решения нравятся, но можно я отвечу?

1. нет sql оверхеда. чем меньше и проще запрос — тем больше влияние этого оверхеда. при тысячах запросов на выборку по PK большая часть процессорного времени расходуется как раз на это. смотрите, например, бенчмарки mysql+handlersocket или mongodb в сравнении с обычным mysql

2. нет необходимости в «реляционности», «таблицах», «строгой типизации». у разных nosql решений есть разные возможности, например, какие-то из них ориентированы на хранение не-униформных данных (что в sql решается добавлением таблицы «ключ объекта — id атрибута — значение атрибута»), какие-то позволяют хранить графы (и делать специфичные для задач на графах выборки и операции). посмотрите, например, на git или svn. оба они используют свои базы данных, не-sqlные, для своих специфических целей.

Answer 3

[afiskon]

MongoDB и Riak дофига где используются. Гуглите оффсайт, смотрите в описании логотипы компаний.

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

При этом однако нет никаких транзакций. Но можно поднять рядом PostgreSQL. Нужна транзакционность - фигачим в PostgreSQL, не нужна - фигачим в Riak кластер. В итоге нагрузка на PostgreSQL становится сильно меньше, что хорошо, так как РСУБД не очень хорошо масшабируются.