Realtime: 用例：同步到Elasticsearch / Solr

嘿@kwakwaversal谢谢你的出色写作。

自述文件中此仓库的复选框表明您已经在Beta中

哎呀。 感谢您的注意！ 我们正在对整个组织的发布状态进行标准化。 我将其移回了alpha-我认为它可以更公平地表示服务器的状态，而且可以整体表示Supabase。 一旦有了一些基准，我们将进入Beta版，更重要的是，我们将聘请可以全职支持此仓库的人员（我们现在是一个非常小的团队）

将记录更新或插入到ES / Solr。 为此，保证交付显然是首选。

很酷。 这可以通过webhooks（https://github.com/supabase/realtime/issues/33）来实现。 一旦我解决了重复使用复制插槽的问题（https://github.com/supabase/realtime/issues/22），便可以保证从Postgres读取并发送。 我不愿意将其称为保证交付，因为一旦将其发送到ES，它就不会等待确认回执。 如果有效载荷未能到达ES（无论出于何种原因），则更改事件也将丢失。 这可能是我们将来要进行的工作，但这将是一个重大的发展（因为它需要持久性）。

有效负载大小（包括类型对象）虽然有用，但实际上会累加成千上万条记录（如果接收到OLD记录则更多）

有趣-这也是我从未想到的。 我将深入探讨JSON转换器的概念。 有效负载值都是字符串，因此添加PARSE_PAYLOAD这样的布尔标志可能更通用，如果为true，则此服务器可以将有效负载解析为正确的类型，并删除columns键共。 这将对性能产生影响，因此这是我们必须权衡的。 您还将丢失很多细节（是smallint还是bigint吗？），但是在很多情况下都没有关系。

我最初的想法是：

• 存储比计算便宜
• 性能很重要

因此，如果仅是为了节省数据库空间，则不是最好的主意。 有什么原因使您无法从有效负载中清除column进入ES后的结果？

我假设减少服务器负载和PostrgreSQL的流输出的首选方法是仅为表的子集创建发布

对，那是正确的。 如果存在您不关心流的表，则不要启用复制。 让我知道您的用例是否有问题！

订阅表而不是创建大量的NOTIFY触发器（就像我们目前在生产中所做的那样）。

如果您没有看到此消息，则NOTIFY有效负载的上限为8000个字节，因此请注意您的系统不会默默地删除事件。 Postgres实际上会引发一个错误，但是很难抓住。 这就是我们去年创建Realtime的确切原因-我使用的是Trigger / NOTIFY并很难发现这一点。

下一步

我将与我们的一个团队一起探索JSON转换器，并告诉您。 这可能会花费一些时间，但是我认为值得在https://github.com/supabase/realtime/issues/47上进行工作

我不愿意将其称为保证交付，因为一旦将其发送到ES，它就不会等待确认回执。

我认为处理Solr的写入而不是使用在服务器中创建Webhook对我来说是有意义的。 我将需要更新Solr FIFO，但我在https://github.com/supabase/realtime/issues/33#issuecomment -635010703中阅读了您建议的Webhooks，不返回2XX表示已写入日志某处。 这将破坏在Solr中更新相关文档的记录顺序，这是不理想的。

附带说明一下，如果不容易查询（并选择提取）未成功转发到Webhook的记录，我认为这可能是个问题。 日志显然很不错，但是如果某些网络挂钩由于任何原因而失败，我想查看一些统计信息。 以编程方式轮询服务器以查找失败的Webhook会有所帮助，但随后您正在更改服务器的简单性。 听起来越来越像是您最终将不得不为Webhooks编写一些琐碎的作业队列。 或者至少保证写入_somewhere_，以使事件不会丢失。

有效负载值都是字符串，因此添加布尔标志（如PARSE_PAYLOAD）可能更通用，并且如果为true，则此服务器可以将有效负载解析为正确的类型，并完全删除column键。

将有效负载解析为正确的类型可能很有用，但我不会说这是必要的。 JSON转换器将允许某人选择属性，以便在一个30列的表中，它仅返回3，并且能够在此过程中重命名这些列。

存储比计算便宜

因此，如果仅是为了节省数据库空间，则不是最好的主意。 您是否有任何理由在将有效载荷降落到ES中后无法从有效载荷中清除该列？

当我提到有效负载大小时，我并不是在谈论存储它，而是从字面上讲是通过接口发送的有效负载大小。 主机之间的网络流量。

如果我有一个数据库服务器，并在其中放置supabase/realtime ，然后在另一台主机上使用一台消耗性的websocket服务器，我将获得许多在主机之间发送的数据。 我很可能会丢弃大量数据，因此对我来说，恢复从触发器发送NOTIFY性能会更好。 但是后来我失去了supabase/realtime最初给我的一些灵活性，因为他们不必不断更改数据库迁移来从NOTIFY有效负载中添加/删除列。 正如讨论的那样，JSON转换器确实会在这里大放异彩。

如果您没有看到此消息，则NOTIFY有效负载的上限为8000字节

嗯是的当尝试通过通知发送存储在数据库中的电子邮件时，我遇到了这个问题。 我的意思是，保持性能很有意义，但当时这是一个头疼的问题。

我将与我们的一个团队一起探索JSON转换器，并告诉您。 这可能需要一些时间，但我认为值得一提的是我们在＃47上进行的工作

好东西。

附录

对于任何可能偶然发现此问题的人，寻找将PostgreSQL同步到ES / Solr的方法， https：//debezium.io/似乎是一个不错的选择。 我希望不要在堆栈中添加过多的东西，因为这会变成：ES / Solr，Debezium，Zookeeper，Kafka，但我想这是在这种情况下要保证交付的价格。

我实际上是在谈论通过接口发送的有效负载大小。 主机之间的网络流量。

知道了，这很有意义。

德比兹

是的，很棒的系统！ 如果您想要全部功能，那肯定很沉重，我认为这是目前市场上唯一的东西。

再次感谢您提供背景信息。 我将需要就此用例与Francesco聊天。 他目前不活跃，因此很遗憾，可能需要一段时间才能看到这方面的进展。 尽管如此，这是我要执行的操作：

• 研究使用排队系统或其他有保证的交付
• 探索JSON转换器

@kwakwaversal

附录

对于任何可能偶然发现此问题的人，寻找将PostgreSQL同步到ES / Solr的方法， https：//debezium.io/似乎是一个不错的选择。 我希望不要在堆栈中添加过多的东西，因为这会变成：ES / Solr，Debezium，Zookeeper，Kafka，但我想这是在这种情况下要保证交付的价格。

我一直在寻找一种debezium替代方案（以避免JVM堆栈），偶然发现了这个问题。 尝试使用supabase进行弹性搜索同步，您能否成功？ 就我而言，我找到了弹性搜索的替代品MeiliSearch（交叉链接https://github.com/meilisearch/integration-guides/issues/20）

另一方面，对于JSON转换，我认为这些库更好并且更受欢迎： https : //github.com/jsonata-js/jsonata或https：// github .com / wankdanker / node-object-mapper （FWIW，https:

感谢解析器@rrjanbiah-我们可能需要找到一些长生不老药，但是这些都是可以工作的良好现有技术。

我们当前的讨论是更新事件解析器，使其与AWS的简单工作流程更加内联。 例如： https： //states-language.net/#choice -state。 这是一个全状态机，应该使它成为一台非常通用的服务器。 虽然这是一项艰巨的任务，所以我们必须花时间弄清楚是否有可能以及是否可以分批发货

@kiwicopple

感谢解析器@rrjanbiah-我们可能需要找到一些长生不老药，但是这些都是可以工作的良好现有技术。

看起来没有维护，但我发现了这个https://github.com/stephan83/ex-jmes

我们当前的讨论是更新事件解析器，使其与AWS的简单工作流程更加内联。 例如： https： //states-language.net/#choice -state。 这是一个全状态机，应该使它成为一台非常通用的服务器。 虽然这是一项艰巨的任务，所以我们必须花时间弄清楚是否有可能以及是否可以分批发货

在这里不太了解...但是，由于您指的是状态机，因此您可能需要检查https://github.com/davidkpiano/xstate，因为它非常流行