MySQL *

Привет, Хабр! Текстовые браузерные MMO вроде старой «Тюряги онлайн» — жанр древний, но до сих пор живой, особенно среди фанатов олдскульных вселенных. В сообществах готоманов нашу игру уже смело окрестили «Тюрягой онлайн 2.0», и сходство тут прямое: и там, и там на бэкенде крутится суровый выживач на зоне. Только в Тюряге ты обычный зэк на нарах, а Миненталь — это колония под магическим барьером, где каждый кусок мяса падальщика на счету. Игрок либо ходит на охоту и пашет на фракцию, либо быстро отбросит коньки в канаве от голода или первого же каторжника.

Когда мы на Бесте с нашими технарями задумали сделать эту тактическую RPG «Путь Героя», пришлось выбирать платформу для серверной части. В итоге мы решили использовать наш старый форум ещё времён 2004 года, обновив его с древней версии 3.4.6 до свежего каркаса IPS 5. Из коробки у него есть всё, что нужно: нормальная система прав, готовая база пользователей и вменяемое API. Но чтобы превратить обычный форум в нормальную игру, пришлось знатно поковыряться под капотом и в базах. Первым делом нужно было решить две главные проблемы: как упаковать всё это дело в легкое мобильное приложение и раз и навсегда отвадить игроков от читерства с кубиками.

При разработке проектов на небольших VPS часто возникает ситуация, когда процесс mysqld загружает процессор на 100%. Обычно в такие моменты приходится заходить по SSH, открывать консоль бд и вручную вводить SHOW FULL PROCESSLIST;, чтобы найти тяжелый запрос и завершить его через KILL. Если запросов много, делать это вручную через стандартный вывод не всегда удобно.

Это легковесный интерактивный CLI - менеджер процессов, который работает на базе асинхронного драйвера aiomysql. Он опрашивает системную таблицу information_schema.processlist и выводит текущую активность в терминал в виде таблицы, позволяя управлять потоками СУБД.

Перед командой, выросшей на MySQL/MariaDB, встаёт вопрос перехода на PostgreSQL: лицензии, экосистема расширений, более предсказуемое поведение при конкурентных нагрузках - причин достаточно. Проблема в другом: как перенести боевую базу, которая не останавливается ни на минуту, без часов простоя и без риска потерять данные, записанные во время переноса.

В этой статье - как мы решали эту задачу для интернет-магазина на MariaDB, почему готовые консольные конвертеры не годятся для «живой» миграции, и как выглядит рабочая схема на Debezium + Kafka Connect, включая Ansible-роль для повторяемого запуска.

Крон отработал. Экзит-код ноль. Файл лежит в S3, размер похож на правду. Мониторинг зелёный. Всё говорит о том, что бэкап сделан успешно, вот только его никогда не пробовали восстановить.

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

Два года по вечерам в одиночку пилю текстовую MMORPG в Telegram. Сейчас в ней 1111 аккаунтов и 586 выживших, которые бродят по мрачному острову. И где-то в админке ждёт кнопка, которая сотрёт их прогресс до нуля. Сезонный вайп, как в Rust. Я собрал её, проверил на тестовом сервере и до сих пор не нажал на проде. Рассказываю, почему «стереть всех» это не DELETE FROM, как один разработчик не держит в голове 99 таблиц, и какой тест блокирует мне деплой, если я забыл про новую таблицу.

Стандартный обмен данными в 1С-Битрикс часто превращается в ночной кошмар: полная выгрузка остатков на больших каталогах может занимать от 1 до 8 часов. Когда бизнес требует обновлять данные каждые 15 минут, штатные методы API и XML-импорт просто перестают справляться.

В этой статье я покажу, как с помощью прямого SQL запроса и временных таблиц в памяти (ENGINE=MEMORY) ускорить импорт в сотни раз. Это реальный кейс с продакшена, который стабильно работает уже 4 года на проекте с миллионом товаров и десятками складов.

Каждый бэкенд-разработчик рано или поздно сталкивается с ситуацией, когда база данных MySQL внезапно ложится при резком пиковом наплыве пользователей. Классическая ошибка на старте - создавать новое независимое соединение с СУБД на каждый чих приложения, выполнять один короткий запрос и закрывать коннект. Когда на сайт одновременно залетают сотни людей, сервер моментально упирается в системный лимит max_connections и падает с ошибкой OperationalError: (1040, 'Too many connections'), попутно забивая всю доступную оперативную память.

"Если вашего бизнеса нет в Интернете, то вас нет в бизнесе! Скоро на рынке останется два вида компаний: те, кто в Интернете и те, кто вышел из бизнеса." 

А потом вдруг интернета не стало и нужно было срочно что-то придумать для работы нашей ERP-системы оффлайн

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

При взаимодействии разработки с менеджментом или бухгалтерией регулярно всплывает одна и та же задача. Нужно либо выгрузить таблицу из базы в Эксель для отчёта, либо, наоборот, залить обратно в СУБД тяжелый xlsx. файл со свежими ценами или списком контрагентов. Настраивать тяжелые ETL-системы ради разовой выгрузки неэффективно. Проблема решилась написанием короткого CLI-скрипта на Python - mysql_bridge. Утилита обеспечивает сквозную двустороннюю конвертацию данных, автоматически анализирует структуру и сохраняет исходные типы на лету. Исходный код скрипта и Readme Здесь. Если Вас заинтересовала или статья была полезна, поддержите звездочками.

Как устроен двусторонний мост

Вся логика инструмента умещается за счёт связки pandas, sqlalchemy и движка openpyxl. Скрипт работает с файлами Эксель напрямую на уровне бинарного кода, поэтому его можно запускать на серверах без установленного офисного софта. Утилита работает в двух режимах.

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

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

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

Цель работы: Автоматизировать процесс контроля оплаты и отправки уведомлений, связав интеграцию ERP‑системы с платежным шлюзом и СМС‑провайдером для увеличения выручки школы.

Проектирование процессов и API‑контракта:

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

Схема взаимодействия систем / UML Sequence Diagram

Если вы когда-либо преподавали SQL или проходили курс по базам данных, то почти наверняка встречали Sakila — маленькую базу данных видеопроката, которая вот уже почти двадцать лет служит эталонным примером в туториалах по MySQL и MariaDB. Схема чистая, нормализованная, данных достаточно для интересных запросов.

Проблема в другом: Sakila спроектирована в 2006 году под MySQL 5.0.

С тех пор многое изменилось.

JOIN - крайне популярная операция в SQL, о которой еще и спрашивают на 99% собеседований на программиста. Но когда начинаешь впервые разбираться с ней, то постоянно путаешься, какие таблицы соединять и когда именно.

В этой статье простыми словами и с великолепной графикой расскажу, что такое JOIN в SQL, что такое Foreign Key, какой тип JOIN когда использовать - INNER или OUTER - и зачем вообще.

Если вы работаете с базами данных и используете ORM, вы, вероятно, сталкивались с той же проблемой, что и я. ORM отлично подходят для отображения таблиц на объекты. Но они начинают мешать, когда запрос становится сложным: агрегации, тщательно продуманные JOIN’ы, формы отчетов, которые не соответствуют одной модели на таблицу. Вы боретесь с ORM, переходите на сырой SQL, а затем вручную пишете связующий код (маппинг).

Не каждый SELECT возвращает то, что подходит под одну ORM-модель. SQL - это лучший язык для доступа к данным. Лучшие ORM, которые я использовал, такие как Drizzle, побеждают, потому что они остаются близки к SQL. Я хотел пойти дальше: хранить SQL в системе контроля версий и генерировать из него типизированный Python.

Именно поэтому я создал nORM (no ORM - не ORM) и выпустил версию v0.1.0 на этой неделе (мой первый опенсорс проект).

Всем привет! Меня зовут Никита и я CEO компании VSL-BI. Мы занимаемся внедрением BI-аналитики.

К нам обратилась компания из сферы продажи стройматериалов. Они активно работали с рекламой в Яндекс Директ и Google Ads (клиент вел деятельность в Казахстане), следили за аналитикой сайта в Яндекс Метрике, в качестве CRM использовали Битрикс24.

Когда CRM в Битрикс24 начинает открывать список сделок по 10 секунд, обычно первым делом подозревают сервер, нагрузку или саму платформу. Но на практике узкое место часто лежит ближе к базе: фильтры по UF-полям без индексов, лишние JOIN, неявный LIKE в ORM, N+1-запросы и обработчики, которые внезапно превращают массовое обновление в нагрузочный тест.

В статье разбираем, как подойти к проблеме системно: включить slow query log, прочитать EXPLAIN, найти реальные причины тормозов и точечно ускорить CRM без миграции и бессмысленного наращивания железа.

Скорее всего читатели знают, но контекста ради.
Flink имеет децентрализованный дизайн с распределенной архитектурой, где набор контейнеров ( Task Manager ) несут ответственность за свою локальную зону или не несут?
Эта зона в случае разбиения через keyBy размазывается исходя из хэша заданного ключа, посредством чего, Flink гарантирует попадание всех событий с этим ключом на тот же контейнер и также гарантирует сохранение того порядка событий, в котором они доехали до оператора, и, как следствие этот контейнер является мастером-владельцем ключа - отсюда понятие локальной зоны становится оправданным, ведь все хэш пространство размазывается на контейнеры равномерно. Однако, если не использовать keyBy и просто попробовать вызвать что угодно, то будет round-robin распределение и тогда снимается понятие локальной зоны ответственности.

Привет, Хабр! Расскажу, как мы спасли крупный новостной сайт ugra-news.ru от постоянных падений — без покупки нового железа и переписывания с нуля. Только точечные оптимизации, знание архитектуры Битрикс и немного детективной работы. Приступим.

Я выпустил вторую версию PHP-веб-панели для управления Amnezia VPN. Теперь это не просто интерфейс к одному серверу, а полноценная система управления VPN-инфраструктурой: 9 протоколов, роли, лимиты, метрики, резервные копии, Docker-управление удаленными хостами и REST API для автоматизации. Проект открыт и доступен на GitHub.

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