Является ли поиск данных, хранящихся в журналах событий, чрезмерно медленными?

Август использует журналы событий для хранения данных, которые никогда не требуют доступа к контракту, поскольку он примерно в 10 раз дешевле, чем на договорной основе. Тем не менее, я заметил, что получение журналов событий (например, с использованием eth_getLogs) занимает значительно больше времени, чем поиск данных по контракту. (Я знаю, что фильтры позволяют слушать журналы событий new , но я специально занимаюсь поиском журналов событий old .)

Я действительно не понимаю, как работает журнал событий под капотом. В настоящее время мы индексируем один (или несколько) аргументов журнала, а затем используем eth_getLogs для поиска по индексированному аргументу. Например, все сделки Augur регистрируются и индексируются как идентификатором рынка, так и учетной записью. Наш пользовательский интерфейс просматривает сделки, сделанные текущим счетом, в рамках начальной загрузки. Сейчас это займет около 10 секунд. Запрос eth_getLogs выполняется асинхронно и чередуется с другими задачами начальной загрузки на рынок, поэтому на данный момент это не слишком раздражает. Однако я обеспокоен тем, как это будет масштабироваться по мере того, как как Augur, так и блок-цепочка Ethereum в целом будут расти.

Мой вопрос: извлечение журналов событий станет чрезмерно медленным, поскольку блок-цепочка станет больше? Более конкретно, какова временная сложность eth_getLogs? (Является ли размер блока цепочки релевантной переменной или чем-то еще? Является eth_getLogs даже правильным RPC просьба о том, что я пытаюсь сделать? В принципе, любое понимание этой проблемы приветствуется!)

22 голоса | спросил tinybike 20 MaramSun, 20 Mar 2016 11:05:42 +03002016-03-20T11:05:42+03:0011 2016, 11:05:42

1 ответ


22

Я постараюсь ответить на ваш вопрос. Я работал над фильтрами цветения в cpp-ethereum и Parity .

  

будет получать журналы событий, становясь слишком медленными, поскольку блок-цепочка становится больше?

Не обязательно. Все зависит от реализации, плотности журналов (среднее количество журналов /блоков) и количества уровней кэша.

  

В частности, какова временная сложность eth_getLogs?

В худшем случае, когда каждый блок содержит журнал, соответствующий вашему запросу, он равен 0 (n). Но это редко бывает. Фильтры Bloom используют вероятность ложных срабатываний , поэтому чем сложнее ваш фильтр (тем больше у него есть), тем быстрее вы получите свои результаты.

  

Является ли eth_getLogs даже правильным запросом RPC для того, что я пытаюсь сделать?

Да

Подводя итог, я считаю, что время отклика 10s вызвано субоптимальным перемещением фильтров цветения в go-ethereum. Ниже приведены результаты тестов с четностью:

Найти все журналы от блока 0 до 986082 с адресом: 0x33990122638b9132ca29c723bdf037f1a891a70c (должно вернуть 1602 журнала).
time curl -X POST --data '{"id":8,"jsonrpc":"2.0","method":"eth_getLogs","params":[{"fromBlock":"0x0","toBlock":"0xf0be2", "address": "0x33990122638b9132ca29c723bdf037f1a891a70c"}]}' -H "Content-Type: application/json" http://127.0.0.1:3030 >> /dev/null

geth первый запрос:

real    0m17.003s

geth второй запрос (я предположил, что результаты должны быть кэшированы после первого).

real    0m18.023s

первый запрос на четность (~ 24 раза быстрее, чем geth)

real    0m0.770s

второй запрос (~ 30 раз быстрее, чем geth)

real    0m0.668s

Разрыв между Parity и geth резко прекращается, когда нет журналов, которые можно найти:

Найти все журналы от блока 0 до 986082 с адресом: 0x33990122638b9132ca29c723bdf037f1a891a70d (адрес не существует, 0 logs).
time curl -X POST --data '{"id":8,"jsonrpc":"2.0","method":"eth_getLogs","params":[{"fromBlock":"0x0","toBlock":"0xf0be2", "address": "0x33990122638b9132ca29c723bdf037f1a891a70d"}]}' -H "Content-Type: application/json" http://127.0.0.1:3030 >> /dev/null

geth первый запрос:

real    0m0.022s

второй запрос geth

real    0m0.021s

первый запрос четности (4 раза медленнее, чем geth)

real    0m0.080s

второй запрос (1.5x медленнее, чем geth)

real    0m0.030s
ответил debris 20 MarpmSun, 20 Mar 2016 16:00:13 +03002016-03-20T16:00:13+03:0004 2016, 16:00:13

Похожие вопросы

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132