1.6.3 自我突破的OLAPServer时期

如果说Metrage系统是弥补Yandex.Metrica性能瓶颈的产物，那么OLAPServer系统的诞生，则是产品形态升级倒逼的结果。在Yandex.Metrica的产品初期，它只支持固定报表的分析功能。随着时间的推移，这种固定化的分析形式早已不能满足用户的诉求，于是Yandex.Metrica计划推出自定义分析报告的功能。然而Metrage系统却无法满足这类自定义的分析场景，因为它需要预先聚合，并且只提供了内置的40多种固定分析场景。单独为每一个用户提供面向个人的预聚合功能显然是不切实际的。在这种背景下，Yandex.Metrica的研发团队只有寻求自我突破，于是自主研发了OLAPServer系统。

OLAPServer系统被设计成专门处理自定义报告这类临时性分析需求的系统，与Metrage系统形成互补的关系。结合之前两个阶段的建设经验，OLAPServer在设计思路上可以说是取众家之长。在数据模型方面，它又换回了关系模型，因为相比Key-Value模型，关系模型拥有更好的描述能力。使用SQL作为查询语言，也将会拥有更好的“群众基础”。而在存储结构和索引方面，它结合了MyISAM和LSM树最精华的部分。在存储结构上，它与MyISAM表引擎类似，分为了索引文件和数据文件两个部分。在索引方面，它并没有完全沿用LSM树，而是使用了LSM树所使用到的稀疏索引。在数据文件的设计上，则沿用了LSM树中数据段的思想，即数据段内数据有序，借助稀疏索引定位数据段。在有了上述基础之后，OLAPServer又进一步引入了列式存储的思想，将索引文件和数据文件按照列字段的粒度进行了拆分，每个列字段各自独立存储，以此进一步减少数据读取的范围。

虽然OLAPServer在实时聚合方面的性能相比MySQL有了质的飞跃，但从功能的完备性角度来看，OLAPServer还是差了一个量级。如果说MySQL可以称为数据库管理系统（DBMS），那么OLAPServer只能称为数据库。因为OLAPServer的定位只是和Metrage形成互补，所以它缺失了一些基本的功能。例如，它只有一种数据类型，即固定长度的数值类型，且没有DBMS应有的基本管理功能（DDL查询等）。