谈服务实例日志分布式存储(200513)

今天谈下ESB总线服务实例日志的存储问题。

对于当前，我们的服务实例日志是存在在结构化数据库中，其中包括了两个部分的内容。其一是服务运行实例头信息，主要记录了服务实例号，调用时间开始和结束，报文数据量，消费方IP和系统，服务英文名称等关键信息。其二是服务实例详细的输入和输出报文信息。

对于这两部分内容，我们当前仍然是采用分开两个表存储，一个是服务实例运行头表，一个是服务运行实例详细报文明细表，在报文明细表中采用Blob字段进行输入和输出报文的存储。

在服务运行次数很大的企业，已经对服务实例历史日志存储周期要求较长的企业，我们都可以看到这个数据量相当大，服务实例头表在1年不到往往就达到20亿条左右的规模。而在这个规模下报文明细的存储量往往更大，仅仅服务日志存储往往就需要上100T的存储空间，而且如果采用类似IP SAN等集中化存储方案的时候本身也是很大的成本和资源投入。

同时可以看到在这个报文日志数据量下，为了提供服务日志查询速度，以及方便后续的服务实例日志清理，我们会对服务实例表建立分区表。原来我们按月建立分区表，但是仍然发现可能一天的数据量就在上千万条，因此后面改为按天建立分区表。

在当前这种模式下，我们定时的对服务实例日志进行清理，加上服务分区表设置本身基本能够应对当前的需求，但是仍然带来了如下问题。

1. 服务实例查询慢，特别是多条件跨天的模糊查询，整体查询效率很低。

2. 需要定期清理日志，无法做到一个比较长周期的服务存储，同时存储扩展也不容易。

基于上面两个问题，我们才需要考虑如何将服务运行实例日志的存储从当前的结构化数据库迁移出来。这就涉及到分布式数据库的使用，而当前主流的分布式数据库，我们先看下我网上摘录的一些选择思路如下：

1. 如果你对数据的读写要求极高，并且你的数据规模不大，也不需要长期存储，选redis；

2. 如果你的数据规模较大，对数据的读性能要求很高，数据表的结构需要经常变，有时还需要做一些聚合查询，选MongoDB；

3. 如果你需要构造一个搜索引擎或者你想搞一个看着高大上的数据可视化平台，并且你的数据有一定的分析价值或者你的老板是土豪，选ElasticSearch；

4. 如果你需要存储海量数据，连你自己都不知道你的数据规模将来会增长多么大，那么选HBase。

而对于分布式数据库的选择，初步来看实际上可以分为三类

1. 偏基于Hadoop体系架构和分布式存储的，类似HDFS库和HBase数据库，也包括中间类型MongoDB

2. 偏内存和缓存类的，类似Redis库

3. 偏全文检索类和数据分析类的，类似ElasticSearch和Solr库

那么基于当前服务实例日志的存储和查询需求，我们可以看到如下几个点。

1. 对于服务实例头信息也可以转移到分布式数据库，选择MongoDB比HBase在模糊查询上支持更好

2. 对于大的报文输入和输出的存储，最好是选择HBase库或直接采用HDFS分布式存储

3. 如果需要对报文输入和输出做关键字的全文检索，那么需要采用ElasticSearch或Solr库

但是我们也看到，如果对所有的报文输入和输出都进行全文检索，那么ElasticSearch或Solr库建立的索引会消耗大量的存储空间。同时这种存储更多的是为查询分析服务，而不能做为一个标准的持久化存储解决方案。