SQL — гибок или почему я боюсь NoSQL

Насчет индексации — есть доля правды. Если в SQL — все более-менее понятно, то в MongoDB — для меня это все ещё частично магия в стиле — а что получится если… :)

Второй недостаток — отсутствие классических транзакций.

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

Интересно, а Armin читал docs.mongodb.org/manual/core/indexes/#index-sub-document?

Утверждение про отсутствие схем полубредовое. Везде, где авторы монго говорят о проектировании БД, они говорят о схемах и о том, что их нужно сперва продумать, прежде чем что-то делать. Разница с SQL только в том, что это добровольное дело. Но если человек дурак, он и в MySQL всё в строку запихает.

Совсем же недавно был курс m101 где все описанные здесь проблемы были разжеваны, даже в картинках.

opening a can of worms = разворошить осиное гнездо

Ваш заголовок не соответствует заголовку оригинала и меняет смысл всего опуса. Автор не боится, он просто рассуждает о преувеличено гибкости некоторых постулатов nosql.
Бояться ничего не надо, нужно просто думать что делаешь, а не слепо верить в серебряную пулю.

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

Сейчас в текущем приложении в тестовой ветке используется аж четыре способа хранения:
— SQL (MySQL) с жесткой схемой, которая, утрируя, может изменяться пользователями через веб-морду (добавление новых атрибутов и типов)
— SQL с сериализованными и частично денормализованными средствами приложения полями
— NoSQL (CouchDB) с сильной денормализацией и активным использованием map/reduce
— Нормализованный NoSQL, где «джойны» и агрегация осуществляются средствами приложения

У всех способов свои недостатки и преимущества. Склоняемся к третьему, но далеко не однозначно.

И такое ощущение, что половина заметок создает культ из какой-то технологии, другая — пытается объяснить, что не стоит этого делать.

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

Ну, как известно, по большому счету NoSQL = NoACID. Этим многое объясняется. Не для всех это подходит.

Странным показалось про индексы: такое ощущение, что люди брались за NoSQL, не читая про основные плюсы/минусы этого подхода, а теперь удивляются «оказывается тут с индексами как-то сложно».

Наконецто первая толковая статья, которая трезво определяет место NoSQL, без лишнего хайпа. Вам жирнейший плюс за перевод.

Я лююблю сравнивать реляционные базы данных с UNIX. Обе технологии — долгожители, пережиили не одно поколение смены других технологий и все еще имеют широкое применение. Причниа этого — настолько же банальна, насколько и проста, изза чего многие падкие на новое и блестящее любят вытирать об них ноги. Причина эта в вашем заголовке — гибкость.

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

Аналогично с БД, только уже на уровне данных. Таблицы — это ваша «файловая системв», а язык SQL — ваши sed, awk, ls, cp итд. NoSQL — это «специальная программа под конкретную задачу». Поэтому каждое NoSQL решение полезно вам в тех случаях, которые подходят под определенный круг задач. Шаг влево, шаг вправо — вам нужна еще одна специальная утилита для каждой новой конкретной задачи, в то время как SQL и логичная схема дают вам универсальный инструмент.

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

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

Если кому то интересны еще «неправославные» аналогии, — такое же место у XML vs JSON. XML — универсальный расширяемый текстовый формат, находящий применение буквально везде и применимый буквально ко всему. JSON — специализированное решение, упрощенный формат под конкретные задачи представления обьектов, где не требуется строгая валидация.

Вся идея в том, что NoSQL — это не «Not SQL», как думают многие, а «Not only SQL », то есть SQL используется только там, где реально нужен ACID, например в финансовых расчетах.

Для некоторых задач NoSQL действительно хороши, но я бы позиционировал их не как «без схемы», а с «гибкой схемой».
Как правильно заметил автор, схема есть всегда, но она гибкая и находится в уме.

Лично мне не хватает в MongoDB утилитки для проверки логической связности базы по заданной гибкой схеме. Иногда хочется проверить что мои джуниоры ничего не начудили в тестовой базе. Интересно, а как другие пользующие MongoDB проверяют консистентность данных, или просто верят в то, что все окей?
Пока же в планах в конце весны заняться этой темой, если никто раньше не напишет конечно.

Молодец, Автор очень последователен. И хорошо отлавливает ОБратную связь ))

В основе SQL лежит реляционная алгебра, потому-то SQL серверы разогнали все предки NoSQL баз данных в 70-х.
Какая алгебра лежит в основе NoSQL баз данных?

Отличная статья, но я бы добавил бы ещё один пункт — всё это многообразие NoSQL-решений появилось по большей части на волне массовой истерии крупных highload-стартапов. То тут, то там в блогах читаешь, что вот мол Facebook разработали Cassandra специально под свои нужды, начали использовать, и сразу все стало хорошо! Или же вот Foursquare — активно используют MongoDB, и тоже все у них круто, все масштабируется на 5+, одолели highload и т.п. Ну блин, ребята, вы же не Facebook и не Twitter. 90% проектов в сети прекрасно работают банально на одном сервере с использованием самой банальной РСУБД аля MySQL или PostgreSQL и даже в ус не дуют. Просто РСУБД — это проверенные временем средства, многие из которых активно разрабатываются и используются чуть ли не два десятилетия. В интернетах десятки обмусоленных тем по поводу различных подводных камней, кучи туториалов, миллионы утилит для разного рода диагностики и логирования, патчи от сторонних разработчиков и т.п. Где все это в NoSQL? РСУБД — это своего рода «швейцарский нож», при помощи которого можно сделать что угодно и как угодно. Про NoSQL же ИМХО имеет смысл задумываться, когда проект уже сформирован, прекрасно работает, и встает вопрос об оптимизации, и уж никак не заместо РСУБД, а вкупе с ними.
P.S. MongoDB, кстати, довольно неплохая штука, подводных камней конечно куча, и распиаренный шардинг с репликацией на деле получаются далеко не такими простыми, как в документации. Но, на мой взгляд, через пару лет MongoDB скорее всего займет свою определенную нишу

Переведённый автор предполагает, что SQL всегда означает строгую типизацию.

На практике существует библиотека SQLite, служащая живейшим исключением из этого правила, и одновременно несказáнно популярная.

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

На прошлом Хайлоаде (2011) один из докладчиков высказывал похожие тезисы,
одним из его тезисов был: «новомодные NoSQL системы еще не проверены временем и есть риск наткнуться на подводные камни, решение которых потребует не запланированных ресурсов»

я использовал и МонгоДв, редис и Тарантул в своих проектах. Да, с каждым из них каждым из них натыкался на какие-то нерешенные проблемы, которые со временем решались. Со старым добрым проверенным SQL, тоже бывают свои проблемы. Только они, в силу более развитого коммунити выевляются и решаются гораздо быстрее.

новые, альтернативные системы хранения информации нужны, и у них есть и будет своя ниша использования. SQL нужен там, где он нужен… одно не должно подменять другое. Биллинг я ни когда не буду писать на МонгоДБ, а для простой и быстрой отдачи контента, не буду использовать MySQL.

Подумал что писал Мицгол, когда увидел режущее слух НРБД. Ну почему бы не писать везде NoSQL?

Имхо народ просто не врубается в основной тезис статьи, И он отнюдь не в том что SQL хуже или лучше NoSQL а в том что для начала проекта, когда многие сущности в процессе изменений SQL гибче. Успех NoSQL прошел на волне рефакторинга сформировавшихся проектов и если схема продумана и проверена, то сделать для нее NoSQL решение с оглядкой на HL очень продуктивно. В тоже время те же самые проекты, которые сделали рекламу NoSQL начинались на простых и известных решениях, в том числе и MySQL в качестве DB.

SQL позволяет как-то формализовывать схему данных, когда она непонятна до конца и решение можно поменять, если не кидать все в кучу. А уже после, когда функционал более менее сложился, когда данные естественно ложатся в схему, можно думать об оптимизации и подыскивать подходящее решение для масштабирования. Если проект выстрелил и вообще имеет смысл его масштабировать :)

В MongoDB наличие или отсутствие индексации меняет результаты выборки иногда

Пример бы посмотреть.

Такое может быть при использовании sparse индексов:

> db.test.insert({a:1, b:2, c:3})
> db.test.insert({a:2, b:3, c:4})
> db.test.insert({a:3, b:4})

> db.test.find({}).sort({c: -1})
{ "_id" : ObjectId("50e4205ce133536eb72229de"), "a" : 2, "b" : 3, "c" : 4 }
{ "_id" : ObjectId("50e42055e133536eb72229dd"), "a" : 1, "b" : 2, "c" : 3 }
{ "_id" : ObjectId("50e42062e133536eb72229df"), "a" : 3, "b" : 4 }

> db.test.ensureIndex({c:1}, {sparse : 1})
> db.test.find({}).sort({c: -1})
{ "_id" : ObjectId("50e4205ce133536eb72229de"), "a" : 2, "b" : 3, "c" : 4 }
{ "_id" : ObjectId("50e42055e133536eb72229dd"), "a" : 1, "b" : 2, "c" : 3 }