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!，下篇“分而治之”将介绍框架如何在较低的硬件下保障高性能。