есть ли какие-то планы по работе с map как с хэш-таблицей (в части доступа за единицу вместо линии, если быть точным)? По банальным тестам все выглядит так, что поиск по ключу в map работает медленнее, чем, например JOIN временной таблицы из этих же значений (видимо, потому, что JOIN создает хэш-таблицу)
Или мы что-то упускаем?
Условно, map это некоторый "сахар" над двумя массивами: ключи и значения. В КХ нет и невозможны индексы в классическом их понимании из-за объема хранящихся данных и особенностей хранения (блоками). Те всегда читаем много и, относительно, oltp - долго.
да, я так и понял, но не совсем ясно, что мешает на лету превращать Map в хэш-таблицу, если запрос использует индексер? Это ведь O(N), вроде ничего не теряем. А вот из-за того, что это не делается, наблюдаются вот такие приколы: SELECT count(*) FROM ( WITH map(0, 1, ..., 255) AS lookup SELECT number, lookup[n.number % 256] FROM numbers(1e8) n ) 1 rows in set. Elapsed: 4.974 sec. Processed 100.03 million rows, 800.21 MB (20.11 million rows/s., 160.88 MB/s.) SELECT count(*) FROM ( WITH lookupTable AS (SELECT 0 key, 1 value UNION ALL SELECT 2 key, 3 value ... UNION ALL SELECT 254 key, 255 value) SELECT number, lookupTable.value FROM numbers(1e8) n INNER JOIN lookupTable ON lookupTable.key = n.number % 256 ) 1 rows in set. Elapsed: 1.411 sec. Processed 100.03 million rows, 800.21 MB (70.88 million rows/s., 567.06 MB/s.)
ну и да, линия вылазит стоит только увеличить N: SELECT count(*) FROM ( WITH map(0, 1, ..., 1023) AS lookup SELECT number, lookup[n.number % 1024] FROM numbers(1e8) n ) 1 rows in set. Elapsed: 17.441 sec. Processed 100.03 million rows, 800.21 MB (5.73 million rows/s., 45.88 MB/s.) в то время, как SELECT count(*) FROM ( WITH lookupTable AS (SELECT 0 key, 1 value UNION ALL SELECT 2 key, 3 value ... UNION ALL SELECT 1022 key, 1023 value) SELECT number, lookupTable.value FROM numbers(1e8) n INNER JOIN lookupTable ON lookupTable.key = n.number % 1024 ) 1 rows in set. Elapsed: 1.265 sec. Processed 100.03 million rows, 800.21 MB (79.05 million rows/s., 632.38 MB/s.)
Обсуждают сегодня