собссно тема. пытаюсь залезть в требуху ХС и понять что там происходит и что делать.
простейшая связка. книга автор. есть индекс книги. есть автор. автор -- эмбеддед ентити внутри книги. можно сделать индекс автора но смысла не много.

теперь ситуация. чтоб это работало я делаю книгу делаю автоера делаю ван-ту-мени. ну все как обычно :)
я кладу книгу в индекс -- получается лист книг где эмбеддед энтити автор.

допустим,у меня индекс в 300 миллионов книг одного автора. (да, такой продуктивный автор)
завтра выясняется, что автор оказывается у книг сменился и мне выходит, надо обойти все 300 миллионов книг чтоб его заменить?
как это работает - ты прост ов сущности книга мменяешь автора и всё. дальше чудеса случаются. как я понимаю, хибернейт берет сущность автора и оттуда втряхивает лист книг и в этом листе в индексе заменяет автора.
тут собссно вопрос - КАК он это делает?

чисто глядя в апи еластика там есть вариант кондишинал апдейт. типа замени автора у всех книг где автор такой то..
вопрос - юзает ли его хибер? и если да, то как это обрабатывает эластик? он идет итеративно построчно меняет или там какой то более оптимальный вариант есть? как такое сказывается на продуктивности?

я к тому что у меня 200 миллионов записей и мне в них надо обновить одно поле (айди это или другой объект внутри поля).

ну давай более приближенный сценарий. биллинг. организация-подписки. подписка-организация.

свободнотекстовые поиск по атрибутам подписки и организации.

у организации может быть 200 миллионов подписок (цифра не с потолка)
организаций может быть несоклько сотен - тысяч.

допустим, индекс подписок. в каждой подписке ембед организация.

юзкейс. у подписки с организации А меняется название организации. (или даже сама организация).

что надо? правильно надо делать апдейт ембед поля в 200 миллионов подписок.

говорю хиберу. окей, хибер, положи в индекс-план новую организацию (новое название)

хибер: да, конечно. беру организацию, через селект * фром сабскрибшн вхере организейшн=организейшн, делаю новй джейсон с новой организацией (имя поменялось) и вызываю еластик батч апдейт апи и начинаю пихать по 200 айтемов в батче в эластик индекс.
хибер: я проверил, у тебя 8 ядер, делаю 8 потоков батчами по 200 айтемов в индекс. каждый батч обрабатывается 120мс.
хибер: прошло 20 часов. апдейт готов. что-то еще?

...можно как то ускорить, например, самому подобрать списки подписок на реиндекс, кидануть батчами в кафку, а с другой стороны 100500 консумеров, что будут эти батчи ловить и пересылать в эластик. тогда что быстрее сдохнет.

я смотрел еластик апдейт апи. там вроде есть кандишинл апдейт. но мне не очень ясен перформанс. возможно тоже самое что и батчапдейт под капотом. если же быстрее, то почему его не привинтили в хибернейт-серче, а сделали на батчах?

с батчами и ембед сущностями все прекрасно работает. но, мягко говоря, не очень быстро. хотя наверное, быстро и не должно.

вариант два. альтернативный - держать два индекса. организаций и подписок.

и если юзерский поиск прилетает - вначале идем в организационный индекс, выгрибаем все матченные организации, выгребаем из них айди, и с этими айдихами идем в индекс сабскрибшинов + пользовательские атрибуты и доделываем серч там. этакий софт-джойн.

из плюсов - мы можем свободно менять название организации, и это будет быстро.
из минусов - лишняя логика с подобием джойнов, два запроса по факту,и если надо сменить владельца подписки с О1 на О2 -- то будут те же пляски с бубном что и выше.

согласен. особенно по пункту два. по пункту один - не очень. но два надо быть готовым к тому что некоторые апдейты могут занимать непозволителньо много времени. и с этим мало что можно поделать.

ну я так посмотрел систему у них дофига индексов по куче таблиц и с разной скажем так степенью обновляемостью. что то часто что то как тут сказали "почти" иммутабельно.

..задал вопрос умникам как они решают вопрос с джойнами пока тишина.

Я про конторских умников. Которые уже решили эту задачу в своем продукте. Вводные кругом-бегом те же

А что мне автор айди даст? Городить "софт" Джойны?
Да и автор у книги тоже может измениться.

Просто зная их бизнес кейсы вероятность изменения автора выше вероятности изменения имени автора.

Вроде выше же описал.
Есть подписки есть организации-владельцы. У организации может быть миллион подписок. У подписки одна организация.организация может сменить имя. У подписки может смениться организация-воаделец.

да, поэтому я сверху поправил кейс и указал реальную схему. организация-подписки. ) автор-книга не очень удачный пример согласен :)

да. вот и пытаюсь разнести. но пока не очень.

mayton,

Я же сказал - две таблицы. Один фк организации в подписке.