对选择数据库的开发者和使用者而言，针对时序数据库和关系型数据库之间选择，也主要考虑以下几个因素：
性能
研究过Oracle的存储结构和索引结构的都知道Oracle的ACID强一致性和B－Tree，保证强一致性导致数据持久化、可靠性、可用性实现的逻辑复杂，而加速数据访问，则需要Oracle 数据库使用 B－Tree 存储索引。
B－Tree 结构的有很多优势：在索引中从任何地方检索任何记录都大约花费相同的时间；B－Tree对大范围查询提供优秀的检索性能，包括精确匹配和访问查询；插入、更新和删除操作有效，维护键的顺序，以便快速检索；B－Tree性能对小表和大表都很好，不会随着表的增长而降低。从Tree这个名字就可以看出，这种B－Tree就是为了解决随机读写问题的。
而时序数据库，核心问题去解决批量读写，对于 95％ 以上场景都是写入的时序数据库，B－Tree 很明显是不合适的，业界主流都是采用 LSM Tree（Log Structured Merge Tree）或者LSM的“升级版”TSM（Time Sort Merge Tree） 替换 B－Tree，比如 Hbase、Cassandra、InfluxDB等。LSM Tree 核心思想就是通过内存写和后续磁盘的顺序写入获得更高的写入性能，避免了随机写入。
LSM Tree 简单操作流程如下：
数据写入和更新时首先写入位于内存里的数据结构。同时，为了避免数据丢失也会先写到磁盘文件中。
内存里的数据结构会定时或者达到固定大小会刷到磁盘。
随着磁盘上积累的文件越来越多，会定时的进行合并操作，减少文件数量。
在内存or文件中，对数据进行压缩、去重等操作。
还有一个提升性能的关键点，即：分布式处理。这里以InfluxDB为例来说明。（顺便吐槽一下：InfluxDB单机版开源，集群版收费……，扔个鱼饵，“吃相”难看呀。）
上图是InfluxDB的逻辑存储架构图，通过RP、ShardGroup、Shard的逐层分解，写入数据被尽可能的分布摊平。最后，每个Shard的TSM引擎负责对数据进行处理。Shard Group实现了数据分区，但是Shard才是InfluxDB中真正存储数据以及提供读写服务的服务。Shard是InfluxDB的TSM Engine，负责数据的编码存储、读写服务等。
通常分布式数据库一般有两种Sharding策略：Range Sharding和Hash Sharding，前者对于基于主键的范围扫描比较高效；后者对于离散大规模写入以及随即读取相对比较友好。
InfluxDB的Sharding策略是典型的两层Sharding，上层使用Range Sharding，下层使用Hash Sharding。对于时序数据库来说，基于时间的Range Sharding是最合理的考虑，但如果仅仅使用Time Range Sharding，会存在一个很严重的问题，即写入会存在热点，基于TimeRange Sharding的时序数据库写入必然会落到最新的Shard上，其他老Shard不会接收写入请求。对写入性能要求很高的时序数据库来说，热点写入肯定不是最优的方案。解决这个问题最自然的思路就是再使用Hash进行一次分区，基于Key的Hash分区方案可以通过散列很好地解决热点写入的问题。
Shard分区好了，就可以采用分布式集群架构予以支撑，分摊压力，提高并行度。
成本和功能
很多时间序列数据都没有多大用处，特别是当系统长时间正常运行时，完整的历史数据意义并不大。而这些低价值数据，占据大量高价值存储空间，会让企业“抓狂”。因此，一些共通的对时间序列数据分析的功能和操作：数据压缩、数据保留策略、连续查询、灵活的时间聚合等，都是为了解决时序数据库的性价比问题的。同时，有些数据库比如 RDDTool 和 Graphite 会自动删除高精度的数据，只保留低精度的。而这些“功能”对关系型数据库而言，简直是不可想象的。
还有一些成本很多人会忘记考虑，比如：License，用需要License的关系型数据库来存储时序数据，成本根本没法承受。
至此，我们得出的结论就一个：选择到底用什么数据库来支持时序数据，还是需要对时序数据的需求进行透彻的分析，然后根据时序数据的特点，来选择适合的数据库。
启用名言作为本文结尾：适合的，就是最好的。
本文作者：格创东智首席架构师王锦博士。格创东智是由智能产品制造及互联网应用服务领军企业TCL孵化的创新型科技公司，致力于深度融合人工智能（AI）、大数据、云计算等前沿技术与制造行业经验，打造行业领先的“制造x”工业互联网平台，同时为各类制造业企业提供优质、安全、高效的管理IT服务，助力传统制造业智能化转型升级。（转载请注明作者及来源）
