作者: UMU @ MEET.ONE 实验
最近三个月尝试各种方案把 EOSIO 链上交易数据同步到数据库中，踩了不少坑，现总结一下经验。
1. 使用 MongoDB 插件同步 transaction_traces 和 action_traces
原始需求是要链上交易数据，所以先是把 transaction_traces 和 action_traces 都同步。
踩坑：无奈地发现速度跟不上，服务器的时间成本比较高，只能舍弃。
2. 使用 MongoDB 插件同步 transaction_traces
研究插件代码，发现 action_traces 是从 transaction_traces 拆出来的，是重复的，所以把 action_traces 去掉，这次成功追上主网区块高度。
踩坑：transaction_traces 在查询 actions 时不太方便，因为 actions 是放到 transaction_traces 内部的一个数组，要查询具体一个 action 就得分两步走，先在 MongoDB 查询出某个 trx，然后再 actions 数组里遍历。数据库使用端的工程师觉得这样太麻烦，无奈继续放弃这到手的肥肉。
3. 使用 MongoDB 插件同步 action_traces
明确 action_traces 才是客户端想要的后，就只同步 action_traces。
踩坑：action_traces 条数比 transaction_traces 多了三倍以上，又出现追不上区块的问题……
4. 使用 MongoDB 插件同步 action_traces，但只要 transfer 数据
客户端最关心的是 transfer 数据，既然跟不上，就舍弃其它数据。
踩坑：舍弃的数据后期不好补。
5. 考虑 kafka_plugin
有人说 kafka_plugin 同步数据很快，可以追上主网区块。
踩坑：从 kafka_plugin 代码就能看出它没有处理 action_traces，如果还要去后端再拿出来处理，再插入到 MongoDB 里，那开发成本和服务器成本一样又上去了。
6. 从 2019 年的区块开始同步
从 35058781 块开始，插入数据库。之前的区块（1 - 35058780）处理后，仅插入数据量相对很小的 account_controls、accounts、pub_keys，其它数据量大的表不插入。
做这个尝试很重要，因为发现重要的线索：
-
大约在 2200 万块开始，nodeos 的处理速度下降很多，平均每块要 2-3ms，所以同步慢的原因在于跑 nodeos 的服务器的性能。
-
在 1 开始的早期区块阶段，同时插入 transaction_traces 和 action_traces，并不能看出比只插入 action_traces 慢，说明 MongoDB 端压力很小。
7. 结论
-
要追上主网区块高度，nodeos 机器性能要好，2.5GHz CPU 不够用。之前听闻 BOS 要求 BP 使用 4.0GHz 的 CPU，现在看起来也是有道理的……以性能成本换取时间。
-
MongoDB 集群，按之前的文章《为 EOSIO MongoDB 插件搭建高可用集群》的配置，插入阶段毫无压力。
-
插件代码有些问题，需要优化，最明显的就是 queue_size 的设计不合理，打印处理时间太长的提示也不合理。
-
queue 函数是个模板，所有的 queue 都调用它，但 max_queue_size 和 queue_sleep_time 缺只有一份，这可能导致一个 queue 导致的 queue_sleep_time 加大，影响到其它 queue，即整体的休眠时间会无用地加大。
-
打印处理时间没有按照 max_queue_size 变化，当 max_queue_size 设置大时，打印就很频繁，带来延迟。
-
-
建议：一定要注意成本问题！如果查询量不是很巨大，找点友商的数据源用用就好了，自己搭建的成本好高……但如果查询量太大，或者友商卖太贵，以上经验就是很好的参考了。
