Confluent Schema Registry — максимальное количество схем
Я имею в виду Confluent Schema Registry:
Есть ли надежная информация о том, сколько различных схем может поддерживать один реестр схем?
Насколько я понимаю реестр схем, он считывает доступные схемы при запуске из темы кафки.
Таким образом, возможными ограничениями могут быть потребление памяти (= количество схем в памяти за раз) или производительность (= поиск схем из Kafka).
Ответы 2
Внутри он использует ConcurrentHashMap для хранения этой информации, поэтому теоретически ограничение составляет примерно максимальный размер резервного массива Java.
Есть ли у массивов Java максимальный размер?
Однако существует несколько карт, поэтому также будут существовать ограничения кучи JVM. Если у вас есть большие строки необработанной схемы, то будет использоваться больше памяти, поэтому для этого нет хорошего расчета.
Тексты схем хэшируются md5 и сравниваются, так что математика будет для уникальных схем, не обязательно количества предметов или сопоставления версий между предметами.
Я создал свой собственный эталонный инструмент для поиска возможных ограничений. Ссылка на репозиторий Github находится здесь.
TL;DR:
Как подозревает @OneCricketeer, фактором масштабируемости является ~ nr of schemas * size of avg schema. Я создал инструмент, чтобы увидеть, как масштабируется использование памяти реестра и процессора для регистрации множества разных схем AVRO одинакового размера (используя настраиваемое поле в схеме, чтобы различать их).
Я запустил инструмент для ~ 48 схем, для тех ~ 900 МБ памяти, которые использовались с низкой загрузкой процессора.
Выводы:
- В начале рост использования памяти намного выше. После начального наращивания использование памяти увеличивается ступенчато, когда выделяется новая память для хранения большего количества схем.
- Большая часть памяти используется для хранения схем в ConcurrentHashMap (как и ожидалось).
- Использование ЦП существенно не меняется со многими схемами, а также время для извлечения схемы.
- Существует кеш для хранения сопоставлений RawSchema -> ParsedSchema (var
SCHEMA_CACHE_SIZE_CONFIG, по умолчанию 1000), но, по крайней мере, в моих тестах я не заметил негативного влияния на промах кеша, это было как попадание, так и промах ~ 1-2 мс для получения схема.
Использование памяти (масштаб x = 100 схем, масштаб y = 1 МБ):
Использование ЦП (масштаб x = 100 схем, масштаб y = использование в %):
Топ-10 объектов в куче Java:
num #instances #bytes class name (module)
-------------------------------------------------------
1: 718318 49519912 [B ([email protected])
2: 616621 44396712 org.apache.avro.JsonProperties$2
3: 666225 15989400 java.lang.String ([email protected])
4: 660805 15859320 java.util.concurrent.ConcurrentLinkedQueue$Node ([email protected])
5: 616778 14802672 java.util.concurrent.ConcurrentLinkedQueue ([email protected])
6: 264000 12672000 org.apache.avro.Schema$Field
7: 6680 12568952 [I ([email protected])
8: 368958 11806656 java.util.HashMap$Node ([email protected])
9: 88345 7737648 [Ljava.util.concurrent.ConcurrentHashMap$Node; ([email protected])
10: 197697 6326304 java.util.concurrent.ConcurrentHashMap$Node ([email protected])
Интересный взгляд на это. Таким образом, в основном верхняя граница составляет 32 - 2 = 30 бит из-за того, как схемы хранятся в картах, и потому, что 32-битное целое число используется для хранения идентификаторов схемы. Для приблизительного расчета памяти кучи можно использовать количество схем, умноженное на расчетный средний размер (плюс некоторый неизвестный коэффициент для другой памяти кучи).