MySQL *

Всем привет! Мы делаем проекты по Zabbix, накопили большую экспертизу и решили сделать переводы нескольких статей, которые нам показались интересными и полезными. Наверняка, будут полезны и вам. Также своим опытом делимся в телеграм-канале zabbix_ru, где вы можете найти полезные материалы и записи наших вебинаров, опубликованных на нашем ютуб-канале (прим. переводчика).

В этой статье мы покажем вам, как перенести базу данных Zabbix из MySQL в PostgreSQL на Rocky Linux 9. Заодно покажем, как включить TimescaleDB, а также выполним некоторые базовые настройки производительности.

В статье предполагается, что если доступны необязательные патчи (ключи с плавающей точкой и первичные ключи ), то они уже применены к базе данных.
Если вы в этом не уверены, информация об этом статусе также отображается во фронтенде в разделе System information, например, «Database history tables upgraded: No».

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

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

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

В Kubernetes короткий жизненный цикл подов — норма. Но когда лидер-узел MySQL внезапно исчезает, рискуешь потерять не только доступность, но и согласованность данных. Оператор Moco предлагает решение: полусинхронная репликация, автоматический failover и восстановление с PITR — всё это без боли миграции на полностью синхронную репликацию.

В статье — детали репликации, бэкапов, PITR, switchover и нюансов работы с пользовательскими образами. А также честно — чем он лучше (и хуже) альтернатив, и стоит ли его рассматривать для продакшена.

JOIN vs коррелированный подзапрос: мой разбор мифа «JOIN всегда быстрее»

Я проверил оба подхода (JOIN + GROUP BY и коррелированный подзапрос) на маленьком датасете и в ряде СУБД. Иногда подзапрос быстрее. Всё зависит от плана (Nested Loop vs Hash) и индексов. Слепо верить «JOIN всегда быстрее» не стоит. Смотрите EXPLAIN.

Первая часть статьи

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

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

Игра на 80% сделана с помощью вайб кодинга, но это не так просто как звучит.

Под катом расскажу, как реализовал свою web-панель для управления Amnezia AWG (WireGuard) VPN на Ubuntu 22–24. Почему не хватило официального приложения, какие задачи решил с помощью простого PHP-интерфейса и чем это может быть полезно другим компаниям или разработчикам. Код и инструкции — в открытом доступе.

Проект на GitHub: amneziavpnphp

Когда мы пишем запрос, СУБД делает гораздо больше, чем просто ищет данные. Она оценивает десятки сценариев выполнения, сравнивает стоимость операций и выбирает оптимальный путь к результату. От этого выбора зависит, будет ли запрос выполняться секунду или минуту. Почему одни системы находят лучший план, а другие выстраивают менее эффективный алгоритм? Попробуем разобраться, как планировщики СУБД принимают решения и что определяет их эффективность.

Мой отец — человек, переживший несколько сложнейших операций на сердце. Жизнь с хроническим заболеванием — это бесконечный поток анализов, заключений и схем приёма лекарств. Находясь далеко (я живу во Вьетнаме), я постоянно волновался: не забудет ли он про дозу, правильно ли понял назначение, задал ли все нужные вопросы врачу?

Мне нужен был не просто бот-напоминалка, а второй пилот — умный, конфиденциальный и мультимодальный AI-Кардиолог. Ассистент, который знает его анамнез наизусть, понимает голосовые команды и может «прочитать» фотографию свежего анализа.

Я решил собрать полноценный автономный агент с возможностью вызова внешних инструментов (Tool‑Calling) и локальной базой знаний (RAG), но без использования громоздких фреймворков вроде LangChain или LlamaIndex.

Транзакции — не про «магическое ACID», а про конкретную механику согласованного доступа к данным под нагрузкой.

Эта статья объясняет как реально работают уровни изоляции и чем отличаются популярные СУБД на практике.

Мы разберём:

Привет, Хабр!

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

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

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

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

За первый месяц сервис использовали более 1000 человек. Ниже — выводы и результаты.

Привет, Хабр!

Сегодня мы рассмотрим Resource Groups в MySQL — и перестанем жить на одной CPU.

Resource Groups — это контроль над CPU прямо из SQL. Вы создаёте логическую группу, говорите «эта группа может использовать только 2 CPU и работать на низком приоритете», и назначаете туда тяжелые, но второстепенные задачи. Всё. Дальше MySQL сам всё регулирует.

Всем привет!

Экспериментировал с оптимизацией SQL запросов в ChatGPT и Claude. В какой-то момент понял, что это превращается в одно и то же: Напиши промт → вставь SQL → подожди → поправь → повтори

Можно ли хранить данные, строить по ним отчетность, при этом обходясь без ETL процессов? Технически — да. Практически — только до первого серьезного роста данных.

Привет, Хабр! Меня зовут Алина, и в этой статье я расскажу о критически важном этапе, через который проходит любая data-driven компания.

Речь о переходе:
от построения отчетности напрямую из операционных баз (или через примитивное копирование в STG)
к структурированным ETL-процессам на специализированном ПО.

В нашем случае этим ПО стал SSIS — но важно подчеркнуть: сейчас мы используем NiFi с [N] процессорами для управления data pipeline. Однако именно опыт с SSIS стал для нас тем самым «мостиком» между хаотичным и осознанным подходом к данным.

P.S. Если хотите узнать про то, как мы организовали работу в NiFi — пишите в комментах, сделаем отдельный материал!

В этой статье — только про этап с SSIS. Не потому что он «лучший», а потому что:

Всем привет! И снова с вами Илья Криволапов – системный аналитик в SENSE, где мы вместе с командой трудимся над проектом одного из цветных банков РФ. Напоминаю, что в профессии я уже больше пяти лет и, несмотря на фамилию, прод все еще живой и здоровый (ну почти)!

В свободное от работы время, я преподаю курс «Хранение и обработка больших объемов данных», где успел накопить немало наблюдений, кейсов и выводов, которые не хочется держать в столе. Поэтому всё самое полезное оформил в цикл статей на Хабре – рассказываю как строить базы данных с прицелом на рост и не сойти с ума под нагрузкой.

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

Материал будет полезен всем, кто проектирует, масштабирует или просто поддерживает «здоровье» базы данных: DBA, архитекторам, DevOps-инженерам, аналитикам и разработчикам.

Финальный рывок – поехали!

Привет, Хабр!

В этой статье разбираем один из самых коварных способов убить базу — плохие JOIN'ы. Казалось бы, простое дело: связать пару таблиц — и вперёд. Но если в ON засунуть LOWER(email), забыть про индексы или перепутать LEFT JOIN с INNER — сервер мигом начнет дышать на ладан.

Всем привет! На связи снова Илья Криволапов — системный аналитик в SENSE, где мы трудимся на проекте одного из цветных банков РФ. Работаю в профессии уже пятый год и, несмотря на мою фамилию, с продом у нас в целом тёплые отношения. 

Помимо боевых задач, я преподаю курс «Хранение и обработка больших объемов данных» и за это время накопил немало практических кейсов и наблюдений. Всё это добро я решил не держать при себе и собрал самое полезное в виде ультимативного гайда по оптимизации и грамотному проектированию баз данных с расчетом на масштабирование, который сейчас публикую на Хабре.

Цикл состоит из 3 частей. В первой мы обсудили два базовых подхода к масштабированию БД: вертикальный и горизонтальный. Поговорили о плюсах, минусах и о том, как делать точно не стоит. 

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

Материал по-прежнему будет полезен всем, кто заботится о «здоровье» базы данных: DBA, архитекторам, DevOps-инженерам, аналитикам и разработчикам.

Готовы продолжать? Тогда поехали!

Мы реализовали мультирегиональность на eCommerce-платформе OpenPets с помощью поддоменов, геолокации по IP, MODX и интеграции с CRM. Делимся архитектурой, кодом, решениями и подводными камнями.