NoSQL学习笔记（1）

我学习NoSQL的原因是始于数据网格中数据传输的学习，在这过程中，我需要学习如何存储数据、如何传输数据，更要研究如何提升各方面的性能。在接触数据存储这块时，我当然想到了关系型数据库，也留意了NoSQL这一新技术，并且现在许多公司诸如Google、Amaze等公司在对内或对外提供的存储服务中已经使用了该技术，确实需要学习学习！该篇文章就是讲讲皮毛的理论。

 

目前，数据量的快速攀升已经带动了很多技术的创新，数据存储及查询的技术革新更是迅猛。传统的关系型数据库的缺陷开始暴露出来，尽管存在cluster解决方案，但是不管是share storage或者是share nothing，其扩展性都有限。也就是说当今数据的大爆炸是NoSQL技术兴起的导火索。

 

NoSQL，即反SQL，是不带有关系的，使用NoSQL技术，当然就要准备面对失去使用很多数据库中的关系操作和运算，不过也是有技术来实现这些关系操作和运算，但是其性能值得商榷。

 

理解NoSQL技术，要先理解CAP原理、BASE模型和最终一致性，这是基础。

CAP：Consistency(一致性), 数据一致更新，所有数据变动都是同步的
         Availability(可用性), 好的响应性能
         Partition tolerance(分区容错性) 可靠性

对于网格来说，必然是分布式存储各种数据，那么就需要具备分区容错性，同时要对用户提供快速的响应，则应该具备可用性，对于一致性则可以通过其他途径来获得，比如最终一致性。所以，我在这里把重心放在可用性（快速响应）+分区容错性+最终一致性上面。当然，具体情况具体分析，基于这三个方面只能同时满足两点的原理，根据自己的使用环境，来决定抛弃哪一个。

BASE：BASE模型反ACID模型，完全不同ACID模型，牺牲高一致性，获得可用性或可靠性：
          Basically Available基本可用。支持分区失败(e.g. sharding碎片划分数据库)
          Soft state软状态 状态可以有一段时间不同步，异步。
          Eventually consistent最终一致，最终数据是一致的就可以了，而不是时时高一致。

BASE思想的主要实现有
1.按功能划分数据库
2.sharding碎片

BASE思想主要强调基本的可用性，如果你需要High 可用性，也就是纯粹的高性能，那么就要以一致性或容错性为牺牲，BASE思想的方案在性能上还是有潜力可挖的。

现在BASE模型反ACID模型，完全不同ACID模型，牺牲高一致性，获得可用性或可靠性：
Basically Available基本可用。支持分区失败(e.g. sharding碎片划分数据库)
Soft state软状态 状态可以有一段时间不同步，异步。
Eventually consistent最终一致，最终数据是一致的就可以了，而不是时时高一致。

BASE思想的主要实现有
1.按功能划分数据库
2.sharding碎片

BASE思想主要强调基本的可用性，如果你需要High 可用性，也就是纯粹的高性能，那么就要以一致性或容错性为牺牲，BASE思想的方案在性能上还是有潜力可挖的。

现在NoSQL运动丰富了拓展了BASE思想，可按照具体情况定制特别方案，比如忽视一致性，获得高可用性等等，NOSQL应该有下面两个流派：
1. Key-Value存储，如Amaze Dynamo等，可根据CAP三原则灵活选择不同倾向的数据库产品。
2. 领域模型 + 分布式缓存 + 存储 （Qi4j和NoSQL运动），可根据CAP三原则结合自己项目定制灵活的分布式方案，难度高。

这两者共同点：都是关系数据库SQL以外的可选方案，逻辑随着数据分布，任何模型都可以自己持久化，将数据处理和数据存储分离，将读和写分离，存储可以是异步或同步，取决于对一致性的要求程度。

不同点：NOSQL之类的Key-Value存储产品是和关系数据库头碰头的产品BOX，可以适合非Java如PHP RUBY等领域，是一种可以拿来就用的产品，而领域模型 + 分布式缓存 + 存储是一种复杂的架构解决方案，不是产品，但这种方式更灵活，更应该是架构师必须掌握运动丰富了拓展了BASE思想，可按照具体情况定制特别方案，比如忽视一致性，获得高可用性等等，NOSQL应该有下面两个流派：
1. Key-Value存储，如Amaze Dynamo等，可根据CAP三原则灵活选择不同倾向的数据库产品。
2. 领域模型 + 分布式缓存 + 存储 （Qi4j和NoSQL运动），可根据CAP三原则结合自己项目定制灵活的分布式方案，难度高。

这两者共同点：都是关系数据库SQL以外的可选方案，逻辑随着数据分布，任何模型都可以自己持久化，将数据处理和数据存储分离，将读和写分离，存储可以是异步或同步，取决于对一致性的要求程度。

不同点：NOSQL之类的Key-Value存储产品是和关系数据库头碰头的产品BOX，可以适合非Java如PHP RUBY等领域，是一种可以拿来就用的产品，而领域模型 + 分布式缓存 + 存储是一种复杂的架构解决方案，不是产品，但这种方式更灵活，更应该是架构师必须掌握的。

Nati Shalom对内存和硬盘在数据库部署和使用中的角色作了一番有理有据的评述。 Shalom着重指出用数据库集群和分区来解决性能和可伸缩性的局限。他说，“数据库复制和数据库分区都存在相同的基本问题，它们都依赖于文件系统/硬盘 的性能，建立数据库集群也非常复杂”。他提议的方案是转向In-Memory Data Grid（IMDG），用Hibernate二级缓存或者GigaSpaces Spring DAO之类的技术作支撑，将持久化作为服务（Persistence as a Service）提供给应用程序。Shalom解释说，IMDG 提供在内存中的基于对象的数据库能力，支持核心的数据库功能，诸如高级 索引和查询、事务语义和锁。IMDG还从应用程序的代码中抽象出了数据的拓扑。通过这样的方式，数据库不会完全消失，只是挪到了“正确的”位置。
IMDG相比直接RDBMS访问的优势列举如下：
（1）位于内存中，速度和并发能力都比文件系统优越得多
（2）数据可通过引用 访问
（3）直接对内存中的对象执行数据操作
（4）减少数据的争用
（5）并行的聚合查询
（6）进程内 （In-process）的局部缓存
（7）免除了对象-关系映射（ORM）

你是否需要改变对应用和硬件的思维方 式，最终取决于你要用它们完成的工作。但似乎公论认为，开发者解决性能和可伸缩性的思路已经到了该变一变的时候。


IMDG需要我重点关注一下！上面一些内容是我看过别人的文章后总结的，也有是我直接复制的，后面会深入学习，多写自己的理解，放在博客上，督促自己！