KTable / KStream потребление памяти с течением времени - PullRequest
1 голос
/ 14 мая 2019

Есть ли способ подсчитать, сколько кучи (или любой другой) памяти приблизительно будет использоваться KTable / KStream в приложении java / scala с течением времени?

У меня есть некоторые конкретные предположения, и я хотел бы знать, верны ли они:

  • Потоки Kafka используют только внутренние темы и RocksDB.

  • RocksDB - это встраиваемая БД, поэтому она использует кучу памяти моего приложения.

  • KStream постоянно удаляет все записи из RocksDB после того, как они больше не могут использоваться ни одним из процессоров в топологии (например, для объединения с указанным JoinWindow) (== используется не так много памяти)

  • KTable полностью сохраняется в RocksDB (== в памяти)

  • Когда KTable получает запись с нулевым значением, она удаляет запись из RocksDB (==память освобождена)

1 Ответ

1 голос
/ 19 мая 2019

Сложно оценить.Для определения общего размера рассмотрите это руководство: https://docs.confluent.io/current/streams/sizing.html

Потоки Кафки используют только внутренние темы и только RocksDB.

Да.Вы также можете заменить RocksDB хранилищами в памяти (которые являются частью Kafka Streams) или реализовать свои собственные хранилища.

RocksDB - это встраиваемая БД, поэтому она использует кучу памяти моего приложения.

RocksDB использует память вне кучи, а также разливается на диск.

KStream постоянно удаляет все записи из RocksDB после того, как они больше не могут использоваться ни одним из процессоров в топологии (например,для объединения с указанным JoinWindow) (== используется не так много памяти)

Это зависит от типа хранилища.Для хранилищ значений ключей (т. Е. «Обычных» KTable с) данные не удаляются (за исключением явных сообщений об удалении, так называемых надгробий).Для KTables с временными окнами / сессионными окнами (результат оконных агрегатов) и объединений существует период хранения, после которого данные удаляются.

KTable полностью хранится в RocksDB (== в памяти)

RocksDB также проливает диск.Это не только в памяти.

Когда KTable получает запись с нулевым ключом, он удаляет запись из RocksDB (== память освобождена)

null записи ключане деформированы.Я предполагаю, что вы имеете в виду запись null, так называемый надгробный камень.Те рассматриваются как удаляет.

...