✙rozho)))k✙🇺🇦

2021-07-19 09:00:00 Оверинжиниринг на пустом месте. DynamoDB, Kinesis, Spark, бигдата.

Ранее я рассказывал про то как можно бросить стартап в болото, занявшись построением совершенно ненужных архитектур. Сегодня расскажу и еще одном таком безумстве.

У нас была задача — рассылать пользователям напоминания о событиях. Человек приходил на сайт, регистрировался, выбирал временной слот. За день до события нужно было ему присылать письмо-напоминание. Вот такая простая задача. Шёл 2015 год.

Что мы делаем? Ну, база данных у нас DynamoDB. Схему тогда спроектировали таким образом, что нельзя было просто так получить информацию о временных слотах одним запросом. Я уже не помню, почему не сделали нормальную схему но тогда это был не вариант. Так же, по причине которую я не помню, мы не использовали GSI, хотя они были у нас в других таблицах. Решили сделать ход конём — стрим изменений таблицы мы подписали на Kinesis, и сделали процессор, который брал события из стрима, смотрел на таймслот и писал эту информацию в виде json-файла на S3 в папку, соответствующую дате события. Таким образом, по мере создания события у нас на S3 появлялись соответствующие записи. Если пользователь отменял — то запись мы естественно удаляли.

Итак, у нас была Dynamo таблица, стрим с таблицы, Kinesis и S3 с JSON-файлами партицированными (разоложенными) по папочкам.

Оставался один вопрос — как именно теперь доставать нужные файлы и получать собственно емейлы пользователей.

На сцену выходит бигдата! Я взял Spark — ведь он умеет читать JSON и даже делать SQL-запросы поверх него! Я могу просто указать спарку нужный S3 бакет и сказать select name, email from bookings where date = "...." после чего дернуть другой микросервис чтобы тот послал письма. Так и сделал, и самое удивительное, что это заработало! Но была проблема: спарк нужно было запускать каким-то образом по расписанию. AWS тогда еще не изобрел cron, кубернетиса у нас не было, поэтому кто-то нашел скедулер, который запускал джобы на ECS. На вход он принимал JSON дефиниции джобы, можно было указывать крон и по этому крону он запускал контейнеры. Вроде все круто!

Но нашлась одна неприятность. Дело в том, что тогда Spark не так-то просто подружить с S3. Из коробки это не работало, нужно было собирать свой дистрибутив спарка с нужными библиотеками от AWS. Эту ценную информацию я почерпнул из статьи в блоге Grammarly, которую сейчас уже даже не смог нагуглить. В итоге я форкаю спарк, добавляю свои зависимости, делаю на это CI/CD.

Делаю CI/CD на скедулер, на джоб дефинишены, пишу на это всё CFN-шаблоны, разворачиваю это на дев и qa короче как-то оно начинает работать, фух.

На всё про всё я потратил наверное месяц времени? Может меньше, дело было давно, уже не помню.

Сейчас бы я сделал эту задачу за час. Таблица в постгресе и крон-джоба которая раз в час пробегается и рассылает что надо.

Вместо этого мы сделали крутой пайплайн из динамо который пишет в кинезис который пишет в s3 который читает спарк который запускается по крону с помощью скала-поделки развернутой на двух машинах. И это я еще не рассказал про микросервисы. Целый сука космолёт вместо одного SQL-запроса! В те годы мне это казалось очень весёлым и интересным, но щас я ловлю лютый кринж от тех воспоминаний.

До продакшена это так и не доехало и всю эту систему выбросили через пол-года.

"Бигдата" крутится—лавеха мутится.

#работа #кулстори
permalink | задонатить Открыть/Комментировать

2021-07-14 09:00:10 Спасибо всем, кто пришёл на акцию протеста против Дія Сіті! Следующий митинг пройдет в четверг 15го числа в 9 утра там же!

Я насчитал 60-70 людей. Cчитаю что это достойный результат. Митинговали с 9 до 11. Было довольно много журналистов, давали интервью налево и направо. Думаю программу-минимум мы выполнили. Обошлось без провокаций и всякого непонятного движа, всё чинно и порядочно.

Если у вас не получилось прийти или вы сомневались — в этот четверг 15го числа в 9:00 под Верховной Радой будет проходить еще одна акция протеста которую организовывает Гильдия ІТ-специалистов @itguildukraine. Так же акция будет проходить в Харькове под ХОГА. Детали: https://dou.ua/forums/topic/34084/

Я буду, приходите!

p.s.: Для тех кто не в курсе чем плох закон 4303: есть длиннейшее заключение главного юридического управления согласно которому он нарушает кучу статей Конституции Украины. Рекомендую к изучению, поорать над джуниор юристами которые нагородили там казус на казусе. Открыть/Комментировать

2021-07-09 09:00:11 Митинг против Дія Сіті и первый Рожок митап

Протест продолжается! В этот вторник, 13го июля в 9 утра, приглашаю всех под Верховную Раду Украины на мирное собрание против законопроектов 4303 и 5376 известных под названием Дія Сіті.

Это исторический момент! Никогда еще в этой стране не было митинга ІТ-специалистов, в основном потому что у нас всё было хорошо. Но очевидно что так не могло продолжаться бесконечно, и власть в итоге очень близка к тому чтобы наложить грязную лапу на одвічну годівницю українського народу.

Наши требования: ветировать или отправить закон на доработку, инициировать нормальные трудовые реформы.

На митинге будут: мегафон, плакаты, спикеры (ваш покорный слуга), журналисты. Для тех кому сложно социализироваться я возьму алиас и две колоды mtg.

13 июля, вторник, 9 утра, Верховная Рада.

Почему 9 утра? Потому что с 9 до 10 на "работу" приходят депутаты, большинство митингов проводится именно в это время.

Телеграм чат с координацией: @StopDiiaCity
Обсуждение на ДОУ: https://dou.ua/forums/topic/34057/
Событие на фейсбуке: https://www.facebook.com/events/164321758975969/

Жду всех! Репост, релайк, рекоммент, приходите сами, приводите друзей! Открыть/Комментировать

2021-07-08 09:00:00 Настольные игры

Встречался недавно с коллегами в кабачке, культурно выпивали. Говорили о всяком разном, в том числе задели настолки, типа а не собраться ли нам и не поиграть в ужас аркхэма.

В детстве я очень-очень любил настольные игры. И классические шахматы, и что-то более современное. Я даже придумывал свои—рисовал карты, делал фигурки, придумывал правила. Всё это было от отсутствия компьютера. Появился компьютер—интерес к картону пропал.

Сейчас у меня изменилось отношение к настолкам.

В любой игре есть два элемента—соревновательный и социальный. С одной стороны люди соревнуются в умении думать, а с другой—через игру взаимодействуют друг с другом.

Люди играют в игры в компаниях как раз ради второго аспекта—социального. Игра в данном случае выступает поводом для общения и социальной смазкой, вроде алкоголя. В настольные игры могут играть незнакомые или малознакомые люди, таким образом обретая связь, которая потом позволит легче социализироваться вне игры.

Если в компании попадется настолко-котлета, которая хорошо знает правила и будет всех нагибать, то вряд ли это понравится людям—никто не любит играть с неравным соперником потому что это неинтересно.

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

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

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

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

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

А какие ваши любимые настолочки? Знаю что среди ІТ-специалистов много любителей. Расскажите в комментариях!

P.S.: еще в игры играют когда нужно потратить время, например в поезде в карты или на базаре в нарды пока покупателей нет. Но смартфоны отлично решили эту проблему, как и проблему необходимости общаться с попутчиками.

#лайфстайл
permalink | задонатить Открыть/Комментировать

2021-07-06 09:00:00 Working class hero

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

Занятие это не очень интеллектуальное. По сути человек превращается в биоробота и делает руками то, что могло бы быть реализовано более совершенными технологиями. Я спросил не поехала ли кукуха у мадам от такой деятельности, на что она ответила—"конечно едет, 12 часов одно и то же делаешь". Собственно поэтому она уже не работает, вместо этого получая ренту с двух квартир доставшихся по наследству, а свободное время посвящает сну и кошкам. Коренная киевлянка-аристократка, учитесь.

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

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

Поэтому люди вынуждены совершать бессмысленные повторяющиеся действия с утра до вечера. В этом есть чудовищная несправедливость, но мы не будем углубляться в левые философствования.

Кто-то из энтерпрайз сектора сейчас может пожаловаться что ему приходится кодировать повторяющиеся процессы. Ну так—по крайней мере во власти разработчика находится автоматизация и совершенствование собственных инструментов. Можно написать фреймворк для форм, можно поговорить с бизнес-аналитиком на предмет адекватности требований, можно перекинуть работу джуну, можно поменять работу в конце-концов! У программиста всегда есть возможность приложить творческое начало и сделать даже самую скучную работу нескучной.

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

#кулстори
permalink | задонатить Открыть/Комментировать

2021-06-25 09:00:00 Боже, джаву храни!

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

У меня есть несколько Ruby приложений которые уже давно живут в продакшене. Версия ruby, которую я использовал, 2.5, перестала поддерживаться, и всех попросили переехать на 2.7. Однако сделать это было не так просто. Бампнув версию и попытавшись запустить я получил кучу ошибок. Я отложил это дело до лучших дней и недавно в приступе прокрастинации все-таки пофиксил что там ругалось и завел их на новой версии. Но, это был бамп минорной версии.

То ли дело Java. Обновив библиотеку Sentry на одном з проектов после деплоя я увидел что она по какой-то причине не захотела заводиться на 8-ой JRE, хотя в доках написано что 8-ая джава поддерживается. Как-то так получилось что разрабатывал я на 11 (с 1.8 source compatibility), а в продакшн заливал докер имедж собранный с 8. Не спрашивайте как, сам удивился.

Так вот, локально все работало, а на проде сломалось. Я решил обновить джаву на проде до 11. Но оказалось, что openjdk не собирают alpine имеджей для 11 джавы. Их вообще почти ни для чего не собирают. Зато для 17-ой alpine-имедж был. Ну я и взял его, чисто наудачу. При том что 17-ая версия еще официально не вышла, а sdkman не содержит даже бинарников 17-ой.

Переключил CI и сборку на 17, тесты пробежали, имедж собрался, я его задеплоил—вуаля—всё работает!

Это при том что я прыгнул с 8-ой версии (которой уже 7 лет) на 17-ю (которая еще даже официально не вышла) и абсолютно ничего не менял в кодобазе.

Вот чему у JVM стоит поучиться, так это поддержке обратной совместимости. Приложение у меня Spring Boot рест сервис.

А как у вас обстоят дела с обновлением рантаймов?

#инструменты
permalink | задонатить Открыть/Комментировать

2021-06-23 09:00:00 Кассовый разрыв

В определении слова "бизнес" написано что это деятельность, целью которой является получение прибыли.

Пока работаешь за зарплату, то этот факт воспринимается оторванно от реальности. Если ты заболел, плохо работал, встрял в неудачный проект, залипал, то в худшем случае босс пожурит тебя или погрозит пальчиком. Независимо от результата работы денежка все равно капнет на счет.

Совсем другое дело если ты успешный кабанчик-предприниматель или молча гребешь в одиночку. Тут любая деятельность должна приносить деньги иначе швах. Заболел — минус деньги. Залипал в соцсети — минус деньги. Пошел в обед прогуляться выпить чаю — минус деньги. Я конечно говорю о ремесленничестве, когда есть прямая связь между жопочасами и заработком.

Любая работа должна быть оплачена, иначе это работа себе в минус. Хочешь порефакторить проект потому что накопился техдолг, но не смог продать это клиенту? Или думай как продать, или продолжай копить техдолг, или работай в минус.

Но сделать работу мало. Нужно еще получить свои деньги. Пока деньги не пришли в банк—задача не закончена.

Кассовый разрыв возникает когда работа уже вроде как сдана, а бабос еще не получен. В случае ритейлеров всяких и прочих овощебаз такое регулируется контрактами, например ты можешь поставить в АТБ тонну помидор, но заплатят тебе аж через 2 месяца, а ты уже должен государству ПДВ за эту продажу. В разработке всё не так жёстко, обычно в контракте указана цифра NET 20, это значит что клиент обязуется заплатить вам в течение 20 рабочих дней после приёма работы.

Когда у нас с партнёрами была шлюпка, то мы позволяли себе создавать неприлично длинные кассовые разрывы — по несколько месяцев, а потом и того больше. Почему так происходило? Причин две. Первая — у нас была очень хорошая финансовая подушка. Со своей зарплаты на фуллтайме я мог обеспечивать почти всю контору. Вторая — как-то так получалось, что деятельность, которую мы разводили, не всегда в результате приносила лаве. Вместо того, чтобы фокусироваться на извлечении максимальной прибыли минимальными усилиями, пушить клиента чтобы сразу же платил деньги мы жили в довольно расслабленном режиме, за что потом и поплатились — клиент стал неприбыльным, людей держать не было возможности, новых продаж не делали. Зафиксировали убытки и разбежались.

Есть мнение что пока человек живет в зоне комфорта, получает зарплату, то ему сложно ворваться в свое дело, потому что нету стимула действительно фокусироваться на успехе. Могу сказать что это точно про меня. Как только кошелёк начал показывать дно, я засуетился и начал работать над тем чтобы кассовые разрывы сокращать. В этом месяце мы получили деньги за проект, сделанный еще в прошлом октябре. У меня есть практически готовый пет проект и один клиент готовый платить, но я никак не могу прикрутить админку и платежи. Потому что в зоне комфорта.

Раньше я работал постоянно над какими-то небольшими задачами—поправить баг, сделать маленькую фичу. Имея основной приток денег с парттайм работы, я не особо беспокоился об своевременном выставлении счетов и позволял работать 2 месяца грубо говоря бесплатно, получая деньги с сильной задержкой.

Сейчас я изменил подход. Сделал задачу—тут же занес в список и пушу клиента чтобы оплачивал счет. Разрыв потихоньку сокращается. Любая деятельность должна быть навправлена на получение прибыли. Иначе это не бизнес а благотворительность.

#работа #лайфстайл
permalink | задонатить Открыть/Комментировать

2021-06-18 12:15:26 Как оверсинкинг и перфекционизм мешают мне заканчивать проекты

Перфекционизм—ближайший друг прокрастинации. Я часто страдаю желанием сделать все "как надо", но неожиданные препяствия, возникающие на этапе делания как надо а не как попало часто тормозят работу, убивают мотивацию и приводят к затягиванию сроков и перерасходу бюджета.

Рассмотрим мой недавний микропроект с ClickHouse. Задача была довольно простая—взять данные из одного места и положить в другое. Всё. Что может быть проще? После завершения PoC клиент дал добро на продакшн-реализацию и я пошёл копать.

Началось всё с базы. Я же девопс, поэтому негоже создавать ресурсы вручную. Все должно разворачиваться с помощью терраформа. В качестве managed решения для ClickHouse было выбрано облако Яндекса. В этот момент я вспомнил, что нужно делать синхронизацию через очередь, потому что может быть такое что сервер перезапустится, умрет, получит таймаут. Все должно быть надежно, поэтому давайте вначале запушим в очередь сообщение с нужным нам объектом, а воркеры будут обрабатывать эту очередь и писать данные. Если вдруг случится таймаут, то сообщение останется на месте и будет обработано позже. Никто не забыт, ничто не забыто.

Яндекс предоставляет свой SQS-совместимый сервис для очередей. Я подумал—раз мы уже делаем кусочек инфры в Яндексе, то может и очередь туда засунем? Сказано-сделано, давай изучать как сконфигурировать очередь через терраформ. Вроде там всё просто, давай делать. Но тут возникает проблема—состояние терраформа надо где-то хранить! На своих других проектах для этого я использовал S3, но тут получается как-то тупо—стейт на S3 а облако в другом месте. У Яндекса ведь есть свой S3! Может быть там развернуть? Я застрял на этой мысли. В итоге попрокрастинировав, я решил для стейта взять terraform cloud. Зарегался там, всё как положено.

Пошел писать очереди. Вроде написал вроде все ок—делаю apply—а не работает! Еще несколько часов трачу на выяснение что не так с моей конфигурацией, ищу примеры в интернете. Ничего не помогает, забиваю и ложусь спать. Перед сном приходит идея—а может ну его, очередь в яндексе? Ведь у меня в приложении уже есть обработка других вещей через AWS SQS и она отлично работает. Потом, для интеграции используется Spring Boot Cloud который позволяет сделать чтение SQS одной аннотацией. Если я хочу делать яндексовую очередь—хоть она и SQS-совместима, надо будет как-то по-другому передавать ключи. Учитывая проблемы с разворачиванием очереди на яндексе через терраформ лучше просто завести еще одну очередь на амазоне и не парить себе мозг.

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

В итоге задача съела в 3 раза больше временного бюджета чем я думал и на неделю затянула релиз. А все потому что я тупил как же мне сохранять стейт, как же мне делать очередь и стремился делать "по-правильному" вместо того чтобы пойти проторенным путём. Вручную это все конфигурится буквально за минуту.

Это один маленький пример, как ловко я умею затягивать проекты. Выбирать технологии, возиться с какой-то ерундой, вместо того чтобы просто взять и сделать. В конце-концов можно было даже без терраформа обойтись и поднять все вручную и уйти в закат. Но это не наш путь.

#инструменты #кулстори
permalink | задонатить Открыть/Комментировать

2021-06-16 09:00:01 ClickHouse. Нюансы

Вообще это очень трендовая база. На хайлоад++ и других конференциях вы можете посмотреть множество докладов посвященных ClickHouse. На хабре куча статей. Материалов очень много. Вся эта движуха прошла мимо меня потому что я предпочитаю использовать проверенные инструменты до последнего. Ну и хайлоад++ не посещаю.

После PoC я прикинул, что нужно сделать для синхронизации основного хранилища в ClickHouse, и приступил к доработке продакшн-решения.

Неожиданность подстерегала меня в самом начале. Сущности которые хранятся у меня в основной таблице могут меняться. Соответственно, мне нужно было обновлять их и в ClickHouse. Первая задача—растыкать везде, где меняется эта сущность, вызов синхронизации. Вторая—собственно обновлять данные. Оказалось, что ClickHouse очень хорошо умеет записывать данные. Но не очень хорошо умеет изменять и удалять .

Пришлось засесть за документацию и разобраться как это работает. Оказывается для каждой таблицы можно выбирать свой "движок", они есть разные и для каждой задачи можно подобрать самый подходящий вариант. Конкретно для дедупликации данных есть ReplacingMergeTree, это структура которая в фоне удаляет записи с одинаковым первичным ключом. То есть вы просто два раза инсертите одну и ту же запись и когда таблица будет оптимизироваться, то она уберет старые записи. Проблема в том, что непонятно когда это произойдет, а это значит, что в отчетах могут выводиться неверные данные. Для того чтобы попросить ClickHouse брать во внимание только нужные строки, используется ключевое слово final. Естественно это замедляет выполнение запросов, потому что базе нужно на ходу выбросить из результата все лишнее. Пока что все работает достаточно быстро, посмотрим как оно будет дальше. Данных у меня не терабайты, поэтому думаю что все будет ок.

Вторая штука была уже приятной неожиданностью—ClickHouse умеет на ходу проксировать запросы к куче источников данных, в том числе mysql. То есть ему можно сказать: сделай мне таблицу из вот этого конекшена к mysql. Таким образом, для части таблиц с небольшим объемом (десятки тысяч строк) мне не нужно было писать код синхронизации а достаточно просто запроксировать. Не знаю как это работает внутри, для т.н. "словарей" там точно есть кеш, а вот такие запросы будут ходить скорее всего каждый раз напрямую. Посмотрим как оно будет.

Третий прикол это типа OOM на запросах. Если ваш запрос по какой-то причине возвращает слишком много данных, то сервер может поднять лапки и сказать "сорян на этот запрос памяти нет". Такая ошибка вываливалась в стандартном просмотре таблицы Metabase потому что он делает select * from table, а если данных много и сервер слишком мал, то запрос просто не выполнится. Нужно или делать группировки или ограничивать колонки.

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

Решение работает в продакшене пару недель, пока все ок. Будем смотреть. ClickHouse мне очень понравился, я уже вижу еще несколько мест куда его можно применить. Очень легковесная и быстрая штука. Советую попробовать всем.

#инструменты
permalink | задонатить Открыть/Комментировать

2021-06-14 09:00:00 Когда олимпиадники могут. ClickHouse

На одном из самых старых проектов которые я разрабатываю начала тупить отчетность. Как только я поставил клиенту BI (напоминаю, это было самое быстрое и самое эффективное решение задачи которое я когда-либо делал), то аналитики сразу начали городить кучу дашбордов и отчетов. В основном все работало бодро, но некоторые запросы изрядно тупили.

Проблему довольно долго удавалось игнорировать, но в какой-то момент данных стало уж слишком много чтобы ими мог ворочать маленький MySQL сервер (4Гб памяти). Основную трудность составляли группировки по low cardinality колонкам. Представьте что у вас есть таблица с событиями где есть куча полей одно из которых может иметь всего три значения. Если вы хотите группировать выборку по этому полю, но кроме того еще и по куче других полей, то база не может подобрать подходящий индекс, берет какой попало и если данных достаточно много, то все это превращается в full scan.

В моем случае на таблице из всего лишь 6M записей такие запросы становились просто неподъемными. Внимательный читатель с навыками DBA предложил бы сделать композитные индексы, но мне пришлось бы делать их 20 штук, потому что кроме low-cardinality поля есть еще и другие по которым тоже нужно делать фильтрацию. Сложность вращения OLAP кубов это известная проблема RDBMS и не решается она в общем случае никак. Даже банальный select count(*) from table со временем начнет тупить на смехотворных 10M записей. Вам надо или делать дополнительные таблицы, или грузить всю таблицу в память, то есть добавлять железа, или ограничивать выборку по первичному ключу или еще как-то изощряться. Железо я в силу разных причин добавить сейчас не могу, костыли в виде дополнительных таблиц уже есть, городить что-то еще не хотелось.

В этот момент кто-то вспомнил про ClickHouse. То ли я, то ли аналитики клиента, уже не помню. Договорились сделать PoC. Подняли самый простой сервер, я сделал экспорт данных из mysql в csv и вгрузил в ClickHouse чтобы понять как оно вообще будет работать.

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

Вторым удивлением оказалась скорость выборок. Запросы которые mysql не мог переварить, отрабатывали за доли секунд. Оно конечно логично, ведь это колоночная база сделанная как раз для группировок по куче колонок, но такой скорости на сервере с 2 Гб памяти я не ожидал.

Третье—полная поддержка SQL синтаксиса. Нам практически не понадобилось переписывать запросы дашбордов, просто поменяли датасорс в Metabase и всё заработало. Очень круто когда решение интегрировано со всем с чем можно.

Главная идея ClickHouse—высокая скорость работы на гигантских объемах данных. Логично, если в Яндексе приходится ворочать петабайтами, то мои смешные десятки гигабайт будут работать очень быстро.

Недавно я писал пост про олимпиадные задачи, алгоритмы и зачем они нужны. Вот результат, пожалуйста. Сам ClickHouse достигает такой скорости за счет хитрых структур данных и многочисленных оптимизаций.

Конечно же не все прошло так гладко как я стелю. Об этом в следующей части.

Используете ClickHouse? Делитесь своим опытом в комментах!

#инструменты
permalink | задонатить Открыть/Комментировать