DC
проблема не в хранении
Size: a a a
2021 February 14
DC
проблема в операциях select / =
MM
у меня две операции: insert into users
и Select * from users where id = 123553446
где тут оверхеды по cpu?
и Select * from users where id = 123553446
где тут оверхеды по cpu?
MM
я пока не хочу зоопарк из БД и поэтому всё кладу в КХ. Если проект взлетит, переложу в мускул в innodb и сделаю транзакции.
MM
@den_crane , ты часто и многим помогаешь. Можешь сейчас тоже пояснить, что не так с массивами при селектах? Или может есть ссылка почитать/посмотреть?
D
да все ок, вряд ли у вас пользователей столько, что это на что-то повлияет.
просто гарантий не-вставки пользователя нет даже когда упал во время вставки.
просто гарантий не-вставки пользователя нет даже когда упал во время вставки.
S
@den_crane , ты часто и многим помогаешь. Можешь сейчас тоже пояснить, что не так с массивами при селектах? Или может есть ссылка почитать/посмотреть?
так объяснили же уже
overhead CPU у вас дикий будет
сравнение массива clickhouse и сравнение строки
строка будет в 10 раз быстрее
там не тупо "массив байт"
там массив "типизированных объектов" из которых типы надо для equal выводить в runtime
overhead CPU у вас дикий будет
сравнение массива clickhouse и сравнение строки
строка будет в 10 раз быстрее
там не тупо "массив байт"
там массив "типизированных объектов" из которых типы надо для equal выводить в runtime
MM
ИМХО, массив типизированных объектов не надо парсить, чтобы сравнить. достаточно сравнить сначала размер, а потом начать сравнивать по байтикам.
MM
хотя понял, проблему. там ведь может быть массив массив, масив других сложных типов...
S
хотя понял, проблему. там ведь может быть массив массив, масив других сложных типов...
в общем Массивы в ClickHouse как правильно заметили они для всяких вещей типа array* когда вам надо работать с элементами массивов
или для arrayJoin
или для arrayJoin
MM
со строками другая проблема будет: на терминале или в разных клиентах эти строки из последовательности байт будут отображаться очень причудливо. терминал попортят, например...
D
"как стелисть соломку с утра 101"
DC
@den_crane , ты часто и многим помогаешь. Можешь сейчас тоже пояснить, что не так с массивами при селектах? Или может есть ссылка почитать/посмотреть?
DC
со строками другая проблема будет: на терминале или в разных клиентах эти строки из последовательности байт будут отображаться очень причудливо. терминал попортят, например...
эээ?? hex() ?
DC
select hex(S) from pass where i = 42;
┌─hex(S)───────────────┐
│ 002A547EA8D2FC27517B │
└──────────────────────┘
┌─hex(S)───────────────┐
│ 002A547EA8D2FC27517B │
└──────────────────────┘
MM
я тут почитал... для хранения хэша пароля вполне сгодится uint256
K
Хмм, соотношение qps подозрительно похоже на соотношение compressed
DC
Хмм, соотношение qps подозрительно похоже на соотношение compressed
нет, проблема в uncompressed
K
со строками другая проблема будет: на терминале или в разных клиентах эти строки из последовательности байт будут отображаться очень причудливо. терминал попортят, например...
Можно в таблице делать ALIAS для вывода в любом удобном виде — хоть массивы из строк строить, хоть hex
K
главное не сравнивать потом по ним