AppBoxFuture(二): Say goodbye to sql!

  信息管理类应用系统离不开关系数据存储，目前你们基本都使用的是传统的数据库如MySql、Postgres等。做者从事信息化建设十多年，我的认为传统的数据库存在如下的问题：

扩展问题：

  系统数据的不断增加是个绕不过去的坎，传统数据库的存储结构一般都基于B+tree，单表数据在必定范围内没有问题，但数据量增大到必定程度后性能便会不断降低，只能经过分库分表的方式或升级硬件来解决，随之而来的是提升了应用软件的开发难度及相应的硬件成本。做者曾建设过一个北斗监控平台，其中单表记录10多亿，通过优化虽能实行秒级查询一天轨迹，但备份及按期删除历史数据很是慢且影响在线操做，后来只能手工实现了一套文件存储来解决（那个时代尚未NoSql)。

可用性问题：

  传统数据库只能使用主从的方式来保障可用性，运维较复杂。做者曾经碰到过一次闪电致使机房（等保三级）内一台数据库用SAN存储的电源背板烧坏，虽这台存储冗余电源，RAID10通通没用，致使系统停用两天。

开发人员问题：

  因为开发人员对sql的熟悉程度不一样，常常能碰到写的很烂的sql语句。另外若是使用ORM，则ORM->Sql字符串->网络传输->Sql引擎分析->执行->网络传输->ORM存在较大性能损耗。做者的一个朋友在一家公司作运维，他说他公司的开发只管程序可否跑通，从无论sql优化问题，致使系统很慢，出了问题全丢给运维处理。

  因为存在上述问题，做者一直在寻找新的适合于信息管理类系统的存储技术，既能简单的随需扩展，又能保障高可用高性能，还能兼顾大数据存储与分析，最好建设与运维的成本尽量的低（做者接触的都是中小微企业）。所以前后学习了互联网企业经常使用的NewSql（TiDB, Cockroach）、NoSql(Cassandra, Kudu, ES等）技术，但愿能将这些技术应用于传统的信息管理系统的建设。但随着进一步的深刻了解，这些技术都存在这样或那样的问题，好比或架构复杂问题，或事务一致性问题，或性能问题（如并发扣减库存）。

  在学习了上述技术的原理后，做者就想可否从新实现一套适合于上述要求的分布式数据库，直接集成至应用框架内，从而能够：

简化应用系统架构

整个应用系统由一个或多个节点组成，每一个节点负责处理用户请求及存储，随需扩展节点。

表分区

大表支持定义为按分区键分区存储（相似于Cassandra的PartionKey），同时支持分区索引及全局索引，以避免热点问题，另外删除整个分区对性能的影响较小。

强一致性事务

基于Raft及2PC支持分布式事务（相似于TiDB, Cockroach)。

简单的Api

支持框架的实体模型与存储结构的直接映射，避免sql字符串转换与分析损耗，另因为直接进程内访问存储引擎，可减小网络通讯开销。
举个简单的保存例子：

var pos = new Entities.VehiclePosition(vehicleId); //车辆位置，根据id分区
pos.LAT = 32.22223;
pos.LNG = 100.2123;
await EntityStore.SaveAsync(pos);

再举个简单的表扫描查询例子，支持其余查询方式如索引扫描，聚合扫描等：

var q = new TableScan<Entities.VehiclePosition>();
q.Partions(p => p.VehicleId == vehicleId); //指定分区条件
q.Filter(t => t.CreateTime >= startday && t.CreateTime < endday); //指定分区内记录过滤条件
var list = await q.ToListAsync(t => new {t.Id, t.LAT, t.LNG}); //选择指定列

小Tip:

1. 在实现表扫描及聚合扫描时，做者利用C#的Emit直接生成条件过滤代码，类似于PG10 llvm生成代码。
2. 关于Join将只支持LeftJoin，复杂Join只能在服务代码内利用C#的Linq处理。
3. 目前事务隔离级别只支持ReadCommitted及Seializable，但纯读支持本地读、线性一致性读、事务读。

  目前做者还在不断踩坑与尝试实现上述目标，固然首先要感谢上述所提的那些技术先驱们，在此但愿有志同道合者来共同完成它。已实现的技术原型参考前篇
AppBoxFuture(一): Hello Future!，下篇“分而治之”将介绍框架如何在较低的硬件下保障高性能。