为什么在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倍的压缩率，但压缩优化的列存储可能更适合于更高的压缩率。

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