Bitcoin Forum
March 30, 2017, 06:57:32 PM *
News: Latest stable version of Bitcoin Core: 0.14.0  [Torrent]. (New!)
 
   Home   Help Search Donate Login Register  
Pages: [1]
  Print  
Author Topic: Хранение цепочки в MySQL  (Read 2944 times)
ArsenShnurkov
Legendary
*
Offline Offline

Activity: 1386



View Profile
May 11, 2012, 10:37:22 PM
 #1

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.
There are several different types of Bitcoin clients. EWallets are like banks -- a central organization has complete control over your money. You shouldn't put much money in EWallets.
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1490900252
Hero Member
*
Offline Offline

Posts: 1490900252

View Profile Personal Message (Offline)

Ignore
1490900252
Reply with quote  #2

1490900252
Report to moderator
1490900252
Hero Member
*
Offline Offline

Posts: 1490900252

View Profile Personal Message (Offline)

Ignore
1490900252
Reply with quote  #2

1490900252
Report to moderator
1490900252
Hero Member
*
Offline Offline

Posts: 1490900252

View Profile Personal Message (Offline)

Ignore
1490900252
Reply with quote  #2

1490900252
Report to moderator
neo_rage
Full Member
***
Offline Offline

Activity: 196



View Profile
May 11, 2012, 10:40:43 PM
 #2

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

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

kimmeriets
Legendary
*
Offline Offline

Activity: 1078


View Profile
May 12, 2012, 03:45:44 AM
 #3

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

Activity: 1092


View Profile WWW
May 12, 2012, 07:55:34 AM
 #4

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

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

Здесь не может находиться ваша реклама Smiley
Protect a future of bitcoin, use p2pool
Donation in BTC: 19fv5yYtfWZ9jQNjx2ncmu1TTrvg5CczZe
Balthazar
Legendary
*
Offline Offline

Activity: 2114


Post rank racist


View Profile WWW
May 12, 2012, 11:12:15 PM
 #5

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

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

novaco.in | Etherium mining pool (50 GH/s)
฿: 1QJ8RFiRKsJKmY8ZAjxfCUeBZXmjthK4Pk: 4RgnHWtnJWEyMhqhDdazW3Hdr7cx5ybF6i ETH: 0x215c86bc952b0d98c4b2313a0a9ae56fa33c7f5d
rPman
Legendary
*
Offline Offline

Activity: 1092


View Profile WWW
May 13, 2012, 06:32:24 AM
 #6

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

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

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


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

Здесь не может находиться ваша реклама Smiley
Protect a future of bitcoin, use p2pool
Donation in BTC: 19fv5yYtfWZ9jQNjx2ncmu1TTrvg5CczZe
somenick
Legendary
*
Offline Offline

Activity: 1324


View Profile
May 13, 2012, 08:18:02 AM
 #7

меня тоже вставляет эта 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 Offline

Activity: 1092


View Profile WWW
May 13, 2012, 11:25:43 AM
 #8

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

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

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

Здесь не может находиться ваша реклама Smiley
Protect a future of bitcoin, use p2pool
Donation in BTC: 19fv5yYtfWZ9jQNjx2ncmu1TTrvg5CczZe
Balthazar
Legendary
*
Offline Offline

Activity: 2114


Post rank racist


View Profile WWW
May 13, 2012, 03:28:41 PM
 #9

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

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

novaco.in | Etherium mining pool (50 GH/s)
฿: 1QJ8RFiRKsJKmY8ZAjxfCUeBZXmjthK4Pk: 4RgnHWtnJWEyMhqhDdazW3Hdr7cx5ybF6i ETH: 0x215c86bc952b0d98c4b2313a0a9ae56fa33c7f5d
rPman
Legendary
*
Offline Offline

Activity: 1092


View Profile WWW
May 13, 2012, 03:56:20 PM
 #10

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

Здесь не может находиться ваша реклама Smiley
Protect a future of bitcoin, use p2pool
Donation in BTC: 19fv5yYtfWZ9jQNjx2ncmu1TTrvg5CczZe
Balthazar
Legendary
*
Offline Offline

Activity: 2114


Post rank racist


View Profile WWW
May 13, 2012, 08:58:07 PM
 #11

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

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

novaco.in | Etherium mining pool (50 GH/s)
฿: 1QJ8RFiRKsJKmY8ZAjxfCUeBZXmjthK4Pk: 4RgnHWtnJWEyMhqhDdazW3Hdr7cx5ybF6i ETH: 0x215c86bc952b0d98c4b2313a0a9ae56fa33c7f5d
rPman
Legendary
*
Offline Offline

Activity: 1092


View Profile WWW
May 14, 2012, 05:37:07 AM
 #12

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

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

Здесь не может находиться ваша реклама Smiley
Protect a future of bitcoin, use p2pool
Donation in BTC: 19fv5yYtfWZ9jQNjx2ncmu1TTrvg5CczZe
Balthazar
Legendary
*
Offline Offline

Activity: 2114


Post rank racist


View Profile WWW
May 14, 2012, 06:36:07 AM
 #13

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

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

novaco.in | Etherium mining pool (50 GH/s)
฿: 1QJ8RFiRKsJKmY8ZAjxfCUeBZXmjthK4Pk: 4RgnHWtnJWEyMhqhDdazW3Hdr7cx5ybF6i ETH: 0x215c86bc952b0d98c4b2313a0a9ae56fa33c7f5d
rPman
Legendary
*
Offline Offline

Activity: 1092


View Profile WWW
May 14, 2012, 06:55:04 AM
 #14

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

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

Здесь не может находиться ваша реклама Smiley
Protect a future of bitcoin, use p2pool
Donation in BTC: 19fv5yYtfWZ9jQNjx2ncmu1TTrvg5CczZe
Yurock
Sr. Member
****
Offline Offline

Activity: 462


View Profile
September 01, 2012, 07:53:34 PM
 #15

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

резервное копирование кошелька необходимо делать после каждой операции
Для чего?
btcsec
Hero Member
*****
Offline Offline

Activity: 700


BITS.MEDIA


View Profile WWW
September 02, 2012, 02:34:02 PM
 #16

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

Bits.media - русскоязычный информационный ресурс о сети Bitcoin
Yurock
Sr. Member
****
Offline Offline

Activity: 462


View Profile
September 02, 2012, 04:27:05 PM
 #17

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

Activity: 700


BITS.MEDIA


View Profile WWW
September 03, 2012, 11:03:20 AM
 #18

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

Bits.media - русскоязычный информационный ресурс о сети Bitcoin
Yurock
Sr. Member
****
Offline Offline

Activity: 462


View Profile
September 04, 2012, 05:35:30 PM
 #19

Это надо постоянно запускать кошелек с параметром -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
Legendary
*
Online Online

Activity: 1862



View Profile
December 07, 2012, 12:22:22 PM
 #20

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

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

Pages: [1]
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!