Проектирование нереляционных баз данных [закрыто]

Question

Мне интересно услышать о стратегиях проектирования, которые вы использовали с нереляционные базы данных "nosql" - то есть (в основном новый) класс хранилищ данных, которые не используют традиционный реляционный дизайн или SQL (такие как Hypertable, CouchDB, SimpleDB, хранилище данных Google App Engine, Voldemort, Cassandra, SQL Data Services и т.д.).Их также часто называют "хранилищами ключей / значений", и в основе своей они действуют как гигантские распределенные постоянные хэш-таблицы.

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

• Придумали ли вы альтернативные проекты, которые намного лучше работают в нереляционном мире?

• Вы ударились головой обо что-нибудь, что кажется невозможным?

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

• Вы вообще сейчас занимаетесь явными моделями данных (напримерв UML) или вы полностью отказались от них в пользу полуструктурированных / ориентированных на документы больших двоичных объектов данных?

• Вам не хватает каких-либо основных дополнительных сервисов, предоставляемых СУБД, таких как реляционная целостность, поддержка произвольно сложных транзакций, триггеры и т.д.?

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

К вашему сведению, здесь были обсуждения StackOverflow на аналогичные темы:

• базы данных следующего поколения
• изменение схем для работы с Google App Engine
• выбор базы данных, ориентированной на документы

Answer 1

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

1. Системы, подобные Bigtable (HBase, Hypertable и т.д.)
2. Хранилища ключей и ценностей (Токио, Волан-де-Морт, и т.д.)
3. Базы данных документов (CouchDB, MongoDB и др.)
4. Базы данных графиков (AllegroGraph, Neo4j, Sesame и др.)

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

Слайды презентации (slideshare) Графические базы данных и будущее крупномасштабного управления знаниями Автор: Марко Родригес содержит также очень приятное введение в проектирование данных с использованием графической базы данных.

Ответы на конкретные вопросы с точки зрения graphdb:

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

Преодоление разрыва:Я склонен делать это по-разному для каждого случая, в зависимости от самого домена, поскольку мне не нужен "таблично-ориентированный граф" и тому подобное.Однако, вот некоторая информация об автоматическом переводе с RDBMS на graphdb.

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

Мисс из мира СУБД:простые способы создания отчетов.Обновить:может быть, это и не так это сложно создавать отчеты из графической базы данных, см. Создание отчета для образца базы данных Neo4J.

Answer 2

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

Тем не менее, у меня есть некоторые предварительные выводы:

Придумали ли вы альтернативные проекты, которые намного лучше работают в нереляционном мире?

Фокус на дизайне смещается:Дизайн модели документа (соответствующей таблицам базы данных) становится практически неактуальным, в то время как все зависит от проектирования представлений (соответствующих запросам).

База ДАННЫХ document DB как бы меняет местами сложности:SQL обладает негибкими данными и гибкими запросами, базы данных документов - наоборот.

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

Хитрость в том, что вы не запрашиваете базу данных в том смысле, в каком вы запрашиваете базу данных SQL:Результаты выполнения функций просмотра хранятся в индексе, и может быть запрошен только индекс.(Например, "получить все", "получить ключ" или "получить диапазон ключей".)

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

Дизайн документов чрезвычайно гибкий.Я нашел только два ограничения:

• Храните связанные данные вместе в одном документе, поскольку нет ничего, соответствующего объединению.
• Не делайте документы настолько большими, чтобы они обновлялись слишком часто (например, помещая все продажи компании за год в один документ), поскольку каждое обновление документа вызывает повторную индексацию.

Но все зависит от проектирования видов.

Альтернативные проекты, которые, как я обнаружил, на порядок лучше работают с CouchDB, чем с любой базой данных SQL, находятся на системном уровне, а не на уровне хранилища.Если у вас есть какие-то данные и вы хотите разместить их на веб-странице, сложность всей системы снижается как минимум на 50%:

• отсутствие разработки таблиц базы данных (незначительная проблема)
• нет промежуточного уровня ODBC / JDBC, все запросы и транзакции через http (умеренный выпуск)
• простое сопоставление базы данных с объектом из JSON, которое почти тривиально по сравнению с аналогичным в SQL (важно!)
• потенциально вы можете пропустить весь сервер приложений, поскольку вы можете спроектировать свои документы так, чтобы они извлекались непосредственно браузером с помощью AJAX, и добавить немного полировки JavaScript, прежде чем они будут отображаться в виде HTML. (ОГРОМНЫЙ!!)

Для обычных веб-приложений базы данных на основе документов / JSON - это огромный выигрыш, а недостатки менее гибких запросов и некоторого дополнительного кода для проверки данных кажутся небольшой ценой.

Вы ударились головой обо что-нибудь, что кажется невозможным?

Пока нет.Сопоставление / сокращение как средство запроса к базе данных незнакомо и требует гораздо больше размышлений, чем написание SQL.Существует довольно небольшое количество примитивов, поэтому получение необходимых вам результатов - это в первую очередь вопрос творческого подхода к указанию ключей.

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

В качестве примера ограничения, подсчеты и суммы просты, но средние значения не могут быть вычислены с помощью представления / запроса CouchDB.Исправить:Верните сумму и посчитайте отдельно и вычислите среднее значение по клиенту.

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

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

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

Это:Один документ для заказа, содержащий идентификатор клиента и продукта, с копируемыми полями по мере необходимости для упрощения запросов.Все, что содержится в документе, может быть легко запрошено, все, что требует перекрестных ссылок, скажем, между Заказом и Клиентом, должно быть выполнено клиентом.Поэтому, если вам нужен отчет о продажах по регионам, вам, вероятно, следует указать код региона в заказе.

Вы вообще сейчас занимаетесь явными моделями данных (напримерв UML)?

Извините, я тоже никогда не занимался UML до document DBs :)

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

Вам не хватает каких-либо основных дополнительных услуг, предоставляемых СУБД?

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

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

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

---

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

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

Я пытаюсь сказать, что все известные мне успешные применения баз данных документов были связаны с данными, которые изначально не имели особых взаимосвязей:Документы (как в поиске Google), записи в блогах, новостные статьи, финансовые данные.

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

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

Answer 3

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

Сильнее:

• Требует переосмысления на концептуальном уровне, так что это "сложнее", поскольку это просто другое.Поскольку вы должны заранее знать свои схемы доступа к данным, автоматический перевод применяться не может.Вам нужно было бы, по крайней мере, добавить шаблон доступа.
• Согласованность не обрабатывается базой данных, но должна быть обработана в приложении.Меньшее количество гарантий означает более легкую миграцию, отказоустойчивость и лучшую масштабируемость за счет более сложного приложения.Приложению приходится иметь дело с конфликтами и несоответствиями.
• Ссылки, которые пересекают документы (или ключ / значение), также должны обрабатываться на уровне приложения.
• Базы данных типа SQL имеют IDE, которые являются гораздо более зрелыми.Вы получаете множество библиотек поддержки (хотя многоуровневость этих библиотек значительно усложняет работу, чем это необходимо для SQL).

Легче:

• Быстрее, если вы знаете свои схемы доступа к данным.
• Миграция / отказоустойчивость базы данных упрощается, поскольку вам как программисту приложений не дается никаких обещаний.Хотя в конечном итоге вы получите согласованность.Вероятно.Наконец-то.Какое-то время.
• Один ключ / значение гораздо легче понять, чем одну строку из таблицы.Все (древовидные) связи уже установлены, и полные объекты могут быть распознаны.

Моделирование должно быть примерно таким же, но вы должны быть осторожны с тем, что вы помещаете в один документ:UML также может использоваться как для моделирования OO, так и для моделирования DB, что уже является двумя разными способами.

Мне бы хотелось видеть хорошую открытую базу данных OO, хорошо интегрированную с C # / Silverlight.Просто для того, чтобы сделать выбор еще более трудным.:)

Answer 4

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

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

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

Answer 5

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

Еще один момент, когда у СУБД возникают проблемы, - это обработка ключей, зависящих от истории / времени.