Стиснення індексу

Як Віктор стискає інвертований індекс крок за кроком, із розмірами на екрані: сирий JSON 4 GB → сплощені масиви 3.4 GB → дельта-кодування відсортованих doc id (зберігати 100, 3, 5 замість 100, 103, 108) 2.3 GB → varbyte-кодування (7 бітів даних + 1 біт продовження на байт), загорнуте в base64, → 1.3 GB — менше за власний FULLTEXT-індекс MySQL з його 1.7 GB (інвертовані індекси). Дельта-стиснення — те, що все уможливлює: воно перетворює великі id на маленькі цілі числа, які VByte (зі статті, на яку він посилається) пакує щільно; це ще й пришвидшує читання з файлової системи та дозволяє більшому індексу поміститися в RAM (Q&A №1).

У Q&A-продовженні він показує оглядову статтю про алгоритми стиснення posting-списків і робить чесні висновки: усі вони передбачають відсортовані цілі числа, універсального переможця немає, а varbyte пристойний скрізь. Наслідок кусається на практиці: UUID як doc id ламають їх усі — спершу треба відобразити UUID у цілі числа, саме це й робить прихована колонка FTS_DOC_ID в InnoDB (Q&A до другої частини, UUID проти auto-increment).