berkeleydb это, вообще-то, один из самых производительных движков для DB из существующих (steam его использует, к примеру.. да и даже в том же mysql раньше была возможность хранения таблиц в berkeleydb, пока оракл не начал давить патентами в свое время). И поддерживает в том числе и репликацию. Так что смысл сабжа непонятен... Переходить на заведомо более тормозное решение только лишь ради поддержки технологий, которые и так есть.
Основной тормоз при загрузке блоков - это не база данных, а openssl. Оптимизация проверки хэша дает ускорение в 3-6 раз без проблем.
Кошелек не предоставляет никакой гибкости по работе с адресами/аккаунтами, до сих пор не сделали нормального механизма запросить по RPC, сколько монет лежит на адресе (офф клиент), это так сложно?
Самая часто выполняемая команда - listtransactions (просто потому что остальные get../list.. просто неадекватны по возможностям), на сколько она замедляется при увеличении кошелька?
p.s. Когда кошелек становится размером с гигабайт, его резервное копирование уже не такое простое, как ожидается.
Лично я еще не работал с такими крупными объемами на кошельке, но когда то читал на форуме в английской ветке, возможно в новых клиентах производительность увеличили?
Подскажите, как настроить репликацию кошелька, средствами BerkeleyDB?
Скачиваете с сайта оракла пакет libdb соответствующей версии, в нем куча утилит для работы с БД.
db_dump/db_load - снятие текстового дампа с базы/восстановление базы из дампа (дампы намного больше по размеру, чем сама база)
db_hotbackup - копирование базы данных "как есть"
db_verify/db_recover - проверка на повреждения/исправление поврежденной БД
db_deadlock - демон, который можно использовать для разрешения возможных ситуаций со взаимными блокировками
db_checkpoint - демон, позволяющий создавать контрольные точки с настраиваемыми интервалами между ними
db_stat - отображает статистику по БД
db_sql - утилита, позволяющая сгенерировать скелет конструкций на языке С/С++ для работы с Berkeley DB, на основании заданной на языке SQL схемы
db_archive - создает список файлов журналов, которые надо бэкапить на случай полного разрушения БД
db_upgrade - обновление формата БД до текущей версии
ну и еще что-то там есть, сейчас по памяти не напишу.
По поводу списка транзакций и прочего суть в том, что все проблемы с производительностью связаны не с berkeley db, а с ее неполноценным использованием. И её замена на что-либо другое проблему никак не решит, потому что не она узкое место. Тормозят, в частности, потому что индексы не используются.
