BSV Planaria框架技术总结二  Bitquery

BSV Planaria框架技术总结二 Bitquery

BSV Planaria框架技术总结二 Bitquery

此文是变形虫技术总结的第二篇,阅读此文之前建议先阅读关于变形虫的前两篇文章。

hqm:Bitcoin SV的开发哲学——变形虫框架zhuanlan.zhihu.com图标hqm:BSV Planaria框架技术总结一 节点搭建zhuanlan.zhihu.com图标

前面的文章说过变形虫是一个持久层框架,通过planaria组件爬取区块链上的交易数据,提取并加工所需的数据后将数据存储到MongoDB中,然后由planarium对外提供接口给应用程序来调取数据。在搭建好数据库之后,我们下一步关注的重点就是如何对数据库进行读写。前文已经介绍过,变形虫与传统数据库最大的区别就是读写分离,不能直接写数据库,只能通过客户端发起链上交易来修改状态机,因此向变形虫写数据本质上就是构造交易,这将在下一篇文章中总结。本文的重点就是如何高效优雅地从变形虫中读取数据。

Bitquery简介

planaria使用一套简单高效的查询语言,称为Bitquery,类似于sql语言,可以将变形虫中的数据进行各种图灵完备的组合和处理,输出各种形态的数据。由于变形虫的开发目的是一个可以满足一切基于比特币链上数据需求的持久层框架,因此必须具备一种专为链上交易数据服务的查询语言,bitquery也就因此而产生。

bitquery查询语句本质上是一个json对象,之所以是这种形态是为了适应MongoDB的查询。这里有必要提及一下,变形虫框架为何内置数据库采用的是MongoDB而不是类似mysql的关系型数据库。照理说,链上交易数据是充分结构化的,各个交易之间,地址之间有很强的关联性,查询交易更适合使用关系型数据库,这样连表操作更为方便,性能也更好。但是对于变形虫而言,它关注的重点并不是交易本身,而是交易上携带的千变万化,各行各业的杂乱无章的非标准数据,这些数据没有统一的范式,也没有统一的关联性。在这种情形下,Nosql的优势就会凸显出来,将一个个非标准数据看做一个个”文件“,不强制要求文件内容的格式,更加符合变形虫的需求目标。我有一种设想,以后的变形虫甚至可以在内部同时集成关系型和非关系型两种数据库,关系型数据库专门处理关联性高的交易数据,提升关联连表查询效率,而非关系型数据库处理各种应用的非标准数据,提升拓展性和兼容性。两种内置的数据库组件各司其职,将变形虫的性能发挥到极致。

bitquery示例如下:



bitquery基于两种非常强大的技术,MongoDB Query Language(mongoDB 查询语言)和JQ(一个基于栈操作的图灵完备的json处理语句)。查询语句如上图所示分为3部分,第一部分是协议的版本号,目前是3,第二部分是基于MongoDB的查询语句,筛选出数据,第三部分是返回结果处理语句,对第二部筛选出来的结果进行整理和包装,处理成应用程序需要的样式。

第二部分查询语句主要基于MongoDB的查询语句,但是与原生的MongoDB查询略有不同,针对Planaria做了一定的适配,选取了部分查询功能,使用json对象的各个成员来标记搜索条件。

第三部分处理搜索结果,第二步返回的结果是一个json,可能包含我们不需要的数据,或者不是我们所希望的数据格式,需要将其整理成我们需要的格式,这时候就需要用到JQ,变形虫内置JQ的处理组件,可以直接帮我们把数据在服务器端就处理好,不需要客户端自行进行数据的处理。

query字段(q)可以包含下列成员(后文会依次详细说明):

  • find:同MongoDB的find条件语句。
  • aggregate:对应MongoDB的聚合语句。
  • project:对应mongoDB的project操作符
  • sort:对应MongoDB的排序操作符
  • limit:对应MongoDB的个数限制操作
  • skip:对应跳过操作,通过limit和skip可以实现翻页
  • db:选择db,目前有c(已确认交易库)和u(未确认交易库)

response字段(r)包含一个f成员,就是后处理function,里面是一个JQ表达式,用于处理query返回的结果。

Genesis数据储存格式

注:详细技术细节和内容请点击链上文章,付费查看(设置付费的原因:1.支持作者劳动成果,激励作者创作更多有价值的文章 2.不欢迎bsv黑子和喷子,只分享给bsv学习者和开发者 3.用实际行动支持bsv价值传递,贡献交易量)

本文的链上地址如下:

BSV Planaria框架技术总结二 Bitquerywww.bitpaste.app

欢迎用bsv砸死我。

编辑于 2019-05-23

文章被以下专栏收录