так что если это работает достаточно быстро, то наивная имплементация, которая начинает сначала и идет до конца может оказаться вполне приемлемой.

это и от размера лога зависит

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

если и это не помогает ,тогда уже оптимизировать.

а если там лог в 1TB? тоже буфер можно подкрутить?

Данные хранятся условно бесконечно

если там лог 1ТВ, то надо начинать с лечения головы

и да - буфер даже в этом случае можно подкрутить. проблема как правило не в IO, а в темпах обработки на стороне консюмера.

а пропускная способность у Кафки дикая совершенно

а сколько "нормально"? какие размеры не вызывают сомнения в адекватности?

Спасибо) Че то не подумал даже на него

под типичный хайлоад?

Сам страдаю. Я пытаюсь уговорить перенести на YT, но очень хз

yes

типичный хайлоад начинается от 32 партиций с репликой миниум 3. партиция должна уверенно помещаться на ноде и в большинстве случаев, в силу идемпотентности, подлежит компактизации. дай считать что хайлоад начинается от 10к rps, размер сообщения возьмем < 4KB, в 95%% случав < 1КБ. дальше надо продолжать или сам посчитаешь?

(это чисто мое субъективно мнение, да)

ну и надо быть законечнным дебилом, чтобы хайлоад без ретеншина хранить

Помогло id string key и KEY_FORMAT=«KAFKA»
Заметил в кондукторе, что в ключе сообщения string (который json, но все же изначально string).
Пример ключа: {"OrderID":42547152}

Отсюда вопрос №1:
Можно ли при такой ситуации (в message key лежит строка с json-ом) в id талицы/стрима подставить значение поля из этого json-а?

Вопрос №2.
Я наверное не до конца понимаю суть таблицы KSQL. Подскажите плз в чем я заблуждаюсь.
а) стрим - это собственно стрим данных, основанный на кафка топике; б) Таблица - грубо говоря, топик с последними состояниями сущностей по primary key
в) таблицы можно кверить, как обычные мускуль таблицы через CLI либо REST API ( select * from table where id = 123 - вернет последнее состояние сущности с id = 123 из соответствующего топика).
г) Под капотом у таблиц лежит compacted topic.

3) Почему когда я делаю запрос в таблицу, то получаю ошибку?
ksql> select * from o_table where OrderID=42547941;
Can't pull from O_TABLE as it's not a materialized table. See https://cnfl.io/queries for more info.
Add EMIT CHANGES if you intended to issue a push query.
В доке вроде как сказано, что к таблицам можно делать pull запрос на получение состояния сущности.

И вот не понял в чем разница Table и Materialized view (которая по сути table, которая as select …)

Сори за возможно делитантские вопросы, но я только погружаюсь в потоковое видение 🙂

1) у тебя где-то с типами напутано. Я уточнил у нижененов - ключ в json в 0.14 поддерживается.
3) потому что надо сказать ksqldb по какому полю делать агрегации. вот тут туториал который многое должен объяснитьнить https://docs.ksqldb.io/en/latest/tutorials/materialized/

А без агрегаций - просто последнее состояние не получится?
Пытаюсь решить задачу получения текущего состояния сущности из топика