Что является примером нереляционной базы данных? Где / как они используются? - PullRequest
27 голосов
/ 15 октября 2008

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

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

Редактировать : Два других подобных вопроса были упомянуты в ответах:

Ответы [ 23 ]

14 голосов
/ 23 октября 2008

По общему признанию неясная, но интересная альтернатива упомянутым здесь типам баз данных - ассоциативная база данных , такая как предложения, от LazySoft Technology . Существует бесплатная личная версия, которую вы можете скачать и попробовать самостоятельно. Корпоративная версия также бесплатна, но требует обращения в компанию.

По сути, ассоциативная база данных позволяет вам хранить информацию практически так же, как это делает наш мозг: как вещи и ассоциации между этими вещами. Название «Предложения» происходит от того, как эта информация может быть представлена ​​в синтаксисе subject-verb-object :

  • Том является братом Лоры
  • Сан-Франциско находится в Калифорнии
  • Майк имеет кредитный лимит $ 10 000

Предложение может быть предметом или объектом другого предложения:

  • (Автобус 570 прибывает в 8:15 утра) в Воскресенье
  • Мэри говорит (пирог был испечен Уильямом)

Итак, все может быть сведено к сущностям и ассоциациям .

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

«Ассоциативная модель данных» - книга, доступная в формате PDF Симоном Уильямсом, одним из создателей предложений.

13 голосов
/ 15 октября 2008

Нереляционная документно-ориентированная база данных, которую мы рассматривали: Apache CouchDB .

Apache CouchDB - это распределенная, отказоустойчивая и не требующая схемы документно-ориентированная база данных, доступная через RESTful HTTP / JSON API. Помимо других функций, он обеспечивает надежную инкрементную репликацию с двунаправленным обнаружением и разрешением конфликтов, а также выполняет запрос и индексирование с использованием механизма таблично-ориентированного представления с JavaScript, выступающим в качестве языка определения представления по умолчанию.

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

11 голосов
/ 15 октября 2008
  • Плоский файл
    • CSV или другие данные с разделителями
    • * 1006 электронных таблиц *
    • / и т.д. / пароль
    • почтовые файлы mbox
  • Иерархическая
    • Реестр Windows
    • Subversion с использованием файловой системы FSFS вместо Berkley DB
9 голосов
/ 15 октября 2008

Любая база данных, которая претендует на то, чтобы быть базой данных «Беркли» или «Ключ / Значение», не является реляционной.

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

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

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

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

8 голосов
/ 15 октября 2008

Все базы данных изначально были нереляционными, только с появлением DB2 и Oracle в середине 1980-х годов они стали общими. До этого большинство баз данных были либо плоскими, либо иерархическими.

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

DB / 1 (настолько непонятный, что я даже не могу найти ссылку на википедию) была предшественницей IBM в прайм-тайм для DB2 (отсюда и название). Это было иерархически - в основном у вас был файл, который состоял из любого числа или «корневых» записей, обычно напрямую доступных по ключу. Каждая корневая запись может иметь любое количество дочерних записей, каждая из которых, в свою очередь, может иметь своих собственных дочерних записей. Чистым эффектом является индексный файл или корневые записи, где каждый корень является вершиной потенциальной древовидной структуры. Доступ к дочерним записям может быть сложным - существуют ограничения прямого доступа, поэтому обычно вам приходится обходить дерево в поисках нужной записи. «База данных» может содержать любое количество этих файлов, обычно связанных ключами.

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

7 голосов
/ 15 октября 2008

Хранилище данных Google App Engine :

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

5 голосов
/ 15 октября 2008

База данных истории PI от OSIsoft не является реляционной. Это сделано только для архивирования данных с метками времени. Он широко используется в промышленности, особенно в качестве внутренней базы данных для всех этих «панелей мониторинга».

В этом нет необходимости быть реляционным, поскольку нет соединений.

5 голосов
/ 03 января 2009

Другие два типа баз данных, которые еще не созданы:

  1. Репозитории контента - это базы данных, предназначенные для контента (то есть файлов, документов, изображений и т. Д.). Они обычно имеют дополнительные конструкции, такие как иерархический способ просмотра содержимого, поиска, преобразования между различными форматами, управления версиями и многое другое. Примеры - Alfresco, Documentum, JackRabbit, Day, OpenText и многие другие поставщики ECM.

  2. Каталоги, то есть Active Directory или каталоги LDAP. Это базы данных, разработанные для сценариев с низкой записью / высоким чтением и сильно распределенные по соединениям с большим географическим расстоянием / высокой задержкой. Хотя они в основном используются для аутентификации / авторизации, они не обязательно должны быть, если ваш вариант использования соответствует требованиям.

4 голосов
/ 16 ноября 2008

Нереляционные базы данных просто не соответствуют требованиям Codd. Intersystems Caché представляет собой полное переписывание / перепроектирование базы данных старой операционной системы Pick. Из того небольшого, что я прочитал о Caché, похоже, что это хорошо сделанный редизайн. Это позволяет программам .net получать доступ к базе данных так же, как это делает SQL. Caché запускает программы Pick OS без каких-либо изменений. Импортируя файлы Pick в Caché, вы по-прежнему можете запускать с ним свои старые приложения с зеленым экраном, а также писать новые программы с использованием .net, чтобы вы могли переходить на приложения Windows, не отказываясь от многолетнего проектирования данных, в которое вы уже вложили средства. Вот некоторые сведения о модели Pick DB. База данных Pick использует записи и поля переменной длины. Все таблицы имеют один уникальный ключ и доступны без чтения индекса. Пик разработал систему для использования алгоритма хеширования, который обычно считывает элемент с диска при первом физическом чтении (при условии, что обслуживание системы было выполнено правильно). Поля в Pick нетипизированы. Все данные хранятся в виде строки, и преобразование остается за программистом. Нули хранятся в виде пустой строки, поэтому ноль не занимает место на диске, как в SQL. Там нет необходимости для иностранных ключей. В «Реляционном мире» администратор баз данных должен создать таблицу заголовков заказов и таблицу позиций строк заказов. В «Pick Model» есть одна таблица. Примером может быть «Дата заказа» - это поле, в котором будет храниться количество дней с 13 декабря 1967 года (сборщик данных был включен впервые). У программистов Pick не было проблем с Y2k. 2-й столбец будет номер клиента. Большая разница в том, что когда вы попадете в столбец «Номер продукта», он будет «Многозначным» (несоответствие Кодда). Другими словами, база данных может обрабатывать 1-32000 товаров в этом столбце. Другие столбцы, такие как Количество по заказу, будут находиться в контролирующей / зависимой взаимосвязи с номером продукта и также будут многозначными. Когда вы перейдете к количеству отгруженного товара, Пик перейдет в третье измерение и будет иметь поле «Полуценное значение». У вас будет столбец с номером отгрузки, и он будет иметь многозначное значение для отдельной позиции и субзначное значение, содержащее количество отгрузки для этой строки для этого номера отгрузки. Внутренних соединений не требуется. Все данные для этого заказа хранятся в одной таблице и в одной записи. Никаких сиротских рядов никогда! Во-вторых, определение данных немного отличается. Наши словари могут содержать определения для данных, которых нет в этой таблице или которыми манипулируют. Несколько примеров: Имя клиента. Он будет определен как ‘Используйте столбец« Номер клиента »и верните поле« Имя »из таблицы клиентов. Другой пример - это расширение позиции, которое будет определено как вычисление количества * цена / цена в расчете на цену. Мне кажется, я где-то читал, что Каше утверждает, что у него более 100 000 установок.

4 голосов
/ 15 октября 2008

Размерные базы данных являются отличными примерами нереляционных баз данных. Они очень часто используются для «Business Dashboards» / «Business Intelligence» для KPI и других типов агрегированных или статистических данных. Они обычно заполняются из реляционных баз данных и в некоторых ситуациях могут обеспечивать более высокую производительность.

http://en.wikipedia.org/wiki/Dimensional_database

...