Прим. перев.: в этой статье сербский «инженер по масштабируемости» нагруженного онлайн-проекта в подробностях рассказывает о своем опыте оптимизации большой БД на базе MySQL. Проведена она была для того, чтобы выдержать резкий рост трафика на сайт, случившийся из-за пандемии.
Примечание: первоначально эта статья была опубликована в блоге моего хорошего друга — unstructed.tech.
Я люблю ввязываться в авантюры, и за последний месяц об одной из них я пару раз рассказывал друзьям, что вызывало восторг, поэтому решил поделиться с хабравчанами! Эта история про отважные пет-проекты, мощь опен-сорса и саморазвитие, а также основные технические детали. Надеюсь, вас это вдохновит :)
Прим. перев.: Этот детальный анализ одной, казалось бы, не очень значительной детали в реализации внутри MySQL вызвал закономерные дискуссии о правильности в подходах к разработке известного Open Source-проекта в целом. О том, что же, собственно, выяснил португальский инженер, он повествует в формате, приближенном к детективу…
Многие в 2020 году стали жертвой странного феномена восприятия времени, но некоторые системы управления базами данных манипулируют временем гораздо дольше. Впервые я обратил на это внимание, когда мой друг в одном из своих проектов (Accord — популярный бот для Discord) столкнулся со следующим исключением от коннектора MySQL при использовании с EF Core:
MySqlException: Incorrect TIME value: '960:00:00.000000'
Будучи не слишком сведущим в MySQL (т.к. предпочитаю PostgreSQL по причинам, которые скоро станут очевидными), я на секунду подумал, что неправильным здесь является число часов. Разумно предположить, что значения TIME ограничены 24 часами или что для значений, охватывающих нескольких дней, требуется другой синтаксис — например, 40:00:00:00 будет представлять 40 дней. Но действительность оказалась куда сложнее и запутаннее.Читать полностью »
Привет! Приглашаем на бесплатный Demo-урок «Параллельный кластер CockroachDB», который пройдёт в рамках курса «PostgreSQL». Также публикуем перевод статьи Тома Брауна — Principal Systems Engineer at EnterpriseDB.
В этой статье рассмотрим несколько полезных советов по работе с PostgreSQL:
Ссылка на всю строку целиком
Сравнение нескольких столбцов
Общие табличные выражения
Пользовательские параметры конфигурации
Сравнение логических значений без "равно"
Изменение типа столбца без лишних затрат
Привет! Карма слита из-за неосторожного комента под холиварной статьей, а значит нужно написать интересный (я надеюсь) пост и реабилитироваться.
Я несколько лет пользуюсь серверным telegram клиентом на php. И как многие пользователи — устал от постоянного роста потребления памяти. Некоторые сессии могут занимать от 1 до 8 гигабайт RAM! Поддержка баз данных была уже давно обещана, но подвижек в этом направлении не было. Пришлось решать проблему самому :) Популярность open source проекта, накладывала интересные требования на pull request:
За подробностями приглашаю всех под кат.
Читать полностью »
В свете того, что Zabbix с некоторых пор поддерживает TimescaleDB, а тут еще и вышел новый LTS релиз Zabbix, то наверняка многие заинтересовались, как осуществить миграцию с MySQL на PostgreSQL.
Несмотря на текст на картинке, вполне можно просто так взять и мигрировать Zabbix с MySQL на PostgreSQL. В интернете есть немало рецептов такой миграции, например:
Доклад с Zabbix Meetup
Видео с Youtube канала Dmitry Lambert
Но я не нашел ни в одном из таких докладов информации, как же минимизировать downtime вашего мониторинга в случае, если полная миграция занимает несколько часов, что конечно зачастую является неприемлемым.
Ниже я опишу свое решение данной проблемы и те подводные камни, которые пришлось обходить по пути.
Важно упомянуть, что я до сих использую Zabbix 4.0. Возможно, в новых версиях схема БД поменялась и поэтапная миграция, описанная ниже, там невозможна.
Прим. перев.: в этой статье тимлид британской компании Ticketsolve делится решением своей весьма специфичной проблемы, демонстрируя при этом общие подходы к созданию так называемых accumulating (накопительных) функций с помощью современных возможностей MySQL 8.0. Его листинги наглядны и снабжены подробными объяснениями, что помогает вникнуть в суть проблематики даже тем, кто не погружался в неё столь глубоко.
Обычная стратегия для выполнения обновлений с использованием накопительных функций в MySQL — применение пользовательских переменных и паттерна UPDATE [...] SET mycol = (@myvar := EXPRESSION(@myvar, mycol)).
Этот паттерн плохо работает с оптимизатором (приводя к недетерминированному поведению), поэтому от него решили отказаться. В результате возникла некая пустота, поскольку (относительно) комплексную логику теперь сложнее реализовать (по крайней мере, с той же простотой).
В статье пойдет речь о двух способах ее реализации: с использованием оконных функций (канонический подход) и с помощью рекурсивных СТЕ (общих табличных выражений).Читать полностью »
Сводная таблица – один из самых базовых видов аналитики. Многие считают, что создать её средствами SQL невозможно. Конечно же, это не так.
Читать полностью »
Любой крупный проект начинался с пары серверов. Cначала был один DB-сервер, потом к нему добавились слейвы, чтобы масштабировать чтение. И тут — стоп! Мастер один, а слейвов много; если уйдет один из слейвов, то всё будет хорошо, а если уйдет мастер — будет плохо: даунтайм, админы в мыле поднимают сервер. Что делать? Резервировать мастер. Мой коллега Павел уже писал об этом статью, я не буду ее повторять. Вместо этого расскажу, почему вам обязательно нужен Orchestrator для MySQL!
Читать полностью »