盘点这些年使用过的数据库

对数据库技术还是十分感兴趣的，盘点一下这些年使用过的数据库。对数据库理解可能不十分到位，达者不必深究。

从数据存储模型上，一般将数据库分为key-value,document,column,graph和relational，对这些库都做了些生产应用或测试，简单记录一下，主要从适用情况，简单原理架构，可靠性等方面。

KV：redis
Document：mongoDB
Column Table：hadoop/hbase,cassandra
Graph：neo4j
Ralational：mysql,oracle,DB2,teradata

KV(redis2.6)
redis是一个开源的、高级键值数据库和数据结构服务程序，其中键可以保存字符串、散列、列表、集合和有序集合。ANSI C写成，采用单进程单线程模式，未使用libevent，自己根据IO multiplexing实现event loop，linux使用epoll，bsd使用kqueue。内存动态分配，默认使用jeMalloc，我在使用中换成TCMalloc，这两个性能和稳定性类似，主要是我的应用场景mem_fragmentation_ratio在TCMalloc下更理想。redis支持事务和批操作，pub/sub的性能也很好，2.6版本还支持lua（没试过），稳定性和性能极好，普通的处理器get/put可以到10w/s。
redis适用于各种结构的二进制缓存，可以作为集中session的服务器，在我的应用中php和tomcat都是用redis做session；高效的pub/sub服务端；redis和nginx的plugin可以做一些高性能页面方案；另外我在redis中直接缓存thrift序列化对象，效果相当好。
redis的部署方案：redis读写都是单线程，故只能使用服务器的一个CPU内核，可以根据cpu核心数，考虑网卡软终端能力后，一台服务器部署多个redis节点。
redis的HA：在官方Redis Sentinel出来之前，redis的HA采用双写的比较多，新浪微博就是这么做的。原来我只做了主从，没做过HA，也从来没崩过，现在我切换到了官方Redis Sentinel上。

Document(mongoDB2.4)
mongoDB是我抱有很大期望的，C++/BOOST开发，使用memory mapped storage engine，将数据文件按单个2G mmap到内存；单线程写，多线程读，没有写锁，写入内存即成功，异步flush到文件；可添加WAL增加数据恢复准确性。
mongoDB基于bson格式，collection存储，内置js引擎，可以替成V8。
mongoDB对CAP的支持都算到位，对于C,mongoDB默认是强一致性，以为它是单主结构，如果在读时使用slaveOK，可能会不一致，但保证最终一致性；对于A，mongoDB使用replica set来做集群，在master失败时选举一个slave到master；对于P，mongoDB实现了auto sharding，虽然在大数据时还是要预先做好sharding。总体来说，mongoDB还是CP。
mongoDB在经过单机可用性和aggregation framework两次加强后，已经可以在生产上使用了。
mongoDB适用场景：mongoDB适合数据比内存小的情况，适合SSD。
如果大量数据在磁盘上，mongoDB会做频繁的mmap操作，不适合数据不按时间热点分布的情况。
我在以下几个场景使mongoDB
1、数据小于内存，事务性要求不高，并发较大
2、用caped collection集中log4j的log
3、多维数据分析
另外，mongoDB的mapreduce是js写的，只能单线程，比较郁闷。

Column(Cassandra 1.2 /cloudera CDH4.2)
Cassandra的系统架构与Dynamo类似，是基于O(1)DHT的完全P2P架构，Cassandra可以几乎无缝地加入或删除节点，非常适于对于节点规模变化比较快的应用场景。
Cassandra的数据会写入多个节点，来保证数据的可靠性，在CAP问题上，Cassandra比较灵活，用户在读取时可以指定要求所有副本一致（C）、读到一个副本即可（A）或是通过选举来确认多数副本一致即可（折衷）。这样，Cassandra可以适用于有节点、网络失效，以及多数据中心的场景。
Cassandra基于java开发，但使用direct buffer而不是heap，可以避免fullgc的问题。
Cassandra基本还是适用于Key-Value的数据模型，如果强制索引有序，会导致数据严重不均衡。
mariadb10.0提供了cassandra的存储引擎，但也只是mysql的一个cassandra window。
------------------
hadoop/hbase的相关文档很多了，这里只记录一下我的使用方法
在hadoop集群中做一些olap中的事实表到汇总表的计算，由于公司的数据仓库（teradata）资源很紧张，有一些汇总工作找不到足够强大的单机，这时使用了hadoop进行处理，计算框架使用了pig，pig比hive好的地方是可以利用操作系统命令，随心所欲的用java写插件，初期计算结果就是pig算完后写入到mysql的。
后来汇总表的量也超过mysql的单机能力，又适逢hbase0.94/cdh4发布，就将pig计算的数据放入到hbase里，因为这时hbase的coprocessor已经可以实现二级索引，ad hoc的查询也基本可以满足。
hadoop/hbase的部署：
在部署hadoop时，最挠头的就是namenode的单点，在hadoop2时，可以使用共享存储来保存元数据，zookeeper调度的方式实现HA，这时使用了iSCSI的一个块存储作为共享，效果还不错。之前使用DRBD+heartbeat来实现。
hbase的关键在于主键的设计，等长，反向时间戳等是需要考虑的。
hbase虽然用的heap内存，但是因为精巧的存储结构设计，可以有效地避免fullgc

关于这部分单独讨论

graph(neo4j)
图形数据库善于处理大量复杂、互连接、低结构化的数据，这些数据变化迅速，需要频繁的查询。在关系数据库或其它结构数据库中，这些查询会产生性能上的问题。
图数据库工作中是用不到的，毕竟是企业应用，虽说有大量的互联网用户访问，但也远没有做成一个社区的考虑。纯粹兴趣
在经过几年的开发后，近日NeoTechnology发布了基于Java的图形数据库Neo4j 1.0，它遵循着属性图形数据模型。InfoQ有幸采访了NeoTechnology的COO Peter Neubauer以深入了解此次发布的Neo4j及其向开发者所提供的功能。
Neo4j中的信息主要有如下3个概念：
Node（又叫做vertex）:类似于对象实例，拥有唯一的ID。
Relationship（又叫做edge）:它连接了两个Node，此外还有方向和RelationshipType。
Property（又叫做attribute）:他们是字符串类型的key/Object值对，Node与Relationship都有Property。
Neo4j围绕图形进行数据建模，Neo4j会以相同的速度遍历节点与边，其遍历速度与构成图形的数据量没有任何关系。此外，Neo4j还提供了非常快的图形算法、推荐系统和OLAP风格的分析。
Neo4j的读、写及遍历都是通过ACID事务系统进行管理的。图形遍历是通过Traverser API进行管理的。
Neo4j的HA如下图

Neo4j的问题是比较难水平扩展，访问基于REST API，性能较差。



Ralational
关系型数据库是企业应用中使用最多的，也是可以解决绝大多数问题的（不计成本的情况）。
在公司使用的RDBMS也比较杂，这和企业IT没有很好的规划有关。主要使用过Oracle,DB2,DB2 for Z/OS,teradata和mysql(ms sql也有用，但我没接触过)
oracle，曾经的数据库王者，RAC也是OLTP的终极方案，加上中国人口信息系统和淘宝，部署了oracle，名声最大。
oracle只支持read commited和serializable事务隔离级别，行锁是在行上加标记，不会造成锁升级。故而程序一般不会折腾死oracle。
oracle更适合在小机上工作，在X86服务器上总会出现假死，无论windows还是linux（windows要多很多）。

DB2
DB2数据库是公司硬件送的，没怎么在生产上用，DB2数据库支持4种事务隔离级别，在AIX上有行锁，页锁和表锁。windows和linux上没有页锁。在DB2的开发上，用惯oracle的人可能会不习惯，无意中会制造很多锁。
DB2 pureScale 技术秉承了 DB2 for z/OS Coupling Facility，在可靠性和可伸缩性上已经极大的超越了oracle的RAC。剩下的就是市场检验了。Coupling Facility已经是久经考验的了，就连Oracle创始人兼CEO Larry Ellison 也说：“我取笑过其他许多数据库，但唯独对大型机版本的 DB2 抱有尊重之心。它是当之无愧的一流技术。”

DB2 for z/OS
这个数据库其实是原来在os400上RPG的文件系统（说法欠妥），这是一个时代的产品，因为公司有这么一套服务在跑，得以接触一下，其实DB2 for z/OS的核心就是Coupling Facility。

teradata
teradata是公司的数据仓库在上面工作，虽然我喜欢的数据挖掘平台是DB2+Essbase+congnose。
teradata使用Shared Nothing的构建原则，包括三个部分：处理节点（Node）,用于节点间通信的内部高速互联（InterConnection）和数据存储介质（通常是磁盘阵列）。多个节点一起构成一个MPP系统，多个节点之间的内部高速互联是通过BYNET的硬件来实现。
另外teradata一个重要概念是Clique，可以认为是node 级的容错机制，通过Vproc Migration技术，当一个TPA节点失败时，Teradata自动重启然后原来运行在失败节点上的Vproc漂移到clique内的其它节点上运行。
teradata了解不多，也没什么机会去了解了。

mysql/MariaDB
mysql是我使用的比较多的系统，一直以来，我都认为mysql可以胜任公司99%以上的数据库应用的要求，尤其在mysql5.5版本中，percona实现了XtraDB的innodb升级版引擎后，mysql已经是足以胜任各种任务了，现在我使用mysql的mariadb5.5的版本，这个版本是继承了XtraDB，同时又做了很多优化，如我最想在mysql中看到的hash join的功能。另外子查询优化也是做的十分到位，同时MariaDB Galera Cluster也是十分成熟了。
MariaDB的部署也十分灵活，根据对可靠性要求可以部署主-从，主-主(DRBD)，主-主(ISCSI)，Galera Cluster等。
另外fedora,opnsuse,Slackware,Arch Linux已经从mysql换成MariaDB了(debian/ubuntu什么时候换？)
在实际的使用中，基本上按照主-主(DRBD)+1从的方式，虽然可靠性不如共享存储，但也能达到3个9的水平。另外对于大并发的一些主键访问，开放了innoDB的socket handler，官方mysql5.6上innoDB有memcached协议的访问，但实测性能并不理想，不到socket handler的一半。




结束语：匆匆记录一下，有时间回头再补。