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

Ответ 1

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

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

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

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

Файл таблицы /CSV

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

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

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

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

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

Amazon Simple DB

• Как и Беркли, я верю, но принимал

Хранилище Google App Engine

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

CouchDB

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

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

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

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

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

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

Ответ 2

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

• Структура: она явно разбивается на части или вы делаете компромиссы?
• Использование: как будут анализироваться/извлекаться данные /grokked?
• Lifetime: как долго данные полезны?
• Размер: сколько данных есть?

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

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

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

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

Ответ 3

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

Ответ 4

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

Ответ 5

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

http://www.hdfgroup.org/

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

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

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

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

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

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

Ответ 6

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

Ответ 7

G'day,

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

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

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

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

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

НТН.

веселит,

Rob

Ответ 8

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

Ответ 9

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

Ответ 10

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

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

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

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

Ответ 11

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

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

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

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

Ответ 12

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

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

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

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

Мерф

Ответ 13

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

Ответ 14

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

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

Ответ 15

Полнотекстовые базы данных, которые могут запрашиваться операторами близости, такими как "в пределах 10 слов" и т.д.

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

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

Ответ 16

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

Ответ 17

K.I.S.S: Держите его маленьким и простым

Ответ 18

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

Ответ 19

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

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

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

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

Ответ 20

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

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

Ответ 21

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

Потому что:

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

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