五大存储模型关系模型、键值存储、文档存储、列式存储、图形数据库

数据库市场需要细分，行式数据库不再满足所有的需求，而有很多需求需要通过本内存数据库和列式数据库解决，列式数据库在数据分析、海量存储、BI这三个领域有自己独到。

1. 关系型数据库(行式数据库) mysql sybase etc

定义：关系模型使用记录（行或者元祖）进行存储，记录存储在表中，表由架构界定。表中的每个列都有名称和类型，表中的所有记录都要符合表的定义。SQL是专门的查询语言，提供相应的语法查找符合条件的记录，如表联接（Join）。表联接可以基于表之间的关系在多表之间查询记录。

存储格式：行式数据库把一行中的数据值串在一起存储起来，然后再存储下一行的数据，以此类推。

例如以下的一个表：

EmpIdLastnameFirstnameSalary1SmithJoe400002JonesMary500003JohnsonCathy44000

1,Smith,Joe,40000;2,Jones,Mary,50000;3,Johnson,Cathy,44000;

特点：据以行相关的存储体系架构进行空间分配，主要适合与小批量的数据处理，常用于联机事务型数据处理。不能满足后面三个需求：对数据库高并发读写要求，对海量数据的高效率存储和访问需求，对数据库高可扩展性和高可用性。 一句话不适合分布式、高并发和海量。

2. 列式存储 Sybase IQ, C-Store, Vertica,

定义：什么是列式数据库?列式数据库是以列相关存储架构进行数据存储的数据库。列式存储以流的方式在列中存储所有的数据，主要适合与批量数据处理和即席查询。

存储格式 ：

列式数据库把一列中的数据值串在一起存储起来，然后再存储下一列的数据，以此类推。

1,2,3;Smith,Jones,Johnson;Joe,Mary,Cathy;40000,50000,44000;

特点：包括查询快，由于查询需要读取的blocks少；数据压缩比高，正因为同一类型的列存储在一起。Load快。 简化数据建模的复杂性。但是插入更新慢，不太适合数据老是变化，它是按列存储的。这时候你就知道它适做DSS（决策支持系统），BI的优秀选择，数据集市，数据仓库，它不适合OLTP。

Examples are Sybase IQ, C-Store, Vertica, VectorWise,MonetDB, ParAccel, and Infobright.

//具体请参考如下地址

http://en.wikipedia.org/wiki/Column-oriented_DBMS.

3. 键值存储 cassandra, hbase, bigtable

即Key-Value存储，简称KV存储。它是NoSQL存储的一种方式。它的数据按照键值对的形式进行组织，索引和存储。KV存储非常适合不涉及过多数据关系业务关系的业务数据，同时能有效减少读写磁盘的次数，比SQL数据库存储拥有更好的读写性能。

典型例子 Sorted String Table即SSTable。其实STL 库中map和hash_map, JAVA中hash_table, hash_map就是键值存储。 但是他们值只支持内存操作，而且map的查询效率太低，关键是他们只是简单的数据结构，不能实现较大规模存储和分布式,而且数据的修改效率比较低。 而SSTalbe就解决了这些问题。

键值存储实际是分布式表格系统的一种。

其中的实现机制也可以参考

LevelDB/Sstable: http://blog.chinaunix.net/uid-26111972-id-3342215.html.

LevelDB： http://www.samecity.com/blog/Index.asp?SortID=12

分布式key-value 系统有cassandra, hbase, bigtable etc

http://kkovacs.eu/cassandra-vs-mongodb-vs-couchdb-vs-redis

4. 文档存储 

文档存储支持对结构化数据的访问，不同于关系模型的是，文档存储没有强制的架构。

事实上，文档存储以封包键值对的方式进行存储。在这种情况下，应用对要检索的封包采取一些约定，或者利用存储引擎的能力将不同的文档划分成不同的集合，以管理数据。

与关系模型不同的是，文档存储模型支持嵌套结构。例如，文档存储模型支持XML和JSON文档，字段的“值”又可以嵌套存储其它文档。文档存储模型也支持数组和列值键。

与键值存储不同的是，文档存储关心文档的内部结构。这使得存储引擎可以直接支持二级索引，从而允许对任意字段进行高效查询。支持文档嵌套存储的能力，使得查询语言具有搜索嵌套对象的能力，XQuery就是一个例子。MongoDB通过支持在查询中指定JSON字段路径实现类似的功能。

MongoDB 对SQL 和ACID 支持的比较全面的数据库了。不过， 比较多的还是介绍日志的采集和存储，小文件的分布式存储，类似互联网微博应用的数据存储等方面的内容。

MongoDB 和 Cassandra的比较：
http://www.csdn.net/article/2013-08-23/2816679-time-series-data-mongdb-vs-cassandra

5.图形数据库

图形数据库存储顶点和边的信息，有的支持添加注释。

图形数据库可用于对事物建模，如社交图谱、真实世界的各种对象。IMDB（Internet MovieDatabase）站点的内容就组成了一幅复杂的图像，演员与电影彼此交织在一起。

图形数据库的查询语言一般用于查找图形中断点的路径，或端点之间路径的属性。Neo4j是一个典型的图形数据库。

为什么使用图数据库？
这个问题，欢迎你跟我交流。图数据库的扩展性，灵活性非常好，适合用于复杂关系管理和关系查询推理，社交关系应用就是一个可选的应用场景。 而我选择图数据库，起因是研究语义网和Ontology的应用，语义网和Ontology的数据结构（三元组）就是图结构数据，而基于RDF构建的语义网，过于复杂，效率很低，实际上不如基于图数据库的构建方便好用，而且Neo4J支持RDF，SPARQL等扩展。另外，我认为OWL，实用价值不大，OWL几乎就是用XML来描述一种面向对象的编程语言，而这种编程语言如果表示能力过强（OWL Full），根本无法实现，如果表示能力过弱（OWL Lite），其实没有多少实用意义。而且，我觉得Tim Berners-Lee的语义网，即基于RDF的语义WEB，用RDF描述语义的这种思路走向了以前基于规则的NLP的思路，虽然加上Human Computation 众包的模式，但还是很难走通。我更关注的是本体关系，知识库的构建，而且知识本体主要是Meta Data，不需要很多数据，尽量不要保存instance data，获取instance data可以关联其他数据库的数据源进行查询（这种数据Key-Value或Table保存即可）。
简单的关系推理，属性传递，其实就是查询，Neo4J中Cypher也可以完成。所以，我倾向于用图数据库来构建知识库knowledge base ("KB")，或knowledge graph ("KG")。知识库对于知识关联查询进行相关搜索或关联推荐，比较有价值。而且，从知识本体关系库中可以推理得到规则， 比如，If Place is Meeting Room and Date is Workday and Than Activity is Meeting.  这样的规则是可以从本体关系中查询得到的，规则可以在很大程度上弥补基于统计的计算学习的许多不足。 更大的作用，我觉得图数据库是一种 “合理的知识保存和描述的方式”，有利于知识的持续积累和不断演进。另外，在未来，知识本体，与模型算法建立关系，如果能在合适的关系条件下，使用正确的算法模型，那将发挥真正的巨大作用，那就离”智能“很近了。