Могут ли в будущем использоваться базы данных на основе документов вместо СУБД во всем приложении?

Question

Чем больше я читаю / использую не-sql базы данных, тем больше мне это нравится.

Это так для мира ООП и его легко использовать, как Rails для Frameworks.

Я знаю недостатки. Основная проблема, кажется, заключается в отсутствии транзакций и отсутствии параллелизма. Я прав?

Являются ли эти единственные функции затрудняющими разработчикам использовать полностью не-SQL базы данных, даже для транзакций?

Если бы эти функции были исправлены, было бы лучше использовать базы данных на основе документов только для приложения?

Потому что теперь кажется, что вам все еще нужно использовать СУБД для данных о счетах клиентов, в то время как ваш контент может находиться в базах данных на основе документов, таких как MongoDB / CouchDB / Cassandra.

Может ли кто-то пролить свет на это.

Answer 1

Да, конечно, вы можете создавать целые приложения на нереляционных моделях данных. Как правило, хотя большинство людей не хотят этого делать. Проблема заключается в том, что иерархические / основанные на графике модели данных (т. Е. Любая модель, которая зависит от навигационных структур данных) значительно увеличивают сложность и снижают эффективность запросов и целостность данных в базе данных. Реляционная модель была изобретена 40 лет назад именно для того, чтобы преодолеть те недостатки, которые присущи навигационным базам данных.

Answer 2

Это зависит также от разработки нового, более быстрого оборудования.

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

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

При распределении данных по нескольким машинам вы должны сделать несколько трудных решений: http://dbmsmusings.blogspot.com/2010/04/problems-with-cap-and-yahoos-little.html, вам не нужно беспокоиться о теореме CAP, если все ваши данные находятся на одном компьютере.

Answer 3

Короче говоря, многие решения NoSql не имеют каскадных обновлений, поэтому, если этого требует схема данных вашего приложения, вы либо программно обновите несколько документов (т. Е. Столбцов), либо воспользуетесь решением на основе SQL для этого.

Параллелизм обрабатывается по-разному для разных решений.

Я думаю, что этот блог хорошо объясняет некоторые компромиссы с использованием решения NoSQL. http://blog.mongodb.org/post/475279604/on-distributed-consistency-part-1

Answer 4

Нет.

Они не подходят для фиксированных схем, больших объемов, в основном числовых данных.Подумайте о хранилищах данных.Подумайте о специальных аналитических запросах.Они могут взять на себя все (или некоторые из) областей, где СУБД в первую очередь не подходили (области, где люди придумали базы данных XML, объектно-ориентированные базы данных, графические базы данных и т. Д.).

Это похоже на то, что Excel не может заменить Word (также по общему признанию, большинство файлов Excel, которые я вижу в эти дни, представляют собой скорее презентацию, чем электронную таблицу).Разные инструменты для разных задач.