MySQL *

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

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

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

Больше года назад мы в LEADS.SU задумались над высокодоступностью нашей БД и начали искать различные варианты. Круг решений сужало то, что мы используем TokuDB, который уже не поддерживается. Вариантов было несколько, но точно было понятно что запуск кластера повлечет за собой полное клонирование файлов /var/lib/mysql, к тому моменту размер этой директории уже перевалил за пару сотен гигабайт и мы задумались над ревизией данных, что привело к долгоиграющему процессу по уменьшению размера БД.

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

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

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

Всего в цикле будет 3 статьи. В первой поговорим о двух разных подходах масштабирования БД и о том, как лучше его делать и как лучше не делать (Никогда. Пожалуйста). 

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

Согласны? Узнали? Тогда поехали!

Всем привет! Это Миша Степнов, руководитель центра R&D Big Data в МТС Диджитал.

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

Чтобы модели не «предвзято учились» и не «выдавали мусор», нужно обеспечивать непрерывные R&D-процессы по управлению данными: от сбора и очистки до хранения и быстрых итераций над ними. И тут возникает важное понятие AI Ready Data: все, что касается доступности данных, их формата и актуальности, должно быть продумано заранее и поддерживаться на высоком уровне качества.

Умение грамотно управлять данными — это уже не «хороший тон», а конкурентное преимущество.  Но как прокачивать навыки работы с ними? Один из способов — читать правильную литературу. Так что в этом посте поделюсь списком книг о базовых принципах реляционных баз данных и SQL, продвинутых инструментах и языках программирования и многом другом. Забирайте в закладки, а при желании дополняйте подборку в комментариях.

Доброго времени. Меня зовут Дмитрий и я веб‑разработчик. На данный момент работаю в группе компаний по экспорту автомобилей и техники из Японии, Китая и Кореи. Но, сейчас поговорим не об основной работе, а о «подработке».

>= 2 лет назад, на меня вышел директор достаточно крупной автошколы нашего города. На тот момент у них имелось порядка 3-х филиалов, и приблизительно 4,5 тыс. учеников (как актуальных, так и те — которые уже получили свои ВУ). Директор предложил мне поработать с их CRM системой. Данное ПО было написано какими‑то фрилансерами, и на протяжении нескольких лет они же и обеспечивали поддержку. Но, со слов директора, они начали забивать на свою работу, затягивали с выполнением задач или во все игнорировали пожелания по внесению изменений (все это было не бесплатно).

Уже лет 20 существует миф (или не миф), что современный Highload-проект невозможен без кэшей. Они всегда нас выручали, когда не справлялись базы данных. Но с тех пор, как появились первые кэши, key-value баз данных и другие технологии, многое изменилось и традиционные СУБД значительно эволюционировали. И так ли теперь нужен кэш?
Мы протестировали самые известные кэш-сервисы и СУБД и попробовали выжать из них миллион запросов в секунду в разных условиях. Делимся с вами результатами в этой статье.
Привет, Хабр! Я Алексей Рыбак, предприниматель и основатель R&D-лаборатории DevHands, автор телеграм-канала про System Design и Highload. В прошлом — СТО и руководитель московского офиса Badoo. Работал во втором по размеру такси-сервисе «Везёт», который мы после продажи интегрировали с Яндекс.Такси. Сейчас наша компания разрабатывает образовательные программы по Highload и перформансу.

Привет! Меня зовут Олег Кретинин, и я разработчик в команде общих компонентов в Яндекс Еде. Сегодня я расскажу о том, как мы смогли успешно снять нагрузку с нашей базы данных, а также уменьшить её размер.

Помимо сервисов, написанных на C++, Go и Python, у нас есть монолит, он же «кора», на PHP, который всё ещё представляет огромную кодовую базу, хранит кучу логики и предоставляет данные по API для 120 сервисов.

После обновления фреймворка и версии PHP мы принялись за решение другой проблемы, которая всё чаще и чаще давала о себе знать. В тот период у нас возросло количество инцидентов, связанных с базой данных, и нам нужно было что‑то придумать, чтобы стабилизировать проект максимально быстро. Случалось, что всё сыпалось во время праздничных дней, когда количество заказов увеличивалось на 30–40%, или во время разовых массовых операций, например когда однажды в большую сеть ресторанов добавлялся бесплатный соус к каждой позиции меню.

Некоторое время назад я запустил Telegram-бота для мониторинга сайтов и обозначил в нём тариф из двух строчек.

Сколько строк на SQL понадобилось для реализации такого тарифа и как в целом устроен биллинг в моём боте расскажу в статье.

Этот пост про толстенную 900-страничную книгу с множеством примеров решения практических задач при работе с СУБД MySQL. Довольно редко, когда американское издательство публикует книги от русскоязычного автора. Однако Света Смирнова — признанный эксперт по MySQL, и ее книги выходят в издательстве O’REILLY с 2012 года. Если вы совершенствуетесь в применении СУБД MySQL — новая книга будет очень хорошим подспорьем, а мы в SSP SOFT поможем с промокодом на покупку. 

В данной статье обсудим проблемы, возникающие при конкурентной работе с данными, а также инструменты для их решения – атомарные инструкции, явные и неявные блокировки и уровни изолированности транзакций, реализованные в OLTP СУБД PostgreSQL, MySQL, SQL Server, Oracle с примерами на Go. Поговорим о деталях их реализации в указанных СУБД. На примере PostgreSQL проведем benchmark-тестирование производительности уровней изоляции с использованием инструмента pgbench

Как удалось ускорить выполнение запроса MySQL почти на порядок с помощью простого изменения формулировки условия.

MariaDB Server исполняется 15 лет! Вот 15 причин, по которым разработчики и администраторы баз данных любят его!

Привет! Я Саша Хренников, руководитель DevOps-юнита в KTS.

Недавно мы провели DevOps-челлендж, где нужно поднять неисправный экземпляр MySQL. Было нелегко — быстрее всех справились восемь сильнейших DevOps-мастеров, которым мы уже отправляем призовой мерч.

В этой статье я разберу задачу и покажу, как её можно решить двумя способами.

Привет! Я Саша Хренников, руководитель DevOps-юнита в KTS.

Наша команда дважды готовила для вас испытания. Сначала вы оживляли сломанное приложение, затем пробовали запустить k8s v0.1, и гардеробы счастливых победителей уже украшает наш мерч. Сегодня мы предлагаем вам пополнить их ряды: вас ждет новый челлендж и новое соревнование за место в списке достойнейших.

Вам предстоит восстановить работу экземпляра MySQL, запущенного с помощью MySQL-оператора. Подведем итоги 17 октября в 19:00, а десять самых быстрых участников получат футболки с Котзиллой по почте.

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

Меня зовут Александр Кленов. Я тимлид разработки Tarantool DB в команде Tarantool. В этой статье я расскажу, почему мы решили добавить в свой продуктовый портфель Tarantool DB и что реализовали в инструменте, а также покажу на примере словарей, почему строить свою СУБД сложно. 

Сегодня, 3 августа 2024 года, был последний день подачи документов в вузы России на бюджет.

Ситуация нервная: слишком много факторов.