Es hängt von Ihrem Anwendungsfall ab. Eine gängige Praxis besteht darin, dies auf der Anwendungsschicht zu handhaben. Im Grunde replizieren Sie die Aktionen einer DB auf die andere. Wenn Sie also beispielsweise einen Eintrag in Postgres speichern, tun Sie dasselbe in Elasticsearch.
Wenn Sie dies tun, müssen Sie jedoch ein Warteschlangensystem einrichten. Entweder ist die Warteschlange auf Ihrer Anwendungsschicht integriert, z. Wenn das Speichern in Elasticsearch fehlschlägt, können Sie die Operation wiederholen. Darüber hinaus implementieren Sie in Ihrem Warteschlangensystem einen Drosselungsmechanismus, um die elastische Suche nicht zu überfordern. Ein anderer Ansatz wäre, Ereignisse an eine andere App (z. B. Logstash usw.) zu senden, sodass die Drosselung und Persistenz von diesem System und nicht von Ihrer Anwendung übernommen wird.
Ein anderer Ansatz wäre dieser https://www.elastic.co/blog/ logstash-jdbc-input-plugin . Sie verwenden ein anderes System, das Ihre Datenbank „abfragt“ und die Änderungen an Elasticsearch sendet. In diesem Fall ist Logstash ideal, da es Teil des ELK-Stacks ist und sich hervorragend integrieren lässt. Überprüfen Sie dies auch https://www.elastic. co/guide/en/logstash/current/plugins-inputs-jdbc.html
Ein anderer Ansatz ist die Verwendung von NOTIFY Mechanismus von Postgres, um Ereignisse an eine Warteschlange zu senden, die das Speichern der Änderungen in Elasticsearch übernimmt.
