存储和管理外汇交易报价数据答案

【问题标题】：Storing and managing Forex trading tick data存储和管理外汇交易报价数据
【发布时间】：2016-03-06 16:47:26
【问题描述】：

我正在为外汇交易构建一个数据可视化系统，并且我正在探索存储我拥有的历史外汇交易报价数据的方法。

数据采用货币对（例如美元/加元）按时间顺序排列的卖价和买价报价。归根结底，我需要在 Elasticsearch 中对我的数据进行索引，而我要寻找的是让它们到达那里的最佳方式。

我在网上找到了几种方法；他们开始很简单，但后来变得复杂。我想知道增加额外的复杂性是否值得。我的一些选择是：

在 PostgreSQL 上存储刻度数据，然后通过插件将它们同步到 Elasticsearch (here)
在 PostgreSQL 上存储刻度数据，将它们推送到 Logstash，然后推送到 Elasticsearch
最后，在 PostgreSQL 上存储分时数据，将它们推送到 Redis，然后到 Logstash，然后到 Elasticsearch

我的直觉说，第 2 种解决方案是理想的解决方案，但什么被认为是最佳实践？

【问题讨论】：

取决于您如何接收报价数据。通过流进行近乎实时的分析，或一天结束的数据转储。如果您正在流式传输，则可能值得使用诸如 InfluxDB 之类的刻度数据库。如果您所做的只是索引一天结束的数据转储，我不确定在源和 ElasticSearch 之间有任何层有什么意义。同样对于流，请查看 Kafka 或 RabbitMQ 的开源选项。
谢谢！目前我正在处理一天结束的数据转储。不过有一个想法是在未来支持实时数据。

标签： postgresql elasticsearch trading

【解决方案1】：

最好将数据存储在长期存储数据库中，例如 PostgreSQL 或类似数据库。这样，您可以随时决定是否需要更改映射、添加字段、删除字段、更改它们的类型或您拥有什么，然后您可以轻松地重建 ES 索引/索引，而不会从主要来源中遇到太多麻烦真实性（即 PostgreSQL），并且您在 ES 中始终拥有干净的数据。

我不知道 ZomboDB（解决方案 1），所以我不能真正代表它，我只知道我通常不太喜欢将两种不同的技术捆绑在一起，这使得升级任何一个都变得困难它们以防您需要/必须/想要应用补丁或从其中任何一个中的新功能中受益。

除非您对源数据进行大而昂贵的转换，否则我认为解决方案 3 不会带来太多，即在中间 Redis 中存储数据的额外步骤，在我看来并没有带来太多（您的里程可能会有所不同）。 good idea 使用临时存储，例如 Redis 或 Kafka，当您可能在管道中丢失数据时，但在这种情况下，由于您的数据在 PostgreSQL 中，所以您不需要真的冒着失去任何东西的风险。如果有的话，您可以重新启动管道并重建几天的数据。

剩下的解决方案 2，考虑到手头的信息，这会很好。使用 Logstash JDBC input，您可以轻松检索最新更改并每 x 分钟将其转发给 ES。

【讨论】：

【解决方案2】：

来自 ZomboDB 的 Eric 在这里。我想尝试回答您关于 ZDB 的问题。

ZomboDB 是专为 Postgres 中的全文搜索而设计的。需要注意的是，它不是将您的 PG 数据同步到 Elasticsearch 的工具。它是一种功能齐全的 Postgres 索引类型（类似于 btree、gin 和 gist 等内置类型），恰好由 Elasticsearch 提供支持。 ZomboDB 使用 Elasticsearch 这一事实确实是一个实现细节。

虽然 ZDB 确实提供了许多 UDF，这些 UDF 公开了对 ES 聚合工具的访问权限，但同样，它确实是为文本搜索而设计的。

因此，如果您的数据真的只是成对的数字，那么您最好直接使用 ES——尤其是当您每天加载一批时。毫无疑问，与标准 Postgres“GROUP BY”查询相比，ZDB 可以提供更出色的聚合性能（因为它会将其传递给 Elasticsearch），但您要为有限的用例付出沉重的操作代价。

另一方面，如果您的询价/出价数据带有大量相关元数据，并且：

你需要 PG 作为你的真实来源，
您需要对该元数据进行文本搜索（无论是否支持聚合），并且
您不想学习 ES 并在您的应用程序中引入另一个数据库系统，那么...

... ZomboDB 可能适合您。

我怀疑 Stack Overflow 不适合讨论这个问题，因此请随时通过 ZDB 的 github 页面推荐的方式与我联系。

【讨论】：