3.1. 弱酸性
长期以来，数据一致性一直是架构师和开发人员的圣牛。所有关系数据库都提供了某种程度的隔离，要么通过更新锁和阻塞读取，要么通过撤消日志。随着海量信息和分布式系统的出现，很明显，一方面要为它们确保一组事务性操作，另一方面要获得高可用性和快速响应时间是不可能的。
此外，即使更新一条记录也不能保证任何其他用户会立即看到系统中的更改，因为更改可能发生在例如主节点中，并且副本被异步复制到从节点，另一个用户可以使用该从节点作品。在这种情况下，他将在一定时间后看到结果。这就是所谓的最终一致性，这就是世界上所有最大的互联网公司现在都在做的事情，包括 Facebook 和亚马逊。后者自豪地宣称，用户可以看到不一致数据的最大间隔不超过一秒。这种情况的一个例子如图所示：
在这种情况下出现的逻辑问题是，如何处理通常对操作的原子性一致性提出高要求同时需要快速分布式集群的系统——金融、在线商店等？实践表明，这些要求不再适用：金融银行系统的一位设计者说：“如果我们真的等待全球自动取款机 (ATM) 网络中的每笔交易完成，交易将花费很长时间，以至于客户会一怒之下逃跑。如果您和您的伴侣同时取款并超过限额会怎样？“你们都会得到钱，我们稍后会解决它。”
另一个例子是图中所示的酒店预订。数据策略假定最终一致性的在线商店需要提供针对此类情况的措施（自动冲突解决、操作回滚、与其他数据更新）。在实践中，酒店总是试图保留一个空闲房间“池”以备不时之需，这可能是解决争议情况的一种方法。
事实上，弱的ACID特性并不意味着它们根本不存在。在大多数情况下，使用关系数据库的应用程序使用事务来更改逻辑上相关的对象（订单 - 订单项目），这是必要的，因为这些是不同的表。通过在 NoSQL 数据库中正确设计数据模型（聚合是一个订单和一个订单项列表），您可以在更改单个记录时实现与在关系数据库中相同的隔离级别。
3.2. 分布式系统，没有共享资源（share nothing）
同样，这不适用于数据库图，根据定义，其结构不能很好地跨远程节点传播。
这也许是 NoSQL 数据库开发的主要主题。随着世界上信息的雪崩式增长以及在合理时间内处理信息的需要，垂直可扩展性的问题出现了——处理器速度的增长停止在 3.5 GHz，从磁盘读取的速度也在以 3.5 GHz 的速度增长速度慢，再加上一台功能强大的服务器的价格总是比几台简单的服务器总价还高。在这种情况下，传统的关系数据库，即使是集群在磁盘阵列上，也无法解决速度、可扩展性和吞吐量的问题。
解决这种情况的唯一方法是水平扩展，当多个独立服务器通过快速网络连接并且每个服务器仅拥有/处理部分数据和/或仅部分读取更新请求时。在这个架构中，要增加存储容量（容量、响应时间、吞吐量），你只需要向集群添加一个新的服务器——仅此而已。分片、复制、容错（即使一台或多台服务器停止响应也会得到结果）、添加节点时的数据重新分配由NoSQL数据库自己处理。
我将简要介绍分布式 NoSQL 数据库的主要特性：
复制——更新时将数据复制到其他节点。允许既实现更大的可扩展性又增加数据的可用性和安全性。习惯上分为两种：
主从：
和点对点： 
第一种类型假定读取具有良好的可扩展性（可以从任何节点发生），但不可扩展的写入（仅对主节点）。在确保持续可用性方面也有一些微妙之处（在主节点崩溃的情况下，手动或自动将剩余节点之一分配到它的位置）。第二种类型的复制假设所有节点都是平等的，并且可以服务于读取和写入请求。
分片是按节点划分数据：
分片通常用作关系数据库的“拐杖”以提高速度和吞吐量：用户应用程序将数据分区到几个独立的数据库中，当用户请求相应的数据时，访问特定的数据库。在 NoSQL 数据库中，分片与复制一样，是由数据库本身自动完成的，用户应用程序与这些复杂的机制是分开的。
3.3. NoSQL 数据库大多是开源的，创建于 21 世纪
基于第二个理由，Sadalaj 和 Fowler 没有将对象数据库归类为 NoSQL（尽管 http://nosql-database.org/ 将它们包含在一般列表中），因为它们创建于 90 年代并且从未获得太多普及. .
NoSQL 运动正以惊人的速度流行起来。然而，这并不意味着关系数据库正在变得过时或过时。它们很可能会像以前一样被积极使用和使用，但越来越多的 NoSQL 数据库将与它们共生。我们正在进入一个多语言持久化时代，一个不同数据存储用于不同需求的时代。现在没有关系数据库作为无可争议的数据源的垄断。越来越多的架构师根据数据本身的性质、我们希望如何操作它以及预期的信息量来选择存储。所以一切都变得更有趣了。
下面我们将尝试以 NoSQL Cassandra DBMS 为例来了解分布式数据库的操作......