如何使用HBase构建NewSQL
发布网友
共2个回答
懂视网
介绍
谷歌对数据系统性能有极高的要求，MySQL这样的系统都很难令其满意，所以谷歌设计F1数据库，其目标是让其具备高度的可扩展性和高度稳定性，除了必备的SQL语言支持外，F1还提供ad hoc类型查询。
基本构架
用户通过客户端语料库（client library）和F1交互。用户发出的请求首先送到某个F1服务器，F1服务器负责之后的任务分配和数据处理。
为了减少处理请求造成的延时（latency），F1的客户端和与之直接相连的负载均衡器会首先向最近的F1服务器相连，但是如果附近的F1服务器非常繁忙或者出现故障，那么就会找其他远一点的服务器。
F1服务器通常和spanner服务器放在一个数据中心，因为这样可以提高数据读写的速度，不过F1服务器也可以连接其他数据中心的spanner服务器。spanner从一个叫做CFS（Colossus File System）的文件系统调取数据，相连的spanner和CFS永远是在同一个数据中心的，也就是说，某个数据中心的spanner不会和另一个数据中心的CFS相连。
因为F1服务器没有存储数据，F1服务器可以根据访问流量的大小随意增减。
整个F1系统处理请求可以在单个节点上完成，也可以在多个节点上分布完成，关键看哪个延时更小。如果是用分布式的方式处理请求，F1会指定多个进程（process）来完成，一个从属服务器（slave server）接管一个进程。多个从属服务器由一个主服务器（master server）管理。F1也支持MapReduce。
Spanner
F1和spanner是同时被研究开发出来的，但是spanner更加偏向于底层处理，例如缓存，数据共享和搬运，数据位置计算等等。
F1本身是关系型数据库，所以数据是一行一行地放在了列表（table）里。spanner将所有数据分成了一个个由很多行数据组成的集群（cluster），或者叫做目录（directory）。每一个目录至少有一个分段（fragment），大的目录通常有好几个分段。一个目录的多个分段组成了一个组（group），每一个数据中心存放了一个组的副本。
spanner在处理查询语句的时候使用二阶段锁（two-phase locking）和二阶段提交（two-phase commit），这样信息交互在网络中增加了一倍，增加了延时。为了保证数据的一致性（consistency），spanner使用时间戳（timestamp）给每一条事务排序，保证全球的事务有序执行。
数据模型
F1的数据模型和关系型数据库相似，都有数据概要（schema），但在此基础上也有扩展。
F1数据概要下的表格（table）是分层的。子表格（child table）里面的所有key必须包含母表格（parent table）里面的key。根表格（root table）里的每一行叫做根行（root row），所有根据某条根行衍生出来的子表格行组成一个spanner目录
Protocol Buffers
普通数据库的一个缺点是，数据结构里的数据要通过繁琐的代码转换成数据库数据之后才能被存入数据库，谷歌使用Protocol Buffer语料库（library），使得表格的每一列支持结构化数据类型。
数据索引
F1有两种索引，一种是局域索引（local index），局域索引的key必须包含根行的key作为前缀。局域索引的key和索引到的结果都和实际的根行放在同一个spanner目录下，所以局域索引的修改占用了事务中很少的一部分用时。
另一种索引是全局索引（global index）。和局域索引不同的是，全局索引的key不包含根行的key，并且和索引的数据分开存放。很多目录都可以访问全局索引，全局索引存放在多个spanner服务器里。如果修改了一条被索引的行，那么更新索引就需要用到2PC(2 phase commit)。全局索引在扩展性方面做得不是很好。比如说，一个新增1000行数据的事务会让索引新增几百条记录，2PC处理这几百条新增的记录会变得很慢。目前谷歌正在研究让全局索引有更好地扩展性的方法。
修改数据概要（schema）
F1数据库是一个全球范围的数据库，这意味着世界上所有人都可以修改里面的同一份数据概要，谷歌要求在这个过程中不允许出现任何故障或者表格上锁（table locking）。
那么如何实现呢？谷歌修改概要的方法是用非同步法，也即是说不同的F1服务器在同一时候可能储存两个本质相同但概要内容不同的数据库。对此，谷歌设计了自己的算法。
事务执行
F1有三种类型的事务：
1. 只读（read-only）事务
2. 直接映射到spanner的事务：此类型的事务直接由spanner处理。
3. 读写事务：为了防止在读取的时候数据被其他事务修改，F1还会给出上一次被修改的时间，数据一旦被更新，这个时间也会随之更新。
默认形式下，F1客户端使用读写事务模式。这样做的优点有
- 读取数据不需要数据锁，而且不会和改写数据相冲突，事务之间互不受影响。
- 某些事务本来就需要很长时间，这样也不会被禁止
- 事务在出错之后可以重新执行
- 客户端在发现远程服务器出现故障后，可以连接另一台服务器
- 事务执行过程中允许读取处理事务以外的数据
但是该模式也有缺点，就是如果某一数据被频繁调取，那么系统在这个数据上的工作效率（throughput）就很低。
数据锁
F1数据库中每一行数据都有一个锁列（lock column）。锁列可以由用户自由定制并且负责该行每一列数据的上锁。这样每一行的不同列就能被不同事务读取修改。
记录修改
F1需要记录过去对数据库的所有更改。F1记录每一条事务的修改记录时会包含每一行某一列修改前和修改后的值，还有primary key。这里的primary key包含根表格的key和提交事务时候的时间，所有这些记录放在了另外一个表格中。这些记录在F1相关应用中有重要作用。
客户端
在F1之前，很多谷歌的数据库应用都是用MySQL的ORM，ORM不适合在F1中使用，因为扩展性不高。于是谷歌设计了自己的API。同时F1也支持NoSQL和SQL。
事务查询处理
F1支持单点事务处理和分布式事务处理，单点OLTP由一个F1服务器处理，分布式OLAP由F1下的从属服务器（slaver）共同处理。
处理远程数据
在F1中，SQL中的join命令要求读取多个数据中心的数据，这会带来网络延时，解决办法是数据批量传送（batching）和流水线操作（pipelining）。
数据计算通常是一部分计算好之后就被输出，减少等待时间。这样做的好处是并行高效和减少存储缓冲，但缺点是数据不能被排序。
分布式计算
每一个事务执行计划包含了几十个子计划，每一个子计划由几个从属服务器执行，同时，数据划分（partitioning）技术也在此处用到。
更多资源（英文）
F1论文
相关讲义
数据库NewSQL之谷歌F1系统
标签：数据库 newsql
热心网友
目前主流的数据库或者NoSQL要么在CAP里面选择AP，比较典型的例子是Cassandra，要么选择CP比如HBase，这两个是目前用得非
常多的NoSQL的实现。我们的价值观一定认为未来是分布式的，一定是尽量倾向于全部都拥有，大部分情况下取舍都是HA，主流的比较顶级的数据库都会选择
C，分布式系统一定逃不过P，所以A就只能选择HA。现在主要领域是数据库的开发，完全分布式，主要方向和谷歌的F1方向非常类似。
目前看NewSQL代表未来(Google Spanner、F1、FoundationDB)，HBase在国内有六个Committer，在目
前主流的开源数据库里面几乎是最强的阵容。大家选型的时候会有一个犹豫，到底应该选择HBase还是选Cassandra。根据应用场景，如果需要一致
性，HBase一定是你最好的选择，我推荐HBase。它始终保持强一致，我们非常喜欢一致性，丧失一致性的时候有些错误会特别诡异，很难查。对于
Push-down特性的设计其实比较好，全局上是一个巨大的分布式数据库，但是逻辑上是分成了一个个Region，Region在哪台机器上是明确的。
比如要统计记录的条数，假设数据分布在整个系统里面，对数十亿记录做一个求和操作，就是说不同的机器上都要做一个sum，把条件告诉他要完成哪些任务，他给你任务你再汇总，这是典型的分布式的 MPP，做加速的时候是非常有效的。
2015年HBaseConf 上面有一句总结: “Nothing is hotter than SQL-on-
Hadoop, and now SQL-
on- HBase is fast approaching equal hotness status”， 实际上SQL-on-HBase 也是非
常火。因为 Schema Less 没有约束其实是很吓人的一件事情，当然没有约束也比较爽，就是后期维护十分痛苦，规模进一步扩大了之后又需要迁移
到 SQL。
现在无论从品质还是速度上要求已经越来越高，拥有SQL的同时还希望有ACID的东西(OLAP一般不追求一致性)。所以TiDB在设计时就强调这
样的特点：始终保持分布式事务的支持，兼容MySQL协议。无数公司在SQL遇到Scale问题的时候很痛苦地做出了选择，比如迁移到
HBase，Cassandra
MongoDB已经看过太多的公司做这种无比痛苦的事情，现在不用痛苦了，直接迁过来，直接把数据导进来就OK了。TiDB最重要的是关注OLTP，对于
互联网业务来说通常是在毫秒级内就需要返回一个结果。
我们到目前为止开发了六个月，开源了两个月。昨天晚上TiDB达到了第一个Alpha的阶段，现在可以拥有一个强大的数据库：支持分布式事务，始终
保持同步的复制，强大的按需Scale能力，无阻塞的Schema变更。发布第一个Alpha版本的时候以前的质疑都会淡定下来，因为你可以阅读每一行代
码，体验每个功能。选择这个领域也是非常艰难的决定，实在太Hardcore了，当初Google Spanner也做了5年。不过我们是真爱，我们就是
技术狂，就是要解决问题，就是要挑大家最头痛的问题去解决。好在目前阿里的OceanBase给我们服了颗定心丸，大家也不会质疑分布式关系型数据库是否
可行。
