Оптимизация производительности пут в Беркли БД - PullRequest
Новая
       5

Оптимизация производительности пут в Беркли БД

6 голосов
/ 29 сентября 2010

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

Вот некоторая информация о данных: - это входит в 512 байтовых кусков - куски приходят в порядок - фрагменты будут удалены в порядке FIFO - если я потеряю некоторые данные из-за сбоя питания, то все в порядке, пока целая база данных не сломана

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

Однако, после попытки некоторого тестового кода, мои самые быстрые результаты были около 1 МБайт в секунду, просто просматривая DB-> put с установленным DB_APPEND. Я также пытался использовать транзакции и массовые путы, но оба эти процесса значительно замедлились, поэтому я не занимался ими в течение длительного времени. Я вставлял в новую базу данных, созданную на чипе NANDFlash на моей плате разработчика Freescale i.MX35.

Поскольку мы стремимся получить скорость записи не менее 2 МБ / с, мне было интересно, что я пропустил, что может улучшить мои скорости, поскольку я знаю, что мое оборудование может писать быстрее, чем эта.

Ответы [ 2 ]

8 голосов
/ 29 сентября 2010

Попробуйте вставить это в свой DB_CONFIG: 

set_flags DB_TXN_WRITE_NOSYNC
set_flags DB_TXN_NOSYNC

По моему опыту, это значительно повышает производительность записи.

DB_TXN_NOSYNC Если установлено, Berkeley DBне будет записывать или синхронно очищать журнал при фиксации транзакции или подготовке.Это означает, что транзакции проявляют свойства ACI (атомарность, согласованность и изоляция), но не D (долговечность);то есть целостность базы данных будет сохранена, но если приложение или система не будут работать, возможно, что некоторое количество самых последних совершенных транзакций может быть отменено во время восстановления.Количество транзакций, подверженных риску, зависит от того, сколько обновлений журнала может поместиться в буфер журнала, как часто операционная система сбрасывает грязные буферы на диск и как часто проверяется журнал. Вызов DB_ENV-> set_flags с флагом DB_TXN_NOSYNC влияет только науказанный дескриптор DB_ENV (и любые другие дескрипторы DB Berkeley, открытые в области действия этого дескриптора).Для согласованного поведения в среде все дескрипторы DB_ENV, открытые в среде, должны либо установить флаг DB_TXN_NOSYNC, либо этот флаг должен быть указан в файле конфигурации DB_CONFIG.

Флаг DB_TXN_NOSYNC можно использовать для настройки БД Berkeley в любомвремя в течение срока службы приложения.

DB_TXN_WRITE_NOSYNC Если установлено, DB Berkeley будет записывать, но не будет синхронно сбрасывать, журнал при фиксации или подготовке транзакции.Это означает, что транзакции проявляют свойства ACI (атомарность, согласованность и изоляция), но не D (долговечность);то есть целостность базы данных будет сохранена, но если система выйдет из строя, возможно, некоторое количество самых последних принятых транзакций может быть отменено во время восстановления.Количество транзакций, подвергающихся риску, определяется тем, как часто система сбрасывает грязные буферы на диск и как часто проверяются контрольные точки журнала.Вызов DB_ENV-> set_flags с флагом DB_TXN_WRITE_NOSYNC влияет только на указанный дескриптор DB_ENV (и на любые другие дескрипторы Berkeley DB, открытые в области действия этого дескриптора).Для согласованного поведения в среде все дескрипторы DB_ENV, открытые в среде, должны либо установить флаг DB_TXN_WRITE_NOSYNC, либо этот флаг должен быть указан в файле конфигурации DB_CONFIG.

Флаг DB_TXN_WRITE_NOSYNC можно использовать для настройки БД Berkeley в любомвремя жизни приложения.

Подробнее см. http://www.mathematik.uni -ulm.de / help / BerkeleyDB / api_c / env_set_flags.html .

1 голос
/ 10 ноября 2010

Я предлагаю вам использовать хранилище данных транзакций / TDS, если, как вы упомянули, вы не можете воссоздать базу данных (то есть это не просто локальный кеш), если она повреждена.Если вы не заботитесь о потере нескольких элементов в случае сбоя / перебоя в питании, DB_TXN_WRITE_NOSYNC улучшит производительность TDS, ваша база данных по-прежнему будет цельной и восстановимой.Если вы храните с использованием BTREE и числового индекса (если у вас нет естественного ключа) и следите за порядковыми номерами, чтобы получить хорошую локализацию ключа и высокую загрузку страниц, то вы сможете получить более 2000 вставок в секунду, особенно дляSSD, особенно если вы используете DbMultileKeyDataBuilder для массовых вставок.

...