Привет, Хабр!
В этой статье разбираем один из самых коварных способов убить базу — плохие JOIN'ы. Казалось бы, простое дело: связать пару таблиц — и вперёд. Но если в ON засунуть LOWER(email), забыть про индексы или перепутать LEFT JOIN с INNER — сервер мигом начнет дышать на ладан.
Всем привет! Это Миша Степнов, руководитель центра R&D Big Data в МТС Диджитал.
Сегодня все говорят о цифровой трансформации и внедрении искусственного интеллекта в бизнес-процессы. Но многие забывают, что ИИ без данных не бывает. Именно качественные, актуальные и правильно структурированные данные определяют успех проекта в области машинного обучения и глубокого анализа.
Чтобы модели не «предвзято учились» и не «выдавали мусор», нужно обеспечивать непрерывные R&D-процессы по управлению данными: от сбора и очистки до хранения и быстрых итераций над ними. И тут возникает важное понятие AI Ready Data: все, что касается доступности данных, их формата и актуальности, должно быть продумано заранее и поддерживаться на высоком уровне качества.
Умение грамотно управлять данными — это уже не «хороший тон», а конкурентное преимущество. Но как прокачивать навыки работы с ними? Один из способов — читать правильную литературу. Так что в этом посте поделюсь списком книг о базовых принципах реляционных баз данных и SQL, продвинутых инструментах и языках программирования и многом другом. Забирайте в закладки, а при желании дополняйте подборку в комментариях.
Уже лет 20 существует миф (или не миф), что современный Highload-проект невозможен без кэшей. Они всегда нас выручали, когда не справлялись базы данных. Но с тех пор, как появились первые кэши, key-value баз данных и другие технологии, многое изменилось и традиционные СУБД значительно эволюционировали. И так ли теперь нужен кэш?
Мы протестировали самые известные кэш-сервисы и СУБД и попробовали выжать из них миллион запросов в секунду в разных условиях. Делимся с вами результатами в этой статье.
Привет, Хабр! Я Алексей Рыбак, предприниматель и основатель R&D-лаборатории DevHands, автор телеграм-канала про System Design и Highload. В прошлом — СТО и руководитель московского офиса Badoo. Работал во втором по размеру такси-сервисе «Везёт», который мы после продажи интегрировали с Яндекс.Такси. Сейчас наша компания разрабатывает образовательные программы по Highload и перформансу.
Привет! Меня зовут Олег Кретинин, и я разработчик в команде общих компонентов в Яндекс Еде. Сегодня я расскажу о том, как мы смогли успешно снять нагрузку с нашей базы данных, а также уменьшить её размер.
Помимо сервисов, написанных на C++, Go и Python, у нас есть монолит, он же «кора», на PHP, который всё ещё представляет огромную кодовую базу, хранит кучу логики и предоставляет данные по API для 120 сервисов.
После обновления фреймворка и версии PHP мы принялись за решение другой проблемы, которая всё чаще и чаще давала о себе знать. В тот период у нас возросло количество инцидентов, связанных с базой данных, и нам нужно было что‑то придумать, чтобы стабилизировать проект максимально быстро. Случалось, что всё сыпалось во время праздничных дней, когда количество заказов увеличивалось на 30–40%, или во время разовых массовых операций, например когда однажды в большую сеть ресторанов добавлялся бесплатный соус к каждой позиции меню.
Привет! Я Саша Хренников, руководитель DevOps-юнита в KTS.
Недавно мы провели DevOps-челлендж, где нужно поднять неисправный экземпляр MySQL. Было нелегко — быстрее всех справились восемь сильнейших DevOps-мастеров, которым мы уже отправляем призовой мерч.
В этой статье я разберу задачу и покажу, как её можно решить двумя способами.
Привет! Я Саша Хренников, руководитель DevOps-юнита в KTS.
Наша команда дважды готовила для вас испытания. Сначала вы оживляли сломанное приложение, затем пробовали запустить k8s v0.1, и гардеробы счастливых победителей уже украшает наш мерч. Сегодня мы предлагаем вам пополнить их ряды: вас ждет новый челлендж и новое соревнование за место в списке достойнейших.
Вам предстоит восстановить работу экземпляра MySQL, запущенного с помощью MySQL-оператора. Подведем итоги 17 октября в 19:00, а десять самых быстрых участников получат футболки с Котзиллой по почте.
Нередко оказывается, что даже в большом «зоопарке» общедоступных решений нет инструмента, отвечающего всем требованиям. В таком случае команды вынуждены двигаться в сторону разработки своего продукта.
Меня зовут Александр Кленов. Я тимлид разработки Tarantool DB в команде Tarantool. В этой статье я расскажу, почему мы решили добавить в свой продуктовый портфель Tarantool DB и что реализовали в инструменте, а также покажу на примере словарей, почему строить свою СУБД сложно.
Сегодня, 3 августа 2024 года, был последний день подачи документов в вузы России на бюджет.
Ситуация нервная: слишком много факторов.
Как MariaDB поломала экспорт файлов MySQL в новых версиях и с чем это связано.
Расследование, которое изменит ваше мнение о том, что могут SQL файлы и почему их импорт может оказаться небезопасным.
Еще один вектор атаки на ваши сервера, который надо учитывать и знать о его существовании.
В процессе тестирования одного курса по SQL на stepik.org встретилась задача, из которой сочинилась другая, более интересная:
Необходимо с помощью одного SQL запроса с использованием обобщенных табличных выражений отобразить иерархию, в соответствии с иллюстрацией выше
Идея упростить или абстрагировать код с помощью ORM, возможно, имеет очень ограниченный контекст применимости. По сути ORM хорош для приложений уровня простого CRUD, а дальше начинает только мешать. А CRUD-приложений в реальной жизни очень мало.
Почему программисты SQL так плохо шутят? Потому что их юмор — это всегда "SELECT * FROM jokes WHERE is_funny = 1".
Я очень люблю визуализации. Человек лучше всего воспринимает информацию через образы. Для трех часто встречающихся баз (MSSQL, Postgres и MySQL) я смастерил плагины к проекту Bell, хотя этот код на Python можно использовать и отдельно. Поэтому для каждой визуализации я буду в скобочках писать имя файла из репозитория GitHub - вы можете этот файл вытащить и использовать его отдельно от проекта (для этого нудны минимальные модификации).
Отмечу только, что я считаю себя экспертом только в MSSQL, а то что сделал с другими базами - сделал по наитию. Кроме того, в отличие от MSSQL у меня нет реальных баз под большой нагрузкой для Postgres и MySQL. Поэтому ошибки/пожелания для скриптов Postgres и MySQL очень и очень welcome!
В основном я задействовал TreeMap.
