?

Log in

No account? Create an account
Он всегда был не прочь подкрепиться. Кроме того, он был поэт. [SPL] [home page] Below are the 10 most recent journal entries recorded in the "inv2004" journal:

[<< Previous 10 entries]

September 20th, 2017
07:59 pm

[Link]

microbenchmarks: Rust vs KDB+ (Q)
Как-то давно натыкался тут на микробенчмарки разных Rust, Haskell и т.д. Но тогда они показались мне абсолютно неадекватными, типа измерение как быстро сможет раздуть в памяти вектор, когда как, на мой взгляд, можно было бы взять не сильно сложные, но гораздо ближе к реальности тесты.

Дело было вечером ... поставил на ноут Rust, и конечно сравниваю его с Q (в домашней 32bit версии).
- Почему именно их? - Потому, что Q у нас в проде, а Rust приобретает репутацию того, что может когда-то взлететит в энтерпрайсе для low-latency и производидтельных задач.

Понятное дело, что сейчас это сравнение интерпретируемого и компилируемого, но Q всегда выдают как что-то запредельно быстрое, с другой стороны на Rust не сильно сложнее писать подобные конструкции через итераторы. В перспективе конечно хорошо бы добавить C и Java в тест. Да и сами тесты немного расширить, только пока не знаю чем.

запушил на гитхаб:
https://github.com/inv2004/rust_vectors

Из того, что было лень пилить - median, оно явно далеко от отпимального на Rust'е.

время в ms

rust-q32

(3 comments | Leave a comment)

July 6th, 2017
12:30 am

[Link]

Всё по кругу. 2/3. ClickHouse / kdb
На работе услышал о новинке - ClickHouse. Ну разумеется несколько бенчмарков, и, кажется, удалось посмотреть на kdb как бы со стороны.

Хотя CH и не кажется чем-то сверхъестественным, и даже не написан на тайном языке Q/K, но с другой стороны поразило, как _современный_подход_ и _адекватная_архитектура_ с ходу решилa большинство преблем, которые kdb, окопавшись в своём мире, имела много лет, и только около года назад, городя конструкции из говна и палок, пытается изобразить что он не просто awk, только векторный.

С другой стороны я привык к kdb, и думаю в в глубине души был бы даже рад, если бы кто в меня вернул веру что kdb + q побеждают всех :)

1) Многопоточность.
KDB однопоточный (кроме чтения с дисков). Это выдаётся как некое "мы и так лучше", но по факту это значит, что пользователи на гейте стояли в очереди и ожидают пока обслужат. Целый гигатский сервер стоит и не занят чем-то особо важным, пока пользовательский запрос не пробежит по ветке процессов и не вернётся назад. Недавно это немного поменяли - запросы хотя бы и уходят в систему асинхронно, но по-прежнему каждый инстанс обрабатывает только по одному из очереди. Ладно, kdb придуман так, что всё должно быть настолько быстро, что якобы и один поток не проблема, но всё не может быть быстро - есть чтение с дисков, есть агрегации на промежуточных процессах. Многократным дублированием этого всего изображается некая как бы многопоточность.

В CH всё кажется уже готово - если есть свободные нитки, то они используются и для чтения, и для распределённой агрегации.

2) Многопоточность.
Если позволять кому-то в kdb залазить своими руками, то всегда надо быть готовым к тому, что кто-то либо отъест всю память (без -w), но скорее он просто заблокирует надолго процесс, и все будут ждать пока он не отвалится по тайм-ауту через много минут.

В CH такой проблемы нет. Да, юзер забьёт одну нитку, другой - вторую, но, если это не какие-то рвущиеся в дверь наркоманы, то система останется работоспособной для всех остальных. В CH даже появятся пулы ресурсов: CPU, disk, net

3) Индексация.
У kdb для диска один индекс `p# - это по сути группировка блоками по этом индексу + сохранние указателя на первый элемент блока. Да, в некоторые случаях это ok, но в реальности случаи сложнее. Как только начинается выборка за пределами индексированного поля, то всё уже не так радостно.

В CH есть составные индексы. Можно не только по одному полю выбирать нормально. С гранулярностью, т.е. и места особо не занимают.

4) Q in-mem.
Вот это интересно думаю. Когда ты пишешь на K, то это по сути обработка простых структур в памяти. Можно сделать довольно эффективно, но для чтения с диска такое не пойдёт - с диска только через select на Q. Разумеется писать разные запросы для памяти и диска никто не будет. Kdb ничего оптимизировать не будет. Итого, какая-нибудь аггрегирующая функция, да хоть last, с группировкой "select last v by k from t", сначала сгенерит для каждого ключа отдельный вектор, покопирует туда соответсвующие группировке данные, а потом выберет последний элемент. Я не знаю как оно там совсем внутри работает (а кто знает?), но select с диска при этом умудряется быстрее отработать. Но именно скорость in-mem продаётся как что-то сверхъестественное. Я с этим не спорю, если писать на моём любимом K или хотя бы изображать это на Q и из памяти- то да, быстро будет, но так писать никто не будет.

В CH есть тип таблицы Memory, потенциально это могло бы накрыть in-mem в kdb, но тут не поддерживаются никакие индексы, да и в целом решение с кешом кажется удобнее. Помимо дискового, в CH есть свой кеш, что можно использовать как in-mem, но только он LVC и нет механизма принудительно там данные удерживать. Но, судя по гугл-группe, какие-то скрытые kdb'шники в группе кликхауса хотят того же. + к этому стоит добавить, что если это простая выборка _только_ по индексам, то kdb выдаёт её за время близкое к нулю, CH такое время не показывает, но причины не искал: может быть обработка запроса, может гранулярность индекса (в kdb `g# в памяти храние все индексы для ключа), а может передача в клиент.

Опять же в kdb - память для данных бывало и заканчивалась, вместе с работой приложения и S1 по сути. С кешом такого произойти не может - да, может замедлиться.

5) Языки. Статическая/динамическая типизация.
Тут уже всё написал thedeemon, я тогда ещё был в жж - http://thedeemon.livejournal.com/54732.html
Да, писать на K и даже на Q удобно и быстро, но оно никуда не развивается. Было и такое, что какие-то данные на входе оборчивались в списки списков, при этом эти данные и принимались и как-то умудрялись обработаться, при этом ломая существующие структуры и частично теряясь. Ес-но в статике такого не было бы. Я бы оставил диалект Q только как какую-то надстройку для пользователей, вроде как и сделал maxim. Видимо надо ещё раз попытаться имитировать K в нормальной системе типов. Так как в основном реальный код на K/Q не является только красивым однострочником, а однострочник можно и переписать на чём-то достаточно функциональном - ML, Haskell, ?Rust?

Но о языках видимо в третьей части, которую ещё не придумал.

(3 comments | Leave a comment)

July 5th, 2017
11:47 pm

[Link]

Всё по кругу. 1/3
Думаю стоит добавить краткое описание от предыдущего поста до этого, т.е. пару пропущенных лет.

Три года назад ушёл в энтерпрайс на Q/kdb, казалось что писать что-то своё особо и не нужно, а даже если и писать, то всё равно выйдет что-то типа K. На фоне этого всё вне-рабочее программирование свелось к нулю, а рабочее - оно понятно - не особо интересно. Как следствие, велосипед заменил компьютер, а ФБ заменил ЖЖ. Два года - сон крепкий, голова - без лишних мыслей.

Но тут опять ударился в программирование и базы данных, тут во второй части.

(Leave a comment)

July 6th, 2015
05:44 pm

[Link]

Вот я и убедился, что регистратор нужен :)
Еду значит в воскресенье на дачу, пробок никаких, но поток чуть замедляется до 70-80кмч. Тут же, мгновенно, сзади появляется обочечник на 120кмч, я его торможу, он метается туда сюда но не пролазит, после чего, лезет во встречный поток и оттуда подрезает и бьёт правой частью по моему крылу. Я торможу. Он проезжает метров 150, а потом, чего я никак не ожидал, задним ходом возвращается и занимает положение как бы на полосе.

Ошибка #1: Регистратор.
Ошибка #2: Надо было мгновенно снимать как он меняет положение.
Ошибка #3: Надо было сразу после ДТП тормозить свидетелей. (Свидетели могли бы конечно и сами затормозить)

(7 comments | Leave a comment)

June 8th, 2015
09:04 pm

[Link]

Об ограничениях при принудительной эвакуации автомобилей
Ожидают хаос на улицах, как пару лет назад.

(Leave a comment)

June 4th, 2015
11:04 am

[Link]

Enduro MTB
Уже долгое время думаю разнообразить велосипед вот таким: долго крутишь вверх, потом долго едешь вниз. Ну так сказать как замена горным лыжам зимой.

(Leave a comment)

June 3rd, 2015
01:25 pm

[Link]

Хроники AG Race Тарутино #5
Велосезон вроде бы начался недавно, а AG Race Tarutino проводит уже пятое мероприятие.


Перетерев о новинках велоиндустрии, стартуем.


Гонка была очень жаркой. Мчим первый круг вот такой группой.


ещё немного фотокCollapse )

(Leave a comment)

May 27th, 2015
10:31 pm

[Link]

Крылатское
Только сегодня оценил соединительные дорожки, которыми связали малое кольцо в крыле - можно закруглиться ещё на минуту для отдыха, например. Куда скинуться деньгами на это и подобные нововведения? :) .

Ещё думаю несколько трещин бы подмазать, не капитальным ремонтом, а ведь есть какой-то холодный асфальт, но опять же хз кто там главный.

Есть и немного и негатив, может провалы в памяти, но я не помню кирпичного здания, которое вплотную к треку на спуске.

(Leave a comment)

12:13 pm

[Link]

КОМПЬЮТЕРНЫЙ ВЕК
Оригинал взят у cpp2010 в КОМПЬЮТЕРНЫЙ ВЕК
Оригинал взят у jo_pa57 в КОМПЬЮТЕРНЫЙ ВЕК

Пособие начинающим блогерам:


(Leave a comment)

May 25th, 2015
08:40 pm

[Link]

Бытовой вопрос:
Как белоснежной велоформе вернуть белоснежность после Бунчихи?

После машинки она осталась похожей на что-то зрязно-пятнистое. Форма чёрно/белая - просто в отбеливатель макнуть - не вариант.

(Leave a comment)

[<< Previous 10 entries]

inv2004's Home Page Powered by LiveJournal.com