图形数据库、NOSQL和Neo4j.pdfVIP

图形数据库、NOSQL 和Neo4j 简介 在众多不同的数据模型里，关系数据模型自80 年代就处于统治地位，而且有不少实现， 如Oracle MySQL 和MSSQL，它们也被称为关系数据库管理系统（RDBMS）。然而， 最近随着关系数据库使用案例的不断增加，一些问题也暴露了出来，这主要是因为两个原 因：数据建模中的一些缺陷和问题，以及在大数据量和多服务器之上进行水平伸缩的限 制。两个趋势让这些问题引起了全球软件社区的重视： 1. 用户、系统和传感器产生的数据量呈指数增长，其增长速度因大部分数据量集中在象 Amazon Google 和其他云服务这样的分布式系统上而进一步加快。 2. 数据内部依赖和复杂度的增加，这一问题因互联网 Web2.0 、社交网络，以及对大量不 同系统的数据源开放和标准化的访问而加剧。 在应对这些趋势时，关系数据库产生了更多的问题。这导致大量解决这些问题某些特定方 面的不同技术的出现，它们可以与现有RDBMS 相互配合或代替它们 - 亦被称为混合持久 化（Polyglo Persistence）。数据库替代品并不是新鲜事物，它们已经以对象数据库 （OODBMS ）、层次数据库（如LDAP）等形式存在很长时间了。但是，过去几年间，出 现了大量新项目，它们被统称为NOSQL 数据库（NOSQL-databases ） 本文旨在介绍图形数据库（Graph Database）在NOSQL 运动里的地位，第二部分则是对 Neo4j （一种基于Java 的图形数据库）的简介。 NOSQL 环境 NOSQL （Not Only SQL，不限于SQL ）是一类范围非常广泛的持久化解决方案，它们不 遵循关系数据库模型，也不使用SQL 作为查询语言。 简单地讲，NOSQL 数据库可以按照它们的数据模型分成4 类： 1. 键-值存储库（Key-Value-stores ） 2. BigTable 实现（BigTable-implementations） 3. 文档库（Documen -stores ） 4. 图形数据库（Graph Database） 就Voldemor 或Tokyo Cabine 这类键/值系统而言，最小的建模单元是键-值对。对 BigTable 的克隆品来讲，最小建模单元则是包含不同个数属性的元组，至于象CouchDB 和MongoDB 这样的文档库，最小单元是文档。图形数据库则干脆把整个数据集建模成一 个大型稠密的网络结构。 在此，让我们深入检阅NOSQL 数据库的两个有意思的方面：伸缩性和复杂度。 1. 伸缩性 CAP: ACID vs. BASE 为了保证数据完整性，大多数经典数据库系统都是以事务为基础的。这全方位保证了数据 管理中数据的一致性。这些事务特性也被称为ACID （A 代表原子性 C 表示一致性 I 是 隔离性 D 则为持久性）。然而，ACID 兼容系统的向外扩展已经表现为一个问题。在分 布式系统中，高可用性不同方面之间产生的冲突没有完全得到解决 - 亦称CAP 法则：  强一致性（C）：所有客户端看到的数据是同一个版本，即使是数据集发生了更新 - 如 利用两阶段提交协议（XA 事务），和ACID ，  高可用性（A ）：所有客户端总能找到所请求数据的至少一个版本，即使集群中某些机 器已经宕机，  分区容忍性（P）：整个系统保持自己的特征，即使是被部署到不同服务器上的时候， 这对客户端来讲是透明的。 CAP 法则假定向外扩展的3 个不同方面中只有两个可以同时完全实现。 为了能处理大型分布式系统，让我们深入了解所采用的不同CAP 特征。 很多NOSQL 数据库首先已经放宽了对于一致性（C）的要求，以期得到更好的可用性 （A ）和分区容忍性（P）。这产生了被称为BASE （基本（B）可用性（A ） 软状态 （S） 最终一致性（E））的系统。它们没有经典意义上的事务，并且在数据模型上引入 了约束，以支持更好的分区模式（如Dynamo 系统等）。关于CAP ACID 和BASE 的更 深入讨论可以在这篇介绍里找到。 2. 复杂度