Почему NOSQL БД становятся популярными?
=========================================

 Поделитесь соображениями, что даёт переход с SQL(postgress, sqllite, db2,oracle) на NOSQL.  

Мотивы мне непонятны.Я вижу один только вред. 

 NOSQL БД не становятся популярными, а занимают свою нишу.   

  

NOSQL никогда не заменит реляционные SQL. Есть направления, в которых NOSQL эффективны, и есть другие направления, в которых SQL эффективна. Сейчас идёт процесс перераспределения сфер применения этих решений. 

 А почему они становятся популярными: они PRят себя (NoSQL компании как CouchBase, MemDB и т.п.), устраивают мероприятия (каждую неделю в Santa Clara какая-нибудь NoSQL конференция), но по-моему, немного «раздувают». И сейчас, как я вижу, это уже стало небольшим трендом. Но интересно, что до последнего момента Oracle очень консервативно не поддерживал NOSQL(прям как Microsoft с HTML5), а буквально полгода назад они обьявили на конференции в Сан Франциско(open world), что за NoSQL будущее. 

 У SQL серьезные проблемы с действительно большими проектами: они очень тяжело кластеризуются как раз из-за реляционности.   

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

  

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

  

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

 Скорость, устойчивость к SQL-injection. 

 SQL -реляционная БД. У них есть проблема с работы с очень большими объёмами данных при высокой нагрузке. Вот вроде и NOSQL будет решать подобные проблемы в том числе. 

 Могу оценивать со стороны MySQL и MongoDB. Помимо [комментария](http://habrahabr.ru/qa/17012/#answer_70279) выше, так хочу добавить, что MySQL очень медленно развивается в горизонтальном масштабирование. В монге же наоборот, это их сильная сторона — удобный, продуманный [шардинг](http://www.mongodb.org/display/DOCS/Sharding+Introduction#ShardingIntroduction-ArchitecturalOverview) с failover репликацией в формате [Replica Set](http://www.mongodb.org/display/DOCS/Replica+Sets). Это основной упор в высоконагруженных проектах.   

Так же монга работает на js движке и всякие процедуры писать на много проще нежели в MySQL.   

У монги самый адекватный и удобный PHP драйвер по сравнению с mysql, mysqli, pdo.   

И да, инъекцию не реально сделать в монге из-за её формата BSON и адекватного драйвера (если, конечно, у вас весь запрос не берётся из урлы, например).   

Так же важным плюсом в монге — её курсоры, которые действительно курсоры, а не имитация как в MySQL. Они (курсоры) действительно шагают по записям тогда когда поросят и могут жить столько сколько попросят, в мускуле, как правило, же всё сразу выгружается в память (поправьте меня, если это проблема драйверов).  

Простота в использовании монги доставляет и подкупает.  

  

Но есть «ложка дёгтя». У монги нет join-ов (хотя это может быть плюсом). И она ооочень прожорлива (дискового пространства). У неё операции над группировкой делается через map reduce, что не очень просто. 

 SQL базы данных затачиваются под универсализацию, те стараются предоставить разумный компромисс мжду скоростью записи и чтения. Это удовлетворяет потребности большинства энтерпрайз приложений, так как паттерн их использования как раз и заключается в «пописали/почитали». Плюс sql базы стремятся предоставить защищенноть данных, следуя принципам ACID, что опять же является критичным для ентерпрайза.  

  

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

 К примеру, многие разработчики предпочитают ORM (Object-relational mapping). NoSQL база (не любая, конечно) предоставляет нативный интерфейс для этой модели, ликвидируя осложнения от реляционной прослойки. В том числе для объектов с нефиксированным набором свойств. Из-за этого упрощается приложение, увеличивается производительность и облегчается шардинг. Естественно, NoSQL не является абсолютной панацеей и заменой SQL, но в некоторых решениях имеет более высокую эффективность и удобство, поэтому и находит там своё применение. 

 В некоторых случаях использование SQL базы — overkill. Например если надо держать много «плоских» данных, с которыми если не проще, то быстрее работать курсорами, нежели запросами.  

  

Или переход от ORM к объектно-ориентированным БД. получается несколько проще и логичнее, нежели отслеживать соответствие диаграммы классов с схемой БД. Миграции не панацея. 

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

основная особенность — *много* (очень) *простых* запросов. их надо выполнять быстро. значит  

1) все держим в памяти  

2) отказываемся от языка запросов, убираем расходы на парсинг и кэши планов, оптимизацию  

3) отказываемся от ACID  

  

получаем то то получаем — IN MEMORY молотилку запросов.