Всё, что вы хотели знать о HANA, но боялись спросить

kernelpanic

Итак, в этом посте срываются покровы и обнародуются шокирующие подробности о SAP HANA!!11!!
А если серьезно, готов в меру своих возможностей и знаний ответить на технические(не холиварные) вопросы об этой СУБД в рамках данного поста, ответы на которые вы не нашли в доках или FAQ.

kds

kernelpanic написал(а):

А если серьезно, готов в меру своих возможностей и знаний ответить на технические(не холиварные) вопросы об этой СУБД в рамках данного поста, ответы на которые вы не нашли в доках или FAQ.

Ну "раз пошла такая пьянка", то первый вопрос

Имеется : HANA SPS09 (VMWare ESX 5.5, 16 VCPU, 48GB RAM). Задеплоен тест TPC-H (scale factor 50).
Слегка модифицированный запрос (3.sql из теста) :

Code:

select
        l_orderkey,
        sum(l_extendedprice * (1 - l_discount)) as revenue,
        o_orderdate,
        o_shippriority
from
       customer,
       orders,
       lineitem
where
        c_mktsegment = 'AUTOMOBILE'
        and c_custkey = o_custkey
        and l_orderkey = o_orderkey
group by
        l_orderkey,
        o_orderdate,
        o_shippriority
order by
        revenue desc,
        o_orderdate

стабильно выполняется за 35 сек.

Строк в таблицах: LINEITEM - 300 мил. , ORDERS - 75 мил., CUSTOMERS - 7.5 мил.

Есть ощущение, что должно быть "более лучше".

Что делал : создавал индексы по join-колонкам, создавал статистику, указывал кучу разных JOIN/OLAP-хинтов.

Безрезультатно. Точнее при использовании OLAP-хинтов рантайм проседает до 53-55 сек.

kds

Странно, при добавлении любого текста к последней фразе в предыдущем сообщении "предпросмотр" превращает пост в кракозябры.

Продолжение.

Что замечено : при ипользовании join engine наблюдается очень "рваное" потребление VCPU, при использовании olap engine вообще 90% времени работает
только на одном VCPU.

Если найдутся мысли как это дело (join больших таблиц) можно оптимизировать, то буду очень признателен за "ликбез"

kernelpanic

Добрый день!

Давайте начнем с performance trace
Сможете его собрать для этого конкретного стэйтмента при отсутствии нагрузки?

kds

Хост тестовый, параллельной нагрузки нет
Отправил в личку ссылку на архив с трейсом и планами

Спасибо.

kernelpanic

kds, приветствую!

Посмотрел perftrace. БОльшая часть времени уходит на group by (почти 16 секунд), на построение таблицы джоина с lineitem (7 секунд) и на вычисление результата (почти 4 секунды)
Из customer берется 1501166 строк и джоинится с 14998184 строк из orders и 60003229 строк из lineitem (итоговая таблица именно такого размера)
Скорость процессинга по groub by по orders - 3.37 микросекунд на строку, по lineitem 5.27 микросекунд на строку.
Калькуляция вычисляемого поля: 15 микросекунд на строку.

Не могу сказать, что тут много возможностей для улучшения, скорее надо сужать условия.

kds

Добрый день.

Спасибо.

Да, это все из планов и трейса я тоже увидел, больше интересовало можно ли как-то (хинтами или еще как) сделать на этом запросе параллелизм более "агрессивным"
Попробовал хинт PREAGGR_BEFORE_JOIN, но рантайм вообще улетел в 4 минуты.
Есть ли где-то какое-то описание use cases для хинтов кроме SELECT ...HINT clause ?

kernelpanic написал(а):

Не могу сказать, что тут много возможностей для улучшения, скорее надо сужать условия

С дополнительными предикатами по LINEITEM и ORDERS ожидаемо работает быстрее.

Вопрос возник собственно из-за того, что две других in-memory-БД тоже самое на том же хосте делают почти в три раза быстрее при этом укладывая в ноль все 16VCPU c первой секунды. Хочется того же добиться от HANA'ы.

Еще вот наткнулся :
Простенький запрос (симулируем фулскан по всей таблице LINEITEM) :

Code:

select l_shipdate, sum(l_extendedprice), count(*) 
from tpchusr.lineitem
group by l_shipdate
order by 1 desc

мухой отлетает за секунду (в 4-5 раз быстрее обоих "конкурентов")
Но если попросить сделать :

Code:

select year(l_shipdate), sum(l_extendedprice), count(*) 
from tpchusr.lineitem
group by year(l_shipdate)
order by 1 desc

то выполняется за 27 сек. При этом две трети времени "думает" в один поток.
Двое других - 3 и 8 сек. соответственно, также съедая CPU.

kernelpanic

Добрый день,

хинты есть, описание к ним запаздывает, увы.
Почему другие in-memory бд отрабатывают быстрее, не готов ответить, не являюсь экспертом. Может быть что угодно, начиная от другой организации хранения и обработки, до Volkswagen-style tuning
Судя по перфоманс-трейсу, у Вас загрузка достигает 80 процентов на параллельной обработке, не могу сказать, что ядра простаивают.
С year() могу предположить, что вычисление функции не параллелится по какой-либо причине, можно попробовать собрать query optimizer трейс или опять-таки performance trace

Kengur

kds а можно полюбопытствовать какие две другие inmemory у вас?

Dimarik

По параллелизации :
Можно попробовать with parameters ('request_flags'='ANALYZE_MODEL')
соответствует hint-у OLAP_PARALLEL_AGGREGATION
По выделению года - читаем BEST PRACTICE в гайдах. Юзаем GC и физ. храним если хотим скорости.

kds

Kengur написал(а):

kds а можно полюбопытствовать какие две другие inmemory у вас?

DB2 10.5.4 (BLU-engine) и Oracle 12.1.0.2 (InMemory Option). Оба движка колоночные.

kds

Dimarik написал(а):

По параллелизации :
Можно попробовать with parameters ('request_flags'='ANALYZE_MODEL')
соответствует hint-у OLAP_PARALLEL_AGGREGATION.

Пробовал оба варианта, рантайм на OLAP-engine одинаковый порядка 55 сек. (выше я писал об этом)

Dimarik написал(а):

По выделению года - читаем BEST PRACTICE в гайдах. Юзаем GC и физ. храним если хотим скорости.

Понятно, что это worst case и "в жизни" никто так не делает. Но вот что есть, то есть.
А "GC" это что ?

Dimarik

GC = GENERATED COLUMN
Пример из гайда -
Slow querySELECT * FROM T WHERE b * c = 10;
Fast querySELECT * FROM T WHERE bc = 10;
DDL for faster queryALTER TABLE T ADD (bc INTEGER GENERATED ALWAYS AS b * c);

Подобные колонки едят память. Поэтому, это как с индексами в классической БД - необходимо подходить с умом:)

Всё, что вы хотели знать о HANA, но боялись спросить

Кто сейчас на конференции