ИМ
@den_crane ранее в чате упоминалось категоричная рекомендация НЕ использовать UUID. Почему так?
Size: a a a
2020 September 22
DC
@den_crane ранее в чате упоминалось категоричная рекомендация НЕ использовать UUID. Почему так?
там же было написано все. UUID -- 16 байт -- это дохера
DC
т.е. в какой-то момент вы поймете что можете хранить данные за последние 7 месяцев, а вот если бы вместо UUID был хеш 8 байт, то влезло бы 12 месяцев, и запросы вместо 6 секунд, работали бы 4
ИМ
Звучит неприятно( А мы как раз везде uuid суём. Чтож спасибо
ИМ
На замену можно UInt32 взять?
DC
На замену можно UInt32 взять?
вы чего-то вообще не о том видимо говорите.
UUID - это id чего? каким образом у вас это поместится в Int32 ? Коллизии будут?
UUID - это id чего? каким образом у вас это поместится в Int32 ? Коллизии будут?
ИМ
Например сейчас используется uuid в качестве идентификации пользователя
ИМ
Не очень помню сколько чего в интах, может не влезет %)
X
доброго. у меня довольно специфичный кейс: в течении ~20 секунд прилетает порядка 900 ивентов, нужно каждый из них записать в CH и как можно быстрее отправить дальше. суть проблемы в том, что я не могу батчить запросы, а производительность при таком раскладе более чем удручающая :( можно ли что-то сделать или я пытаюсь заставить CH делать то, что он делать не предназначен?
НБ
Xor
доброго. у меня довольно специфичный кейс: в течении ~20 секунд прилетает порядка 900 ивентов, нужно каждый из них записать в CH и как можно быстрее отправить дальше. суть проблемы в том, что я не могу батчить запросы, а производительность при таком раскладе более чем удручающая :( можно ли что-то сделать или я пытаюсь заставить CH делать то, что он делать не предназначен?
Может движок типа RabbitMQ или Kafka решит твою проблему?!
X
каким образом?
НБ
Не придётся батчами отсылать результаты ивентов. Просто пихаешь в очередь и она отдаёт все данные кликхаусу потоком из очереди.
НБ
Xor
каким образом?
Мы таким образом реализовывали систему записи логов о перемещении юзера по карте. Все работает на ура пока что :)
X
а каким образом CH её оттуда забирает? у меня как раз писалка и тормозит
X
по сути проблема выглядит вот так: https://gist.github.com/224294e4e781129102e3097e306c8c66
DT
Xor
доброго. у меня довольно специфичный кейс: в течении ~20 секунд прилетает порядка 900 ивентов, нужно каждый из них записать в CH и как можно быстрее отправить дальше. суть проблемы в том, что я не могу батчить запросы, а производительность при таком раскладе более чем удручающая :( можно ли что-то сделать или я пытаюсь заставить CH делать то, что он делать не предназначен?
buffer table engine, in-memory parts, compact parts
X
buffer table engine, in-memory parts, compact parts
buffer table выглядит очень интересно. спасибо, пойду пробовать
НБ
Xor
а каким образом CH её оттуда забирает? у меня как раз писалка и тормозит
В бдшке есть встроенная поддержка очередей. Просто задаёшь роуты к твоей очереди и указываешь нужный движок и оно будет писать в таблицу.
Подробнее в документации по движкам найдёшь.
Подробнее в документации по движкам найдёшь.
DT
Xor
buffer table выглядит очень интересно. спасибо, пойду пробовать
Но вообще они на любителя и желательно ими не пользоваться в новых версиях кх от них скорее будут отказываться в пользу in-memory партов
X
В бдшке есть встроенная поддержка очередей. Просто задаёшь роуты к твоей очереди и указываешь нужный движок и оно будет писать в таблицу.
Подробнее в документации по движкам найдёшь.
Подробнее в документации по движкам найдёшь.
тут косяк получается в том, что мне нужна гарантированная запись (БД должна сказать, что таки да записано и я отправляю пакет дальше), а в случае с очередью мне никто не скажет дошли данные или нет