БД основной памяти vs объектная БД

Question

Я сейчас пытаюсь выбрать поставщика базы данных.

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

Мой вопрос особенно направлен на людей, которые:

1) ранее использовали БД основной памяти (MMDB), которая поддерживает репликацию на диск (гибрид) (т. Е. ExtremeDB )

или

2) использовали База данных объектов Versant и / или База данных объективности и / или Progress ObjectStore

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

Мое приложение - это коммерческое объектно-ориентированное приложение C ++ GIS, работающее в режиме реального времени (читай: высокопроизводительное), в котором нам нужно много выполнять поиск по широте / долготе (т. Е. По заданной области найти все подходящие цели в пределах площадь ... Индекс R-Tree).

Все типы данных, которые я хотел бы сохранить в базе данных, смоделированы как объекты и используют std :: list и std :: vector, поэтому, естественно, Object Database имеет смысл. Я прочитал достаточно статей, чтобы убедить себя, что традиционная RDBMS, вероятно, не то, что я действительно ищу с точки зрения

1. производительность (объединение или несколько таблицы для данных динамической длины, таких как список / вектор)
2. простота программирования (несоответствие импеданса)

Однако, с точки зрения производительности,

1. Входные данные поступают в систему со скоростью около 40 МБ / с.

2. Следовательно, система также будет выполнять вставку в базу данных со скоростью примерно 350 вставок в секунду (где каждый объект варьируется от 64 КБ до 128 КБ),

3. База данных будет постоянно искать и обновлять через несколько потоков.

Насколько я понимаю, все объектные БД, которые я перечислил здесь, используют кеш для хранения объектов базы данных. ExtremeDB утверждает, что, поскольку он разработан специально для памяти, он может избежать накладных расходов на логику кэширования и т. Д. Узнайте больше, прибегая к помощи Google: основная память и базы данных RAM-Disk: тест на основе Linux

Итак ... Я просто немного сбит с толку. Можно ли использовать объектные БД в системе реального времени? Это так же быстро, как MMDB?

Answer 1

По сути, я различие между MMDB и OODB в том, что MMDB ожидает, что все его данные основаны на RAM, но в какой-то момент сохраняются на диске. Принимая во внимание, что OODB является более обычным в том смысле, что не ожидается, что вся БД вписывается в ОЗУ.

MMDB может использовать это, отказавшись от концепции, что постоянные данные не обязательно должны «соответствовать» данным в оперативной памяти.

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

Почти все БД для этого используют какой-то журнал. Эти журналы в основном представляют собой «сырые» страницы данных или, возможно, отдельные транзакции, добавленные в файл. Когда файл становится слишком большим, запускается новый файл.

Как только журналы правильно объединены в основном хранилище, журналы отбрасываются (или используются повторно).

Теперь необработанная БД в ОЗУ может существовать, просто добавляя транзакции в файл журнала, а при перезапуске просто загружает журнал в ОЗУ. Итак, по сути, файл журнала является базой данных.

Недостатком этого метода является то, что чем больше и больше транзакций у вас есть, тем больше ваш журнал / БД и, следовательно, тем больше время запуска БД. Но в идеале вы также можете «снимать» текущее состояние, что устраняет все журналы в актуальном состоянии и эффективно сжимает их.

Таким образом, все рутинные операции, выполняемые БД, - это добавление страниц в журналы, а не обновление других страниц диска, страниц индекса и т. Д. Поскольку в идеале большинству систем не требуется «запуск» что часто, возможно, время запуска не так важно.

Таким образом, таким образом, MMDB может быть быстрее, чем OODB, который имеет другой контракт с диском, поддерживая журналы и страницы диска. Таким образом, OODB может работать медленнее, даже если вся БД помещается в ОЗУ и должным образом кэшируется, просто потому, что вы выполняете дисковые операции вне операций журнала во время обычных операций, по сравнению с MMDB, где эти операции выполняются как «обслуживание». задание, которое можно запланировать во время простоя и / или тихого времени.

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

Answer 2

Внутренние части баз данных (процессы чтения и записи, кэширование, управление блокировками, файлы журнала txn, семантика ACID) одинаковы, поэтому RDB и OODB на самом деле очень похожи здесь. Разница заключается в интерфейсе приложения-программиста. Сложна ли ваша модель данных, состоит из множества классов с реальными отношениями наследования? Тогда ОО это хорошо. Это относительно плоский и простой? Тогда иди в RDB. Какова природа отношений? Это как указатель и как? Тогда иди в RDB. Это сложнее, как (упорядоченный) список, массив, карта? Тогда ты должен идти OO. Кроме того, у вас есть автономное приложение без необходимости интеграции с другими приложениями? Тогда ОО в порядке. Нужно ли вам обмениваться данными с другими приложениями (т. Е. Несколько приложений обращаются к одной базе данных)? Тогда это соглашение для OO, и вы должны придерживаться RDB. Стабильна ли схема вашей базы данных или вы ожидаете ее частого развития? OODB - плохая эволюция схемы рекламы, поэтому, если вы ожидаете частых изменений, используйте RDB.