我正在考虑使用postgres ORM中的钩子来同步postgres和elasticsearch之间的数据。这是一种实用的方法吗？或者这太贵了？
答案 0 :(得分：2)
你必须谈论触发器。诚实的答案是，这在很大程度上取决于你的写作量。
如果你处于一个恒定的写入负载下，这可能是一个坏主意。 ES希望在一个大区域内输入大量数据。通常，您使用ES作为其他数据库（例如Postgres）之上的索引，并且您可以使用ES稍微陈旧。曾经有一种称为河流的ES技术来帮助解决这个问题。我现在看到it has been deprecated。
我想说你有几个选择：
事件采购方法基本上是让您的应用程序以某种方式广播事件流，然后有两个进程监听该流：一个写入Postgres，另一个写入ES。这种方法也在 I Heart Logs 中提倡，但Kafka是事件流。我认为你可以使用许多其他选项而不是Kafka，例如AMQP。
批处理方法是老派;基本上，有一个定期运行的cron作业将数据从数据库复制到ES。如果您进行了大量小的更改，但整体数据库大小不是很大，这可能会显着提高性能。这是一个稳定的架构，很容易正确（特别是因为ES作为长期数据存储机制并不是特别受信任;有关详细信息，请参阅Aphyr's posts about it。）
所以，触发器。它看起来像someone else has tried your approach;可能值得与他们联系，看看它是否曾成为生产价值。我发现搜索的另一个选项是Zombodb，这似乎使得Postgres使用ES作为索引服务而没有透露它。
就个人而言，我不会向Postgres添加代码来写入ES，因为我会担心线程问题和连接失败。您的应用程序可能更适合在与ES交谈时处理网络故障（将发生），而不是深入数据库本身。另外，我不想做任何可能破坏主数据存储稳定性的事情。这并不意味着这是最糟糕的想法，只是我会毫不犹豫地投入生产。这里超级引人注目的优势是获得了相当强烈的感觉，如果我写了一些东西给Postgres，它是在ES中，而不是真的不在乎我是从这个应用程序或那个应用程序写的。这些都是很好的优点，但你可以很容易地说服自己，当你真的没有时，你正在绕过CAP定理，你只是接受更强大的一致性模型更新，更广泛的失败模式而不是你真正需要的。
事件采购模型具有类似的优势，只是提升了一个级别：如果我写入广播频道，那么我可以假设它将最终由两个数据库加载 - 如果频道如果消息到达那里是持久的，等等。但它更容易让人相信这两个系统最终是一致的，这对于分布式系统来说通常比“完美”一致性更有用（如果你有两个服务，你可能有一个分布式系统。）