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

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

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

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

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

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

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

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

HTH.

ваше здоровье,

Роб

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

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

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

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

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

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

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

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

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

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

Простая БД Amazon

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

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

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

CouchDB

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Мерф

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

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

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

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

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

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

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

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

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

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

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

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

Custom (hand-written) storage engine / Potentially very high performance in required uses cases

http://www.hdfgroup.org/

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

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

HDF supports several different data models, including multidimensional arrays, raster images, and tables.

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

HDF5 is a suite that makes possible the management of extremely large and complex data collections.

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

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

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

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

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

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

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

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

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

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

K.I.S.S: будь маленьким и простым

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

Потому что:

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

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

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

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

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

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

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