ArsenShnurkov (OP)
Legendary
Offline
Activity: 1386
Merit: 1000
|
|
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.
|
|
|
|
|
|
|
|
According to NIST and ECRYPT II, the cryptographic algorithms used in
Bitcoin are expected to be strong until at least 2030. (After that, it
will not be too difficult to transition to different algorithms.)
|
|
|
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction.
|
|
|
|
neo_rage
|
|
May 11, 2012, 10:40:43 PM |
|
А какое решение требуется? Можно попробовать сконвертировать базу данных из клиента в mysql. Это разовое решение. Можно попробовать написать скрипт, который будет стартовать по крону и синхронизироваться с blockchain. Это постоянное решение.
Задача несложная.
|
|
|
|
kimmeriets
Legendary
Offline
Activity: 1064
Merit: 1000
|
|
May 12, 2012, 03:45:44 AM |
|
может лучше в экселовских таблицах?
|
|
|
|
rPman
Legendary
Offline
Activity: 1120
Merit: 1069
|
|
May 12, 2012, 07:55:34 AM |
|
Поддерживаю, проблема есть. Для сервисов с сотнями тысяч клиентов кошелек разрастается до миллиона адресов, клиент тупо не справляется (mtgox запилили свой клиент для этого), btc-e/metabank/... решили проблему просто - один клиент = один адрес.
mysql (и другие реляционные БД) предоставляют больше возможностей по администрированию (например репликация, кластеризация для горизонтальной масштабируемости).
|
|
|
|
Balthazar
Legendary
Offline
Activity: 3108
Merit: 1358
|
|
May 12, 2012, 11:12:15 PM |
|
berkeleydb это, вообще-то, один из самых производительных движков для DB из существующих (steam его использует, к примеру.. да и даже в том же mysql раньше была возможность хранения таблиц в berkeleydb, пока оракл не начал давить патентами в свое время). И поддерживает в том числе и репликацию. Так что смысл сабжа непонятен... Переходить на заведомо более тормозное решение только лишь ради поддержки технологий, которые и так есть. Основной тормоз при загрузке блоков - это не база данных, а openssl. Оптимизация проверки хэша дает ускорение в 3-6 раз без проблем.
|
|
|
|
rPman
Legendary
Offline
Activity: 1120
Merit: 1069
|
|
May 13, 2012, 06:32:24 AM |
|
berkeleydb это, вообще-то, один из самых производительных движков для DB из существующих (steam его использует, к примеру.. да и даже в том же mysql раньше была возможность хранения таблиц в berkeleydb, пока оракл не начал давить патентами в свое время). И поддерживает в том числе и репликацию. Так что смысл сабжа непонятен... Переходить на заведомо более тормозное решение только лишь ради поддержки технологий, которые и так есть. Основной тормоз при загрузке блоков - это не база данных, а openssl. Оптимизация проверки хэша дает ускорение в 3-6 раз без проблем. Кошелек не предоставляет никакой гибкости по работе с адресами/аккаунтами, до сих пор не сделали нормального механизма запросить по RPC, сколько монет лежит на адресе (офф клиент), это так сложно? Самая часто выполняемая команда - listtransactions (просто потому что остальные get../list.. просто неадекватны по возможностям), на сколько она замедляется при увеличении кошелька? p.s. Когда кошелек становится размером с гигабайт, его резервное копирование уже не такое простое, как ожидается. Лично я еще не работал с такими крупными объемами на кошельке, но когда то читал на форуме в английской ветке, возможно в новых клиентах производительность увеличили?
Подскажите, как настроить репликацию кошелька, средствами BerkeleyDB?
|
|
|
|
somenick
Legendary
Offline
Activity: 1286
Merit: 1004
|
|
May 13, 2012, 08:18:02 AM Last edit: May 13, 2012, 10:52:56 AM by 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
Legendary
Offline
Activity: 1120
Merit: 1069
|
|
May 13, 2012, 11:25:43 AM |
|
Конечно же нужен собственный кошелек, хотя разделение мои адреса и чужие адреса считаю искусственными, инструмент работы с bitcoin должен одинаково работать как чужими адресами, так и со своими (только что не будет возможность создавать транзакции, использующие чужие, естественно).
abe и аналогичные утилиты работают с уже загруженной базой, т.е. необходимо закрыть клиент bitcoin, запустить утилиту синхронизации базы блоков с базой sql, после этого запустить клиент bitcoin (и так при каждом найденном блоке).. несколько неудобно/медленно, не находите?
Я несколько месяцев не изучал вопрос, кажется с появлением libbitcoin и аналогов появились утилиты, работающие с блоками и текущими транзакциями в пуле нативно.
|
|
|
|
Balthazar
Legendary
Offline
Activity: 3108
Merit: 1358
|
|
May 13, 2012, 03:28:41 PM |
|
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
Legendary
Offline
Activity: 1120
Merit: 1069
|
|
May 13, 2012, 03:56:20 PM |
|
Эээ... master-master репликация на базах online? (используемых на данный момент) это что то фантастическое... или все это великолепие работает при неблокированной базе (т.е. клиент bitcoin закрыт)?
|
|
|
|
Balthazar
Legendary
Offline
Activity: 3108
Merit: 1358
|
|
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 эта функция не реализована.
|
|
|
|
rPman
Legendary
Offline
Activity: 1120
Merit: 1069
|
|
May 14, 2012, 05:37:07 AM |
|
Для того, чтобы безболезненно можно было работать с уже заблокированной базой bitcoin необходимо в RPC реализовать не flush, а flush-block и unblock-reread, при которых база будет переводиться в состояние, доступное для работы другим приложениям (и открывать естественно в режиме shared write), а при попытках записать что-либо между этими вызовами - блокировать работу клиента.
Что то мне говорит, если немного под суетиться, безо всяких изобретений новых вызовов одновременная работа с базой возможна и так, всего то сменить режим открытия базы и реализовать коллбаки на модификацию базы. в критических местах.
|
|
|
|
Balthazar
Legendary
Offline
Activity: 3108
Merit: 1358
|
|
May 14, 2012, 06:36:07 AM |
|
Для того, чтобы безболезненно можно было работать с уже заблокированной базой bitcoin необходимо в RPC реализовать не flush, а flush-block и unblock-reread, при которых база будет переводиться в состояние, доступное для работы другим приложениям (и открывать естественно в режиме shared write), а при попытках записать что-либо между этими вызовами - блокировать работу клиента.
Что то мне говорит, если немного под суетиться, безо всяких изобретений новых вызовов одновременная работа с базой возможна и так, всего то сменить режим открытия базы и реализовать коллбаки на модификацию базы. в критических местах.
Работать да. А для копирования и просто flush сойдет.
|
|
|
|
rPman
Legendary
Offline
Activity: 1120
Merit: 1069
|
|
May 14, 2012, 06:55:04 AM |
|
flush недостаточно, во время копирования может произойти очередная запись... хотя, если совместить с технологиями от операционных систем для такого копирования (теневое копирование windows или lvm/btrfs/nilfs/... - снапшотами), то уже нормально.
Только вот резервное копирование кошелька необходимо делать после каждой операции, а если он гигабайтового размера, то это несколько затруднительно (в пределах одной машины - так же снапшотами можно обойтись, а вот на соседний хост, уже никак).
|
|
|
|
Yurock
|
|
September 01, 2012, 07:53:34 PM |
|
Цепочка блоков - общедоступная информация, большой объём. База блоков должна работать быстро. Бумажник - личная информация, небольшой объём (у большинства пользователей). Бумажник должен работать надёжно. Совсем не обязательно использовать одну и ту же технологию для хранения первого и второго. резервное копирование кошелька необходимо делать после каждой операции Для чего?
|
|
|
|
btcsec
|
|
September 02, 2012, 02:34:02 PM |
|
Для чего?
Ну не после каждой, конечно. Принимать можно сколько угодно не меняя бэкапа. А вот если отправлять монеты, то вполне возможно кошелек создаст для сдачи отдельный адрес, если свободные закончились. Тогда при восстановлении из бэкапа вся сдача потеряется.
|
|
|
|
Yurock
|
|
September 02, 2012, 04:27:05 PM |
|
вполне возможно кошелек создаст для сдачи отдельный адрес, если свободные закончились. Пул адресов легко настраивается. Допустим, в сутки в среднем совершается 1000 транзакций. Автоматическое резервное копирование производится каждый день. Устанавливаем размер пула в 10000 адресов. Монеты из новых транзакций не пропадут, даже если 1-2 бекапа зафэйлятся.
|
|
|
|
btcsec
|
|
September 03, 2012, 11:03:20 AM |
|
Yurock Это надо постоянно запускать кошелек с параметром -keypool=10000? Он точно будет пользоваться ранее сгенерированными адресами, а не последними?
|
|
|
|
Yurock
|
|
September 04, 2012, 05:35:30 PM |
|
Это надо постоянно запускать кошелек с параметром -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
Legendary
Offline
Activity: 2296
Merit: 1057
|
|
December 07, 2012, 12:22:22 PM |
|
А какое решение требуется? Можно попробовать сконвертировать базу данных из клиента в mysql. Это разовое решение. Задача несложная.
как в Винде (наверно через rpc) получить в виде плоской таблики все блоки как в блокчейне ? Hash, Previous Block, Next Block, Height, и так далее
|
Sign for rent, СОБИРАЮ МЕRIT! NVC: 4 YoBLincaRdAEG4v8tbZ4T26ZnKbT9SBsu
|
|
|
|