Таймеры (Heap против RocksDB)

поскольку я использую RocksDB в качестве бэкэнда состояния для моей работы Flink, и я настраиваю параметры этого бэкэнда состояния, я прочитал на этой странице Flink, что у меня есть два варианта сохранения таймеров (RockDB или куча), и я прочитал объяснение, но все еще не понимаю, что означает эта его часть:

Однако поддержание таймеров в RocksDB может иметь определенную стоимость, поэтому Flink предоставляет возможность хранить таймеры в куче JVM, даже если RocksDB используется для хранения других состояний. Таймеры на основе кучи могут иметь лучшую производительность при меньшем количестве таймеров.

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

apache-flink flink-streaming flink-cep rocksdb
person Alejandro Deulofeu    schedule 18.09.2020    source источник

Ответы (1)


arrow_upward
1
arrow_downward

Доступ к таймерам на основе кучи можно получить с меньшей задержкой. Тесты, которые я слышал, показали лишь незначительное улучшение (ускорение на 5-10%). Однако хранение таймеров в куче увеличивает количество объектов, участвующих в сборке мусора, поэтому это также может повредить общей производительности (например, задержка в наихудшем случае).

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

person David Anderson    schedule 18.09.2020