rust делает билд за 30 сек, судя по видео. А транспиляцию за 1:40 сек примерно.
Осталось понять сколько делает все компилятор на С на такой же машине. Мне тоже интересно сравнить.
Где-то помню читал, что на валидации почтового ящика должно быть одно правило — наличие @
А основная валидация происходит открытием ссылки активации из почты.
Пора делать музей аналоговой эпохи, чтоб можно было любой экспонат проиграть на любом представленном плеере. А то толку от частных коллекций таких примерно ноль. Я когда-то задумывался восстановить магнитофон, накупить кассет. Но дело не дошло даже до включения магнитофона. Зачем? Когда в цифре всё есть и довольно просто включается и «перематывается».
Go как раз предназначен для обработки миллионов строк. Не надо стесняться его применять для этого. За 26 секунд обработать результат работы целых суток — по-моему хорошее соотношение, которое оставляет задел на стократный рост. Хотя на С++ думаю в 2 раза быстрей было бы по скорости обработки. Но есть ещё такой параметр как время на разработку, ту же компиляцию, отладку и поддержку. И тут Go для меня выигрывает. Плюс приятно в проекте иметь один язык — и для сервера и для скриптов обработки.
Если бы я писал обработку этого запроса на PHP, к примеру, я бы тоже постарался уменьшить число строк с помощью БД. Там цикл на сто тысяч уже может показаться «вечным» и оптимизировать что-то как здесь — не представляется даже возможным.
Если делать GROUP BY campaignID — как это поможет посчитать кол-во по bannerID или siteID? Делать потом ещё 10 запросов?
Плюс GROUP BY на MySQL не такой шустрый, например
SELECT campaignID, COUNT(*) FROM hit_20180507 GROUP BY campaignID
Занимает 8,6 секунд на этом сервере на прогретых данных. А группировка по двум полям уже 12,9 секунд.
36 секунд я путем манипуляций превратил в 27 секунд. И судя по профилировщику — там можно выжать ещё пару секунд, убрав ненужные конвертации через строку. Данные находятся на localhost-сервере, 5 Гб на диске SSD, ещё и в кеше. Думаю сама передача занимает секунд 10.
Проверил — оставил цикл
for rows.Next() {
c++
}
итог — 11.9 секунд. Остальное время тратится на доступ к хеш-мапам, ну и конечно же на Scan.
Я же не описывал весь движок — статья не про это. Статистика за сегодня из сервера сбрасывается раз в минуту в базу. Плюс фронт-енд может запросить напрямую у сервера json с актуальными полями по любому объекту. Так что у нас полный риалтайм касаемо сегодняшних данных.
Но допустим вам надо вычесть из статистики фрод-показы и актуализировать вчерашние данные. Как тогда быть?
Кликхаус будет следующий объект для тестов. Сейчас вставляю параллельно в 2 базы — пока длится процесс перехода. А какой библиотекой вы вычитываете в Go миллионы строк?
Естественно, можно и таким путем пойти.
Для примера я оставил только 5 объектов. Их на самом деле больше. Есть ещё связки типа баннер-кампания. Есть связки через дополнительные поля, которые в других таблицах. В итоге если делать 10 запросов GROUP BY подряд с INSERT'ом в таблицы статистики — мы нагрузим MySQL, залочим таблицы. Плюс есть ещё особая логика подсчета дополнительных параметров — я её выбросил для чистоты експеримента. Ну и в планах делать антифрод по прошествии суток — там уже на SQL никак не провести анализ — нужны деревья.
Язык Go, как мне кажется, больше подходит для работы с большими наборами данных. Проблема в универсальных драйверах БД, которые стремясь угодить программисту, дают оверхед на конвертацию пришедшего из базы туда-сюда-обратно. Вот я и выяснил для себя какая связка дает большую скорость, далее, видимо, закодирую её в каких-то функциях, чтобы перевести остальную часть проекта на более производительные SELECT-ы. Ну и решил поделиться с сообществом, ибо такие задачи для Go должны возникать в любом серьезном проекте.
Протестировал. Отписал в статье результат. Если кратко, то пилюли, которая сразу всем и всё улучшает не получилось, как я и предполагал по описанию из их README.
Зависит от задачи всё. В моем примере — reflect был скрыт под капотом драйвера. И, возможно, на выборке SELECT 20-ти записей — его оверхед не заметен вообще никак на фоне миллисекунд выполнения запроса.
Но кешировать Reflect — вполне здравая идея. Это уже относится к задаче оптимизации работы с ним, которая появляется от того, что всё-таки там есть что ускорять. Я сам его использовал раз в месте которое выполнялось один раз при инициализации. Там можно не задумываться об оптимизациях. Но вот если в цикле на миллион шагов — тут уже я бы подумал про его применение.
Вот драйвер я никак не ускорял, признаюсь честно. Исследовал внутренности, пробовал разные протоколы и типы данных — это да. Цель была проста: получить как можно более быструю скорость обработки SELECT c целочисленными полями. Её и достигал.
Осталось понять сколько делает все компилятор на С на такой же машине. Мне тоже интересно сравнить.
А основная валидация происходит открытием ссылки активации из почты.
Не стой когда можно сидеть. Не сиди, когда можно лежать.
Мне кажется из той же серии, что и анализ ДНК
У Фокала(Electra sw 1000s) в мануале пишут, что лучшая позиция для их саба — угол. Он дает наиболее линейный АЧХ
Если бы я писал обработку этого запроса на PHP, к примеру, я бы тоже постарался уменьшить число строк с помощью БД. Там цикл на сто тысяч уже может показаться «вечным» и оптимизировать что-то как здесь — не представляется даже возможным.
Плюс GROUP BY на MySQL не такой шустрый, например
SELECT campaignID, COUNT(*) FROM hit_20180507 GROUP BY campaignID
Занимает 8,6 секунд на этом сервере на прогретых данных. А группировка по двум полям уже 12,9 секунд.
36 секунд я путем манипуляций превратил в 27 секунд. И судя по профилировщику — там можно выжать ещё пару секунд, убрав ненужные конвертации через строку. Данные находятся на localhost-сервере, 5 Гб на диске SSD, ещё и в кеше. Думаю сама передача занимает секунд 10.
Проверил — оставил цикл
for rows.Next() {
c++
}
итог — 11.9 секунд. Остальное время тратится на доступ к хеш-мапам, ну и конечно же на Scan.
Но допустим вам надо вычесть из статистики фрод-показы и актуализировать вчерашние данные. Как тогда быть?
Для примера я оставил только 5 объектов. Их на самом деле больше. Есть ещё связки типа баннер-кампания. Есть связки через дополнительные поля, которые в других таблицах. В итоге если делать 10 запросов GROUP BY подряд с INSERT'ом в таблицы статистики — мы нагрузим MySQL, залочим таблицы. Плюс есть ещё особая логика подсчета дополнительных параметров — я её выбросил для чистоты експеримента. Ну и в планах делать антифрод по прошествии суток — там уже на SQL никак не провести анализ — нужны деревья.
Язык Go, как мне кажется, больше подходит для работы с большими наборами данных. Проблема в универсальных драйверах БД, которые стремясь угодить программисту, дают оверхед на конвертацию пришедшего из базы туда-сюда-обратно. Вот я и выяснил для себя какая связка дает большую скорость, далее, видимо, закодирую её в каких-то функциях, чтобы перевести остальную часть проекта на более производительные SELECT-ы. Ну и решил поделиться с сообществом, ибо такие задачи для Go должны возникать в любом серьезном проекте.
Но кешировать Reflect — вполне здравая идея. Это уже относится к задаче оптимизации работы с ним, которая появляется от того, что всё-таки там есть что ускорять. Я сам его использовал раз в месте которое выполнялось один раз при инициализации. Там можно не задумываться об оптимизациях. Но вот если в цикле на миллион шагов — тут уже я бы подумал про его применение.