Comments 2
почему не avx-512? Два миллиона строк группировка и сумма по индексу выполняется одну секунду? Это оооочень медленно. Представьте что есть агрегатор цен на 100 тысяч товаров (что мало) и цены обновляются раз в день у сотни (тоже мало) магазинов. Посчитайте сколько за месяц строк набежит. Тестируйте на всех диапазонах, 100, 1000, 10000 и т.д.
По AVX-512: мы намеренно держим AVX2 как базовый уровень — это позволяет запускаться на широком классе машин без проверки поддержки более широких регистров. Сейчас приоритет — надёжность и корректность в storage-слое, а не максимальная скорость на топовом железе. Когда storage стабилизируется, займёмся SIMD-оптимизацией серьёзно: расширим поддержку регистров, добавим явные векторизованные ядра под конкретные ISA.
По «очень медленно»: 1 012 мс — это наш результат для 2,25 млн строк в force_vector. PostgreSQL на тех же данных — 2 699 мс, ускорение 2.67×. Узкое место здесь не SIMD-арифметика, а RowToColumnBridge: при сканировании строчной таблицы каждая строка транспонируется в колоночный батч прямо в памяти, перед любой агрегацией. Это цена row-store пути.
По вашему сценарию (300 млн строк/мес): для такого объёма мы проектируем движок HtapRowColumn — строчная таблица остаётся основным хранилищем для OLTP, но рядом асинхронно строится колоночное представление тех же данных. Аналитические сканы читают его напрямую, без RowToColumnBridge и с нативными SIMD-агрегатами. В бенчмарке мы измеряли чистый RowStore — честный срез OLTP-пути. Когда колоночное представление станет основным аналитическим путём — покажем новые числа.
Вопрос по скорости хороший, 1с на 2 млн строк это не финальная цифра, а текущий срез того, где мы сейчас.
HTAP внутри OLTP: как мы строили векторизованный движок с самого начала