Пример задачи, которую база данных NoSQL не может обработать (если есть)
Я хотел бы проверить мир NoSQL. Это просто любопытство, а не абсолютная необходимость (пока). Я прочитал несколько вещей о различиях между базами данных SQL и NoSQL. Я убежден в потенциальных преимуществах, но немного беспокоюсь о случаях, когда NoSQL не применим. Если я понимаю, базы данных NoSQL по существу пропускают свойства ACID.
Может ли кто-нибудь привести пример какой-то реальной работы (например, сайта электронной коммерции, или научного приложения, или...), с которой может справиться реляционная база данных ACID, но где база данных NoSQL может потерпеть неудачу, либо систематически с каким-то видом из-за гонки или из-за перебоя в питании и т. д.
Прекрасным примером будет то, где не может быть никакого обходного пути без модификации ядра базы данных. Примеры, где база данных NoSQL просто плохо работает, в конечном итоге станут другим вопросом, но здесь я хотел бы увидеть, когда теоретически мы просто не можем использовать такую технологию.
Может быть, поиск такого примера зависит от конкретной базы данных. Если это так, давайте возьмем MongoDB для представления мира NoSQL.
Изменить: чтобы уточнить этот вопрос, я не хочу спорить о том, какой тип базы данных лучше для определенных случаев. Я хочу знать, может ли эта технология быть абсолютным тупиком в некоторых случаях, потому что, как бы мы ни старались, какие-то функции, которые предоставляет база данных SQL, не могут быть реализованы поверх хранилищ nosql. Поскольку существует много доступных хранилищ nosql, я могу согласиться выбрать существующее хранилище nosql в качестве поддержки, но меня больше всего интересует минимальное подмножество функций, которое должно обеспечить хранилище для реализации функций более высокого уровня (например, могут ли транзакции быть реализованы с помощью магазин, который не предоставляет X...).
6 ответов
Этот вопрос немного похож на вопрос о том, какую программу нельзя написать на императивном / функциональном языке. Любой Turing-полный язык и выразить каждую программу, которая может быть решена с помощью Turing Maching. Вопрос в том, действительно ли вы, как программист, действительно хотите написать систему учета для компании из списка Fortune 500 в виде непереносимых машинных инструкций.
В конце концов, NoSQL может делать все, что могут движки на основе SQL, разница в том, что вы, как программист, можете нести ответственность за логику в чем-то вроде Redis, который MySQL предоставляет вам бесплатно. В базах данных SQL очень консервативный взгляд на целостность данных. Движение NoSQL ослабляет эти стандарты, чтобы улучшить масштабируемость и упростить задачи, общие для веб-приложений.
MongoDB (мое текущее предпочтение) упрощает репликацию и разделение (горизонтальное масштабирование), очень быстро вставляет и отбрасывает требование строгой схемы. В обмен на это пользователи MongoDB должны кодировать более медленные запросы, когда индекс отсутствует, внедрить транзакционную логику в приложении (возможно, с тремя фазовыми фиксациями), и мы постараемся снизить эффективность хранения.
CouchDB имеет аналогичные компромиссы, но также жертвует специальными запросами для возможности работать с данными в автономном режиме, а затем синхронизировать с сервером.
Redis и другие хранилища значений ключей требуют, чтобы программист писал большую часть индекса и объединял логику, встроенную в базы данных SQL. В обмен на это приложение может использовать знания предметной области о своих данных, чтобы сделать индексы и объединения более эффективными, чем общее решение, которое потребует SQL. Redis также требует, чтобы все данные помещались в ОЗУ, но взамен дает производительность наравне с Memcache.
В конце концов, вы действительно можете делать все, что MySQL или Postgres делают только с командами файловой системы ОС (в конце концов, именно так делали люди, написавшие эти движки баз данных). Все сводится к тому, что вы хотите, чтобы хранилище данных делало для вас, и что вы готовы отдать взамен.
Хороший вопрос. Сначала уточнение. В то время как область реляционных хранилищ объединяется довольно прочной основой принципов, и каждый поставщик выбирает добавленную стоимость в функциях или ценах, нереляционное поле (nosql) является гораздо более разнородным.
Существуют хранилища документов (MongoDB, CouchDB), которые отлично подходят для управления контентом и аналогичных ситуациях, когда у вас есть плоский набор переменных атрибутов, которые вы хотите построить вокруг темы. Возьмите сайт-настройку. Использование хранилища документов для управления пользовательскими атрибутами, которые определяют способ, которым пользователь хочет видеть свою страницу, хорошо подходит для платформы. Несмотря на свою рекламную шумиху, эти магазины не всегда хорошо масштабируются в терабайты. Это можно сделать, но это не идеально. MongoDB обладает множеством функций, обнаруженных в реляционных базах данных, таких как динамические индексы (до 40 на коллекцию / таблицу). CouchDB создан, чтобы быть абсолютно восстанавливаемым в случае сбоя.
Существуют хранилища ключей / значений (Cassandra, HBase...), которые отлично подходят для высокораспределенного хранилища. Кассандра для низких задержек, HBase для высоких задержек. Хитрость заключается в том, что вы должны определить потребности вашего запроса, прежде чем начинать вводить данные. Они не эффективны для динамических запросов к любому атрибуту. Например, если вы создаете службу регистрации событий клиента, вы хотите установить свой ключ на уникальный атрибут клиента. Оттуда вы можете вставить различные структуры журналов в свой магазин и получить все журналы по ключу клиента по запросу. Однако было бы гораздо дороже попытаться просмотреть журналы для поиска событий журнала, в которых тип был "сбой", если только вы не решили сделать этот ключ второстепенным. Еще одна вещь: в последний раз, когда я смотрел на Cassandra, вы не могли запустить регулярное выражение в запросе M/R. Означает, что, если вы хотите искать шаблоны в поле, вам придется извлечь все экземпляры этого поля и затем выполнить его через регулярное выражение, чтобы найти нужные вам кортежи.
Граф базы данных сильно отличается от двух выше. Отношения между предметами (объектами, кортежами, элементами) текучие. Они не масштабируются в терабайты, но это не то, для чего они предназначены. Они отлично подходят для того, чтобы задавать вопросы типа "эй, сколько из моих пользователей любят зеленый цвет? Из них сколько живет в Калифорнии?" С реляционной базой данных у вас будет статическая структура. С графической базой данных (я упрощаю, конечно), у вас есть атрибуты и объекты. Вы подключаете их, как имеет смысл, без применения схемы.
Я бы не положил ничего критического в нереляционный магазин. Коммерция, например, где вы хотите гарантировать, что транзакция завершена до доставки продукта. Вы хотите гарантированной целостности (или, по крайней мере, лучший шанс гарантированной целостности). Если пользователь теряет свои настройки сайта, ничего страшного. Если вы потеряете коммерческий переход, большое дело. Там могут быть некоторые, кто не согласен.
Я также не стал бы помещать сложные структуры ни в один из перечисленных выше нереляционных магазинов. Они плохо соединяются в масштабе. И это нормально, потому что это не тот способ, которым они должны работать. Там, где вы можете поместить идентификатор для address_type в таблицу customer_address в реляционной системе, вы захотите внедрить информацию address_type в кортеж клиента, хранящийся в документе или ключе / значении. Эффективность данных - это не область документа или хранилище ключей / значений. Дело в распределении и чистой скорости. Жертва - это след.
Существуют и другие подтипы семейства магазинов, помеченных как "nosql", которые я здесь не освещал. Существует множество (по последним подсчетам, 122) различных проектов, ориентированных на нереляционные решения проблем данных различных типов. Riak - еще один, о котором я продолжаю слышать и не могу дождаться, чтобы попробовать.
А вот и хитрость. Поставщики реляционных продуктов с большим долларом наблюдали, и есть вероятность, что они все строят или планируют создавать свои собственные нереляционные решения, чтобы связать их со своими продуктами. В ближайшие пару лет, если не раньше, мы увидим зрелое движение, крупные компании скупают лучших в своем классе, а поставщики реляционных услуг начинают предлагать интегрированные решения, для тех, которые еще этого не сделали.
Это чрезвычайно интересное время для работы в области управления данными. Вы должны попробовать несколько из них. Вы можете скачать Couch или Mongo и запустить их в считанные минуты. HBase немного сложнее.
В любом случае, я надеюсь, что я, не смущаясь, сообщил, что я достиг просветления без существенной предвзятости или ошибки.
СУБД хороши в соединениях, а движки NoSQL - нет. Движки NoSQL хороши в распределенной масштабируемости, а RDBMS обычно нет.
СУБД хороши при проверке данных, в отличие от движков NoSQL. Движки NoSQL хороши в гибких и не требующих схем подходах, а СУБД обычно - нет.
Оба подхода могут решить любой набор проблем; разница в эффективности.
Вероятно, ответ на ваш вопрос заключается в том, что mongodb может справиться с любой задачей (и sql тоже). Но в некоторых случаях лучше выбрать mongodb, в других - базу данных sql. О преимуществах и недостатках вы можете прочитать здесь.
Также, как сказал @Dmitry, mongodb открывает дверь для простого горизонтального и вертикального масштабирования с репликацией и разбиением.
RDBM действительно хороши для быстрого суммирования сумм, средних значений и т. Д. Из таблиц. например SELECT SUM(x) FROM y WHERE z, Это удивительно сложно сделать в большинстве баз данных NoSQL, если вы хотите получить ответ сразу. В некоторых хранилищах NoSQL отображение / уменьшение является способом решения одной и той же задачи, но в реальном времени это не так, как в мире SQL.
СУБД обеспечивают строгую согласованность, в то время как большинство no-sql в конечном итоге согласованно. Таким образом, в определенный момент времени, когда данные считываются из БД без SQL-кода, они могут не представлять самую последнюю копию этих данных.
Типичным примером является банковская транзакция, когда пользователь снимает деньги, узел A обновляется этим событием, если в то же время узел B запрашивает баланс этого пользователя, он может вернуть устаревший баланс. Этого не может произойти в СУБД, поскольку атрибут консистентности гарантирует, что данные обновляются до того, как их можно будет прочитать.