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

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

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

Сравнительный анализ Apache Kafka и RabbitMQ

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

Тема будет интересна разработчикам на проектах, где требуется обмен информацией между разными компонентами или системами.

В прошлых двух статьях мы рассказывали об IIoT — индустриальном интернете вещей — строили архитектуру, чтобы принимать данные от сенсоров, паяли сами сенсоры. Краеугольным камнем архитектур IIoT да и вообще любых архитектур работающих с BigData является потоковая обработка данных. В ее основе лежит концепция передачи сообщений и очередей. Стандартом работы с рассылкой сообщений сейчас стала Apache Kafka. Однако, для того, чтобы разобраться в ее преимуществах (и понять ее недостатки) было бы хорошо разобраться в основах работы систем очередей в целом, механизмах их работы, шаблонах использования и основной функциональности.

Мы нашли отличную серию статей, которая сравнивает функциональность Apache Kafka и другого (незаслуженно игнорируемого) гиганта среди систем очередей — RabbitMQ. Эту серию статей мы перевели, снабдили своими комментариями и дополнили. Хотя серия и написана в декабре 2017 года, мир систем обмена сообщениями (и особенно Apache Kafka) меняется так быстро, что уже к лету 2018-го года некоторые вещи изменились.

Упрощает? Но как?

Только 3.5% россиян знают английский. Пакистан 50%, Германия 56%, Египт 40% — почему? Генетика, лень, система образования, не с кем практиковать... Много причин и очень много вопросов к каждой. У меня есть собственная гипотеза, основанная на личном опыте.

Никогда не используйте MySQL, всегда используйте PostgreSQL

И вот почему, по результатам нагрузочного тестирования:

PostgreSQL в два раза меньше потребляет ресурса CPU, PostgreSQL в два раза меньше потребляет ресурса RAM, PostgreSQL в полтора раза меньше потребляет ресурса HDD (storage), PostgreSQL в три раза быстрее выполняет запросы, PostgreSQL после выполнения команды очистки (TRUNCATE TABLE) полностью очистил диск , MySQL очистил диск только наполовину.

Наверное MySQL надо уметь готовить ? Наверное. Если кто то напишет рецепт в комментариях, то благодарное человечество, в лице меня лично, скажет большое спасибо.

Одновременно с этим есть PostgreSQL, который можно не уметь готовить и иметь большую (такую же?) эффективность, стоит ли связываться с MySQL ?

Телеграм сейчас является основным источником контента для многих. У Хабра тоже есть канал t.me/habr_com, его читает более 100 000 подписчиков. Кроме этого, о технологиях есть тысячи других каналов. Сколько их? Какая у них аудитория? Где найти данные? Разберемся в статье.

Стало интересно сделать анализ всех телеграм каналов: подписчики, рейтинги, частота статей, процент репостов, процент рекламы и т.д., поэтому посмотрел как можно достать данные. Забегая вперёд, скажу что собрал датасет со всеми телеграм каналами, в том числе и каналы с одним подписчиком. Их около 2 млн по всем гео. Какого-то сервиса, где можно сразу быстро и просто взять все каналы и набор метрик по ним, я не нашел, поэтому посмотрел что есть из готовых данных.

Существуют агрегаторы данных телеграм типа tgstat (https://tgstat.ru/). Один из способов - парсинг данных агрегаторов. Варианты с ботами, виртуальными аккаунтами показались более затратными, поэтому парсил несколько агрегаторов.

Итак, посмотрел ряд агрегаторов, взял на пробу три датасемпла. Самым адекватным показался семпл tgstat, поэтому, остановился на нем. В сервисе надо регистрироваться по телеграм аккаунту. Контент динамический, то есть, подгружается по клику. В парсинге всех данных не было смысла - важно было посмотреть что получится на семплах. Спарсил несколько категорий RU домена.

Сегодня расскажу про tech каналы с этой страницы (https://tgstat.ru/tech). Это каналы категориии 'Технологии', Россия. Периодически читаю каналы этой категории, ну и канал Хабра там есть. Поэтому, реллевантно будет здесь расказать именно о технологических каналах.

Каким бы ни был здоровым человек (как психически, так и физически), проблемы со сном в той или иной мере были у каждого. Многие не раз задавали себе вопрос: как быстро уснуть, если на сон ограниченное время? Как уснуть ночью, когда по различным причинам этого не удаётся сделать? Все мы прекрасно знаем, что крепкий сон - это залог продуктивной деятельности и здоровья. Поэтому, давайте разберем разные моменты и подходы во Вселенной Морфея и Гипноса.

Приведу 7 отличий, которые было бы неплохо знать.

Привет, Хабр! Это снова мы — Павел Конотопов и Михаил Жилин, сотрудники компании Postgres Professional. Напомню, что Павел занимается архитектурой построения отказоустойчивых кластеров, а я анализом производительности СУБД. У каждого из нас за плечами более десяти лет опыта в своей области.

Во второй части статьи «Мифы и реалии «Мультимастера» в архитектуре СУБД PostgreSQL» мы говорили о гарантии согласованности данных и разрешение конфликтов. Разобрали как выявлять и разрешать конфликты, используя разные способы. Теперь пришла пора одной из самых важных характеристик хранения данных — надёжности.

Привет, Хабр! Это снова мы — Павел Конотопов и Михаил Жилин, сотрудники компании Postgres Professional. Напомню, что Павел занимается архитектурой построения отказоустойчивых кластеров, а я анализом производительности СУБД. У каждого из нас за плечами более десяти лет опыта в своей области.

В первой части статьи «Мифы и реалии «Мультимастера» в архитектуре СУБД PostgreSQL» мы посмотрели как развивалась технология «Мультимастер» в экосистеме PostgreSQL. Обсудили существует ли «Честный Мультимастер», какие у него реализации и как его следует применять. Теперь поговорим о надёжности хранения данных.

Привет, Хабр! Недавно мы делали доклад на конференции HighLoad 2023 — «Мифы и реалии Мультимастера в архитектуре СУБД PostgreSQL». Мы — это Павел Конотопов (@kakoka) и Михаил Жилин (@mizhka), сотрудники компании Postgres Professional. Павел занимается архитектурой построения отказоустойчивых кластеров, а Михаил — анализом производительности СУБД. У каждого за плечами более десяти лет опыта в своей области.

Порассуждаем о том, как развивалась технология «Мультимастер» в экосистеме PostgreSQL, остановимся на том, что она из себя представляет, на каких внутренних механизмах PostgreSQL основана и как её можно использовать.

Мы также поговорим о том, существует ли «Честный Мультимастер» (само понятие «Честный Мультимастер» достаточно специфично и в основном употребляется в кругу разработчиков), какие реализации у него есть и как его следует применять.

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

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

Шаблоны проектирования распределенных систем предоставляют разработчикам проверенные решения и передовые методы проектирования и внедрения распределенных приложений.

Привет, Хабр! Меня зовут Илья Стариков. Я ведущий бизнес-аналитик МТС Диджитал, занимаюсь направлением HMI (Human Machine Interface): оно связывает работу систем автомобиля с пользовательским опытом.

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

В целом несколько лет изучал интерфейсы в разных авто, так что готов написать об этом сотни десятки постов. Сегодня на примерах Mercedes, Audi и BMW покажу, как менялись системы управления с 1904 года. Я много наездил на автомобилях разных поколений от этих производителей и знаю, какие нюансы тут есть. Плюс немного затрону Land Rover и Tesla. Жду вас под катом!

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

На большей части проектов сейчас востребованы знания по тест-дизайну и тестированию API.

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

В этой статье мы рассмотрим описание процесса тестирования программного обеспечения сквозь призму работы с API. Я попытался собрать полезные факты из книги “Hands on restful API design and the best practices” авторов Harihara Subramanian и Pethuru Raj. В книге подробно описываются этапы проектирования API и есть отдельная глава по тестированию RESTful сервисов в связке с API.

Можно читать в связке с моим предыдущим переводом “Стратегия тестирования REST API: что именно вам нужно тестировать?”. По ходу перевода я привожу примеры из личной практики (выделены курсивом), чтобы наглядно проиллюстрировать каждый этап из книги.