系统架构：

Ｃａｓｓａｎｄｒａ 是 一 套 开 源 分 布 式 Ｎｏ －ＳＱＬ 数据库系统， 基于一致性哈希算法的 Ｐ２Ｐ 环形结构。 这种结构 各节点功能完全相 同， 可灵活添加节点来完成系 统的扩充或删除节点， 且无需大规模转移数据， 同 时彻底避免系 统因 单点故障

导致的不稳定性； 每个节点通过 Ｇｏｓｓｉｐ 机制进行消息同步； 每 个 数据 项 都 会 被 复 制 到 Ｎ 个节 点（ Ｎ 是通过参数配置的副本因 子）， 系 统利 用 数据

的复制机将存储在各节点上的数据复制到其他节点上， 实现了数据的高度可获得性与安全性。

数据模型：

Ｃａｓｓａｎｄｒａ 使用 宽 列 存 储 模 型， 每 行 数 据 记录是以 Ｋｅｙ － Ｖａｌｕｅ 形式进行存储， 其中 Ｋｅｙ为 唯一标识。 每 个Ｋｅｙ－ Ｖａｌｕｅ 其 中 的 Ｖａｌｕｅ 也 称 为Ｃｏｌｕｍｎ， 作 为 一 个 三 元 组， 包 含 有

Ｃｏｌｕｍｎ Ｎａｍｅ 、 Ｃｏｌｕｍｎ　Ｖａｌｕｅ 与 ｔｉｍｅｓｔａｍｐ ； 每 个 ＣＦ 由一个 Ｋｅｙ及其对应的若干个 Ｃｏｌｕｍｎ 标识组成。一个

ｋｅｙｓｐａｃｅ 包含若干 个 ＣＦ ， 类似关系 型数据库中一个

ｄａｔａｂａｓｅ 可有 多 个ｔａｂｌｅ 。

下 图 为 一 个Ｃｏｌｕｍｎ 型数据模型。

CPA理论：

ＮｏＳＱＬ 典 型 遵 循 由 Ｅｒｉｃ　Ｂｒｅｗｅｒ 提 出 的ＣＡＰ 理论  ， 依据此理论， 在一个大规模的分布式数据系统中， 有三个需求是彼此循环依赖的， 一致性（ ｃｏｎｓｉｓｔｅｎｃｙ ） 、 可 用 性 （ ａｖａｉｌａｂｉｌｉｔｙ ） 、 分 区 耐受性（ ｐａｒｔｉｔｉｏｎ　ｔｏｌｅｒａｎｃｅ ） 。

一致性： 对所有数据库客户 端 使 用 同 样 查 询 都 可 得 到 相 同 的 数 据；

可用性： 所 有 数 据 库 客 户 端 都 可 读 写 数 据；

分区耐受性： 数 据 库 分 散 到 多 个 服 务 器 上， 即使发生 网 络 故 障， 仍 可 提 供 服 务。

ＣＡＰ 理 论 可简单描述 为 ：

一 个 分 布 式 系 统 不 能 同 时 满 足 以上三个 特 性， 最 多 只 能 同 时 满 足 两 个。

Ｃａｓｓａｎｄｒａ 主要支持 可 用 性 和 分 区 耐 受 性。

在 Ｃａｓｓａｎｄｒａ 中 ， 数据 具 备 最 终 一 致 性， 集 群 整 体 的 完 全

可用 性。

存储机制

Ｃａｓｓａｎｄｒａ 依赖本地的文件系统通过内存与磁盘的双重存储机制来保证数 据的持久性 。

Ｃａｓｓａｎｄｒａ 有三 个重 要 的 数 据 结 构， 记录 于 内 存

的 Ｍｅｍｔａｂｌｅ ， 保 存 在 磁 盘 中 的 Ｃｏｍｍｉｔ　Ｌｏｇ和

ＳＳＴａｂｌｅ 。

Ｍｅｍｔａｂｌｅ 记 录 最 近 的 修 改， 而ＳＳＴａｂｌｅ 记录着数据库 所承载的 绝大部分数据。通常 情 况 下， 一 个 Ｃａｓｓａｎｄｒａ 表 会 对 应 着 一 个

Ｍｅｍｔａｂｌｅ 和多 个ＳＳＴａｂｌｅ 。

Ｃａｓｓａｎｄｒａ 接收到 客户端发送来的数据， 首先将写操作记录到 位于磁

盘的 ＣｏｍｍｉｔＬｏｇ 中； 上述操作成功 后， 更新位于内存中 的 Ｍｅｍｔａｂｌｅ 数 据 结 构。 持 续 的 写 入 数据， 使得 Ｍｅｍｔａｂｌｅ 逐渐增长， 当 其数据量到 达某个阈 值时， Ｃａｓｓａｎｄｒａ 的数据迁移被触发， 一 方面将

Ｍｅｍｔａｂｌｅ 刷 写 到 本 地 磁 盘 上 成 为 永 久 的ＳＳＴａｂｌｅ ， 另一方面将 ＣｏｍｍｉｔＬｏｇ 中 的 写 入记录移除。 对于读操作， 客 户 端 先 查 询

Ｍｅｍｔａｂｌｅ 中的数据， 若无法获取所需信息， 则 检索本地磁盘。

Ｃａｓｓａｎｄｒａ 会定期执行压紧ｃｏｍｐａｃｔ 操作， 将同一条数据不同的版本进行合并， 过时数据也会在此过程中被删除； 分层数据压缩， 有效减少数据体积

及磁盘 Ｉ ／ Ｏ 。

系统设置（集群）

针对实时气象数据存储系统， 用户对该系统读取的性能需求远远高于写入数据。 通过对副本数进行合理设置， 可分散读取压力 。 对于５ 节点集群， 将副本数设置为 ３ ；

Ｒｏｗ 分区 模式：

采用自动分区方式， 使不同的 Ｒｏｗ　Ｋｅｙ 均匀分布在各节点上， 有利于数据读取压力的分散。

Ｃａｓｓａｎｄｒａ 表设计

作为典型的非结构化数据，气象数据可以由多维索引 来确定一个唯一的数据。

业务用户常见的操作包括“最新数据”“左右翻页”“上下翻页”等。

数据表

根据不同数据类型建立相应数据表， 用于存储数据内容， 包括：

ＥＣＭＷＦＨＲ（高分辨率数值预报产品 ）、

ＳＡＴＥＬＬＩＴＥ （ 卫 星 资料）、

ＵＰＰＥＲＡＩＲ （高空站点资料）、

ＳＩＮＧＬＥＲＡＤＡＲ （雷达资料） 等。

以“ Ｔ６３９ ”为 例 说明 数据表结构（表 １ ）。

建表 语 句： ＣＲＥＡＴＥ　ＴＡＢＬＥ "Ｔ６３９ "

（ "ｄａｔａＰａｔｈ " ｔｅｘｔ ， ｃｏｌｕｍｎ１  ｔｅｘｔ ，

ｖａｌｕｅ　ｂｌｏｂ ， ＰＲＩＭＡＲＹ　ＫＥＹ （" ｄａｔａＰａｔｈ " ，

ｃｏｌｕｍｎ１ ） ） ；

层次表

用于存储所有模式或实况的层次信息， 表名为ｌｅｖｅｌ ； 用 户 在 客户 端进行上下翻页操作， 从ｌｅｖｅｌ 表中获取当前层次的上一层或下一层信息； 利用层次表与数据表， 可检索到不同层次的数据（表２ ）。

建表语 句： ＣＲＥＡＴＥ　ＴＡＢＬＥ　ｌｅｖｅｌ （

"ｄａｔａＰａｔｈ " ｔｅｘｔ ， ｃｏｌｕｍｎ１ ｉｎｔ ， ｖａｌｕｅ　ｉｎｔ ， ＰＲＩＭＡＲＹ ＫＥＹ （" ｄａｔａＰａｔｈ " ， ｃｏｌｕｍｎ１ ）） ；

最新时刻表

用于存储各类数据的最新时刻信息， 表名 为ｌａｔｅｓｔｄａｔａｔｉｍｅ 。 利 用 最新时刻表， 用户能通过客户端快速查找到最新数据文件名。 用户根据完整索引 （文件路径与最新数据文件名）， 例： Ｔ６３９ ／ ＷＩＮＤ ／ ５００ ／ １７０３０１０８． ０００ ， 即可在“数据表”中获取到对应数据（表 ３ ）。

建表语句： ＣＲＥＡＴＥ　ＴＡＢＬＥ　ｌａｔｅｓｔｄａｔａｔｉｍｅ

（ " ｄａｔａＰａｔｈ " ｔｅｘｔ ， ｃｏｌｕｍｎ１  ｔｅｘｔ ， ｖａｌｕｅ　ｔｅｘｔ ，ＰＲＩＭＡＲＹ　ＫＥＹ （" ｄａｔａＰａｔｈ " ， ｃｏｌｕｍｎ１ ）） ；

存储系统性能测试

测试环境

选用５台相同配置的服务器用来搭建分布式存储系统。 服 务 器 操作 系 统 为 Ｒｅｄ　Ｈａｔ　Ｅｎｔｅｒ －ｐｒｉｓｅ　Ｌｉｎｕｘ　Ｓｅｒｖｅｒ　ｒｅｌｅａｓｅ　７． １ ， 处理器参数为Ｉｎｔｅｌ （ Ｒ ） Ｘｅｏｎ （ Ｒ ） ＣＰＵ　Ｅ５ － ２６２０ ｖ２ ＠ ２． １０ＧＨｚ ， 主频为２． １ ＧＨｚ ； 内 存大小为 ２５６ ＧＢ ；６ 块４ＴＢ　ＳＡＴＡ 硬盘； 服务器间通过万兆光纤连接。Ｃａｓｓａｎｄｒａ 数据库版本为２． ２． ５ 。

高可用性测试

由 ５ 个节点所组成分布式存储系统， 其结构上具有如下特点。

（ １ ）服务器双网卡绑定， 即将两个物理网卡虚拟成一个逻辑网卡； 提升服务器之间的传输带宽，实现网卡冗余。

（ ２ ）用于集群内部数据交换的两台万兆光纤交换机， 采取级联方式， 可互为备份。

（ ３ ） ６ 块ＳＡＴＡ 硬盘， 其中 ２ 块做 ＲＡＩＤ１， 安装操作 系 统 及 软 件； 另 外 ４ 块 ４ＴＢ 用 作 两 个ＲＡＩＤ０ ， 用于存储数据。

（ ４ ）服务器集群为环形结构， 没有 ｍａｓｔｅｒ 节点， 各节点功能完全一样。

按照表４中内容， 对系统的基础设施层（包括网络设备、存储设备等）、 软件层（数据库） 进行测试， 来验证系统的高可用 性； 从表中结论可知， 系统中用于内部数据交换的光纤或网卡、交换机及任一 Ｃａｓｓａｎｄｒａ 服务器故障， 均不影响 ＭＩＣＡＰＳ４客户端调取数据。

读取性能测试

通过读取数据的脚本文件（可获取数据字节数信息， 表５中 ＥＣＭＷＦ ＿ ＨＲ ／ ＴＭＰ ／ １００ 目 录下数 据 字 节 数 为 １３２６４２ 字 节， ＳＡＴＥＬＬＩＴＥ ／

ＦＹ２Ｅ ／ Ｌ１ ／ ＩＲ３ ／ ＥＱＵＡＬ 下数据字节数为５５４９４４字节，

Ｔ６３９ ／ ＷＩＮＤ ／ １００ 下数据字节数为１４４９０５２字节）， 模拟单用户及５０ 用 户 、 １００ 用 户 客户 端对同一类型数据进行读取， 共分 ３ 组， 即对三种不同类型的数据进行测试， 测试性能见表５ ， 注意测试结果包含网络传输时间。

从数据读取的测试结果可以看出 ：

（ １ ）５０ 用户并发和１００ 用 户 并发 客户 端 同 时 对 同 一 类 型数据进行 读 取 的 时 间 与 单 用 户 读 取 时 间 相 当 。以 Ｔ６３９ ／ ＷＩＮＤ／１００ 为 例， ５０ 用 户 并 发 和 １００用 户 并发与单用 户 读取相 关数据 所 花 费 的 平 均时间 均在２０ ｍｓ 左右。

（ ２ ） 在１００ 用 户 并发情况下， 从数据库 中 调 取数据 所消 耗 的 时 间 均 以 ｍｓ量级为 单 位 （ 包 含 网 络 传 输 时 间 ） ， 时 间 远 远 小于在ｓａｍｂａ 服 务 器 上 读 取 数 据 的 时 间 。

（ ３） 数据读取时 间 和 单 个 数 据 的 字 节 数 近 似 成 正 比，即单个数 据 文 件 字 节 数 越 大， 读 取 数 据 所 花 费的时间 则 越长。

结语

利用 Ｃａｓｓａｎｄｒａ 分布式数据库搭建的存储环境， 提高了实时气象数据存储效率与检索速度， 通过统一的数据平台， 实现了运维人员对该系统“零”维护。 通过在实际业务环境中进行测试， 验证了该分布式数据环境的高可用性； 以毫秒级为单位的数据读取时间， 能很好地满足业务对数据时效性的需求。