MySQL *

В обзорной статье мы разобрали, зачем использовать в поиске тот же UUID, что и в основной базе (если таковая имеется). Здесь сразу перейдём к практике: создадим таблицу, выполним основные операции через SQL и JSON API, а затем загрузим несколько документов через /bulk.

Все примеры рассчитаны на Manticore Search 28.5.0 или новее. Значение <generated UUID> в ответах обозначает UUID, который Manticore создаст при обработке запроса. Копировать эту строку в следующий запрос не нужно: подставьте фактический id из своего ответа.

Допустим, у вашего товара в основной базе уже есть ID 550e8400-e29b-41d4-a716-446655440000. Он попадает в события, логи и ответы API. Но при загрузке того же товара в Manticore приложению приходится выдавать ему ещё один, числовой ID.

До Manticore Search 28.5.0 ID документа был беззнаковым 64-битным числом. UUID можно было сохранить в отдельном строковом атрибуте, однако идентификатором документа он от этого не становился. Для UPDATE, REPLACE и DELETE всё равно требовался числовой id.

В результате приходилось хранить соответствие между UUID из основной БД и числовым ID в таблице Manticore. Теперь без него можно обойтись: RT-таблица Manticore умеет использовать UUID как ID документа.

Дисклеймер: Это статья-проверка на прочность. Проект работает на PHP + MySQL + Polling каждые 3 секунды. Если вы кликнули по ссылке, а сервер отдаёт 502 или упорно молчит — значит, поллинг взял своё под нагрузкой Хабра, а я прямо сейчас судорожно оптимизирую запросы и чиню базу!

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

Я в одиночку разработал web‑мессенджер Conlink Messenger. Его главная фича — полный отказ от привязки к номеру телефона: только email, пароль и никакого сбора персональных данных.

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

Если после этой статьи окажется, что половину backend'а стоит переписать — значит, опубликовал не зря. Приглашаю устроить проекту честный краш‑тест!

Фасеты в интернет-магазине кажутся простыми до первого выбранного фильтра.

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

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

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

В Manticore Search 25.12.0 появился facet_filter_mode, который переносит это поведение в API фасетов. Теперь в запросе можно описать, как ведёт себя панель фильтров магазина, а приложению не нужно вручную собирать почти одинаковые запросы для каждого фасета.

Несколько дней назад Meilisearch опубликовал сравнение с Manticore Search . Мы тоже любим сравнения: в 2023 году опубликовали своё с воспроизводимыми бенчмарками. Сразу оговоримся: мы спорим не со всей статьёй. Часть выводов Meilisearch справедлива, а кое-где сравнение говорит в пользу Manticore Search.

Однако часть сведений о Manticore Search уже устарела. Спорить в теории мы не стали: запустили актуальные версии обоих движков (Manticore Search 28.4.4 и Meilisearch 1.41/1.48) и повторили описанные сценарии. Ниже мы приводим команды и ответы обоих движков, чтобы проверку можно было повторить самостоятельно.

Привет, Хабр! Текстовые браузерные 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.