支持在线扩容、缩容：蜂鸟支持在不中断在线服务的情况下，进行系统扩容、缩容等运维操作；而且扩容、缩容操作支持以表粒度进行。

支持在线Bug Fix：蜂鸟支持在不中断在线服务的情况下，修复软件Bug。

高速数据恢复：即磁盘或机器永久故障后，系统可将数据损失的副本数据高速（集群环境下 20 - 60分钟）恢复，尽快让副本数重新达到期望值。

8. 编程和使用接口

具备方便、易用的用户接口是时序数据库系统能被接受的首要条件，那什么样的接口是最方便、易用呢？从我们多年工程实践经验来看，时序数据库目前最成熟、最受欢迎的用户接口还是SQL（JDBC/ODBC） —— 蜂鸟实现了SQL92标准！

一是因为SQL接口表现力很强，常见的时序查询和统计需求几乎都可用SQL表达。

二是因为SQL接口容易和第三方或遗留系统对接。JDBC,ODBC是第三方系统访问数据库的业界标准接口，遵循其标准才能与第三方软件实现互联互通。

鉴于此，我们首推SQL接口；其次我们还提供了其它访问方式：

NativeJava Api (直接操作NOSQL层)

ThriftApi（直接操作NOSQL层） —— 可适配各种编程语言（python、c++、ruby、java、erlang等）

除了上述访问接口外，蜂鸟系统同时也兼容Hadoop体系，因此可以直接使用Hive,Pig和M/R程序访问蜂鸟中存放的时序数据。

9. 竞品分析

时序数据处理的产品大致分为两类：一类是NOSQL架构的时序数据存储产品（还不能说是数据库）；一类是在传统关系数据库内实现时序功能的商业数据库产品。

前者具有良好的扩展性、可用性和并发性能，但接口一般不支持标准SQL（即便有些产品能模仿SQL接口，但也不能支持聚合运算、嵌套查询、或多表关联等操作）；后者能支持标准SQL（甚至支持事务操作），但扩展性和并发性能相比前者要逊色许多。

蜂鸟系统架构融合了NOSQL和SQL架构的精髓（见体系架构一章）。既具备了NOSQL系统的高扩展性、可用性和高并发特征，同时也具备了SQL系统方便的查询接口和强大的分析功能。

9.1主要竞品分析

Oralce/Mysql/MS-SQL

Oracle/Mysql/MS-SQL等传统关系数据库的设计目标是针对“随机访问、随时更新”类档数据，而对于“流式追加、区间检索”类时序数据并未做任何优化处理。事实上传统关系数据库无法应对大规模时序数据处理需求（具体原因见章节2）。

Hbase

Hbase具备良好的可扩展性，而且也经常被用于存储时序数据。对于时序数据存储又可分为横表存储和纵表存储。横表是指用RowKey存储ID（KEY），而用动态列存储时序事件；纵表则是用RowKey存储ID和事件时间戳的组合键（组合方式多种，如蜂鸟格式中的 PKT，KT，TK等）。但Hbase/Cassandra存在如下问题是:

1. 未能支持SQL92标准，因此对于聚合运算、嵌套查询、多表join等常用操作都无法简单实现。

2. 由于存储引擎使用java语言实现，相比C/C++实现的存储引擎，检索性能相对较慢。

3. Hbase存储按rowKey有序，因此若采用横表方式存储时序数据，则会遇到“热点”问题（具体见7.1章节）。

Cassandra

Cassandra 相比Hbase而言，对时序数据更友好—— 其避免了hbase的热点问题。但其最终一致性模型对于下推扫描和计算并非最佳选择。

Druid、Geras、InfluxDB、KairosDB、KDB+、OpenTSDB、SiteWhere、TempoDB、TreasureData

维基百科给出了上述当前比较流行的NOSQL类时序数据库。这些NOSQL架构的时序数据库，其主要服务形态是提供云服务，对外一般提供rest风格的web 接口。它们和Hbase、Cassandra的主要缺陷一样（实际上不少后台的存储就是Hbase或Mysql）—— 不支持SQL92，不支持聚合运算、嵌套查询、多表join等常用查询。

Hive/Impala

Hive/Impala 实现了SQL92的相关标准，适合数据离线分析（一般使用时间分区的方式将数据存储于HDFS之上）。但对于时序数据处理要求的“实时数据获取”需求无法满足（见7.3），因此不便运用于实时在线系统。

Informix Timeseries

InformixTimeseries 是当前时序数据库领域里的商业数据库的代表。其有专门“时序数据”类型、也支持SQL92、甚至还支持事务操作。但它扩展性上和并发性比不上NOSQL架构的时序存储系统，也是因为这个原因使得其计算能力受到限制，因此面对计算密集性业务，Informix TimeSeries 比不上蜂鸟。除此以外，InformixTimeSeries 还有两个重要“缺点” —— 成本高、非国产。

Oracle xadata

Oracle Exadata 数据库是ORACLE应对大规模数据分析的旗舰产品，其已以高性能著称。但Exadata必须使用专有硬件，而且也并非为时序数据优化。另外，和Informix 一样，Exadata扩展性和并发性的局限也使得其计算能力受限（简单计算即可得知：装备20台PC服务器的蜂鸟集群可有大约12*20个CPU CORE 投入计算任务，而Exdata全机架配置也不过128个CPU），而且相比informix其成本更高。

10. 基准测试

10.1对比Mysql

我们使用一组来自NCDC（National Climatic Data Center）的全球气象监控（来自全球分布的气象站）数据作为测试数据，比较蜂鸟和MYSQL对海量气象时序数据处理能力差异。

测试环境说明：

物理机器一台： 16G内存、1个容量1T的STATA硬盘、E5-2640(8 core)CPU

时序数据： 1992-2014年，共约1200个气象监测站，数据记录50字节左右，每分钟产生1条记录。因此原始数据大约120亿条，大小600G左右。

数据原始格式：93721KBWI（气象站ID） BWI2003090100080508（时间戳） 0.148 N 0.138 N 153（2min均向） 5(2min均速) 151（最高5sec均向） 6（最高5sec均速） 10 60（能见度）

查询语句： 查询某天平均“能见度” —— SELECT avg 能见度列 FROM data WHERE id（气象站ID） = ‘93721KBWI’AND timestamp BETWEEN ‘2013-01-01’ AND ‘2014-01-02’—— 大约需要扫描170万(1200*24*60)条记录

?

图4

如图（4）可见蜂鸟和MYSQL除了统计速度上存在明显差距外，Mysql 在大约写入4亿条数据之后（这时系统内存不够存放索引），读取性能显著下降，而蜂鸟系统则表现出“恒时查询”特性。

注：为了便于比较，我们仅是单机单盘条件下对比蜂鸟和Mysql系统。

?

10.2.性能预测

由于蜂鸟系统按KEY和时间有序存储数据（类似传统数据库的聚集索引），而且具备线性扩展能力，因此完全可以在给定的硬件环境下，较为准确的预测出检索速度。

具体的推测方式可按下面的公式简单计算：

机器数量 = M