问外汇交易滴答数据的存储和管理

EN

最好将数据存储在长期存储DB中，比如PostgreSQL或类似的数据库。这样，您可以在任何时候决定是否需要更改映射、添加字段、删除字段、更改字段类型或其他类型，然后可以轻松地重新构建ES索引/索引，而不需要从主要的真实来源(即PostgreSQL)中获取太多的麻烦，而且ES中总是有干净的数据。

我不知道ZomboDB (解决方案1)，所以我不能真正支持它，我所知道的是我通常不太喜欢将两种不同的技术结合在一起，因此很难升级它们中的任何一种，以防您需要/必须/想要应用修补程序或从它们中的新特性中受益。

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

这就留下了解决方案2，考虑到手头的信息，这将是很好的。使用Logstash JDBC输入，您可以轻松地检索最新的更改并每隔x分钟将它们转发给ES。

这里是ZomboDB公司的埃里克。我想试着回答你的问题，因为它涉及到ZDB。

ZomboDB实际上是为在Postgres中进行全文搜索而设计的。需要注意的是，它不是将PG数据与Elasticsearch同步的工具。它是一种功能齐全的Postgres索引类型(类似于btree、gin和gist等内置类型)，恰好得到了Elasticsearch的支持。ZomboDB使用Elasticsearch这一事实实际上是一个实现细节。

虽然ZDB确实提供了一些UDF来公开对ES聚合设施的访问，但它实际上是为文本搜索而设计的。

因此，如果您的数据实际上只是一对数字，您可能最好直接使用ES --特别是如果您每天加载一批数据。毫无疑问，与标准Postgres "GROUP“查询相比，ZDB可以提供更好的聚合性能(因为它将其传递给Elasticsearch)，但是对于有限的用例，您将付出沉重的操作代价。

另一方面，如果您的询问/出价数据附带了大量相关元数据，那么：

1. 你需要PG做你的真相来源，
2. 您需要通过文本搜索元数据(无论是否支持聚合)，以及
3. 你不想学习ES并将另一个数据库系统引入到应用程序中，那么.

..。ZomboDB可能适合你。

我怀疑Stack溢出不是进入这个位置的地方，所以可以通过ZDB的github页面推荐的方式与我联系。