Хранение цепочки в MySQL

[ArsenShnurkov]

We really wanted to keep the blockchain and wallet in MySQL database. But we don't have a technical solution yet.

I have a customized version of BitcoinJ that does just that.

[neo_rage]

А какое решение требуется?
Можно попробовать сконвертировать базу данных из клиента в mysql. Это разовое решение.
Можно попробовать написать скрипт, который будет стартовать по крону и синхронизироваться с blockchain. Это постоянное решение.

Задача несложная.

[kimmeriets]

может лучше в экселовских таблицах?

[rPman]

Поддерживаю, проблема есть.
Для сервисов с сотнями тысяч клиентов кошелек разрастается до миллиона адресов, клиент тупо не справляется (mtgox запилили свой клиент для этого), btc-e/metabank/... решили проблему просто - один клиент = один адрес.

mysql (и другие реляционные БД) предоставляют больше возможностей по администрированию (например репликация, кластеризация для горизонтальной масштабируемости).

[Balthazar]

berkeleydb это, вообще-то, один из самых производительных движков для DB из существующих (steam его использует, к примеру.. да и даже в том же mysql раньше была возможность хранения таблиц в berkeleydb, пока оракл не начал давить патентами в свое время). И поддерживает в том числе и репликацию. Так что смысл сабжа непонятен... Переходить на заведомо более тормозное решение только лишь ради поддержки технологий, которые и так есть.

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

[rPman]

berkeleydb это, вообще-то, один из самых производительных движков для DB из существующих (steam его использует, к примеру.. да и даже в том же mysql раньше была возможность хранения таблиц в berkeleydb, пока оракл не начал давить патентами в свое время). И поддерживает в том числе и репликацию. Так что смысл сабжа непонятен... Переходить на заведомо более тормозное решение только лишь ради поддержки технологий, которые и так есть.

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

Кошелек не предоставляет никакой гибкости по работе с адресами/аккаунтами, до сих пор не сделали нормального механизма запросить по RPC, сколько монет лежит на адресе (офф клиент), это так сложно?
Самая часто выполняемая команда - listtransactions (просто потому что остальные get../list.. просто неадекватны по возможностям), на сколько она замедляется при увеличении кошелька?

p.s. Когда кошелек становится размером с гигабайт, его резервное копирование уже не такое простое, как ожидается.
Лично я еще не работал с такими крупными объемами на кошельке, но когда то читал на форуме в английской ветке, возможно в новых клиентах производительность увеличили?

Подскажите, как настроить репликацию кошелька, средствами BerkeleyDB?

[somenick]

меня тоже вставляет эта bdb, ибо нет sql,
если быбло бы в sqllite хотя бы, то можно было позырить все таблицы и так далее
а с этим bdb жить нельзя

вот нашёл
https://bitcointalk.org/index.php?topic=50721.0
говорит что фигачит всё в postgres

ну или как вариант самому с помощью rpc вытащить все транзакции все блоки и тд
хотя это всё нужно делать )

вам нужна репликация кошелька (wallet) или базы всей ?

https://bitcointalk.org/index.php?topic=22785.0
- это кажется даже работает

[rPman]

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

abe и аналогичные утилиты работают с уже загруженной базой, т.е. необходимо закрыть клиент bitcoin, запустить утилиту синхронизации базы блоков с базой sql, после этого запустить клиент bitcoin (и так при каждом найденном блоке).. несколько неудобно/медленно, не находите?

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

[Balthazar]

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, а с ее неполноценным использованием. И её замена на что-либо другое проблему никак не решит, потому что не она узкое место. Тормозят, в частности, потому что индексы не используются.

[rPman]

Эээ... master-master репликация на базах online? (используемых на данный момент) это что то фантастическое... или все это великолепие работает при неблокированной базе (т.е. клиент bitcoin закрыт)?

[Balthazar]

Эээ... master-master репликация на базах online? (используемых на данный момент) это что то фантастическое... или все это великолепие работает при неблокированной базе (т.е. клиент bitcoin закрыт)?

Для master-master и вообще какой бы то ни было репликации нужно чтобы использующее БД приложение было написано соответствующим образом, текущая реализация работы с БД не позволяет использовать подобный функционал т.к. в биткоине база используется не более как свалка ключей и значений. В этом плане, в общем, еще есть куда расти и очень далеко (как с master-master на berkeley db не в курсе, оракл вроде много на эту тему говорил... но master-slave достаточен в большинстве случаев и не является чем-то необычным для berkeley db).

Вообще, в bitcoin предусмотрена возможность делать flush для валлета (эта процедура вызывается периодически сама, ну и при некоторых действиях, таких как скачивание блока, содержащего принадлежащую клиенту транзакцию), что существенно снизит риски при копировании "на горячую" (практически до нуля), но почему-то в RPC calls эта функция не реализована.

[rPman]

Для того, чтобы безболезненно можно было работать с уже заблокированной базой bitcoin необходимо в RPC реализовать не flush, а flush-block и unblock-reread, при которых база будет переводиться в состояние, доступное для работы другим приложениям (и открывать естественно в режиме shared write), а при попытках записать что-либо между этими вызовами - блокировать работу клиента.

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

[Balthazar]

Для того, чтобы безболезненно можно было работать с уже заблокированной базой bitcoin необходимо в RPC реализовать не flush, а flush-block и unblock-reread, при которых база будет переводиться в состояние, доступное для работы другим приложениям (и открывать естественно в режиме shared write), а при попытках записать что-либо между этими вызовами - блокировать работу клиента.

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

Работать да. А для копирования и просто flush сойдет.

[rPman]

flush недостаточно, во время копирования может произойти очередная запись... хотя, если совместить с технологиями от операционных систем для такого копирования (теневое копирование windows или lvm/btrfs/nilfs/... - снапшотами), то уже нормально.

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

[Yurock]

Цепочка блоков - общедоступная информация, большой объём. База блоков должна работать быстро.
Бумажник - личная информация, небольшой объём (у большинства пользователей). Бумажник должен работать надёжно.
Совсем не обязательно использовать одну и ту же технологию для хранения первого и второго.

резервное копирование кошелька необходимо делать после каждой операции

Для чего?

[btcsec]

Для чего?

Ну не после каждой, конечно. Принимать можно сколько угодно не меняя бэкапа. А вот если отправлять монеты, то вполне возможно кошелек создаст для сдачи отдельный адрес, если свободные закончились. Тогда при восстановлении из бэкапа вся сдача потеряется.

[Yurock]

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

Пул адресов легко настраивается. Допустим, в сутки в среднем совершается 1000 транзакций. Автоматическое резервное копирование производится каждый день. Устанавливаем размер пула в 10000 адресов. Монеты из новых транзакций не пропадут, даже если 1-2 бекапа зафэйлятся.

[btcsec]

Yurock
Это надо постоянно запускать кошелек с параметром -keypool=10000? Он точно будет пользоваться ранее сгенерированными адресами, а не последними?
 

[Yurock]

Это надо постоянно запускать кошелек с параметром -keypool=10000?

Так, или записать

Code:

keypool=10000

в bitcoin.conf.

Он точно будет пользоваться ранее сгенерированными адресами, а не последними?

По идее, ключи из пула дожны использоваться в порядке генерации. Номера ключей хранятся в отсортированном массиве CWallet::setKeyPool. Функция CWallet::TopUpKeyPool добавляет ключи с большими номерами, которые оказываются в конце массива, а функция CWallet::ReserveKeyFromKeyPool берёт ключи с номерами из начала массива. Массив сохраняется в файле бумажника. Вот, например, как bitcoind выдаёт новый адрес:

Value getnewaddress(const Array& params, bool fHelp)
{
...
    if (!pwalletMain->GetKeyFromPool(newKey, false))
...

bool CWallet::GetKeyFromPool(vector<unsigned char>& result, bool fAllowReuse)
{
...
        ReserveKeyFromKeyPool(nIndex, keypool);
...

void CWallet::ReserveKeyFromKeyPool(int64& nIndex, CKeyPool& keypool)
{
...
            TopUpKeyPool();

        // Get the oldest key
...

[yo-blin]

А какое решение требуется?
Можно попробовать сконвертировать базу данных из клиента в mysql. Это разовое решение.
Задача несложная.

как в Винде (наверно через rpc) получить в виде плоской таблики все блоки как в блокчейне ?
Hash, Previous Block, Next Block, Height, и так далее