Привет, Хабр! Меня зовут Антон, я – старший разработчик в отделе разработки баз данных в IBS. В этой статье я расскажу о том, как нашей командой была решена задача по сохранению в ClickHouse большого количества данных, генерируемых веб-приложением, с последующим получением сохранённых данных в агрегированном виде.

Решение задачи, описанной выше, было бы простым и вряд ли заслуживающим отдельной статьи на Хабре. Но наш случай представлял собой ряд нюансов: здесь есть технические дубли записей и бизнес-дубли (обновления), есть агрегированные данные и необходимость обновления агрегированных данных. А это уже пример не совсем типичного использования ClickHouse, которым мы и хотим поделиться.

Итак, сегодня мы поговорим о самой интимной для любого специалиста теме - его зарплате. Именно из-за интимности этот простой вопрос способен вызвать холивар, бунт или даже маленькую войну. Всё потому, что как и в любой интимной теме люди легко радикализируются и бьются на две противоположные секты. Обзовём их “Адепты бесконечной зарплаты” и “Свидетели отсутствия мотивации”. Рассмотрим идеологию этих сект подробнее.

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

Я учил язык по статьям из интернета — просто брал каркас и дальше дописывал, смотрел где что падает, постоянно решал задачи на leetcode. Писал я тогда ужасно, но что было, то было. Мне нравилось, но чем больше я углублялся, тем сильнее раздражали скорость выполнения, ограничения параллелизма и динамическая типизация.

Тогда я решил попробовать Go.

Мы решили внести свой скромный вклад в развитие комьюнити и перевели оригинальную статью. Статья опубликована на сайте Simplilearn.

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

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

Приветствую вас, хабровчане, решил поделиться с сообществом переводом довольно часто (по личным наблюдениям) упоминаемого поста SOLID Go Design из блога Dave Cheney, который выполнял для собственных нужд, но кто-то говорил, что нужно делиться. Возможно для кого-то это окажется полезным.

SOLID дизайн Go

Этот пост на основе текста из основного доклада GolangUK прошедшего 18-ого Августа 2016.
Запись выступления доступна в YouTube.

­­ 

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

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

Статья подготовлена на основе открытого занятия из видеокурса по Apache Kafka. Авторы — Анатолий Солдатов, Lead Engineer в Авито, и Александр Миронов, Infrastructure Engineer в Stripe. Базовые темы курса доступны на Youtube.

Эта статья берет за основу Go 1.12.

Go радует нас легким и умным управлением горутинами. Легким, поскольку стек горутин изначально весит всего 2 КБ, а умным, потому что горутины могут автоматически увеличиваться/уменьшаться в соответствии с нашими потребностями.