184 похожих чатов

Всем привет. Подскажите какие подводные камни от использования словарей с

типами *_ARRAY ? Радует более низкий постоянные расход памяти, местами разница колоссальная. Сильно ли влияет на пиковый расход памяти при выполнении запросов? Были замечены ООМ через какое-то время после перевода словарей (прогружены они были заранее) на эти типы, потом также быстро само и прошло, не понял на них грешить или нет :)

10 ответов

20 просмотров

они чуть медленее чем hashed

Anton-Mikhalev Автор вопроса
Denny [Altinity]
они чуть медленее чем hashed

спасибо, по скорости особо разницы не заметил пока. значит что-то другое ООМ вызвало

https://github.com/ClickHouse/ClickHouse/issues/30236#issuecomment-945188809 можете почитать весь ишью

Denny [Altinity]
https://github.com/ClickHouse/ClickHouse/issues/30...

спасибо за ссылку. Есть ещё интересный вопрос - почему так много внимания уделяется словарям, а join engine забыт? Я тут провел подобные тесты и получилось, что join engine работает не сильно медленее hashed, однако занимает в разы меньше памяти. И обновлять значения по ключу можно без мучительной перегрузки. Может там есть какой-то подвох?

Boris
спасибо за ссылку. Есть ещё интересный вопрос - ...

1. Я не пользуюсь engine join, потому что источники данных у меня внешние -- http. Я не вижу смысла писать ETL который будет перекладывать в engine=Join. 2. Engine = join не гарантирует целостности при перезагрузке. 3. Бекэнд не умеет Engine=Join, а SQL запросы руками не пишем вообще никогда, и переделывать бекэнд лень. 4. Engine join если наделать множество инсертов, создаст кучу каталогов на диске, мержить он не умеет (или не умел) , я уже видел КХ который стартовал 2 часа, атача engine=join. Спасибо. 5. Словари более менее консистенты между шардами без вообще траты каких-либо ресурсов на это.

Denny [Altinity]
1. Я не пользуюсь engine join, потому что источник...

А если Engine=Join для очень маленьких файлов которые не меняеются почти никогда, у меня в таком лежит справочник по странам где всякая инфа(200 строк буквально), не должно быть проблем больших?

Denny [Altinity]
1. Я не пользуюсь engine join, потому что источник...

а да, разве layout = SparseHashed занимает сильно больше памяти чем engine join?

Denny [Altinity]
а да, разве layout = SparseHashed занимает сильно ...

Да. 1.5Gb/7sec против 5.27 GiB/224 sec. Но для словаря пришлось отказаться от LowCardinality в пользу обычных строк. Наверное из-за этого.

Boris
Да. 1.5Gb/7sec против 5.27 GiB/224 sec. Но для сло...

не понимаю, что такое "1.5Gb/7sec" ? мы обсуждали "однако занимает в разы меньше памяти"

Похожие вопросы

Обсуждают сегодня

Господа, а что сейчас вообще с рынком труда на делфи происходит? Какова ситуация?
Rꙮman Yankꙮvsky
29
А вообще, что может смущать в самой Julia - бы сказал, что нет единого стандартного подхода по многим моментам, поэтому многое выглядит как "хаки" и произвол. Короче говоря, с...
Viktor G.
2
30500 за редактор? )
Владимир
47
а через ESC-код ?
Alexey Kulakov
29
Чёт не понял, я ж правильной функцией воспользовался чтобы вывести отладочную информацию? но что-то она не ловится
notme
18
У меня есть функция где происходит это: write_bit(buffer, 1); write_bit(buffer, 0); write_bit(buffer, 1); write_bit(buffer, 1); write_bit(buffer, 1); w...
~
14
Добрый день! Скажите пожалуйста, а какие программы вы бы рекомендовали написать для того, чтобы научиться управлять памятью? Можно написать динамический массив, можно связный ...
Филипп
7
Недавно Google Project Zero нашёл багу в SQLite с помощью LLM, о чём достаточно было шумно в определённых интернетах, которые сопровождались рассказами, что скоро всех "ибешни...
Alex Sherbakov
5
Ребят в СИ можно реализовать ООП?
Николай
33
https://github.com/erlang/otp/blob/OTP-27.1/lib/kernel/src/logger_h_common.erl#L174 https://github.com/erlang/otp/blob/OTP-27.1/lib/kernel/src/logger_olp.erl#L76 15 лет назад...
Maksim Lapshin
20
Карта сайта