分布式数据库进化史（大略写了一下nosql）

nosql-->bigtable-->spanner 打算周末找资料写完，nosql可能会找的比较少。果然一天是写不完的，今天大致的看了一下nosql和bigtable。 nosql参考网址：http://www.jos.org.cn/ch/reader/create_pdf.aspx?file_no=4416&journal_id=jos

NoSQL 是指那些非关系型的、分布式的、不保证遵循 ACID 原则的数据存储系统,并分为 key-value 存储、文档数据库和图数据库这 3 类。bigtable属于key-value存储的一种。 NoSQL 典型地遵循 CAP 理论[24]和 BASE 原则[25].CAP 理论可简单描述为:一个分布式系统不能同时满足一致性(consistency)、可用性(availability)和分区容错性(partition tolerance)这 3 个需求,最多只能同时满足两个.因此,大部分 key-value 数据库系统都会根据自己的设计目的进行相应的选择,如 Cassandra,Dynamo 满足 AP;BigTable,MongoDB 满足 CP;而关系数据库,如 Mysql 和 Postgres 满足 AC.BASE 即 Basically Available(基本可用)、Soft state(柔性状态)和 Eventually consistent(最终一致)的缩写.Basically Available 是指可以容忍系统的短期不可用,并不强调全天候服务;Soft state 是指状态可以有一段时间不同步,存在异步的情况;Eventuallyconsistent 是指最终数据一致,而不是严格的时时一致.因此,目前 NoSQL 数据库大多是针对其应用场景的特点,遵循 BASE 设计原则,更加强调读写效率、数据容量以及系统可扩展性. 尽管目前流行的 NoSQL 数据存储系统的设计与实现方式各有不同,但是总结起来大体上有两种架构:master-slave 结构和 P2P 环形结构.两者各具特色. master-slave 结构 master 节点负责管理整个系统,监视 slave 节点的运行状态,同时为其下的每一个 slave 节点分配存储的范围,是查询和写入的入口.master 节点一般全局只有 1 个,该节点的状态将严重影响整个系统的性能,当 master 节点宕机时,会引起整个系统的瘫痪.实践中,经常设置多个副本 master 节点,通过联机热备的方式提高系统的容错性.slave 节点是数据存储节点,通常也维护一张本地数据的索引表.系统通过添加 slave 节点来实现系统的水平扩展.在 master-slave 框架下,master 节点一直处于监听状态,而 slave节点之间尽量避免直接通信以减少通信代价.在运行过程中,salve 节点不断地向 master 节点报告自身的健康状况和负载情况,当某个节点宕机或负载过高时,由 master 节点统一调度,或者将此节点的数据重新分摊给其他节点,或者通过加入新节点的方式来调节.BigTable,Hbase 是典型的 master-slave 结构的 key-value 存储系统. P2P 环形结构 在 P2P 环形结构[18,19]中,系统节点通过分布式哈希算法在逻辑上组成一个环形结构,其中的每个 node 节点不但存储数据,而且管理自己负责的区域.P2P 环形结构没有 master 节点,可以灵活地添加节点来实现系统扩充,节点加入时只需与相邻的节点进行数据交换,不会给整个系统带来较大的性能抖动.P2P 环形结构没有中心点,每个节点必须向全局广播自己的状态信息.例如,目前流行的采用 P2P 环形结构的 Cassandra 和 Dynamo 系统采用 Gossip 机制[24]来进行高效的消息同步. 两种结构对比

1. Master-Slave 结构的系统设计简单,可控性好,但 master 中心节点易成为瓶颈（bigtable为master节点不成为瓶颈做了很多措施）;P2P 环形结构的系统无中心节点,自协调性好,扩展方便,但可控性较差,且系统设计比 master-slave 结构的系统要复杂.
2. Master-Slave 结构的系统需要维护 master 服务节点,由 master 节点维护其管理的 slave 节点,维护简单、方便;P2P 环形结构的系统自协调维护网络,扩展方便,可扩展性好.
3. Master-Slave 结构的系统将 master 节点和 slave 节点的功能分开,可减轻节点的功能负载;P2P 环形结构的系统,各节点平等,没有起到功能分布的作用.
4. Master-Slave 结构的系统通常基于水平分区实现数据分布,方便支持范围查询;P2P 环形结构的系统适于基于 Hash 分布数据,负载均衡性好,但不利于支持范围查询. 数据索引太简单了，没什么好说的，看原文就好 。。。省略。。。 读写方式（支持大数据的读写方式机制大概如下） 通常,当写入数据时,数据首先会被写到一个内存结构（类似操作系统中的cache和主存）中,系统返回写入成功.当内存中的数据达到指定大小（超过指定大小，有点类似writeback？）或存放超过指定时限时,会被批量写入磁盘.当需要读取数据时,首先访问内存结构,如果未命中则需要访问磁盘上的实例化文件.当系统发生意外宕机时,内存结构中的数据将丢失,因此,一般采用日志的方式来帮助进行数据恢复.为了进一步提高写入效率和并发能力,许多系统都采用了 Append 的方式,即将修改和删除操作都追加写到文件末尾,而读数据时利用时间戳过滤掉旧信息,返回给用户最新版本的数据.因此,数据库需要进行定期的数据合并,将过期的冗余数据删除. 此外,在一些面向文档的 NoSQL 数据库中(例如 MongoDB),其主要采用内存文件映射的机制(MMAP)来实现对文档的读写操作,即把磁盘文件的一部分或全部内容直接映射到内存当中,避免了频繁的磁盘 IO,通过简单的指针来实现对文件的读写操作,极大地提高了读写效率.

基于 flash 内存扩展缓存的研究（为什么现在很多关于flash的研究，原因在此，可能还有是因为flash好发论文？ ） 为了提高数据的读写速度,提出了基于 flash内存扩展缓存的研究,以提高持久化的 key-value 存储系统的吞吐率,进而提高系统应用性能.由于 flash 内存在性能和费用上介于 DRAM 和 disk 之间,如目前 flash 内存比硬盘高 100 倍~1 000 倍的访问时间,比 DRAM 访问时间约低 100 倍;相反地,flash 内存的费用是 DRAM 的 1/10 左右,而比 disk 贵 20 倍左右,可见,flash 内存是自然的选择.为此,为了提高系统的数据处理性能,进行了相关应用 flash内存[52−56]的 key-value 存储系统的研究,它们混合使用 RAM 和 flash 内存,将所有的 key-value 对存于 flash 内存中,并将少量的 key-value 对的元信息存在 RAM 中支持快速插入和查询.flash 内存的容量可远远大于 RAM,因此需要减少存在于 flash 内存中的 key-value 对所需要的 RAM 字节数.目前,这方面的研究侧重于如何利用最小RAM 存储最多的 flash 中的 key-value 对以及恰当的多级存储策略,提供高吞吐率和低延迟的服务. 今天先到这里，看了一半，bigtable也是看了一半。。。坚持看下去不走神不容易啊！！！等下周有空继续写。。。

转载于:https://my.oschina.net/hhjuliet/blog/783830