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

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

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

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

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

  • Вы преодолели разрыв с любыми шаблонами проектирования, например, перевести с одного на другого?

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

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

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

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

113 голосов | спросил Ian Varley 27 J000000Monday09 2009, 22:46:43

5 ответов


0

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

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

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

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

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

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

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

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

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

ответил nawroth 28 J000000Tuesday09 2009, 12:57:49
0

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

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

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

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

БД документов как бы меняет сложность: SQL имеет негибкие данные и гибкие запросы, а БД документов - наоборот.

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

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

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

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

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

Но все зависит от разработки представлений.

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

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

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

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

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

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

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

Вы преодолели разрыв с любыми шаблонами проектирования, например, перевести с одного на другой?

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

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

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

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

Извините, но никогда не делал много UML до БД документов :)

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

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

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

Компания, над которой я работал, создала продукт (веб-приложение), предназначенный для работы с базами данных SQL от разных поставщиков, и «дополнительные сервисы» настолько различны в разных БД, что их приходилось реализовывать отдельно для каждая БД. Поэтому для нас было меньше работы по переносу функциональности из СУБД. Это даже распространяется на полнотекстовый поиск.

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


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

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

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

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

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

ответил j-g-faustus 13 Mayam10 2010, 11:59:44
0

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

Harder:

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

проще:

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

Моделирование должно быть примерно таким же, но вы должны быть осторожны с тем, что вы положили в один документ: UML также можно использовать как для моделирования ОО, так и для моделирования БД, которые уже являются двумя разными животными.

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

ответил Rutger Nijlunsing 27 J000000Monday09 2009, 23:05:09
0

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

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

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

ответил xpda 27 J000000Monday09 2009, 23:11:08
0

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

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

ответил Stephan Eggermont 24 PM000000110000001631 2010, 23:01:16

Похожие вопросы

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132