当你进行区块链数据的处理操作之时, ESK（ElasticStack） 几乎是难以回避的存在。因为存储在链上面的数据总量变得越来越庞大, 所以传统的 SQL 数据库根本承受不住这种压力。
因此, 只有使用 ESK 来建立索引以及提供检索功能, 相关系统才能真正实现高效运行。本人在带领团队从事链上数据平台开发工作的长达三年时间里, 经历过多种挫折与问题。现在想要谈论一些具有实际指导意义的内容。
区块链esk怎么用
把上链数据弄进ESK这个事儿, 其核心逻辑主要就是两步操作, 我们得先把区块还有交易的信息转写成JSON格式的文档, 然后依据区块的高度来进行分片处理, 最后把这些数据映射到ES集群里头去, 你可千万别以为能用一条命令就直接搞定所有事，因为以太坊的receipt结构和币安的K线数据在字段方面是完全不一样的, 所以你就必须单独去编写对应的映射模板。
在实际部署并且开始运行的过程中, 大家最觉得令人感到困扰和棘手的事情就是增量数据的同步操作。这是因为区块链出块的时间间隔存在不确定性并且缺乏规律性, 特别是在网络拥堵的高峰期间, 单个区块里面会塞进去上万的笔交易记录, 这就导致批量查询的接口程序会直接出现超时无法响应的故障现象。
为了解决这一难题, 我们的团队后来把系统架构修改成了利用Kafka这个异步消息队列中间件来进行数据缓冲的处理方式, 同时也在Elasticsearch集群那边设置好了叫做refresh_interval的相关参数配置项, 这样以来整个系统的稳定性就非常稳固而且好控制了很多。
区块链esk能做什么
在查询这一块，ESK的DSL比SQL灵活得实在是太多了。如果你要查“过去30天某地址转出超100万USDT且对手方命中黑名单”这种需求, 直接用boolquery加上filter就能直接出结果。根本就不用去JOIN三四张表那么麻烦。
聚合分析这个能力同样是很强的。在去做链上的风险控制的监测工作的时候, 可以按照时间窗口来进行数据的汇总压缩操作, 并且可以按照具体的地址来作为分组的标准去算出百分位数的相关指标, 这一套复杂的需求可以通过编写一句嵌套了多种聚合操作的查询请求就轻松搞定了。
我们的风控团队在日常的工作中每天都会执行数百个这样的聚合分析任务, 即便是在三节点集群这样一个比较基础的架构部署情况下, 所观察到的系统响应时间的
现在的工具确实没有那种能够处理一切情况的万能款, 不过就处理链上数据这一项工作而言, 在我目前所了解的范围内，我真的没有找到其他能在成本效益方面超越ESK的替代选项。
