为何在NoSQL上使用TimescaleDB？

为何在NoSQL上使用TimescaleDB？

与通常NoSQL数据库（例如MongoDB，Cassandra）或更专门的时间导向数据库（例如InfluxDB，KairosDB）相比，TimescaleDB提供了定性和定量差别：数据库

普通SQL：即便在规模上，TimescaleDB也能够为时间序列数据提供标准SQL查询的功能。大多数（全部？）NoSQL数据库都须要学习新的查询语言或使用最好的“SQL-ish”（它仍然与现有工具兼容）。

操做简单：使用TimescaleDB，您只须要为关系数据和时间序列数据管理一个数据库。不然，用户一般须要将数据存储到两个数据库中：“正常”关系数据库和第二个时间序列数据库。

JOIN能够经过关系数据和时间序列数据执行。

对于不一样的查询集，查询性能更快。在NoSQL数据库中，更复杂的查询一般是缓慢或全表扫描，而有些数据库甚至没法支持许多天然查询。

像PostgreSQL同样管理，并继承对不一样数据类型和索引（B树，哈希，范围，BRIN，GiST，GIN）的支持。

对地理空间数据的本地支持：存储在TimescaleDB中的数据能够利用

PostGIS的几何数据类型，索引和查询。

第三方工具：TimescaleDB支持任何能够说SQL的东西，包括像Tableau这样的BI工具。分布式

何时不用TimescaleDB数据库？

而后，若是如下任一状况属实，则可能不想使用TimescaleDB：
工具

简单的读取要求：若是您只须要快速键值查找或单列累积，则内存或列导向数据库可能更合适。前者显然不能扩展到相同的数据量，可是，后者的性能明显低于更复杂的查询。

很是稀疏或非结构化的数据：尽管TimescaleDB利用PostgreSQL对JSON / JSONB格式的支持，而且至关有效地处理稀疏性（空值的位图），但在某些状况下，无模式体系结构可能更合适。

重要的压缩是一个优先事项：基准测试显示在ZFS上运行的TimescaleDB得到约4倍的压缩率，但压缩优化的列存储可能更适合于更高的压缩率。

不频繁或离线分析：若是响应时间较慢（或响应时间限于少许预先计算的度量标准），而且您不但愿许多应用程序/用户同时访问该数据，则能够避免使用数据库，而只是将数据存储在分布式文件系统中性能