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

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

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

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

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

Ответ 1

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

С высокораспределенными системами любой набор данных может быть распределен между несколькими серверами. Когда это произойдет, реляционные ограничения, которые может гарантировать механизм БД, значительно сокращаются. Некоторая часть вашей ссылочной целостности должна быть обработана в коде приложения. При этом вы быстро обнаружите несколько болевых точек:
- ваша логика распространяется на несколько уровней (приложение и db).
- ваша логика распространяется на нескольких языках (SQL и ваш язык приложения по выбору)
Результат заключается в том, что логика менее инкапсулирована, менее портативна и намного дороже в изменении. Многие разработчики находят больше логики в коде приложения и меньше в базе данных. В крайнем случае схема базы данных становится неактуальной.
Управление схемой - особенно в тех системах, где время простоя не является вариантом - это сложно. уменьшение сложности схемы уменьшает эту трудность.
ACID не очень хорошо работает для распределенных систем (BASE, CAP и т.д.). Язык SQL (и вся реляционная модель в определенной степени) оптимизирован для транзакционного мира ACID. Поэтому некоторые из особенностей языка SQL и лучшие практики бесполезны, в то время как другие действительно вредны. Некоторые разработчики испытывают дискомфорт в отношении "против зерна" и предпочитают полностью отказаться от SQL в пользу языка, который был разработан с нуля для их требований.
Стоимость: большинство систем РСУБД не являются бесплатными. Лидерами по масштабированию (Oracle, Sybase, SQL Server) являются все коммерческие продукты. При работе с крупными ( "веб-масштабами" ) затраты на лицензирование баз данных могут соответствовать или превышать затраты на оборудование! Затраты достаточно высоки, чтобы радикально изменить нормальные требования к построению/покупке для создания пользовательского решения поверх предложения OSS (все существенные предложения NOSQL - OSS)

Ответ 2

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

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

Ответ 3

Скромность отлично по двум причинам:

Мозговая оптимизация интуитивности хранения документов
Разрешает Разреженная матрица и Entity- Атрибут-значение.

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

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

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

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

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

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

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

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

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

Ответ 4

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

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

Ответ 5

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

Ответ 6

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

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