坚持写NoSQL技术博客以来的几点感想..

华为云上的NoSQL数据库服务CloudTable，基于Apache HBase，提供全托管式集群服务，集成了时序数据库OpenTSDB与时空数据库GeoMesa，在TB/PB级别的海量数据背景下，可提供ms级查询以及千万级TPS，点我了解详情。

在学习的时候，我一直保持着记笔记或者做简单总结的习惯，内容比较随性，但这些内容有助于自己的快速回顾。在技术领域，最好的总结是一个直观的流程图，所谓"一图胜千言"，然后配以简单的文字说明。但可惜，那时没有想过写作公开的技术博客，周边也缺乏这样的氛围。

几个月前，正式决定开始写博客和公众号。初衷还是希望能督促自己在业余时间的学习，当正式开始以后，如下几点内容感受非常深刻：

1. "以输出倒逼输入"，这就要求每天必须坚持学习。如果写作只是将自己知道的内容写出来，对于我，那将变成一件枯燥而无趣的事情。

2. 公开的内容对质量会有更高的要求，进一步提高了对学习的要求。

3. 如果写作的内容得到其他人的认可，可以带给自己更多坚持下去的信心。

但频繁更新却是一件极其艰难的事情。技术总结内容，通常需要细致的阅读源码细节，如果追求高质量输出，难以在短时间内快速完成。另外因日常工作方面的原因，自由可支配的时间时常不受控制。

上面这些内容，更多的是自己的几点感受。希望阅读了此文的同学们也能开始自己的技术写作，对于已经开始的，也应该长期坚持下去。

接下来是关于NoSQL技术的一些漫谈内容。最初，对于这个公众号名称，我曾纠结过一段时间。NoSQL一词，俨然已过了风头正盛的时期，甚至听起来像一个"过时"的概念。关于这个公众号，主要想探讨如下领域的内容：

- 分布式KeyValue系统

- 稀疏矩阵形态的宽列存储技术

- 搜索技术

- 图数据库技术

- 文档数据库技术

- 时序/时空数据库技术

- 多模数据库技术

- 分布式索引技术

- NewSQL技术

- 分布式计算技术

认真思考一下，也只有NoSQL一词可将其尽可能的囊括起来。每一种技术，都有自己独特的精彩实现内容，但更多的是一些通用的技术，如RPC通信技术，索引技术，分布式共识算法，MVCC， SQL能力等等。

对比于NoSQL，NewSQL听起来像是一个更新潮的概念。Google对于NoSQL与NewSQL技术架构的影响可谓深远，我们先来看看Google从Bigtable到Spanner/F1的演进过程，下面列举了每一种技术的设计关键点：

Bigtable:

• LSM-Tree架构

• Auto-Scaling

• 基于分布式文件系统GFS/Colossus

• 稀疏矩阵

• Schema less设计

• 行级事务

• 异步容灾（Paper中提及但最终未实现）

Megastore:

• 基于Bigtable构建

• 在NoSQL与RDBMS之间做了妥协，支持半关系型模型

• 支持SQL接口

• 支持多种二级索引类型

• 基于Paxos协议实现了跨DataCenters间的同步容灾

• 支持Entity Group级别的跨行事务

Spanner:

• 参考了Bigtable的设计后全新实现

• Auto-Scaling

• 半关系型模型

• 支持SQL接口

• 支持同步容灾

• 支持广泛的分布式事务能力

F1: 

• 基于Spanner构建

• 分布式SQL查询能力

• 支持事务一致性的二级索引

• 支持异步的Schema变更

• 支持乐观事务

• 数据变更历史记录跟踪

关于NoSQL与NewSQL，这篇文章《NewSQL是否是NoSQL的取代者？》做了更详细的探讨。这里仅简单的罗列一下观点：

- NoSQL通常指一种非关系型存储技术，涉及的范围广泛，本身与是否具有SQL接口能力无关。

- NewSQL更多是指一种分布式的关系型数据库技术，典型意义上的NewSQL包括Spanner， CockroachDB， NuoDB以及国内的TiDB，它通常会更加强调分布式事务能力。

NewSQL更多是RDBMS与NoSQL技术结合的一种产物，对于传统的应用，会更加友好，也具有广泛的普适性。在可预见的未来，它也一直会有可观的市场空间。而每一种NoSQL技术更像是一种专业化能力的存在：

- HBase：稀疏矩阵，基于KeyValue提供了简单的读写接口

- Elasticsearch：提供分布式搜索能力

- Druid：基于事件数据的OLAP能力

- Neo4j：提供图数据库能力

- OpenTSDB/InfluxDB：提供时序数据库能力

在"nosql-database.org"这个网站中，收录了大量的NoSQL技术，大家可以参考一下。

如果每一种技术只提供一种专业的能力，那就带来了通用性方面的问题，同一份数据时常需要在不同的系统中各复制一份是一个无法忍受的问题。从应用的角度来看，大家更期望一种"One Size Fit More/All"的技术，但这在技术实现上几乎不可能。多模数据库似乎是一个不错的答案，它的设计理念为：

"基于一套存储引擎，提供多种模型，多种访问接口"

以当前火热的AZure Cosmos DB为例，支持如下三种模型：

- Document

- Graph

- KeyValue

AZure Cosmos DB基于上面三种模型，提供了多语言(Java/Python/Node.js/.NET)访问接口，并且提供了MongoDB Document API以及基于SQL的访问接口。

再以ArrangoDB为例，它同样支持如下三种模型：

- Document

- Graph

- KeyValue

ArrangoDB主要提供了AQL(SQL-Like)接口以及HTTP接口。

多模数据库像是NoSQL技术的大杂烩，但的确不失为NoSQL技术一个不错的演进方向。随着公有云，人工智能，物联网等行业的快速发展，以及即将到来的5G技术，需要存储和查询的数据量也会变得越来越大，相信NoSQL技术会生生不息，一定会取得更广泛的应用场景。 这也是我坚持在"NoSQL"领域写技术博客的一个关键原因。

欢迎扫描关注公众号NoSQL漫谈