|
Синхронизация данных основного хранилища (PG) и ElasticSearch
|
|||
---|---|---|---|
#18+
Доброго вечера! Имеется некотрое приложение приложение: - SpringBoot2 - Hiberante (ORM) - PostgreSQL Требуется реализовать механизм поиска данных (по достаточно большому) объему данных. С учетом того что PG горизонтально плохо масштабируется было принято решение использовать для этого ElasticSearch (Rest client). Вопросы: 1. Как гарантировать консистентность данных в разных хранилищах? 2. Как элегантно в связке Hibernate/Spring передавать изменения в ElasticSearch? P.S. Я понимаю что в конце методов CustomerServiceImpl.customerCreate() или CustomerServiceImpl.customerUpdate() можно передавать данные в ES. Но подозреваю что это плохое решение. Поделитесь пожалуйста опытом. Как подобную задачу решали вы? Заранее благодарю! P.P.S Надеюсь Ваш ответ пригодится не только мне. ... |
|||
:
Нравится:
Не нравится:
|
|||
28.09.2020, 00:24 |
|
Синхронизация данных основного хранилища (PG) и ElasticSearch
|
|||
---|---|---|---|
#18+
student42 Вопросы: 1. Как гарантировать консистентность данных в разных хранилищах? 2. Как элегантно в связке Hibernate/Spring передавать изменения в ElasticSearch? Сага и Event Sourcing ?! <:o) ... |
|||
:
Нравится:
Не нравится:
|
|||
28.09.2020, 06:49 |
|
Синхронизация данных основного хранилища (PG) и ElasticSearch
|
|||
---|---|---|---|
#18+
student42, Что значит плохое? В java нет одного золотого решения. Вот решение выше с микросервисами)) Вы бы хотя бы 5 минут почитали про инструмент поиска. Или гугл на слово "синхронизация". Без микросервисов есть паттерн OLAP/OLTP Когда есть бд только для чтения. И она догоняет всегда бд текущую оперативной работы. Для этого ничего не надо ставить дополнительно. Ни контейнеров, ни микросервисов, ни server messenger ... |
|||
:
Нравится:
Не нравится:
|
|||
28.09.2020, 08:16 |
|
Синхронизация данных основного хранилища (PG) и ElasticSearch
|
|||
---|---|---|---|
#18+
student42, авторТребуется реализовать механизм поиска данных (по достаточно большому) объему данных. С учетом того что PG горизонтально плохо масштабируется было принято решение использовать для этого ElasticSearch (Rest client). Не логично и анекдотично пишите. Что такое горизонтальное масштабирование навернов PHP лучше знают. https://habr.com/ru/company/oleg-bunin/blog/319526/ Лучше бы написали - бд плохо ищет. Было бы логичнее. ... |
|||
:
Нравится:
Не нравится:
|
|||
28.09.2020, 08:31 |
|
Синхронизация данных основного хранилища (PG) и ElasticSearch
|
|||
---|---|---|---|
#18+
student42 1. Как гарантировать консистентность данных в разных хранилищах? Что бы гарантировать, надо что бы был драйвер PostgreSQL и Elastic поддерживали XA. Бегло поискав в гугле, рядом стоящими слов Elastic + XA лично я не увидел. Ну и в любом случае, это будет крайне дорого с точки зрения накладных расходов / производительности. Лучше бы написали - бд плохо ищет. Было бы логичнее. +100500 ... |
|||
:
Нравится:
Не нравится:
|
|||
28.09.2020, 09:29 |
|
Синхронизация данных основного хранилища (PG) и ElasticSearch
|
|||
---|---|---|---|
#18+
student42 Доброго вечера! Имеется некотрое приложение приложение: - SpringBoot2 - Hiberante (ORM) - PostgreSQL Требуется реализовать механизм поиска данных (по достаточно большому) объему данных. С учетом того что PG горизонтально плохо масштабируется было принято решение использовать для этого ElasticSearch (Rest client). Вопросы: 1. Как гарантировать консистентность данных в разных хранилищах? 2. Как элегантно в связке Hibernate/Spring передавать изменения в ElasticSearch? P.S. Я понимаю что в конце методов CustomerServiceImpl.customerCreate() или CustomerServiceImpl.customerUpdate() можно передавать данные в ES. Но подозреваю что это плохое решение. Поделитесь пожалуйста опытом. Как подобную задачу решали вы? Заранее благодарю! P.P.S Надеюсь Ваш ответ пригодится не только мне. Такс. а теперь попридержи коней. Попробуй разобраться что тебе конкретно нужно, по большей части с точки зрения бизнес-логики. У тебя есть два варианта. 1) Чтобы система работала абсолютно консистентно. То есть если данные появились в одной системе(PG) то сразу же должны быть отражены в другой. Не спеши с ответом, может тебя устроит что данные появятся в ES через 2 секунды после инсерта в PG? Ну или 10. Если тебятакой вариант не устраивает - значит скорее всего тебе ES и не нужен, все что ты можешь выиграть на так называемой масштабируемости, ты проиграешь в производительности. Ибо кроме как распределенными транзакциями ты это не сделаешь, и это будет долго, больно и дорого. Но выполнимо. 2) Ты можешь жить с eventual consistency. И хоть это и размытый термин, но смысл в том, что читающий ES будет видеть согласованную картину(если в системе нету записи, то нет и той что произошла после нее), хотя она возможно будет немного "запоздалой". В этом случае есть множество вариантов, начиная от вызова триггера в PG который вызывает ES, до евент сорсинга и батчинга. Вот тут можешь почитать варианты - https://stackoverflow.com/questions/41456752/would-using-transactions-to-make-sure-elasticsearch-and-postgres-data-are-sync-a Но в целом, тебе надо понять что это ограничение фундаментально. Невозможно сделать быстрый и консистентный вторичный индекс в распределенной системе. Либо ты теряешь в скорости либо в консистентности. Так что начни с того что определись что тебе реально надо ... |
|||
:
Нравится:
Не нравится:
|
|||
28.09.2020, 11:08 |
|
Синхронизация данных основного хранилища (PG) и ElasticSearch
|
|||
---|---|---|---|
#18+
student42 Как элегантно в связке Hibernate/Spring передавать изменения в ElasticSearch? - насчет "элегантно" не уверен, но есть готовое решение Hibernate Search ... |
|||
:
Нравится:
Не нравится:
|
|||
28.09.2020, 12:25 |
|
|
start [/forum/topic.php?desktop=1&fid=59&tid=2120673]: |
0ms |
get settings: |
28ms |
get forum list: |
15ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
121ms |
get topic data: |
12ms |
get forum data: |
3ms |
get page messages: |
272ms |
get tp. blocked users: |
2ms |
others: | 308ms |
total: | 767ms |
0 / 0 |