В чем привлекательность систем баз данных без схем?

Question

Я слышал много разговоров о системах баз данных без схемы (часто распределенных), таких как MongoDB, CouchDB, SimpleDB и т.д...

Хотя я понимаю, что они могут быть полезны для некоторых целей, в большинстве моих приложений я пытаюсь сохранять объекты, которые имеют определенное количество полей определенного типа, и я просто автоматически думаю в реляционной модели.Я всегда думаю в терминах строк с уникальными целочисленными идентификаторами, полей null / not null, типов данных SQL и запросов select для поиска наборов.

Хотя меня привлекает распределенный характер и простые интерфейсы JSON / RESTful этих новых систем, я не понимаю, как свободно типизированные хэши ключей / значений помогут мне в моей разработке.Почему свободно типизированная система без схемы была бы хороша для хранения чистых наборов данных?Как я могу, например, найти все элементы с датами между x и y, когда у них может не быть дат?Существует ли какое-либо понятие объединения?

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

Answer 1

Я просто позвоню одну или две общие причины (я уверен, что люди будут писать ссылки на эссе)

1. При высоко распределенных системах любой заданный набор данных может быть распространен по нескольким серверам. Когда это произойдет, реляционные ограничения, которые могут гарантировать, что двигатель БД может быть значительно уменьшен. Некоторый Вашей референциальной целостности необходимо будет обрабатывать в код приложения. При этом вы быстро обнаружите несколько болевых очков:

   • Ваша логика распространяется по нескольким слоям (приложение и дБ)
   • Ваша логика распространяется на нескольких языках (SQL и ваш язык приложения по выбору)

   Результатом заключается в том, что логика менее инкапсулирована, менее портативна, и намного дороже для изменения. Многие Devs оказывают сами писать больше логики в приложении и меньше в базе данных. Внесенные до крайности, схема базы данных становится неактуальной.

2. Управление схем - особенно на системах, где простоя не является вариантом - сложно. Уменьшение сложности схемы снижает эти трудности.

3. Кислота не очень хорошо работает для распределенных систем (ОСНОВАНИЕ, КРЫШКА, и т.д). Язык SQL (и вся реляционная модель в определенной степени) оптимизирован для мира транзакционного кислота. Поэтому некоторые функции языка SQL и лучшие практики бесполезны, в то время как другие на самом деле вредны. Некоторые разработчики чувствуют себя некомфортно о «против зерна» и предпочитают падать SQL полностью в пользу языка, который был разработан с нуля за их требования.

4. Стоимость: большинство систем RDBMS не бесплатны. Лидеры в масштабировании (Oracle, Sybase, SQL Server) являются коммерческими товарами. При работе с большими («веб-масштабными» системами), расходы на лицензирование базы данных могут соответствовать или превышать стоимость оборудования! Стоимость достаточно высока, чтобы изменить обычные соображения в построении / покупках радикально настроить пользовательское решение на вершине предложений OSS (все значимые предложения NoSQL OSS)

Answer 2

Отсутствие схемы отлично подходит по двум причинам:

1. Мозг, оптимизирующий интуитивность хранения документов
2. Разрешает Разреженная матрица и Сущность-Атрибут-Значение проблемы с хранением.

Я использовал как SQL, так и No-SQL для производственных приложений в Ruby on Rails.Я не специалист по базам данных и должен признаться, что погуглил ACID и подобные термины, поскольку они мне не знакомы.

"Ах-ха!Еще один ничего не знающий сторонник тренда, прыгающий на последнюю подножку ", - можете сказать вы.Но, на самом деле, я действительно доволен своим решением использовать MongoDB в нашем последнем приложении 2-летней давности, и вот почему...

Обратной стороной интуитивности, оптимизирующей работу мозга, стал мой опыт работы с системой электронной коммерции Magento.Я не хочу критиковать его, потому что в то время он хорошо служил мне, но это действительно сильно ударило по процессору, пытаясь вычислить атрибуты для каждого продукта.Основной причиной было хранилище данных продукта "Сущность-атрибут-значение".Решением было спрятать или быть проклятым.

Главным преимуществом для меня является оптимизация в единственном месте, которое действительно имеет значение - ваш собственный мозг.Так много технологий подвергаются критике за их эффективность в отношении памяти, процессоров, аппаратного обеспечения, и все же наличие чрезвычайно интуитивно понятной базы данных имеет свои преимущества.Мы быстро добавили функции в наш код, потому что база данных просто очень похожа на реальный мир, который мы моделируем.Когда я прошу клиентов электронной коммерции представить мне список своих товаров, они, естественно, предпочитают использовать Excel (think table store).Первые столбцы просты:

1. Название продукта
2. Цена
3. Тип продукта (

Затем это становится сложнее и покрывается примечаниями, цветовой кодировкой и ссылками на другие таблицы (ага..отношения)

4. Цвет (Только для некоторых продуктов)
5. Размер (X большой, Large, Small) - только для изделий 8'9'10, клюшки для гольфа используют другой масштаб
6. Цвет 2.Ошейники для кошек бывают двух цветов.
7. Мощность
8. Тип крепления (Мужской, Женский)

Таким образом, это заканчивается ужасным беспорядком таблиц Excel, которые не имеют смысла ни для меня, ни для людей, которые изо дня в день работают с продуктами.Мы вскидываем руки вверх и решаем пройтись по каталогу, и тут меня осеняет!Разве не было бы здорово, если бы вы могли хранить данные в том виде, в каком они указаны в каталоге!?Просто коллекции записей по каждому продукту, в которых просто перечислен атрибут этого продукта.Затем вы можете выбрать общие атрибуты для индексации для последующего извлечения.Конечно, это хранилище документов.

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

Answer 3

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

Большинство окружающей среды, которые я знаю об использовании Nosql. Решения также используют решение RDBMS в некоторой форме или моде. Решения на основе RDBMS - это норма, где целостность данных чрезвычайно важна, и вам нужны кислотные транзакции. Однако, если ваша система не основана на транзакции, но вам нужно быстро масштабировать или масштабировать Nosql. решение может быть желательным.

Answer 4

Я играл только с MongoDB, но одна вещь, которая действительно интересовала меня, было то, как вы могли бы представить документы. В MongoDB документ в основном нравится запись. Это действительно приятно, потому что традиционно в RDBMS, если вам нужно было вытащить запись «человека» и получить связанный адрес, информацию о работодателе и т. Д. Вы бы часто должны были перейти к нескольким таблицам, присоединиться к ним вверх, сделать несколько баз данных. звонки. В растворе NoSQL, такое как MongoDB, вы можете просто гнестите связанные записи (документы) и не должны беспорядок с зарубежными ключами, присоединением, несколько вызовов баз данных. Все связано с этим одной записи.

Это особенно удобно при работе с объектами. Во многих случаях вы можете просто хранить объект как серию вложенных документов.

Answer 5

NoSQL базы данных не схема; Схема встроена в данные. Они должным образом называют полустрадами. Однако в некоторых магазинах данных KV схема может даже быть встроена в код. Преимущество полуструктурированного подхода - это два раза: гибкость, в которой столбцы являются частью строки (одна строка может иметь 5 столбцов, а другая имеет 5 различных столбцов, а гибкость в характеристиках столбцов (например, переменной длины)

Answer 6

Обычно притяжение состоит в том, что змеиное масло - большинство людей, которые их не имеют никакого ключа о реляционной теореме и не говорят на уровне, делающих профессионалы Puke. Ничего не представляя, какие кислотные условия, эхи, они важны и т. Д.

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