ну сейчас мне кажется, проще selectExpr какой-нибудь сделать, особенно, если это pyspark

раньше (в 2.2.0) была большая проблема с множеством union, пара тысяч партиций склеивались несколько часов. В какой-то версии её пофиксили, но я пользуюсь имплиситом, который вызывает Union для всех датафреймов сразу. Делал бенчмарк, обычный юнит-тест, разница во времени получалась от пятидесяти раз до нескольких тысяч
А вот на колумны не делал, всегда было незаметно на фоне остальных операций. Так что, наверное, не стоит беспокоиться

set mem_limit=40g;
оно?

Да

маму твою по театрам водил

Всем привет.
Есть вопрос по hbase-у.
У hbase-а задаётся размер memstore и blockcache в процентах. По умолчанию 0.4 и 0.4. Остальные 20% видимо идут на какие-то внутренние нужды hbase. Как-то можно правильно понять, сколько точно хватит самому hbase-у? Кто-то пробовал задавать memstore + blockcache суммарно больше 80%?)

Раньше натыкался когда они даже больше 100% оказались, ушёл в перманентный gc сервер, потом оом

Опять же 20% хипа это много или мало?

Зависит от размера этого хипа

Да, но может от того, какой размер memstore или blokcache следует пропорциональная зависимость всего остального. Может она как раз должна быть 20%, если 80% - это memstore и blockcache.

А может быть нет и достаточно 5gb, тогда я могу сам высчитать из размера heap-а, сколько мне оставить

Мемстор активно на записи используется

Блоккеш при чтении

Дальше уже плясать от нагрузки и можно туда сюда двигать их

Наверное вопрос такой: есть ли там пропорциональная зависимость или есть просто какой-то потолок, который я могу задать?

оверкоммитить не надо, а относительно размеров -вы подбираете что под вашу нагрузку нужно, мемстор влияет на то как часто оно компактит на диск, блок кэш снимает дисковую нагрузку на чтение (так же как бакет кэш, не забывайте про него), подходящие вам настройки зависят от вашей нагрузки

0.4/0.4 по-моему хороший бейзлайн, дальше вы запускаете свои стресстесты и смотрите как оно себя ведет

> оверкоммитить не надо

Это означает, что больше 80% задавать их суммарно не стоит?

да, не стоит

Спасибо!

А меньше есть ли мысл?

нет, смысла меньше нет

20% это резерв по сути

у меня были проблемы с withcolumn, когда их было 5 тысяч. План запроса формировался 1 час, переделал на select(col array) время снизилось до пары секунд