Индексный файл раздела Kafka

Question

Итак, я читал это: https://thehoard.blog/how-kafkas-storage-internals-work-3a29b02e026

По поводу кафки и внутренностей хранения придумал 2 вопроса:

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

2. Если я правильно понял, позиция, которая сохраняется в файле журнала, - это позиция этого сообщения внутри раздела (в основном, его индекс). Позиция, сохраненная в индексном файле, является той же самой позицией, верно? для быстрого доступа, например, если мне нужно сообщение 6 раздела, я ищу 6, используя бинарный поиск в файле индекса и используя смещение в той же записи, я иду на эту строку в файле журнала? (например, если позиция 6 имеет индекс 7, я перехожу к строке 7 в файле журнала)

Answer 1

Это интересный!

По общему признанию, мое понимание внутренних функций Кафки ограничено, но я все равно попытаюсь разобраться с этим.

По первому вопросу :

Я посмотрел исходный код OffsetIndex.scala - кажется, что смещенная часть в индексном файле вычисляется в методе relativeOffset() каждый раз, когда создается новая запись. Чтобы добавить к этому, описание в исходном коде говорит

Индекс, который сопоставляет смещения с физическими местоположениями файлов для определенного сегмента журнала. Этот индекс может быть разреженным: то есть он может не содержать запись для всех сообщений в журнале .

Итак, согласно справочной статье, которой вы поделились, - вероятно, из-за этой редкой природы этого индекса,

поиск смещения использует бинарный поиск, чтобы найти ближайшее смещение меньше или равно целевому смещению

Из объяснения видно, что смещение просто увеличивается - это не обязательно так. Например, я создал тему и посмотрел содержимое журнала и индекса.

**** Содержимое файла 000---180.index было **** (обратите внимание на смещения здесь - НЕ увеличивается последовательно):

offset: 217 position: 4107 offset: 254 position: 8214 offset: 291 position: 12321 offset: 328 position: 16428 offset: 365 position: 20535 offset: 402 position: 24642 offset: 439 position: 28749

**** Содержимое файла 000---180.log было **** (обратите внимание на смещения - последовательно увеличивается ):

[Чтобы было проще, я использовал 3 точки (...) для представления строк между этими смещениями, доступными в индексе]

offset: 217 position: 4107 CreateTime: 1537550091903 isvalid: true keysize: 0 valuesize: 43 magic: 2 compresscodec: NONE producerId: -1 sequence: -1 isTransactional: false headerKeys: [] offset: 218 position: 4218 CreateTime: 1537550092908 isvalid: true keysize: 0 valuesize: 43 magic: 2 compresscodec: NONE producerId: -1 sequence: -1 isTransactional: false headerKeys: [] offset: 219 position: 4329 CreateTime: 1537550093910 isvalid: true keysize: 0 valuesize: 43 magic: 2 compresscodec: NONE producerId: -1 sequence: -1 isTransactional: false headerKeys: [] ... offset: 253 position: 8103 CreateTime: 1537550127960 isvalid: true keysize: 0 valuesize: 43 magic: 2 compresscodec: NONE producerId: -1 sequence: -1 isTransactional: false headerKeys: [] offset: 254 position: 8214 CreateTime: 1537550128961 isvalid: true keysize: 0 valuesize: 43 magic: 2 compresscodec: NONE producerId: -1 sequence: -1 isTransactional: false headerKeys: [] offset: 255 position: 8325 CreateTime: 1537550129962 isvalid: true keysize: 0 valuesize: 43 magic: 2 compresscodec: NONE producerId: -1 sequence: -1 isTransactional: false headerKeys: [] ... offset: 289 position: 12099 CreateTime: 1537550164007 isvalid: true keysize: 0 valuesize: 43 magic: 2 compresscodec: NONE producerId: -1 sequence: -1 isTransactional: false headerKeys: [] offset: 290 position: 12210 CreateTime: 1537550165008 isvalid: true keysize: 0 valuesize: 43 magic: 2 compresscodec: NONE producerId: -1 sequence: -1 isTransactional: false headerKeys: [] offset: 291 position: 12321 CreateTime: 1537550166009 isvalid: true keysize: 0 valuesize: 43 magic: 2 compresscodec: NONE producerId: -1 sequence: -1 isTransactional: false headerKeys: [] offset: 292 position: 12432 CreateTime: 1537550436878 isvalid: true keysize: 0 valuesize: 43 magic: 2 compresscodec: NONE producerId: -1 sequence: -1 isTransactional: false headerKeys: [] ... offset: 327 position: 16317 CreateTime: 1537550471917 isvalid: true keysize: 0 valuesize: 43 magic: 2 compresscodec: NONE producerId: -1 sequence: -1 isTransactional: false headerKeys: [] offset: 328 position: 16428 CreateTime: 1537550472919 isvalid: true keysize: 0 valuesize: 43 magic: 2 compresscodec: NONE producerId: -1 sequence: -1 isTransactional: false headerKeys: [] offset: 329 position: 16539 CreateTime: 1537550473920 isvalid: true keysize: 0 valuesize: 43 magic: 2 compresscodec: NONE producerId: -1 sequence: -1 isTransactional: false headerKeys: []

По второму вопросу :

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

Надеюсь, это поможет!