SteemLightDB (以下简称 LightDB ) 是一个基于 Steem 链的 MySQL 数据服务。
在有 SBDS 的情况下，为啥还要在弄一个 SteemLightDB 呢？
由于之前搭建过 SBDS 服务，发现里面有很多的问题，其中稳定性、数据原始性、数据容量这三个问题比较突出。
- SBDS 的稳定性直接依赖于其取数据的节点的稳定性；
- SBDS 的数据太原始，加工度不够，如果应用开发者需要一些数据之间的关系，需要开发者获取后自己加工，增加了开发者的开发工作量和难度；
- SBDS 占用空间太大，对于穷人来说，服务器费用开销太大。
LightDB 主要就是要针对以上三点进行优化，这就是 LightDB 的目的。LightDB 希望最终完成一套基于 Docker 的数据方案，开发者除了可以使用我提供的节点外，还可以自己快速便捷的搭建起来 LightDB。
介绍
首先看下 LightDB 大致的结构图：
LightDB 主要分为四层。
整体的工作流程就是，有单独的脚本通过数据节点获取 Blockchain Data 然后存入 MySQL，这就是 MySQL Base Data 层。
第二层数据其实就是整个区块链每个块的原始数据。第二层的目的就是让 LightDB 的稳定性不再依托数据节点。通过第一层到第二层的脚本程序，来保证 LightDB 的数据源的稳定性，进而保证 LightDB 的稳定性。
从第二层到第三层由另外一个独立程序对原始数据进行加工，这种加工就是对整个区块数据进行重播。LightDB 的核心思想就是要建立一个更像是社交网站的数据库。 通过对整个区块链数据的重播，把所有的原始数据和数据之间的关联都存入数据库，这样第三层的数据其实就是一个初步加工后的数据了。
第四层API层的目的是为开发者提供更便捷的数据服务。这一层会对常用数据进行封装，对更复杂的应用场景下的数据关联进行封装，并且可以缓存的数据将进行缓存。这样对于开发者来说，不必要直接连接 LightDB 的数据库，也可以直接获取到加工后的数据。
这其中还有一部分没有在图中体现出来，就是在第二层和第三层都会有回收程序，对数据进行清理。对于很多工具类应用开发者来说，超过一个月的数据可能就是没有用的了，因此回收程序的目的就是保证数据只留存设置的天数。当然你也可以选择不启动回收程序，而搭建一个全数据量的节点。
整个项目计划将分为三个大部分去完成，第一部分工作是第二层的建立，第二部分工作是第三层建立，第三部分工作是建立第四层。
进度 20180515
目前第一阶段暂时不考虑收益计算，那个太复杂了。当前只是针对社交内容进行了设计。
- 目前第二层的代码工作已经完成并开始同步数据，当前同步高度在将近 20000000 的位置。
- 对于第三层的数据结构设计也基本完工，近期将开始编写 Replay 程序。
由于项目比较大，尤其是对于原有的数据结构需要去研究，因此整体进度推进的比较慢。目前已经过去了三周了吧，总体进度不是很乐观。其中第三层的数据库结构设计来来回回了好几遍，也是够折腾。
Over!
欢迎使用 SteemMention 获取最新的 Steem 回复提醒。
欢迎使用 SteemEditor 来编写文章，最好用的 Steem 编辑器，没有之一！！！
感谢你的阅读，我是中文区见证人之一，欢迎通过 SteemConnect 来给我投票，或者打开 https://steemit.com/~witnesses/ 页面，输入 ety001 进行投票。
中文区的见证人目前有：
支持一下他们（按字母顺序），一人可以有30票：
Thank you for reading. I'm a witness. I would really appreciate your witness vote! You can vote by SteemConnect. Or open https://steemit.com/~witnesses page, input ety001 to vote.
This post is powered by SteemEditor.