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

Поделитесь соображениями, что даёт переход с SQL(postgress, sqllite, db2,oracle) на NOSQL.
Мотивы мне непонятны.Я вижу один только вред.
  • Вопрос задан
  • 4609 просмотров
Пригласить эксперта
Ответы на вопрос 10
NOSQL БД не становятся популярными, а занимают свою нишу.

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

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

Каждый выбирает для своего проекта тот инструмент, преимущества которого перевешивают недостатки в данном конкретном случае.
Ответ написан
Комментировать
@ShouldNotSeeMe
Скорость, устойчивость к SQL-injection.
Ответ написан
SQL -реляционная БД. У них есть проблема с работы с очень большими объёмами данных при высокой нагрузке. Вот вроде и NOSQL будет решать подобные проблемы в том числе.
Ответ написан
Aco
@Aco
Заклинатель кода
Могу оценивать со стороны MySQL и MongoDB. Помимо комментария выше, так хочу добавить, что MySQL очень медленно развивается в горизонтальном масштабирование. В монге же наоборот, это их сильная сторона — удобный, продуманный шардинг с failover репликацией в формате Replica Set. Это основной упор в высоконагруженных проектах.
Так же монга работает на js движке и всякие процедуры писать на много проще нежели в MySQL.
У монги самый адекватный и удобный PHP драйвер по сравнению с mysql, mysqli, pdo.
И да, инъекцию не реально сделать в монге из-за её формата BSON и адекватного драйвера (если, конечно, у вас весь запрос не берётся из урлы, например).
Так же важным плюсом в монге — её курсоры, которые действительно курсоры, а не имитация как в MySQL. Они (курсоры) действительно шагают по записям тогда когда поросят и могут жить столько сколько попросят, в мускуле, как правило, же всё сразу выгружается в память (поправьте меня, если это проблема драйверов).
Простота в использовании монги доставляет и подкупает.

Но есть «ложка дёгтя». У монги нет join-ов (хотя это может быть плюсом). И она ооочень прожорлива (дискового пространства). У неё операции над группировкой делается через map reduce, что не очень просто.
Ответ написан
@1nd1go
SQL базы данных затачиваются под универсализацию, те стараются предоставить разумный компромисс мжду скоростью записи и чтения. Это удовлетворяет потребности большинства энтерпрайз приложений, так как паттерн их использования как раз и заключается в «пописали/почитали». Плюс sql базы стремятся предоставить защищенноть данных, следуя принципам ACID, что опять же является критичным для ентерпрайза.

С друой стороны, есть задачи которым важно чтото определенное из всего набора. Например мы хотим бысто быстрои много писать, но можем пожертвовать скоростью чтения или свежестью данных. Или у нас объекты пишутся часто разной структуры, и мы хотим получать быструю их фильтрацию. Для всего этого традиционных подход sql создает ненужные обвязки, которые тормозят эти операции. И эти проблемы решают специализированные базы данных nosql
Ответ написан
Комментировать
Stdit
@Stdit
К примеру, многие разработчики предпочитают ORM (Object-relational mapping). NoSQL база (не любая, конечно) предоставляет нативный интерфейс для этой модели, ликвидируя осложнения от реляционной прослойки. В том числе для объектов с нефиксированным набором свойств. Из-за этого упрощается приложение, увеличивается производительность и облегчается шардинг. Естественно, NoSQL не является абсолютной панацеей и заменой SQL, но в некоторых решениях имеет более высокую эффективность и удобство, поэтому и находит там своё применение.
Ответ написан
Комментировать
savant
@savant
В некоторых случаях использование SQL базы — overkill. Например если надо держать много «плоских» данных, с которыми если не проще, то быстрее работать курсорами, нежели запросами.

Или переход от ORM к объектно-ориентированным БД. получается несколько проще и логичнее, нежели отслеживать соответствие диаграммы классов с схемой БД. Миграции не панацея.
Ответ написан
Комментировать
@shagguboy
всё просто. есть задача: небольшая, заведомо влезающая в оперативку база данных, простая схема БД, простые запросы, большинство тупо по первичному ключу потеря данных не критична.
основная особенность — *много* (очень) *простых* запросов. их надо выполнять быстро. значит
1) все держим в памяти
2) отказываемся от языка запросов, убираем расходы на парсинг и кэши планов, оптимизацию
3) отказываемся от ACID

получаем то то получаем — IN MEMORY молотилку запросов.
Ответ написан
Комментировать
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы