Title: Хранение цепочки в MySQL Post by: ArsenShnurkov on May 11, 2012, 10:37:22 PM 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. Title: Re: Хранение цепочки в MySQL Post by: neo_rage on May 11, 2012, 10:40:43 PM А какое решение требуется?
Можно попробовать сконвертировать базу данных из клиента в mysql. Это разовое решение. Можно попробовать написать скрипт, который будет стартовать по крону и синхронизироваться с blockchain. Это постоянное решение. Задача несложная. Title: Re: Хранение цепочки в MySQL Post by: kimmeriets on May 12, 2012, 03:45:44 AM может лучше в экселовских таблицах?
Title: Re: Хранение цепочки в MySQL Post by: rPman on May 12, 2012, 07:55:34 AM Поддерживаю, проблема есть.
Для сервисов с сотнями тысяч клиентов кошелек разрастается до миллиона адресов, клиент тупо не справляется (mtgox запилили свой клиент для этого), btc-e/metabank/... решили проблему просто - один клиент = один адрес. mysql (и другие реляционные БД) предоставляют больше возможностей по администрированию (например репликация, кластеризация для горизонтальной масштабируемости). Title: Re: Хранение цепочки в MySQL Post by: Balthazar on May 12, 2012, 11:12:15 PM berkeleydb это, вообще-то, один из самых производительных движков для DB из существующих (steam его использует, к примеру.. да и даже в том же mysql раньше была возможность хранения таблиц в berkeleydb, пока оракл не начал давить патентами в свое время). И поддерживает в том числе и репликацию. Так что смысл сабжа непонятен... Переходить на заведомо более тормозное решение только лишь ради поддержки технологий, которые и так есть. ::)
Основной тормоз при загрузке блоков - это не база данных, а openssl. Оптимизация проверки хэша дает ускорение в 3-6 раз без проблем. Title: Re: Хранение цепочки в MySQL Post by: rPman on May 13, 2012, 06:32:24 AM berkeleydb это, вообще-то, один из самых производительных движков для DB из существующих (steam его использует, к примеру.. да и даже в том же mysql раньше была возможность хранения таблиц в berkeleydb, пока оракл не начал давить патентами в свое время). И поддерживает в том числе и репликацию. Так что смысл сабжа непонятен... Переходить на заведомо более тормозное решение только лишь ради поддержки технологий, которые и так есть. ::) Кошелек не предоставляет никакой гибкости по работе с адресами/аккаунтами, до сих пор не сделали нормального механизма запросить по RPC, сколько монет лежит на адресе (офф клиент), это так сложно?Основной тормоз при загрузке блоков - это не база данных, а openssl. Оптимизация проверки хэша дает ускорение в 3-6 раз без проблем. Самая часто выполняемая команда - listtransactions (просто потому что остальные get../list.. просто неадекватны по возможностям), на сколько она замедляется при увеличении кошелька? p.s. Когда кошелек становится размером с гигабайт, его резервное копирование уже не такое простое, как ожидается. Лично я еще не работал с такими крупными объемами на кошельке, но когда то читал на форуме в английской ветке, возможно в новых клиентах производительность увеличили? Подскажите, как настроить репликацию кошелька, средствами BerkeleyDB? Title: Re: Хранение цепочки в MySQL Post by: somenick on May 13, 2012, 08:18:02 AM меня тоже вставляет эта bdb, ибо нет sql,
если быбло бы в sqllite хотя бы, то можно было позырить все таблицы и так далее а с этим bdb жить нельзя вот нашёл https://bitcointalk.org/index.php?topic=50721.0 говорит что фигачит всё в postgres ну или как вариант самому с помощью rpc вытащить все транзакции все блоки и тд хотя это всё нужно делать ) вам нужна репликация кошелька (wallet) или базы всей ? https://bitcointalk.org/index.php?topic=22785.0 - это кажется даже работает Title: Re: Хранение цепочки в MySQL Post by: rPman on May 13, 2012, 11:25:43 AM Конечно же нужен собственный кошелек, хотя разделение мои адреса и чужие адреса считаю искусственными, инструмент работы с bitcoin должен одинаково работать как чужими адресами, так и со своими (только что не будет возможность создавать транзакции, использующие чужие, естественно).
abe и аналогичные утилиты работают с уже загруженной базой, т.е. необходимо закрыть клиент bitcoin, запустить утилиту синхронизации базы блоков с базой sql, после этого запустить клиент bitcoin (и так при каждом найденном блоке).. несколько неудобно/медленно, не находите? Я несколько месяцев не изучал вопрос, кажется с появлением libbitcoin и аналогов появились утилиты, работающие с блоками и текущими транзакциями в пуле нативно. Title: Re: Хранение цепочки в MySQL Post by: Balthazar on May 13, 2012, 03:28:41 PM berkeleydb это, вообще-то, один из самых производительных движков для DB из существующих (steam его использует, к примеру.. да и даже в том же mysql раньше была возможность хранения таблиц в berkeleydb, пока оракл не начал давить патентами в свое время). И поддерживает в том числе и репликацию. Так что смысл сабжа непонятен... Переходить на заведомо более тормозное решение только лишь ради поддержки технологий, которые и так есть. ::) Кошелек не предоставляет никакой гибкости по работе с адресами/аккаунтами, до сих пор не сделали нормального механизма запросить по RPC, сколько монет лежит на адресе (офф клиент), это так сложно?Основной тормоз при загрузке блоков - это не база данных, а openssl. Оптимизация проверки хэша дает ускорение в 3-6 раз без проблем. Самая часто выполняемая команда - listtransactions (просто потому что остальные get../list.. просто неадекватны по возможностям), на сколько она замедляется при увеличении кошелька? p.s. Когда кошелек становится размером с гигабайт, его резервное копирование уже не такое простое, как ожидается. Лично я еще не работал с такими крупными объемами на кошельке, но когда то читал на форуме в английской ветке, возможно в новых клиентах производительность увеличили? Подскажите, как настроить репликацию кошелька, средствами BerkeleyDB? 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, а с ее неполноценным использованием. И её замена на что-либо другое проблему никак не решит, потому что не она узкое место. Тормозят, в частности, потому что индексы не используются. Title: Re: Хранение цепочки в MySQL Post by: rPman on May 13, 2012, 03:56:20 PM Эээ... master-master репликация на базах online? (используемых на данный момент) это что то фантастическое... или все это великолепие работает при неблокированной базе (т.е. клиент bitcoin закрыт)?
Title: Re: Хранение цепочки в MySQL Post by: Balthazar on May 13, 2012, 08:58:07 PM Эээ... master-master репликация на базах online? (используемых на данный момент) это что то фантастическое... или все это великолепие работает при неблокированной базе (т.е. клиент bitcoin закрыт)? Для master-master и вообще какой бы то ни было репликации нужно чтобы использующее БД приложение было написано соответствующим образом, текущая реализация работы с БД не позволяет использовать подобный функционал т.к. в биткоине база используется не более как свалка ключей и значений. В этом плане, в общем, еще есть куда расти и очень далеко (как с master-master на berkeley db не в курсе, оракл вроде много на эту тему говорил... но master-slave достаточен в большинстве случаев и не является чем-то необычным для berkeley db).Вообще, в bitcoin предусмотрена возможность делать flush для валлета (эта процедура вызывается периодически сама, ну и при некоторых действиях, таких как скачивание блока, содержащего принадлежащую клиенту транзакцию), что существенно снизит риски при копировании "на горячую" (практически до нуля), но почему-то в RPC calls эта функция не реализована. Title: Re: Хранение цепочки в MySQL Post by: rPman on May 14, 2012, 05:37:07 AM Для того, чтобы безболезненно можно было работать с уже заблокированной базой bitcoin необходимо в RPC реализовать не flush, а flush-block и unblock-reread, при которых база будет переводиться в состояние, доступное для работы другим приложениям (и открывать естественно в режиме shared write), а при попытках записать что-либо между этими вызовами - блокировать работу клиента.
Что то мне говорит, если немного под суетиться, безо всяких изобретений новых вызовов одновременная работа с базой возможна и так, всего то сменить режим открытия базы и реализовать коллбаки на модификацию базы. в критических местах. Title: Re: Хранение цепочки в MySQL Post by: Balthazar on May 14, 2012, 06:36:07 AM Для того, чтобы безболезненно можно было работать с уже заблокированной базой bitcoin необходимо в RPC реализовать не flush, а flush-block и unblock-reread, при которых база будет переводиться в состояние, доступное для работы другим приложениям (и открывать естественно в режиме shared write), а при попытках записать что-либо между этими вызовами - блокировать работу клиента. Работать да. А для копирования и просто flush сойдет.Что то мне говорит, если немного под суетиться, безо всяких изобретений новых вызовов одновременная работа с базой возможна и так, всего то сменить режим открытия базы и реализовать коллбаки на модификацию базы. в критических местах. Title: Re: Хранение цепочки в MySQL Post by: rPman on May 14, 2012, 06:55:04 AM flush недостаточно, во время копирования может произойти очередная запись... хотя, если совместить с технологиями от операционных систем для такого копирования (теневое копирование windows или lvm/btrfs/nilfs/... - снапшотами), то уже нормально.
Только вот резервное копирование кошелька необходимо делать после каждой операции, а если он гигабайтового размера, то это несколько затруднительно (в пределах одной машины - так же снапшотами можно обойтись, а вот на соседний хост, уже никак). Title: Block chain vs. wallet storage. Post by: Yurock on September 01, 2012, 07:53:34 PM Цепочка блоков - общедоступная информация, большой объём. База блоков должна работать быстро.
Бумажник - личная информация, небольшой объём (у большинства пользователей). Бумажник должен работать надёжно. Совсем не обязательно использовать одну и ту же технологию для хранения первого и второго. резервное копирование кошелька необходимо делать после каждой операции Для чего?Title: Re: Хранение цепочки в MySQL Post by: btcsec on September 02, 2012, 02:34:02 PM Для чего? Ну не после каждой, конечно. Принимать можно сколько угодно не меняя бэкапа. А вот если отправлять монеты, то вполне возможно кошелек создаст для сдачи отдельный адрес, если свободные закончились. Тогда при восстановлении из бэкапа вся сдача потеряется.Title: Размер пула адресов. Post by: Yurock on September 02, 2012, 04:27:05 PM вполне возможно кошелек создаст для сдачи отдельный адрес, если свободные закончились. Пул адресов легко настраивается. Допустим, в сутки в среднем совершается 1000 транзакций. Автоматическое резервное копирование производится каждый день. Устанавливаем размер пула в 10000 адресов. Монеты из новых транзакций не пропадут, даже если 1-2 бекапа зафэйлятся.Title: Re: Хранение цепочки в MySQL Post by: btcsec on September 03, 2012, 11:03:20 AM Yurock
Это надо постоянно запускать кошелек с параметром -keypool=10000? Он точно будет пользоваться ранее сгенерированными адресами, а не последними? Title: Пул адресов Post by: Yurock on September 04, 2012, 05:35:30 PM Это надо постоянно запускать кошелек с параметром -keypool=10000? Так, или записатьCode: keypool=10000 Он точно будет пользоваться ранее сгенерированными адресами, а не последними? По идее, ключи из пула дожны использоваться в порядке генерации. Номера ключей хранятся в отсортированном массиве 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 ... Title: Re: Хранение цепочки в MySQL Post by: yo-blin on December 07, 2012, 12:22:22 PM А какое решение требуется? Можно попробовать сконвертировать базу данных из клиента в mysql. Это разовое решение. Задача несложная. как в Винде (наверно через rpc) получить в виде плоской таблики все блоки как в блокчейне ? Hash, Previous Block, Next Block, Height, и так далее |