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

Question

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

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

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

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

Answer 1

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

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

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

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

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

3. ACID не очень хорошо работает для распределенных систем ( BASE , CAP и т. Д.). Язык SQL (и вся реляционная модель в определенной степени) оптимизирован для мира транзакционных ACID. Таким образом, некоторые функции и рекомендации языка SQL бесполезны, а другие на самом деле вредны. Некоторые разработчики чувствуют себя некомфортно из-за «противодействия» и предпочитают полностью отказаться от SQL в пользу языка, который был разработан с нуля для их требований.

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

Answer 2

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

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

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

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

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

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

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

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

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

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

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

Answer 3

Главной заботой должно быть то, что вам нужно делать с вашими данными. Если у вас огромный набор данных и вы считаете, что традиционная СУБД является узким местом, то вы можете поэкспериментировать с решением без схемы или NOSQL .

В большинстве сред, в которых я знаю об использовании NOSQL решений, также используется решение СУБД в той или иной форме или в любом виде. Решения на основе RDBMS являются нормой, когда целостность данных чрезвычайно важна, и вам нужны транзакции ACID. Однако, если ваша система не основывается на транзакциях, но вам нужно очень быстро масштабировать или масштабировать, может быть желательным решение NOSQL .

Answer 4

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

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

Answer 5

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

Answer 6

Обычно привлекательность змеиного масла - большинство людей, предпочитающих их, не имеют ни малейшего представления о теореме отношений и говорят на SQL на уровне, вызывающем рвоту профессионалов. Понятия не имею, что такое условия КИСЛОТЫ, они важны и т. Д.

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