Инженеры SQLite показали, как ускорить вставку случайных данных в базу — без перехода на UUID7. Проблема в том, что B+Tree, на котором построена SQLite, любит последовательные записи. А случайные ключи вроде UUID4 или токенов сессий разбрасывают страницы, вызывают page splits и ребалансировку. Каждый вставленный элемент может перескочить в другой блок, дерево перестраивается — и скорость падает.
Автор взял 20-байтовый BLOB, сгенерированный через SecureRandom — примерно такой используют для неугадываемых идентификаторов. Сначала он вставлял 10 миллионов таких записей напрямую, батчами по миллиону. Получилось около 100 тысяч вставок в секунду. К 10 миллионам время выросло до 11 секунд — то есть каждый новый миллион добавлял всё больше работы.
Затем — фокус. Раз данные уже батчатся, почему бы их не отсортировать перед вставкой? Для сортировки не нужно сравнивать все 20 байт — достаточно первых восьми. Автор конвертирует их в unsigned long через ByteBuffer и использует Long/compareUnsigned — так порядок совпадает с тем, как SQLite сравнивает BLOB через memcmp(). Это черновая оптимизация, но она работает.
Результаты: после сортировки первые миллионы вставляются за те же 2 секунды, но дальше рост почти плоский. На 10 миллионах — 3,8 секунды вместо 11,1. Ускорение в 2–3 раза, причём с каждым батчем оно становится заметнее. Даже с учётом накладных расходов на саму сортировку (она идёт в памяти) выигрыш огромный.
Вывод простой: если вы батчите данные со случайными или неупорядоченными ключами — отсортируйте их перед записью. Это бесплатная оптимизация, которая даёт кратное ускорение без изменения схемы или формата идентификаторов. Код бенчмарка лежит в репозитории, обсуждение — в Datastar Discord.