Почему реляционные базы данных непригодны для неструктурированных данных?

Question

Я изучал базы данных NoSQL, и общая тема, которая возникает, заключается в том, что реляционные базы данных не подходят для хранения неструктурированных данных. Например:

К сожалению, жестко определен подход схемы на основе используется реляционными базами данных ... бедный подходит для неструктурированных и слабоструктурированных данных [source]

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

Answer 1

Мой любимый пример неструктурированных данных, который не подходит для реляционной базы данных, это база данных деталей аппаратного обеспечения.

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

Каждый товар имеет name, a price и vendor. Но процессоры имеют clock rate, а cache size и # of cores, мониторы имеют size и resolution, модули оперативной памяти имеют а capacity и жесткие диски имеют также capacity (который не может быть по сравнению с модулями оперативной памяти).

Как вы храните эти данные в реляционной базе данных?

• Вы можете создать очень широкий стол с сотнями полей для любого возможного атрибута, который может иметь какой-то продукт, но для большинства продуктов большинство этих полей будут NULL.
• Вы могли бы иметь отдельную таблицу для каждой категории продуктов
• Вы могли бы иметь огромный стол с колоннами product, property и value который отображает все свойства значений (но какой тип вы используете для value, когда некоторые свойства являются цифровыми, а другие нет?)

Все три варианта действительны, но ни одна из них не является действительно удовлетворительной.

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

Answer 2

Я не думаю, что вопрос должен быть неструктурированным или неструктурированным. Это больше о производительности для большого количества данных. У меня есть некоторый опыт, пытаясь сделать базу данных SQL в неструктурированном хранилище данных. В моем случае у меня была куча динамических (JSON) объектов, которые нужно было входить в таблицу. Я использовал SQL, потому что объекты были связаны друг с другом через отношения родитель-потомок (то есть самосоединение). Он отлично работал для набора тестовых данных около 5000 объектов.

Использование SQL

ОДНАКО, моя производственная база содержит около 3gb ценность данных (около 1 миллионов объектов, плюс-минус). Я потратил несколько недель на создание и оптимизацию своих подключений и запросов в sql. Я смог достичь максимальной производительности около 10 мс, чтобы вернуть несколько узлов из выбранного места в дереве.Затем я столкнулся с необычными проблемами производительности запросов, которые можно было решить только путем реструктурирования индексов и/или удаления и повторного создания хранимых процедур. Я потратил столько времени, чтобы сохранить проклятую базу данных SQL, поскольку я кодировал остальную часть моего приложения. Нехорошо. (О, и я должен упомянуть, что у меня около трех лет практического опыта DBA с SQL-сервером, поэтому я отнюдь не новичок в игре).

Использование Couchbase

Быстро вперед 18 месяцев. Теперь я использую Couchbase (популярная база данных nosql). Я смог получить идентичную функциональность от CB, используя представления и карту/уменьшить. Я потратил одну неделю на то, чтобы начать развертывание CB. Задержка поиска запросов - это субмиллисекунда. Конечный пользователь отмечает резкое увеличение производительности.

Bottom Line

Если у вас есть много данных, вы собираетесь быть трудно нажиму, чтобы найти ситуацию, когда SQL придет в какой-либо производительности в NoSQL архитектуры базы данных, независимо от того, как структурирован или неструктурированные данные.

Answer 3

Вопрос, кажется, основан на двух или трех неправильных представлениях. К сожалению, они слишком распространены среди энтузиастов faddish продуктов NoSQL.

Во-первых, информация (не «данные») никогда не является неструктурированным. Структура - это объектив, через который мы просматриваем данные, чтобы видеть информацию. Структура - причина, по которой данные полезны.

Во-вторых, часто цитируемые примеры таких данных (документы, изображения, смешанный контент) являются чрезвычайно подходящими кандидатами для хранения в реляционной форме.

В-третьих, SQL! = Реляционная. Обоснованием для продуктов NoSQL является то, что необходимы альтернативы SQL. Это не подлежит сомнению. К сожалению, сторонники NoSQL, как правило, основывают свои идеи на неправильном понимании того, что проблемы и ограничения СУБД SQL являются проблемами, присущими реляционной модели данных. Это не отдаленно верно. Можно было бы сделать сильный вывод о том, что наилучшим видом СУБД NoSQL будет реляционный.