Мне интересно услышать о стратегиях проектирования, которые вы использовали с нереляционными базами данных "nosql", то есть о (в основном новом) классе хранилищ данных, которые не используют традиционный реляционный дизайн или SQL (например, Hypertable, CouchDB, SimpleDB, хранилище данных Google App Engine, Voldemort, Cassandra, SQL Data Services и т. Д.). Их также часто называют «хранилищами ключей и значений», и по сути они действуют как гигантские распределенные постоянные хеш-таблицы.
В частности, я хочу узнать о различиях в концептуальном дизайне данных с этими новыми базами данных. Что проще, что сложнее, чего вообще нельзя?
Вы придумали альтернативный дизайн, который лучше работает в нереляционном мире?
Вы ударились головой о что-нибудь, что кажется невозможным?
Устраняли ли вы пробел с помощью каких-либо шаблонов проектирования, например, для перевода с одного на другой?
Вы вообще сейчас создаете явные модели данных (например, в UML) или полностью отказались от них в пользу частично структурированных / документально-ориентированных больших двоичных объектов данных?
Вам не хватает каких-либо основных дополнительных услуг, которые предоставляют СУБД, таких как реляционная целостность, поддержка произвольно сложных транзакций, триггеры и т. Д.?
Я вырос в реляционной базе данных SQL, поэтому нормализация у меня в крови. Тем не менее, я получаю преимущества нереляционных баз данных в плане простоты и масштабируемости, и мое чутье подсказывает мне, что должно быть более широкое совпадение возможностей проектирования. Что вы наделали?
К вашему сведению, здесь были обсуждения StackOverflow на похожие темы:
Ответы:
Я думаю, вы должны учитывать, что нереляционные СУБД сильно различаются по своей модели данных, и поэтому концептуальный дизайн данных также будет сильно отличаться. В потоке « Дизайн данных в нереляционных базах данных» группы NOSQL Google различные парадигмы классифицируются следующим образом:
Я в основном увлекаюсь графическими базами данных , и именно элегантность проектирования данных с использованием этой парадигмы привела меня к этому, устав от недостатков РСУБД . Я поместил несколько примеров дизайна данных с использованием базы данных графов на этой вики-странице, а также есть пример того, как моделировать базовые данные IMDB о фильмах / актерах / ролях.
Презентационные слайды (слайд-шоу) « Графовые базы данных и будущее крупномасштабного управления знаниями » Марко Родригеса содержат очень хорошее введение в дизайн данных с использованием графической базы данных.
Отвечая на конкретные вопросы с точки зрения graphdb:
Альтернативный дизайн: добавление отношений между множеством различных типов объектов без каких-либо забот или необходимости заранее определять, какие объекты могут быть связаны.
Устранение разрыва: я стараюсь делать это по-разному для каждого случая, в зависимости от самой предметной области, поскольку мне не нужен «таблично-ориентированный граф» и тому подобное. Однако вот некоторая информация об автоматическом переводе из СУБД в graphdb.
Явные модели данных: я делаю это все время (стиль доски), а затем использую модель в том виде, в котором она есть в БД.
Мисс из мира СУБД: простые способы создания отчетов. Обновление: может быть , это не что трудно создать отчеты из базы данных графов, см Создание отчета для базы данных Neo4j образца .
источник
Я только начал работать с нереляционными базами данных и все еще пытаюсь осмыслить это и выяснить, какая модель будет лучшей. И я могу говорить только от лица CouchDB.
Тем не менее, у меня есть предварительные выводы:
Вы придумали альтернативный дизайн, который лучше работает в нереляционном мире?
Фокус дизайна смещается: дизайн модели документа (соответствующей таблицам БД) становится почти несущественным, в то время как все зависит от разработки представлений (соответствующих запросам).
Документная БД как бы меняет местами сложности: SQL имеет негибкие данные и гибкие запросы, документальные БД - наоборот.
Модель CouchDB представляет собой набор «документов JSON» (в основном вложенных хеш-таблиц). Каждый документ имеет уникальный идентификатор, и его можно легко получить по идентификатору. Для любого другого запроса вы пишете «представления», которые представляют собой именованные наборы функций отображения / сокращения. Представления возвращают набор результатов в виде списка пар ключ / значение.
Уловка заключается в том, что вы не запрашиваете базу данных в том смысле, в котором вы запрашиваете базу данных SQL: результаты выполнения функций представления хранятся в индексе, и можно запросить только индекс. (Как «получить все», «получить ключ» или «получить диапазон ключей».)
Самая близкая аналогия в мире SQL была бы, если бы вы могли запрашивать БД только с помощью хранимых процедур - каждый запрос, который вы хотите поддерживать, должен быть предопределен.
Дизайн документов чрезвычайно гибкий. Я нашел только два ограничения:
Но все зависит от оформления видов.
Я обнаружил, что альтернативные конструкции лучше работают с CouchDB, чем с любой базой данных SQL, на системном уровне, а не на уровне хранения. Если у вас есть некоторые данные и вы хотите передать их на веб-страницу, сложность всей системы снижается как минимум на 50%:
Для обычных веб-приложений БД на основе документов / JSON - это огромная победа, а недостатки менее гибких запросов и некоторого дополнительного кода для проверки данных кажутся небольшой платой.
Вы ударились головой о что-нибудь, что кажется невозможным?
Еще нет. Map / reduce как средство запроса к базе данных незнакомо и требует гораздо больше размышлений, чем написание SQL. Существует довольно небольшое количество примитивов, поэтому получение необходимых результатов - это в первую очередь вопрос творческого подхода к тому, как вы указываете ключи.
Существует ограничение в том, что запросы не могут просматривать два или более документов одновременно - никаких объединений или других видов многодокументных отношений, но до сих пор ничто не было непреодолимым.
В качестве примера ограничения подсчеты и суммы просты, но средние значения не могут быть рассчитаны с помощью представления / запроса CouchDB. Исправление: вернуть сумму и подсчитать отдельно и вычислить среднее значение для клиента.
Устраняли ли вы пробел с помощью каких-либо шаблонов проектирования, например, для перевода с одного на другой?
Я не уверен, что это возможно. Это скорее полный редизайн, вроде перевода программы функционального стиля в объектно-ориентированный стиль. В общем, типов документов гораздо меньше, чем таблиц SQL, и в каждом документе больше данных.
Один из способов подумать об этом - посмотреть на свой SQL на предмет вставок и общих запросов: какие таблицы и столбцы обновляются, например, когда покупатель размещает заказ? А какие для ежемесячных отчетов о продажах? Эта информация, вероятно, должна быть в том же документе.
То есть: один документ для заказа, содержащий идентификатор клиента и идентификаторы продукта, с реплицированными полями по мере необходимости для упрощения запросов. Все в документе можно легко запросить, все, что требует перекрестных ссылок между, скажем, Заказом и Заказчиком, должно выполняться клиентом. Поэтому, если вам нужен отчет о продажах по регионам, вам, вероятно, следует указать в заказе код региона.
Вы вообще сейчас делаете явные модели данных (например, в UML)?
Извините, я никогда не делал много UML до DB документов :)
Но вам нужна какая-то модель, говорящая, какие поля каким документам принадлежат и какие значения они содержат. Как для вашей справки позже, так и для того, чтобы убедиться, что все, использующие БД, знают соглашения. Поскольку вы больше не получаете сообщение об ошибке, если, например, сохраняете дату в текстовом поле, и каждый может добавить или удалить любое поле, которое ему нравится, вам понадобится как код проверки, так и соглашения, чтобы устранить провисание. Особенно, если вы работаете с внешними ресурсами.
Вам не хватает каких-либо основных дополнительных услуг, которые предоставляют РСУБД?
Нет. Но мой опыт - разработчик веб-приложений, мы имеем дело с базами данных только в той мере, в какой это необходимо :)
Компания, в которой я работал, создала продукт (веб-приложение), который был разработан для работы с базами данных SQL от нескольких поставщиков, а «дополнительные услуги» настолько отличаются от БД к БД, что их приходилось реализовывать отдельно для каждой БД. Таким образом, для нас было меньше работы по перемещению функциональности из СУБД. Это даже распространилось на полнотекстовый поиск.
Так что от того, от чего я отказываюсь, у меня вообще никогда не было. Очевидно, ваш опыт может отличаться.
Предостережение: сейчас я работаю над веб-приложением для финансовых данных, котировок акций и тому подобного. Это очень хорошо подходит для документной БД, с моей точки зрения, я получаю все преимущества БД (постоянство и запросы) без каких-либо проблем.
Но эти данные довольно независимы друг от друга, сложных реляционных запросов нет. Получайте последние котировки по тикеру, получайте котировки по тикеру и диапазону дат, получайте метаинформацию компании, вот и все. Другой пример, который я видел, - это приложение для блогов, и блоги также не характеризуются чрезвычайно сложными схемами баз данных.
Я пытаюсь сказать, что все успешные применения документных БД, о которых я знаю, были связаны с данными, которые изначально не имели много взаимосвязей: документы (как в поиске Google), сообщения в блогах, новостные статьи, финансовые данные. ,
Я ожидаю, что есть наборы данных, которые лучше сопоставляются с SQL, чем с моделью документа, поэтому я полагаю, что SQL выживет.
Но для тех из нас, кому нужен простой способ хранения и извлечения данных - а я подозреваю, что таких много, - базы данных документов (как в CouchDB) - находка.
источник
Я отвечаю на это с помощью CouchDB в глубине души, но я полагаю, что большинство из них будет справедливо и для других БД. Мы рассмотрели возможность использования CouchDB, но в конце концов отказались от него, поскольку наш доступ к данным заранее неизвестен и проблема не в масштабируемости.
Сильнее:
Полегче:
Моделирование должно быть примерно таким же, но вы должны быть осторожны с тем, что вы помещаете в один документ: UML также может использоваться как для объектно-ориентированного моделирования, так и для моделирования БД, которые уже являются двумя разными зверями.
Мне бы хотелось увидеть хорошую открытую объектно-ориентированную базу данных, хорошо интегрированную с C # / Silverlight. Просто сделать выбор еще сложнее. :)
источник
Плоские файлы долгое время считались непонятными и непрактичными для набора данных любого размера. Однако более быстрые компьютеры с большим объемом памяти позволяют загружать файл в память и сортировать его в реальном времени, по крайней мере, для достаточно небольших n и локальных однопользовательских приложений.
Например, обычно вы можете прочитать файл из 10 000 записей И отсортировать его по полю менее чем за полсекунды, что является приемлемым временем отклика.
Конечно, есть причины использовать базу данных вместо плоского файла - реляционные операции, целостность данных, многопользовательские возможности, удаленный доступ, большая емкость, стандартизация и т. Д., Но увеличенная скорость компьютера и объем памяти сделали манипуляции в памяти данных в некоторых случаях более практично.
источник
Реляционные базы данных, которые я вижу в реальной жизни, как правило, вообще не очень хорошо нормализованы, вопреки вашему утверждению. Когда меня спрашивают, дизайнеры говорят, что это в основном из-за производительности. RDBM не подходят для объединения, поэтому таблицы, как правило, слишком широки с точки зрения нормализации. Объектно-ориентированные базы данных, как правило, намного лучше справляются с этим.
Еще одна проблема, с которой у RDBM возникают проблемы, - это обработка ключей, зависящих от истории / времени.
источник