Google Analytics存储了全球范围内网站的大量静态数据，随着数据体积越来越大，检索的难度也必然随之增加。近日，Gen Furukaw在Dzone上撰文表示，Google Analytics的高效一定程度上归功于其兼职存储BigTable
在Google，随时都可能存在大量应用程序被添加到其基础设施，而这些应用程序中，任意一个都可能给系统带来繁重的工作负载。迎合这样的资源需求并不简单，而在有限时间内做到这一点就更是难上加难了。
假如Google部署的是一个单节点上的传统数据库，那么一旦达到容量限制，他们必须为其更新硬件。鉴于Google应用程序的数量和存储数据的体积，这种硬件升级可能每天都会进行一次。虽然负载也可以分配到多个节点，但随着节点数的增加，系统维护的难度将变得不可思议。
综上所述，鉴于大规模系统升级和维护的难度，标准关系型数据库对Google来说并不可选。
寻找一个可扩展解决方案
为了保证速度，及避免频繁的更新硬件，Google定制了自己的存储解决方案——BigTable。取代关系型数据库将数据存放到表格中，BigTable使用了多维排序映射的方式对数据进行存储，也就是现在我们所说的键值存储类型。这种方式不仅提升了性能，也简化了扩展过程。
关系型数据库中的信息存储
关系型数据库将信息的每个部分都存放到独立的位置，通常是表中的一列。同时，在关系型数据库中，数据的规范化非常重要，这个过程保证了其他表格或者列中不会存在冗余数据。
举个例子，客户的“姓”必须存放在某个表格的对应列中。假如某个客户的姓在其他位置发现，那么它将被删除，信息的检索仍然会被指定到原始表格。
这种结构的缺点是数据库内部可能变得非常复杂，从而导致即使一个简单的查询都可能涉及到大量的执行路径，而所有这些路径都会在运行时进行计算以寻找最优路径。数据库越复杂，运行时就需要越多的资源来确定查询路径。
键值存储中的信息存储
在键值存储中，数据被允许存在多个备份。取代使用其他昂贵硬件资源来增加速度，这里的设计理念是利用磁盘空间，它更新起来非常容易，成本也不高。
对于简单查询来说，多备份非常有利，在键值存储中，相关的数据可以被存储到一起，从而避免在查询过程中访问多个路径以获得所需数据。
取代关系型数据中的表格存储类型，键值存储使用域，同时也无需预定义数据结构模式。域中存储的数据通过键定义，它们可以通过大量不同的属性访问。
这些属性可能是字符串，也可以是流行编程语言中匹配的任意数据类型，它可能会是数组、对象、整形、浮点型、布尔型以及编程语言中使用的任意基本数据类型。
在键值存储中，取代数据本身，数据完整性和逻辑通过应用程序代码维护，通过使用1个或多个API，开发者可以编写出最优的实现方法。这样一来，数据检索工作被转移到编写正确的逻辑上，而不是依赖数据库去优化在大量可能路径中选择一个最佳路径。
写在最后
当然，除了键值存储的使用之外，Google Analytics快还源于其优秀的编程逻辑，这点就不再一一详述了。