MySQL *

Статья посвящена реализации join-операций в системах потоковой обработки данных на базе Apache Flink. Рассматриваются основные подходы к объединению потоков в реальном времени, включая inner join, а также паттерны дедупликации. Уделено внимание использованиюKeyedCoProcessFunction для построения отказоустойчивых и масштабируемых join-пайплайнов. Работа ориентирована на инженеров, строящих real-time витрины и сложные трансформации на Flink в продакшене.

Что делать, если один отдел компании работает в Битрикс24, другой – в 1С, а данные о клиентах хранятся в третьей сторонней системе? Очевидно, страдать и прикладывать все силы, чтобы информация была хотя бы немного актуальной. Компания «Кореана» устала терпеть такую рассинхронизацию и путаницу, терять заявки и тратить время своих сотрудников на ручную сверку данных. Она обратилась к нам – в студию разработки LABA – для настройки интеграции всех своих систем. Теперь данные обновляются мгновенно, процессы автоматизированы, а сотрудники могут сосредоточиться на главном – качественном взаимодействии с клиентами. В этом кейсе мы подробно расскажем, как мы этого добились.

Хочу поведать о своей библиотеке для написания тестов в транзакция при работе с MySQL.

Я люблю писать тесты для своего кода, но при этом не люблю писать моки и всю необходимую для них обвязку. Особенно это касается базы данных ибо как правило замокать вызовы внешних сервисов и очереди сообщений, еще не так сложно, а вот с БД все гораздо сложнее, ведь взаимодействие с ней обычно довольно «богатое». И это ведет к тому, что приходится писать много хрупких и утомительных моков, и при этом сами запросы к БД не покрываются тестами (а там зачастую могут таиться ошибки связанные с некорректными запросами или ошибками миграции схемы).

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

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

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

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

Привет, Хабр! Меня зовут Артем Майоров, я администратор баз данных в компании MONS (КОРУС Консалтинг).
Расскажу, как мы не дали упасть больше 100 ПВЗ России благодаря спасению Percona
MySQL-сервера.
Подробнее, как это сделать и почему вообще его пришлось спасать, я рассказал в тексте!

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

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

>= 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 понадобилось для реализации такого тарифа и как в целом устроен биллинг в моём боте расскажу в статье.

Эта статья написана Мариусом Матилионисом, старшим разработчиком и экспертом по Manticore Search в компании Ivinco. Ivinco специализируется на предоставлении передовых решений для поиска, оптимизации баз данных, управлении инцидентами и настройке систем мониторинга, помогая бизнесам достигать более быстрых, эффективных и масштабируемых операций.

Основной причиной перехода с SQLite на MySQL базу данных является внезапное повреждение файла .db, после которого невозможно ни открыть файл, ни восстановить оставшиеся данные — ни в этот, ни в новый файл базы.

В данной публикации описан пошаговый алгоритм миграции действующей базы данных без использования docker.

Кратко: Узнайте, как Manticore Search даёт возможность искать изображения по текстовому описанию, совмещая обработку естественного языка и поиск по векторным представлениям. Мы рассмотрим разные пути — от классических методов до современных решений на базе векторного поиска. А если хотите увидеть всё в реальном времени, загляните в наше демо.

Зачем вообще "надёжно" стирать данные? Главное же, чтобы пользователь через интерфейс СУБД не мог их достать. Мало ли, что там за остатки данных в файлах болтаются, это же не проблема. Или нет?

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

Никогда не используйте MySQL, всегда используйте PostgreSQL

И вот почему, по результатам нагрузочного тестирования:

PostgreSQL в два раза меньше потребляет ресурса CPU, PostgreSQL в два раза меньше потребляет ресурса RAM, PostgreSQL в полтора раза меньше потребляет ресурса HDD (storage), PostgreSQL в три раза быстрее выполняет запросы, PostgreSQL после выполнения команды очистки (TRUNCATE TABLE) полностью очистил диск , MySQL очистил диск только наполовину.

Наверное MySQL надо уметь готовить ? Наверное. Если кто то напишет рецепт в комментариях, то благодарное человечество, в лице меня лично, скажет большое спасибо.

Одновременно с этим есть PostgreSQL, который можно не уметь готовить и иметь большую (такую же?) эффективность, стоит ли связываться с MySQL ?

Добрый день!

Хотел написать статью, обобщающую то, что я нашёл в интернете. Может кому-то она покажется слишком простой, может ненужной, а может наоборот вызовет обсуждение, на что я крайне надеюсь.

В двух словах о чём статья:

С нуля мы создадим flutter-проект с подключением к push-уведомлениям. Будем отправлять уведомления не только на Android, IOS, но и на наш веб-сайт, который может рассылать уведомления в т.ч. на мобильные устройства. Нам потребуется дополнительно лишь небольшой хостинг с mysql БД и php.

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

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