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

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

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

   • your logic is spread across multiple layers (app and db)
   • ваша логика распространяется на несколько языков (SQL и выбранный вами язык приложения)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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