NoSQL против SQL, когда масштабируемость не имеет значения

Question

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

Answer 1

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

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

например ...

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

Если вам потребуется запросить данные определенным образом, вам снова нужно изучить, что вам предлагает MongoDB.

Я бы не думал о NoSQL как о замене СУБД, а немного о другом инструменте, который имеет свои преимущества и недостатки, что делает его более подходящим для одних проектов, чем для других.

(Обе базы данных могут использоваться при некоторых обстоятельствах. Также, если вы решите пойти по пути возможного использования MongoDB, как только вы изучите веб-сайты там и у вас есть более конкретные вопросы, вы можете посетить канал Freenode IRC #mongodb)

Answer 2

Есть много других условий, о которых я слышал о нереляционных системах по сравнению с реляционными. Я предпочитаю эту терминологию вместо sql / no-sql, так как лично я думаю, что она лучше описывает различия, и некоторые из серверов "no-sql" имеют надстройки sql, так или иначе .... какой тип шаблона параллелизма или изоляции транзакции требуется в вашей системе. Одно из предполагаемых различий между rel и non-rel dbs - это «непротиворечивый всегда», «непротиворечивый в основном» или «непротиворечивый в конце концов». Относительные базы данных по умолчанию обычно попадают в категорию «в основном согласованные» и с некоторой работой, а также множеством условий блокировки и гонки;) могут быть «всегда согласованными», поэтому каждый всегда смотрит на наиболее правильное представление данный кусок данных. Большая часть того, что я читал / слышал о не относящихся к БД, состоит в том, что они в основном "последовательны в конце концов". Это означает, что может быть много экземпляров наших данных, поэтому пользователь «A» может видеть, что у нас есть 92 виджета в инвентаре, тогда как пользователь «B» может видеть 79, и они могут не примириться, пока кто-то на самом деле не уйдет вытащить вещи со склада. Другая проблема - изменчивость данных, как часто это нужно обновлять? Конкретные базы данных, не относящиеся к rel, которые я получил, имеют больше накладных расходов на обновления, некоторым из них приходится регенерировать весь набор данных для включения любых обновлений.

А теперь подумайте, я думаю, что non-rel / nosql - отличный инструмент, если он действительно соответствует вашему варианту использования. У меня есть несколько проектов, которые я сейчас изучаю. Но вы должны учитывать все компромиссы при принятии решения, в противном случае это просто превращается в разработку, основанную на резюме.

Answer 3

следует отметить самые важные вещи, чтобы различать No-SQL и SQL который : NO-SQL полезен, когда база данных масштабируется таким образом, как социальные сети например : Переполнение стека: каждый вопрос имеет несколько ответов, а не воображаемый ответ без вопроса, поэтому No-SQL обеспечит, чтобы на каждый вопрос были ответы в результате при получении ответов на вопрос мы можем получить все ответы без объединения. Потому что объединение является самым дорогим запросом в соответствующей базе данных. большое спасибо

Answer 4

Я не думаю, что вы должны выбирать NoSQL хранилище данных для его дизайна без схемы. Свободный от схемы дизайн всегда существовал в РСУБД через XML, и некоторые базы данных имеют хорошую поддержку XML. С базой данных работать намного проще, чем с хранилищем данных NoSQL. Масштабируемость и большие данные должны быть основными драйверами для выбора хранилища данных NoSQL, в противном случае компромисс между ACID и SQL очень важен для перехода на NoSQL.

Answer 5

что вызвало эту проблему, если у вас большая ферма серверов и вам необходимо управлять распределением ваших данных и балансировкой нагрузки, что сложнее и сложнее реализовать с помощью RDBMS и требует высоких навыков в области ИТ для проектирования, планирования и развертывания для вашей решение (и все же производительность меньше). но если у вас есть только 3 или 4 сервера с небольшим проектом. Я не думаю, что у вас есть проблема по этому поводу. База данных NoSQL обычно рассматривается в крупных серверных фермах, а не в небольшом количестве серверов