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

Question

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

Хотя я могу понять, что они могут быть полезны для некоторых целей, в большинстве моих приложений я пытаюсь сохранить объекты, у которых есть определенное количество полей определенного типа, и я просто автоматически думаю в реляционной модели. Я всегда думаю в терминах строк с уникальными целочисленными идентификаторами, нулевыми / ненулевыми полями, типами данных 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

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

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

Answer 3

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

1. Оптимизирующая мозг интуитивность хранения документов
2. Решает проблемы хранения Sparse-Matrix и Entity-Attribute-Value.

Я использовал как 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. ваттность
8. Тип крепления (мужской, женский)

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

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

Answer 4

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

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

Answer 5

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

Answer 6

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

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