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

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

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

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

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

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

Таблица / файл CSV

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

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

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

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

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

Простая БД Amazon

• Во многом похоже на Berkeley DB, но на хостинге

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

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

CouchDB

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

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

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

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

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

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

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

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

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

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

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

Заметьте, я больше привык думать о «больших» размерах.

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

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

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

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

http://www.hdfgroup.org/

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

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

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

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

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

Подумайте о петабайтах данных дистанционного зондирования NASA / JPL.

Доброго времени суток,

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

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

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

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

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

HTH.

ура,

Роб

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

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

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

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

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

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

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

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

Такие сервисы, как Amazon S3, предоставляют более простые модели хранения (ключ-> значение), которые не поддерживают SQL. Масштабируемость - ключ к успеху.

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

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

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

Для нас это все - мы либо собираемся использовать что-то, что будет делать SQL (MS предлагает набор инструментов, которые запускаются из .DLL для выполнения однопользовательских вещей на всем пути до корпоративного сервера, и все они говорят на одном и том же SQL (с ограничениями на нижнем уровне)) или мы собираемся использовать XML в качестве формата, потому что (для нас) многословие редко является проблемой.

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

Мерф

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

Файлы BTree часто намного быстрее, чем реляционные базы данных. SQLite содержит в себе библиотеку BTree, которая находится в общественном достоянии (как действительно «общественное достояние», без использования этого термина).

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

Полнотекстовые базы данных, которые можно запрашивать с помощью операторов близости, таких как «в пределах 10 слов от» и т. Д.

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

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

Также: * Встроенные сценарии - где обычно требуется использовать что-то меньшее, чем полноценная СУБД. Db4o - это ODB, который можно легко использовать в таком случае. * Быстрая разработка или отработка концепции - когда вы хотите сосредоточиться на бизнесе и не беспокоиться об уровне устойчивости

Теорема CAP лаконично объясняет это. SQL в основном обеспечивает «сильную согласованность: все клиенты видят одно и то же представление, даже при наличии обновлений».

KISS: будь маленьким и простым

Я бы предложил СУБД :) Если у вас нет проблем с настройкой / администрированием, переходите на SQLite. Встроенная СУБД с полной поддержкой SQL. Он даже позволяет хранить данные любого типа в любом столбце.

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

О полнотекстовом поиске: SQLite также имеет модули для полнотекстового поиска ..

Просто наслаждайтесь приятным стандартным интерфейсом для ваших данных :)

Одна из веских причин не использовать реляционную базу данных - это когда у вас большой набор данных и вы хотите выполнять массовую параллельную и распределенную обработку данных. Веб-индекс Google был бы прекрасным примером такого случая.

Hadoop также имеет реализацию файловой системы Google, называемую распределенной файловой системой Hadoop .

Я настоятельно рекомендую Lua в качестве альтернативы хранилищу данных типа SQLite.

Так как:

• Язык был разработан как язык описания данных с самого начала.
• Синтаксис удобочитаем (XML - нет )
• Для повышения производительности можно скомпилировать фрагменты Lua в двоичный файл.

Это вариант «сборник на родном языке» принятого ответа. Если вы используете C / C ++ в качестве уровня приложения, вполне разумно добавить движок Lua (100 КБ двоичного кода) только для чтения конфигураций / данных или их записи.