Если чтоб просто сделать таблицу с тестами - норм, но вы сравниваете разное и получаете, внезапно, разные результаты. У вас сериализация ровно такая же как и в любой другой реализации нативного протокола на Go, так что особой разницы +- вы не увидите. Есть оверхед на интерфейс совместимости с database/sql, но в плане записи он не сильно критичен, а на чтение оно и не особо нужно в перфомансе (за очень редким исключением). Те в плане бенчмарков можно поставить точку. В том что у вас есть описание нативного формата это огромный плюс для всех, в том числе и для реализции новых драйверов (не все хотят код КХ для этого читать). Думаю, если она повится в каком-то читабельном виде, то ее можно будет поместить на https://clickhouse.com/. Если нужна помощь с техписами, то, при наличии доки, ее можно будет тут найти, и ее помогут превратить в читабельный формат.
Дальше нужно чтоб API у библиотеки был юзабельным, с этим нужно работать, сейчас у вас просто кусок кода который позволяет создать блок с данными и позволяет его пушнуть на сервер. Этим не удобно пользоваться, у database/sql отличный интерфейс, но реализация сильно так себе, можно его и принять за основу. Хороший пример pgx (https://github.com/jackc/pgx)
Я делаю бенчмарки на оверхед клиента. У нас получилось свести его в ноль благодаря оптимальной архитектуре. У меня сериализация не такая же как и в любой другой реализации нативного протокола на Go, так как там используется прямая работа с памятью, как и в Rust. Если бы вы посмотрели код, для вас это было бы очевидно. На микробенчмарках она выигрывает в 60-100 раз, на практике, конечно, все упирается в другое. По поводу эргономики: не уверен, что блочная вставка через оф. клиент и через ch отличается, тут скорее удобнее с ch работать (на мой вкус).
Обсуждают сегодня