понимаю, что большие ключи ведут к большим накладным расходам, но полного понимания нет.
Вопросы:
1. Про какие индексы там идёт речь?
2. Как понять, что storefileIndexSize большой? по сравнению с чем большой? По этой ссылке было такое умозаключение.
3. Какой командой можно получить вывод таких метрик?
У хбейз ток один индекс - лексикографический (если вопрос в этом); сами индексы (key твоей key/value) могут быть большими оч
Ага, т.е. там (по ссылке в офицальной книге) имеется ввиду стандартный индекс по rowid (который по факту ввобще не индекс, а упорядоченный по rowid кусок данных)?
это _индекс_; да имеется ввиду ключ строк
Видимо осталось 2 вопроса. Возможно они про HDFS. Туда я просто вообще ещё не смотрел.
а что за структура под этим индексом B-Tree или какоя то Hash ?
1. Store File Index это структура в памяти которую держит Region Server чтобы знать по каким HFile искать https://github.com/apache/hbase/blob/889049eab666f99bc300c070ced5505d0a59d3c5/hbase-server/src/main/java/org/apache/hadoop/hbase/io/hfile/HFileReaderImpl.java#L245
2. Все относительно, надо смотреть сколько у вас всего в куче, и сколько эти индексы едят 3. Через JMX достают с Region Server
Спасибо. Стало яснее немножко.
вы напишите какую проблему решаете, может подскажут что-то более опытные коллеги
Я читаю книгу по порядку и увидел такое, что мой мозг не воспринял. Кажется, что читателя не подготовили к этому, хотя может я невнимателен)
вы хорошо читаете эту книгу) самый важный месседж в этой главе передан верно - лучше чтобы ключи и колонки были маленькие
а почему бы не хранить сразу связку ключа, офсета на диски внутри sstable?
Присылайте PR, люди рассмотрят)
если это не так во многих реализациях, то значит на это есть основания. мне просто интересно. понять эти основания. какие ограничения мешают это сделать. пока видится - что это не работает из-за того, что при слиянии нужно будет обновлять эту структуру и это заблочит читателей
я не уверен что понял ваше предложение, прочитаю после обеда еще раз
Обсуждают сегодня