SQL это когда запросы пишутся на SQL, а noSQL это когда запросы пишутся другим способом. Что не ясно?
Файловая система тоже БД, но к SQL не имеет отношения.
Ещё вопросы?

Идите-ка вы со своими базами в Development :)

А зачем спорить, если можно использовать их вместе правильно выбирая инструменты под задачи?

NoSQL это «модно» и «не такой как все». Этого достаточно.

Священная война же. Остаться должен только один!

Монго, редис и прочее не могут то, что может оракл. И наоборот. Например, редис не сможет скинуть БД на диск, размером в 256Гб (полное покрытие) на диск при ОЗУ в 256Гб. Надо покупать сервак на 512гб-1Тб ОЗУ.

Монго также сильно зависит от ОЗУ, но хуже всего, что монго не патчит 2-3х летние баги, хотя бабло им присылают некисло. К примеру, в прошлом? году они получили 140млн. баксов, для сравнения, гугл отчислял по 100 млн. мозилле в год. При этом кода в мозилке в разы больше...

На этом фоне, даже ленивые парни из оракла смотрятся намного лучше. Пока Ларри жив, оракл будет процветать и развиваться. А дальше? Дальше может придти Элоп, скинуть стоимость акций в 10-20 раз и продать оракл в Майкрософт.

Вкратце примерно так...

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

Иначе нормальная СУБД.

Я об этом и писал.

sql/nosql не имеет никакого отношения к хранению, но хипсторы в качестве nosql обычно предпочитают всякое eventual consistency непотребство. Для денежных применений, например для биллинга, это не годится, поэтому оракл будет жить вечно.

Спасибо, хороший ответ.

слова «аналитика» и «OLAP» для тебя это позы из камасутры

Я не знаю задач уровня выше гостевой книги, где слово «аналитика» лишнее. Реально не знаю. Весь мой опыт говорит о том, что в любой более-менее большой (не сложной даже, а просто большой) системе однажды появится необходимость в срезах, выборках, аналитике.

Это к модераторам.

По-моему, эта темка в «Разработка» не тянет.

Как насчет NoSQL OLAP?

Полтора метра колючей проволоки?

WAT?

Это объяснение мне тоже понравилось, господа:

А вы все NoSQL да NoSQL (комментарий)

Что получится, если скрестить ежа с ужом?

А области применения так и не были названы...

Это не еж и не уж, а две отдельных вещи. Идея OLAP не требует использования SQL

Нет, конечно, SQL это всего лишь инструмент. Вообще-то речь не об sql, а о реляционных бд.

Это как-то не по ЛОРовский.

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

Монго и редис к ним не относятся.

В конце концов, в Оракле тоже можно настроить уровни транзакционной безопасности, НЯП.

Если данные слабо структурированы или не структурированы вовсе, то их лучше хранить в nosql. Во всех остальных случаях алгебра Кодда к вашим услугам.

Если данные слабо структурированы или не структурированы вовсе, то их лучше хранить

в файловой системе. А перед этим подумать, ПОЧЕМУ они не структурированы, и не стоит ли добавить им структуры?

Пельмени vs Вареники

SQL и Oracle будут жить вечно

ну пока конца и края им нет, postgress и mysql/mariadb тоже живут хорошо.

Но, среди всякой хипстоты и различных новомодных проектов растет популярность nosql решений, вроде Монго, Редиса

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

в файловой системе

Не понял. Файловая система — это прекрасный пример строгой иерархической структуры.

ПОЧЕМУ они не структурированы

Потому что rapid development, время стоит денег. Оценивать данные, раскладывать их по отношениям, выбирать оптимальные типы данных для хранения, типы и состав индексов, строить планы запросов и потом оптимизировать их — это всё очень здорово, когда делаешь какое-то долгоживущее приложение, но это нафиг не нужно, когда нужно по-быстрому обработать массив raw данных и получить результат.

Ну да, ну да

В двух фразах - вся суть.
«по-быстрому обработать массив raw данных» - как-то обработать какой-то массив. Например, перебрать массив чисел от 1 до гугола.
«получить результат» - какой-то результат. «Массив raw-данных обработан», например.

rapid development, время стоит денег

Блядская копроэкономика, а не rapid development. Сегодня у нас rapid development, а завтра нам нужна аналитика, но при разработке про неё никто не думал, а отчёт завтра нужен уже вчера, и не один экземпляр отчёта, а на регулярной основе, да ещё и с ручками для кручения. Но руководителя проекта уже нет, старого директора уже нет, есть только программисты и три конверта.

Если человек не знает зачем ему «no sql», то оно ему на самом деле и не нужно.

Красиво сказано, но не вполне верно.
Дело в том что под NoSQL часто подразумевают «всякие там монги и редисы о которых вопит хипстота». Но вообще-то NoSQL это всё что не SQL (:
К NoSQL можно отнести кучу очень разных СУБД с разными подходами к хранению и работе с данным. От memcached (ключ-значение, хранение в памяти, используется для кеша), до SciDB (версионирование, многомерность, распределённость, большие объёмы, предназначина для аналитики, например над научными данными). От Neo4j (для работы с графами, удобно для анализа соответствующих данных, медленно) до Casandra (очень быстрое чтение и запись, за счёт оптимального использования HDD (минимизация случайного доступа, короче реализация гуглового BigTable), распределённость, лёгкое масштабирование, колонко-ориентированная СУБД (богаче чем ключ-значение, буднее РСУБД)).

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

Но дебилом с обеих сторон барикад на это пофиг, ведь так прикольно брызжа слюной орать «МОНГА! МОНГА ВО ВСЕ ПОЛЯ!!!1 SQL НЕНУЖЕН! Бигдата вебдваноль денормализация ноджэйэс лайк кококо!!!!» или задирать нос в духе «всё что не оракл — кал». Среди адептов Пресвятого Оракла попадаются поциенты которые похоже действительно не верят что-то отличная от Оракла в принципе не способно работать, и воспринимают Оракла как единственное спасение и панацею от всего. Фэйсбук, вконтакт, гуглояндекс и половина интернета живащая на шаредхостингах с мускулем и всяких там вордпресах это видимо бесовские иллюзии и хипсторская пропаганда, ага (:

пельмени, очевидно же.

Это не еж и не уж, а две отдельных вещи. Идея OLAP не требует использования SQL

Построить куб из неструктурированных данных несколько нетрадиционно, но можно.

Но нужно ли?

в файловой системе. А перед этим подумать, ПОЧЕМУ они не структурированы, и не стоит ли добавить им структуры?

:) Вот вы и сами дошли до NoSQL :)
http://en.wikipedia.org/wiki/Hadoop
Type: Distributed file system

MongoDB реально полезна если данных много и их можно хранить в денормализованном виде.
Redis вообще быстрое key-value хранилище, видел как использовали его с MongoDB для ускорения запросов к некоторым данным.

Славно, спасибо за отклик.

Читал с интересом, благодарю!

Если тема интересует рекомендую посмотреть курс лекций «базы данных» от Computer Science Center
http://compscicenter.ru/courses/data-bases/2013-autumn/

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

http://cdn.liewcf.com/blog/wp-content/uploads/nosql-expert.png

В чем фича nosql? В отсутствии стандартного языка запросов? :) Сила и ахиллесова пята nosql в отсутсвии ACID, который собственно и тормозит в RDBMS. Но энтот самый ACID, ВНЕЗАПНО, бывает очень нужен, поэтому nosql и дальше будут сидеть в своей нише, ведь если у них появится ACID, у них исчезнет главное преимущество - скорость, и они просто станут медленной БД без стандарта на язык запросов :)

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

Да, на свете есть идиоты (процентов 95 или около того :). Да, среди фанатов nosql их тоже есть. И чё?
Некоторые, наиболее громкие, NoSQL продукты преподносят себя как более простые решения, привлекая (в том числе) опредёлнную публику. И чё?

поэтому nosql и дальше будут сидеть в своей нише

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

У каждой технологии есть границы в которых её разумно применять и границы в которых её в принципе можно применять (последние шире).

Не везде нужен ACID, не везде нужна реляционная модель данных. Где-то нужно только что-то одно из этого, где-то не нужно ни то ни другое, где-то нужно и то и другое.

NoSQL это не только долбаная монга, NoSQL чертовски разнообразен. В этом главная его фишка.

MongoDB is web scale

http://www.youtube.com/watch?v=b2F-DItXtZs

ЛОРовцы

Сам ты овца.

у одного моего знакомого профессионального погромиста Оракл есть мнение, от том, что SQL и Oracle будут жить вечно

Насчет оаркла не знаю, но SQL нас всех точно переживёт.

среди всякой хипстоты и различных новомодных проектов растет популярность nosql решений

noSQL отъест свою нишу у SQL, но заменить последнего полностью он не может просто по определению.

Does /dev/null support sharding?

Убило :D

Мнение говнопрогера.

Сильно зависит от ORM для использования. Единственный факт таков, что именно sql-подход уже бесит, но не реляционные бд. Инструменты для mongodb подкупают простотой использования внутри кода, безумной простотой. SQL как стандарт реляционных бд покрывает слишком много фич и от некоторых этих фич проблем при разработке несложных систем больше, чем удобств. Делать нынче двойную проверку данных средствами структур таблиц sql имеет смысл при нестрого-типизированных языках? ибо в строго-типизированных языках средств самого языка достаточно. ( А я использую play+scala+mongodb)

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