https://habr.com/ru/company/badoo/blog/451938/

Неплохая статья, интересная

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

Вот именно, и меня интересует, конечно же, агрегированная структура, компактный вектор, по которому можно очень быстро просканить таблицу, секцию или файл. С любыми целыми числами это можно сделать, добавив оффсеты к сжатым или обычным битовым картам. С другими типами данных и кортежами намного сложнее. Отображение их в целые числа, походу, настолько нетривиально, что проще использовать блум или куку. Хотя, всегда есть бинарное представление, а это тоже число! Но мысль дальше не идёт (

Мне тут трудно что-то посоветовать, ресерча на тему кодирования разных типов данных море, наверное надо попробовать с частного и конкретного кейса/цели.
Ещё раз только скажу, как Евгению, что блум на партиции/блоке, как и наша битовая маска в заголовке строки - это не то что обычно в базах называют индексом, меня это смутило. Можно конечно себе представить вторичную структуру сбоку в которой лежат PK и битмапы (такое в дореляционных базах делали) или идентификатор партиции и блумы, такое формально будет индексом,  но накладные уже будут другие.

В PG есть bloom индекс.
Кажется это то, что здесь называется bitmap индекс.
И есть bitmap индекс скан, но он означает совсем другое (чтобы не считывать страницы многократно)

Просто в статье было написано, что в PG нет bitmap индекса.

Вроде да, был экстеншен для ПГ; он как раз делает вторничную структуру, удобно для большого числа числовых колонок, но для аналитики подходит так себе (он построчный, размер будет огромный)

👍👍

Ну да, размер будет в константу раз меньше от общего размера.

А разве по ссылке не по строчно?

Проблема только в том что это lossy индекс, и надо будет сходить в базовую таблицу за настоящими значениями (такой индекс не может быть покрывающим), то есть получается ещё и джоин в запросе с использованием такого индекса

А тут в любом случае идти в таблицу. Из того, что биты совпали, не следует ничего.

Блум обычно делается колоночно, на партицию или блок, чтобы пропустить приличный процент объема при скане

Да, понял, это видимо в аналитике.

Ну поэтому и толк в аналитике так себе, мы же обычно запрашиваем не конкретную строку, а приливную порцию таблицы

Хм... Я вот сейчас понял, что я не уверен, как работает bloom в hbase) просто по-разному можно сделать

Ну в кх, bloom filter индекс обычно неплохо себя показывает когда нужно дернуть строку по уникальному id

Все вторичные структуру в аналитике делаются для двух целей:
1. Если про базовую таблицу - читать только нужные строчки, выкинуть из скана как можно больше заведомо лишнего
2. Читать какую-то заведомо меньшую покрывающую структуру, и не читать базовую таблицу

Это OLTP нагрузка

Да, но обычно не так плохо выходит. А ставить рядом другую субд не все хотят

Для пропуска StoreFile в которых точно нет нужной строки