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

Question

В настоящее время я пытаюсь выбрать поставщика базы данных.

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

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

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

или

2) использовали База данных объектов Versant и/или База данных объективности и/или Хранилище объектов прогресса

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

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

Все типы данных, которые я хотел бы хранить в базе данных, моделируются как объекты и используют std::list и std::vector, поэтому, естественно, объектная база данных имеет смысл.Я прочитал достаточно статей, чтобы убедить себя, что традиционная СУБД, вероятно, не то, что мне действительно нужно с точки зрения

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

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

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

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

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

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

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

Answer 1

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

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

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

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

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

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

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

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

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

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

Answer 2

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