3.3 NoSQL数据库解决的核心难题

针对关系型数据库在Web 2.0环境中所面临的难以克服的问题，NoSQL数据库围绕访问数据的方式和一致性原则两大方面进行创新，有效解决了关系型数据库中高速查询和多写瓶颈问题。

3.3.1 实现高速查询

几年前，1TB的个人数据就被认为是非常庞大的了，但今天，本地硬盘驱动器和备份驱动器的容量通常都有这么大。可以料想，在未来几年里，即便硬盘驱动器的默认容量超过了数个TB也不足为奇。我们生活在一个数据大爆炸的时代里，数码设备的输出、博客、日常社交网络的更新、微博、微信、电子文档、扫描的内容、音乐文件以及视频都在快速增多。可以说，我们在消费大量数据的同时也在生成大量数据。

当数量达到PB级时，即便是非常简单的查询操作，其执行也会变得异常复杂。例如，某国际知名数据库以80M/s的速度顺序扫描1GB的数据只需要12.5秒，而顺序扫描1PB的数据则需要约146天，可以说，这犹如大海捞针。如果包括复杂的计算，将更加耗时。例如，为了找出在一个时间段内所有运动轨迹相似的车辆，需要对车辆的所有运动轨迹做各种关联分析和复杂运算，这种需求即便是在小规模环境下，查询也相当耗时。

在大多数NoSQL数据库中，对数据访问的方式都被限定为通过键（查询条件）来查询相对应的值（查询对象数据）这一种。由于存在这样的限定，可以实现高速查询。而且，大多数NoSQL数据库都可以以键为单位进行自动水平分割，这样也有利于提高查询速度。此外，也有像memcached这样不永久保存数据，只是作为缓存来使用的数据库。

3.3.2 满足多写需要

在Web 2.0时代，互联网网站“我来搭台您来唱戏”，以论坛（BBS）、博客（blog）、微信为主要代表，信息注重小而精。内容的提供者是一个个分离的个体，所有信息不再像Web 1.0时代的密集访问，即便有个别的明星博客、SNS焦点神秘嘉宾也不例外，总体上是“少读多写”（Write heavy）的局面。然而，传统的关系型数据库产品主要是面向传统的模式设计，而且为了实现数据驱动、内容驱动以及预定式信息处理，往往要对“写”赋予严格的条件要求，包括生成重做日志、检查各类锁控制、激发触发器并对触发的内容做出响应等。不仅如此，在数据写入后，关系型数据库还要提供复杂的分布式处理，这包括信息复制、内容归档、通知外围监控系统等。因此，难以提供“少读多写”信息应用模式所需要的良好处理性能。

大多数NoSQL数据库都遵循“BASE”原则（Basically Available 、Soft-state和Eventually consistent的缩写BASE），重视可用性（Basically Avai1able），但不追求状态的严密性（Soft-state），且不管过程中的情况如何，只要最终能够达成一致即可（Eventually consistent），这样，用于保持一致性的开销就可以得到有效控制，有效解决了传统关系型数据库在任何情况下都要保持严格的一致性的开销难题。

NoSQL数据库通过使用分布式结点集（称为集群）提供高度弹性扩展功能，让用户可以通过添加结点来动态处理负载。同时，只给用户“必要的”功能，让大家可以“自助式”地进行读/写处理，进而将数TB、甚至PB的信息加以管理。所有的读/写操作也都是直入主题的，对运行环境不要求，也不提供多余的操作，最终加速用户的“多写少读”的性能。