Хорошие причины НЕ использовать реляционную базу данных?

Question

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

Answer 1

Обычные текстовые файлы в файловой системе

• Очень просто создавать и редактировать
• Легко для пользователей манипулировать с помощью простых инструментов (например, текстовые редакторы, grep и т. Д.)
• Эффективное хранение двоичных документов

---

XML или JSON файлы на диске

• Как и выше, но с немного большей способностью проверять структуру.

---

Электронная таблица / CSV-файл

• Очень простая модель для бизнес-пользователей, чтобы понять

---

Subversion (или аналогичная дисковая система контроля версий)

• Очень хорошая поддержка для контроля версий данных

---

Berkeley DB (в основном, хеш-таблица на основе диска)

• Очень просто концептуально (просто нетипизированный ключ / значение)
• Довольно быстро
• Никаких административных расходов
• Поддерживает транзакции, которые я считаю

---

Простая база данных Amazon

• Очень похоже на Беркли Д.Б., я верю, но принимал

---

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

• Хостинг и масштабируемость
• Хранение значения ключа для каждого документа (т.е. гибкая модель данных)

---

CouchDB

• Фокус документа
• Простое хранение полуструктурированных / основанных на документе данных

---

Коллекции родного языка (хранящиеся в памяти или сериализированные на диске)

• Очень тесная языковая интеграция

---

Пользовательский (рукописный) механизм хранения

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

---

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

Answer 2

Ответ Мэтта Шеппарда великолепен (мод), но я бы учел эти факторы, когда думал о шпинделе:

1. Структура: она явно разбивается на куски, или вы делаете компромиссы?
2. Использование: как данные будут проанализированы / извлечены / обработаны?
3. Срок службы: как долго полезны данные?
4. Размер: сколько там данных?

Одно особое преимущество CSV-файлов перед RDBMS заключается в том, что их можно легко уплотнить и перемещать практически на любую другую машину. Мы осуществляем передачу больших объемов данных, и все достаточно просто, мы просто используем один большой файл CSV и легко пишем с помощью таких инструментов, как rsync. Чтобы уменьшить количество повторений в больших CSV-файлах, вы можете использовать что-то вроде YAML . Я не уверен, что буду хранить что-либо вроде JSON или XML, если только у вас не будет существенных требований к отношениям.

Что касается не упомянутых альтернатив, не стоит сбрасывать со счетов Hadoop , который представляет собой реализацию MapReduce с открытым исходным кодом. Это должно хорошо работать, если у вас есть тонна свободно структурированных данных, которые необходимо проанализировать, и вы хотите оказаться в сценарии, когда вы можете просто добавить еще 10 машин для обработки данных.

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

Примечание Я более привык думать о "больших" размерах.

Answer 3

Файловая система prety удобна для хранения двоичных данных, которая никогда не работает на удивление хорошо в реляционных базах данных.

Answer 4

Если вам не нужна ACID , вам, вероятно, не нужны служебные данные СУБД. Итак, сначала определите, нужно ли вам это. Большинство ответов, не относящихся к СУБД, представленных здесь, , а не , предоставляют ACID.

Answer 5

Попробуйте Prevayler: http://www.prevayler.org/wiki/ Превайлер является альтернативой СУБД. На сайте есть дополнительная информация.

Answer 6

Пользовательский (рукописный) механизм хранения / Потенциально очень высокая производительность в необходимых случаях использования

http://www.hdfgroup.org/

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

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

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

Он также иерархичен, как файловая система, но данные хранятся в одном магическом двоичном файле.

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

Вспомните петабайты данных дистанционного зондирования НАСА / JPL.

Answer 7

G'day,

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

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

Почти во всех этих случаях используется OO DB , либо коммерческий продукт, либо самозакрученная система, которая допускает иерархию объектов.

Я работал над приложением по мониторингу 3G для крупной компании, которая останется безымянной, но с логотипом, окрашенным в красное вино (-: ячейки в сети.

Опрос таких БД выполняется с использованием запатентованных методов, которые, как правило, полностью свободны от SQL.

НТН.

ура

Rob

Answer 8

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

Answer 9

Существовал RAD-инструмент под названием JADE , написанный несколько лет назад и имеющий встроенную OODBMS. Более ранние воплощения движка DB также поддерживали Digitalk Smalltalk. Если вы хотите попробовать создать приложение с использованием не-RDBMS-парадигмы, это может быть началом.

Другие продукты OODBMS включают в себя Объективность , GemStone (Вам потребуется получить VisualWorks Smalltalk для запуска версии Smalltalk, но также есть и версия Java). В этом пространстве были также некоторые исследовательские проекты с открытым исходным кодом - на ум приходят EXODUS и его потомок SHORE.

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

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

Answer 10

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