cassandra

软件工程师对于最荒渺的事情非常热衷。我们倾向于认为自己是超理性的，但是当我们面临一种技术选择的时候，我们最终会陷入一种疯狂状态——从一个人的Hacker News评论跳到另一个人的博客文章，直到变得麻木，我们无助地漂浮朝着最明亮的光线倾斜，并且俯卧在它的前面，而忽略了我们最初寻找的东西。 这不是理性的人做出决定的方式，而是软件工程师决定使用MapReduce的方式。 正如Joe Hellerstein在他的本科数据库课程[1]上所说的（在54分钟）： 问题是世界上有5家公司从事如此大的工作。对于其他所有人……你正在为实际上不需要的容错能力执行所有这些I/O。人们在2000年代有点Google的狂热：“我们将像Google一样做所有事情，因为我们也运行着世界上最大的互联网数据服务” [横摆倾斜，等待笑声] 你们的数据中心大楼有几层？Google在俄克拉荷马州梅斯县的数据中心是4层。 拥有比所需更多的容错能力可能听起来不错，但考虑到成本：不仅会做更多的I/O，而且可能会从一个成熟的系统（如事务，索引和查询优化器）过渡到某种相对不成熟的系统上。真是倒退了一大步[2]。有多少Hadoop用户自觉地进行了这些折衷？有多少用户明智地进行了这些折衷？ 目前，MapReduce/Hadoop仅仅是一个简单的目标（soft target），即使开发人员已经意识到目标不是很合适。但是

典型 Web App 架构 以下是一个典型的高负载 web 应用示例： 上图展示了一个典型的，三层架构的高性能 Web 应用。这种成熟的架构多年以来已被广泛部署于包括 Google、Yahoo、Facebook、Twitter、Wikipedia 在内的诸多大型 Web 应用中。 　 反向代理服务 位于三层构架中最外层的反向代理服务器负责接受用户的接入请求，在实际应用中，代理服务器通常至少还要完成以下列表中的一部分任务： 连接管理 ：分别维护客户端和应用服务器的连接池，管理并关闭已超时的长连接。 　 攻击检测和安全隔离 ：由于反向代理服务无需完成任何动态页面生成任务，所有与业务逻辑相关的请求都转发至后端应用服务器处理。因此反向代理服务几乎不会被应用程序设计或后端数据漏洞所影响。反向代理的安全性和可靠性通常仅取决于产品本身。在应用服务的前端部署反向代理服务器可以有效地在后端应用和远程用户间建立起一套可靠的安全隔离和攻击检测机制。 如果需要的话，还可以通过在外网、反向代理、后端应用和数据库等边界位置添加额外的硬件防火墙等网络隔离设备来实现更高的安全性保证。 　 负载均衡 ：通常使用轮转（Round Robin）或最少连接数优先等策略完成基于客户请求的负载均衡；也可以使用 SSI 等技术将一个客户请求拆分成若干并行计算部分分别提交到多个应用服务器。 　 分布式的 cache 加速

前言 在有代表性的关系型数据库如MySQL、SQL Server、Oracle中，数据存储与索引的基本结构就是我们耳熟能详的B树和B+树。而在一些主流的NoSQL数据库如HBase、Cassandra、LevelDB、RocksDB中，则是使用日志结构合并树（Log-structured Merge Tree，LSM Tree）来组织数据。本文先由B+树来引出对LSM树的介绍，然后说明HBase中是如何运用LSM树的。 回顾B+树 为什么在RDBMS中我们需要B+树（或者广义地说，索引）？一句话：减少寻道时间。在存储系统中广泛使用的HDD是磁性介质+机械旋转的，这就使得其顺序访问较快而随机访问较慢。使用B+树组织数据可以较好地利用HDD的这种特点，其本质是多路平衡查找树。下图是一棵高度为3的4路B+树示例。 与普通B树相比，B+树的非叶子节点只有索引，所有数据都位于叶子节点，并且叶子节点上的数据会形成有序链表。B+树的主要优点如下： 结构比较扁平，高度低（一般不超过4层），随机寻道次数少； 数据存储密度大，且都位于叶子节点，查询稳定，遍历方便； 叶子节点形成有序链表，范围查询转化为顺序读，效率高。相对而言B树必须通过中序遍历才能支持范围查询。 当然，B+树也不是十全十美的，它的主要缺点有两个： 如果写入的数据比较离散，那么寻找写入位置时，子节点有很大可能性不会在内存中