| 
 | 
| 
 
два топика две сущности 
 | 
|||
|---|---|---|---|
| 
 #18+ 
    
  и снова я тут. собссно тема. не знаю как лучше сделать. хранилище - эластик. есть топик А по нему летят документы А, есть топик Б в него летят документы Б. документ А содержит лист документов Б. документы Б могут удаляться, или же менять владельца (документ А). в топике Б документы летят с одним только статусом - криейт апдейт и делет. документ Б содержит ключ от документа А. есть требование в выдаче отдавать список документов А, (в каждом внутри список документов Б). собссно варианта два: 1) мы держим два индекса и на лету при выдаче их джоиним. ну типа запрос в первый индекс и во второй а потом склеиваем. - производительность конечно же упадет. 2) мы получаем некий апдейт документа Б, идем по айди документа Б в индекс А, находим там документ А, и смотрим айди документа А в документе Б. и если они одинаковые обновляем документ А. если нет то удаляем из документа А и вкладываем документ Б в новый документ А. - тут просаживаемся по перформансу уже на инсерте. да еще и заморочки с версионированием получаем. вроде в эластике есть штука с почти классическими джойнами но ее советуют не использовать. ...  | 
|||
| 
 : 
 Нравится:
      
  Не нравится:
      
  
   | 
|||
| 01.06.2021, 00:24 | 
  
  
  
   | 
||
| 
 
два топика две сущности 
 | 
|||
|---|---|---|---|
| 
 #18+ 
    
  andreykaT, При чем тут ElasticSearch :-) Главное из эластика вытащить список id-ников, по которым из БД вытаскиваются уже полные данные. <:o) ...  | 
|||
| 
 : 
 Нравится:
      
  Не нравится:
      
  
   | 
|||
| 01.06.2021, 06:21 | 
  
  
  
   | 
||
| 
 
два топика две сущности 
 | 
|||
|---|---|---|---|
| 
 #18+ 
    
  ElasticSearch (если он имеется в виду) это все таки документно-ориентированная система. Ищем по ключевым словам документы и получаем их контент. Поэтому при изменениях документов - надо их просто актуализировать в индексе. ...  | 
|||
| 
 : 
 Нравится:
      
  Не нравится:
      
  
   | 
|||
| 01.06.2021, 11:47 | 
  
  
  
   | 
||
| 
 
два топика две сущности 
 | 
|||
|---|---|---|---|
| 
 #18+ 
    
  Если есть возможность для документов Б, в случае смены владельца, вместо события изменения публиковать удаление + создание, то лучше сделать так. Это _значительно_ упростит консьюмера. Если такой возможности нет, то придется хранить состояние связи Б -> A, но я бы не стал это делать в эластике. Можно либо использовать локальное для ноды консьюмера хранилище (RocksDB), так делает Flink, либо отдельный компактный топик в кафке, так делает KafkaStreams. Соответственно, при получении события изменения Б, сверяемся с состоянием и если связь Б->A не изменилась делаем update документа в эластике, а если изменилась, то делаем delete + insert и обновляем состояние. Это несложно написать самому, а можно также написать Stateful Consumer на Flink или KafkaStreams. ...  | 
|||
| 
 : 
 Нравится:
      
  Не нравится:
      
  
   | 
|||
| 01.06.2021, 14:08 | 
  
  
  
   | 
||
| 
 
два топика две сущности 
 | 
|||
|---|---|---|---|
| 
 #18+ 
    
  mad_nazgul andreykaT, При чем тут ElasticSearch :-) Главное из эластика вытащить список id-ников, по которым из БД вытаскиваются уже полные данные. <:o) нет никакой бд. эластик и есть документная бд. да. в данном контексте шла речь про документную бд. в общем у нас есть А с листом Б внутри. операции есть где Б добавляется в А или Б удаляется из А. есть топик куда летят А есть топик куда летят Б (с айдишкой на А). я всё же склоняюсь к одному индексу куда буду складывать и А и Б (отыскивая их по айди А и просто добавляя в лист. суть сервиса - быстрый ответ пользователю поэтому данные надо держать типа подготовленными. наверное это ближе всего к CQRS и последнее его звено. тут уже скорее специфика эластика пошла. я читаю сущность А из бд, добавляю в нее элементы Б из топика и кладу А+Б в бд. но. транзакций никаких нет :) там вроде есть версионность. типа оптимистическая блокировка. играюсь с ней. суть в том что если не смог вложить Б в А то просто не коммичу мессадж в кафке и делаю попытку еще раз пока не будте успеха в сохранении. ...  | 
|||
| 
 : 
 Нравится:
      
  Не нравится:
      
  
   | 
|||
| 01.06.2021, 18:08 | 
  
  
  
   | 
||
| 
 
два топика две сущности 
 | 
|||
|---|---|---|---|
| 
 #18+ 
    
  fixxer Если есть возможность для документов Б, в случае смены владельца, вместо события изменения публиковать удаление + создание, то лучше сделать так. Это _значительно_ упростит консьюмера. Если такой возможности нет, то придется хранить состояние связи Б -> A, но я бы не стал это делать в эластике. Можно либо использовать локальное для ноды консьюмера хранилище (RocksDB), так делает Flink, либо отдельный компактный топик в кафке, так делает KafkaStreams. Соответственно, при получении события изменения Б, сверяемся с состоянием и если связь Б->A не изменилась делаем update документа в эластике, а если изменилась, то делаем delete + insert и обновляем состояние. Это несложно написать самому, а можно также написать Stateful Consumer на Flink или KafkaStreams. мы ограничены в списке технологий - кафка и эластик. причем с рестхл-клиентом. хотя это наверное и к лучшему :) ...  | 
|||
| 
 : 
 Нравится:
      
  Не нравится:
      
  
   | 
|||
| 01.06.2021, 18:10 | 
  
  
  
   | 
||
| 
 
два топика две сущности 
 | 
|||
|---|---|---|---|
| 
 #18+ 
    
  andreykaT мы ограничены в списке технологий - кафка и эластик. причем с рестхл-клиентом. хотя это наверное и к лучшему :) Ну, ручками напиши стейтфул консамер с использованием компакт топика, наподобии KafkaStreams. И непонятно, почему KafkaStreams нельзя использовать? Это всего лишь библиотека. ...  | 
|||
| 
 : 
 Нравится:
      
  Не нравится:
      
  
   | 
|||
| 01.06.2021, 18:13 | 
  
  
  
   | 
||
| 
 
два топика две сущности 
 | 
|||
|---|---|---|---|
| 
 #18+ 
    
  кафкастримз можно. ты там выше какое то хранилище я так понял упомянул. по кафкастримз не очень понял идею, сорян. ...  | 
|||
| 
 : 
 Нравится:
      
  Не нравится:
      
  
   | 
|||
| 01.06.2021, 18:56 | 
  
  
  
   | 
||
| 
 
два топика две сущности 
 | 
|||
|---|---|---|---|
| 
 #18+ 
    
  andreykaT по кафкастримз не очень понял идею, сорян. Ну так пойми. Разжевываю для первоклашек. 1. Тебе нужно хранить связь Б->A чтобы определить, что обновление Б меняет родителя и сделать delete + insert, вместо update. 2. Ты можешь просто хранить это в Map в памяти. Но это не переживет перезапуска сервиса. Хранилище должно быть персистентным, но локальным, для перфоманса, и при этом партиционировано также как и топик событий для Б. 3. KafkaStreams предлагает использовать для хранения состояния еще один топик в кафке, по принципу чейдж-лога реляционной таблицы. Компакт-топик изоморфен таблице. KTable На каком пункте пропадает понимание? ...  | 
|||
| 
 : 
 Нравится:
      
  Не нравится:
      
  
   | 
|||
| 01.06.2021, 19:10 | 
  
  
  
   | 
||
| 
 
два топика две сущности 
 | 
|||
|---|---|---|---|
| 
 #18+ 
    
  андреич,тут же гарик пояснил за кафку- что это шляпа,никто ее не юзает с его слов- зачем оно тебе? ...  | 
|||
| 
 : 
 Нравится:
      
  Не нравится:
      
  
   | 
|||
| 01.06.2021, 20:40 | 
  
  
  
   | 
||
| 
 | 

start [/forum/topic.php?fid=59&tid=2120432]:  | 
    0ms | 
get settings:  | 
    9ms | 
get forum list:  | 
    13ms | 
check forum access:  | 
    4ms | 
check topic access:  | 
    4ms | 
track hit:  | 
    69ms | 
get topic data:  | 
    11ms | 
get forum data:  | 
    2ms | 
get page messages:  | 
    50ms | 
get tp. blocked users:  | 
    2ms | 
| others: | 11ms | 
| total: | 175ms | 

| 0 / 0 | 

    Извините, этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
    
    
    «На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
    
    
    ... ля, ля, ля ...