NoSQL по сравнению с SQL, когда масштабируемость не важна
Недавно я читал много о различных базах данных NoSQL и как они эффективно развертываются некоторыми главными веб-сайтами там. Я запускаю проект, в котором я думаю, что природа без схем базы данных, такой как MongoDB была бы чрезвычайно полезна. Все, что я считал, хотя, кажется, указывает, что основным преимуществом базы данных NoSQL является масштабируемость. Действительно ли выбор является базой данных NoSQL для дизайна без схем столь же законное проектное решение как та из масштабируемости?
3 ответа
Да, иногда СУБД - не лучшее решение, хотя есть способы разместить определяемые пользователем поля (см. Тип данных XML, шаблон проектирования EAV или просто иметь запасные общие столбцы), иногда база данных без схемы является хорошим выбором.
Тем не менее, вам необходимо четко сформулировать свои требования, прежде чем выбирать базу данных документов, так как вы потеряете большую часть возможностей, к которым вы, возможно, привыкли с реляционной моделью
например ...
Если в противном случае у вас было бы несколько таблиц в базе данных СУБД, вам нужно будет изучить возможности MongoDB для удовлетворения этих потребностей.
Если вам нужно будет запросить данные определенным образом, вам снова нужно изучить, что предлагает MongoDB.
Я бы не стал думать о NoSQL как о замене СУБД, скорее как о немного другом инструменте, который имеет свои собственные преимущества и недостатки, что делает его более подходящим для одних проектов, чем для других.
(Обе базы данных могут использоваться в некоторых случаях. Также, если вы решите пойти по пути возможного использования MongoDB, после того, как вы изучите веб-сайты и у вас возникнут более конкретные вопросы, вы можете посетить канал Freenode IRC #mongodb)
что подняло этот вопрос, что если у вас есть большая ферма серверов и нужно управлять распределением данных и балансировкой нагрузки, что сложнее и труднее реализовать с помощью RDBMS и требует высоких навыков ИТ для проектирования, планирования и развертывания для вашего решения (и все еще производительность меньше). Но если у вас всего 3 или 4 сервера с небольшим проектом. Я не думаю, что у вас есть проблемы с этим. NoSQL базы данных обычно рассматриваются в больших серверных фермах, а не в небольшом количестве серверов
.Есть много других условий, о которых я слышал о нереляционных системах по сравнению с реляционными. Я предпочитаю эту терминологию sql / no-sql, поскольку я лично считаю, что она лучше описывает различия, а некоторые из серверов "no-sql" имеют надстройки sql, так что в любом случае .... какой тип параллелизма или изоляция транкации требуется в вашей системе. Одно из предполагаемых различий между rel и non-rel dbs - это «согласованный-всегда», «согласованный-в основном» или «согласованный-в конечном итоге». Базы данных отношений по умолчанию обычно попадают в категорию "в основном согласованные" и после некоторой работы и множества условий блокировки и гонки;) могут быть "согласованными-всегда", поэтому каждый всегда ищет наиболее правильное представление данный фрагмент данных. Большинство из того, что я читал / слышал о базах данных, не относящихся к rel, - это то, что они в основном "согласованные-в конечном итоге".Это означает, что может быть много экземпляров наших данных, перемещающихся вокруг, поэтому пользователь «A» может видеть, что у нас 92 виджета в инвентаре, тогда как пользователь «B» может видеть 79, и они не могут быть согласованы, пока кто-то действительно не уйдет. вытащить вещи со склада. Другой вопрос - изменчивость данных, как часто их нужно обновлять? Я обнаружил, что конкретные не относящиеся к rel db имеют больше накладных расходов на обновления, некоторые из них должны регенерировать весь набор данных, чтобы включить какие-либо обновления.
Учтите, я считаю, что не-rel / nosql - отличные инструменты, если они действительно соответствуют вашему варианту использования. У меня есть несколько проектов, которые я сейчас ищу. Но вы должны учитывать все компромиссы при принятии решения, иначе это просто превратится в разработку, основанную на резюме.