最近，我以研究工程师的身份加入了一个项目，该项目主要致力于科伦坡市区（即斯里兰卡城市水域中心，简称CUrW-SL）的天气预报，建模和风险评估。 我的首要职责是实现适合中心的数据存储层。 几乎所有的预测，建模，风险评估和实时观测输出都是带有地理标签（即纬度和经度）的时间序列数据，并且在每日天气预报和天气模型的每日运行中会生成大量数据， 风险评估模型。
显然，中心需要的是一个数据库管理系统（DBMS），该系统可以有效地存储和处理来自各种来源的大量时间序列数据。 随着对合适的时序数据平台或DBMS的研究的进行，我们迷失了对时序数据平台和DBMS的茫茫大海。 人们可以找到大量专门用于时间序列数据的数据平台，而且其中大多数都是开源的。 真正的问题是我们应该选择什么。 显然尝试所有这些都不是一个可行的选择，因此我们下班了，不得不推迟工作，并且必须在下一个季风袭击斯里兰卡时（即到2018年4月底）建立一个工作系统。
关于时序数据库，InfluxDB最有可能是您在互联网搜索中遇到的之一件事。 它看起来很吸引人，而且尝试性的，并且可能感觉像InfluxDB就是这样。 但是要获得可伸缩版本，您要购买企业版。 然后很明显，如果这是一个大数据问题，您可能想研究基于Hadoop的解决方案。 当然，这里有很多东西（即Warp10）是我们遇到的，但是对我们来说，认为我们手头的问题是大数据问题似乎太过分了。 但是，在此链接中，您可以找到InfluxDB和Warp10平台的不错比较。
为什么以及如何使用RDBMS代替NoSQL
在大多数社区都同意使用时间序列数据应用程序的环境中，更好使用No-SQL解决方案，一个名为" Timescale"并引入" TimescaleDB"的组织拥有坚强的理由说应该不这样做。 CEO在这篇博客文章中解释了为什么以及如何在处理时间序列数据的应用程序中使用RDBMS而不是NoSQL。 以我的观点，我知道他们的博客文章令人难以置信，也许您会喜欢他们。 可能是谁知道您可能最终将" TimescaleDB"用于您的应用程序。
为什么Uber Engineering从Postgres切换到MySQL？
TimescaleDB被编写为PostgreSQL的扩展。 在社区中，关于更好的是PostgreSQL还是MySQL争论不休。 我仍在寻找该问题的独特答案。 但是，Uber已从PostgresSQL迁移到MySQL，他们写了一篇博客文章介绍这样做的原因。 在那篇博客文章中，他们解释了PostgreSQL的技术性问题，以及MySQL如何解决这些问题或没有此类问题。 另一方面，我想说的是，该博客文章是了解DBMS如何实际工作的好地方。
'起初，我们需要采取一些措施，如果我们能够遵循更佳实践和软件开发原则，那是很好的选择，但是这是可选的，因为如果我们不能按时将产品推向市场，那将根本没有产品。 当然，稍后我们应该重构或可能重写以使其成为可管理的产品，从而使其在其他产品中脱颖而出。"
回到我们的用例，除了技术上的关注之外，还有一些观点上的关注。 我们的团队负责人，顾问，主管和CUrW-SL负责人（东京大学土木工程教授）要求根据需要分析和处理数据。 他使用的工具之一是Wolfram Mathematica。 由于NoSQL和BigData平台比RDBMS相对新，因此没有与Mathematica之类的分析工具一起使用的连接器。 教授和土木工程人员也都熟悉SQL，因此不愿转向NoSQL。 此外，时间和工作量甚至足以为分析工具编写我们自己的连接器，以便与我们认为最适合我们要求的NoSQL解决方案一起使用。
另一方面，即使是免费版本，直到撰写本文时，数据流入对于MySQL来说也不成问题。 哦..我没有提到最后我们决定使用MySQL吗？ 我记得曾经有一次Sanjiva Weerawarna博士说过："起初我们需要做一些工作，如果我们能够坚持更佳实践和软件开发原则是件好事，但它是可选的，因为如果我们未能按时将产品推向市场， ，将完全没有产品。 当然，稍后我们应该重构或重新编写以使其成为可管理的产品，以使其在其他产品中脱颖而出。'说实话，这正是我们团队领导在他坚持的基础上所想到的 我们应该使用MySQL。
(本文翻译自Thilina Madumal的文章《Timeseries DBMSs, Where You Would Get Lost》，参考：https://medium.com/@madumalt/timeseries-dbmss-where-you-would-get-lost-2e3f2a8d2471)
