NoSQL（Not Only SQL）


传统的数据库缺点

按行存储，对某一列进行运算的场景 效率较低 
表结构 Schema 扩展不方便 修改表结构，需要执行 DDL(data definition language) 修改期间会导致锁表
全文搜索功能较弱 只能使用like  性能和扩展性差
存储和处理复杂关系型数据功能较弱 ，譬如社交关系、推荐引擎、欺诈检测、知识图谱、生命科学和 IT/网络等


行存储  适合 OLTP
列存储  适合 OLAP


NoSQL 一般不支持 事务 ACID , 换取更高的性能 和扩展性

NoSQL 5大类型

列式数据库 
批量数据处理和即时查询   HBase
列 数据类似 压缩效率高 常见的字典表压缩
按列读取效率高 按列过滤计算聚合

K-V 数据库
Redis Cassandra （参考 Amazon Dynamo实现）
LevelDB

文档数据库
MongoDB CouchDB

全文搜索引擎

倒排索引 inverted index
Elasticsearch 
solr

图数据库

Neo4j
ArangoDB
Titan


Neo4j 图 graph
节点 边

节点表示实体，边表示实体之间的关系。节点和边都可以有自己的属性。不同实体通过各种不同的关系关联起来，形成复杂的对象图。

存储节点 使用 index-free adjacency，每个节点都有指向其邻居节点的指针
adjacency 邻接
索引自由邻接

Neo4j 中边是最重要的， first-class entities，单独存储，有利于提高图遍历速度，也可以很方便地以任何方向进行遍历。


优点

高性能表现，图的遍历是图数据结构所具有的独特算法，即从一个节点开始，根据其连接的关系，可以快速和方便地找出它的邻近节点。 
这种查找数据的方法并不受数据量的大小所影响，因为邻近查询始终查找的是有限的局部数据，不会对整个数据库进行搜索。

设计的灵活性，数据结构的自然伸展特性及其非结构化的数据格式，让图数据库设计可以具有很大的伸缩性和灵活性。 
因为随着需求的变化而增加的节点、关系及其属性并不会影响到原来数据的正常使用。

开发的敏捷性，直观明了的数据模型，从需求的讨论开始，到程序开发和实现，以及最终保存在数据库中的样子，它的模样似乎没有什么变化，甚至可以说本来就是一模一样的。
完全支持 ACID  支持事务


缺点

节点，关系和属性数量限制。
不支持拆分。

使用场景

关系性强的数据中，例如社交网络。
推荐引擎。将数据以图的形式表现，有益于推荐的制定。

不适用场景：
记录大量基于事件的数据（例如日志条目或传感器数据）。
对大规模分布式数据进行处理，类似于 Hadoop。
适合于保存在关系型数据库中的结构化数据。
二进制数据存储。


选型参考指标

数据量
并发量
实时性
一致性要求
读写分布和类型
安全性
运维成本

一般参考

内部使用的管理型系统，如运营系统，数据量少，并发量小，首选考虑关系型。
大流量系统，如电商单品页，后台考虑选关系型，前台考虑选内存型。
日志型系统，原始数据考虑选列式，日志搜索考虑选倒排索引。
搜索型系统，例如站内搜索，非通用搜索，如商品搜索，后台考虑选关系型，前台考虑选倒排索引。
事务型系统，如库存，交易，记账，考虑选关系型+缓存+一致性型协议。
离线计算，如大量数据分析，考虑选列式或者关系型也可以。
实时计算，如实时监控，可以考虑选内存型或者列式数据库。


设计实践 基于需求、业务驱动架构 数据存储方案 各种权衡