一ＴｅｃｈｎｏＩｏｇｙ Ｊ技术 基于内存数据库的分布式数据库架构 ■文／何坤 本文通过引入内存数据库层，建立了两层多分区分布式数据库架构，用于解决海量高并发系 统的数据存储和访问问题，尤其适用于电子商务等数据模型复杂且业务复杂的互联网站。 些年互联网站发展迅猛，为 Ｔ恤”，或者在阿里巴巴上“列出某 的基本访问模式。 篙 雾票萋 个会员所有待发货的订单”。这类查 抛开持久化的可靠性，即数据可 询主要针对多个非主键字段，即便对 以先不存储到磁盘（Ｄｉｓｋ）上，内存 设计思想，例如Ｋｅｙ—ＶｌａＩｕｅ引擎、数据 于ＢｉｇＴａｂｌｅ、Ｃａｓｓａｎｄ ｒａ这样的基于 存储的性能远高于磁盘存储。表１和表 分区等。而对于电子商务类网站，海 Ｃｏｌｕｍｎ的Ｋｅｙ—Ｖａｌｕｅ数据库，其简单 ２展示了针对Ｏｒａｃｌｅ和Ａｌｔｉｂａｓｅ所做的 量数据问题还有一个重要特点，就是 的Ｑｕｅｒｙ ＡＰｌ还无法胜任此类需求。 性能对比，后者在插入和查询上性能 数据结构化及数据之间的关联，淘宝 因此在阿里巴巴和淘宝，Ｏ ｒａｃＩｅ、 是Ｏｒａｃｌｅ的５—７倍。 如此，阿里巴巴也是如此，这是与社区、 ＭｙＳＱＬ等关系数据库将仍然扮演重要 视频、博客等互联网站的显著差异。 角色。 ＮｏＳＱＬ是灵丹妙药吗？ ＭｙＳＱＬ集群 Ｎ０ＳＱＬ、ＫｅＹ．Ｖａｌ ｕｅ引擎如 引入Ｋｅｙ—Ｖａｌｕｅ￣ｌ擎等非关系数据 ＢｉｇＴａｂｌｅ、Ｃａｓｓｅｎｄｒａ等在很多大型网 库无非是要解决海量数据在高并发环 站被采用，很好地解决了海量数据存 境下的高效读写问题，最大程度地在 Ｓｉｍｐｌｅ Ｄ曩 ＾０∞ｌ Ｍｏｄｅ 储和访问问题。而对于电子商务类网 可靠的持久化（Ｄｕｒａｂｌｅ）与高访问性 ．Ｄｉｓｋ ｏ８ 站，Ｋｅｙ．Ｖａｌｕｅ和ＮｏＳＱＬ并不是解决 能（Ｐｅｒｆｏｒｍａｎｃｅ）之间选择一个平衡 图１ 传统磁盘数据库的基本访问模式 此问题的灵丹妙药，最多它们仅能用 点。在高度结构化系统中，同样的考虑 表１ Ｏｒａｃｌｅ、Ａｌｔｉｂａｓｅ性能对比：插入５万条 于一些数据模型较为简单的应用。出 驱使我们需要考虑另外的解决方案。 现这种现象的原因有以下两个方面。 目前一种通行的做法是ＭｙＳＱＬ读 写分离式集群，１个或少数Ｍａｓｔｅｒ写， 表２ Ｏｒａｃｌｅ、Ａｌｔｉｂａｓｅ性能对比：关联查询 １０万条 数据模型复杂 多数Ｓｌａｖｅ读，Ｍａｓｔｅｒ与Ｓｌａｖｅ进行变 淘宝和阿里巴巴的会员、宝贝、 更数据的同步。首先，这种方案经过 供求、订单等核心实体数据模型复 大量的实践，可靠且可行。 由此可见：Ｐｍ（内存数据库读写性 杂，属性个数几十到上百个。例如： 然而，直接向ＤＢ执行写操作， 能）远远高于Ｐｄ（磁盘数据库读写性 会员（Ｍｅｍｂｅｒ）就包含基本信息、联 仍然比较耗时（参见表１和表２），数 能）。 系、工商、账户等多个域的信息；另 据复制，也可能存在不一致延时的情 结合前面分析的模型复杂性和业 外，核心实体之间、外围实体与核心 形。是否还有更快的方案？ 务复杂性原因，必须采用关系数据库 实体之间还存在复杂的关联。 （ＲＤＢＭＳ）。因此，这两点考虑可以 内存 关系数抛库 推导出另一个解决思路：内存型关系 业务复杂 可靠的持久化指数据存储到磁盘 数据库。如表３所示。 模型的复杂源于业务和逻辑的复 等设备上。图１展示了传统磁盘数据库 在这个方案中，我们可以将内 杂。电子商务网站大量查询场景是结 表３ ＤＢ选型对比分析 构化查询，例如在淘宝上查询“卖家 在江浙沪，价格在５０￣２００元的男士 １１６程序员
