MySQL *

В одно мгновение мир, который мы знали, рухнул, оставив после себя только воспоминания о былой цивилизации. Теперь, в 2050 году, перед выжившими стоит задача не только сохранить себя, но и восстановить утраченное, шаг за шагом возвращаясь к технологическому прогрессу. Как?

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

Вместо интро

Сегодня мы расскажем о нашем опыте создания своего поиска для репозиториев в GitHub, почти похожее на то, которое там и используется, но немного другое.

Для затравки — посмотрите, что у нас получильнось на нашем репозитории → Демка
Можно проиндексировать и свой, для этого нужно немного подождать завершения процесса индексации → github.manticoresearch.com, а пока идет индексация — добро пожаловать под кат.

Здравствуйте! Если вы когда-либо пытались извлечь данные пользователей из крупных телеграм-групп и каналов, вы наверняка знаете о технических сложностях, которые могут возникнуть. В рамках нашего проекта — платформы для спикеров и коучей — мы столкнулись с необходимостью эффективно продвигать курсы, используя рекламу в других группах и каналах. Однако далеко не каждый готов предоставить доступ к своему каналу или группе, особенно если предлагаемые темы курсов перекликаются с их собственными.

Для решения этой задачи наша маркетинговая команда разработала трехуровневую партнёрскую программу. Суть программы заключается в том, что владельцы групп, согласные на сотрудничество, получают уникальный идентификатор в нашей системе. Под этим ID регистрируются все новые пользователи, которые, в случае покупки курсов, генерируют вознаграждение для владельца группы.

Эта инициатива казалась нам многообещающей, однако в процессе реализации мы столкнулись с серьёзным ограничением. При попытке загрузить список пользователей из группы на 13,000 человек, система смогла обработать только 10,000. Это ограничение API Telegram значительно усложнило выполнение задуманного плана, требуя от нас дополнительных технических решений.

Меня зовут Александр, я активно исследую экономические данные, строю регрессии, ML-модели. Данные использую разные: перекрёстные, панельные, временные.
По специфике своей работы часто пользуюсь ЕМИСС. ЕМИСС — это кладезь социально-экономических данных, но и одновременно платформа, которая может довести до головных болей и дергающегося глаза, а то и двух сразу.

Поставим себе, например, задачу выяснить, как влияет Х на У. Возьмём в качестве объектов наблюдения — регионы РФ. И тут нас будут ждать сюрпризы. Как быстро, не вырывая волосы из головы, получить две колонки данных за последний год по субъектам? Мы, конечно, можем использовать VLOOKUP/XLOOKUP в экселе и всё такое. Но нам встретятся обязательно двойняшки (тройняшки): «г. Москва» и «Город Москва столица Российской Федерации город федерального значения»; «Кемеровская область - Кузбасс» и «Кемеровская область — Кузбасс». Да, мелочи, но неприятно бороться с этими исключениями вручную.

Привет, Хабр! Представляю вам перевод статьи "How Uber Serves Over 40 Million Reads Per Second from Online Storage Using an Integrated Cache" автора Preetham Narayanareddy. Из неё вы узнаете, как в Uber проектировалась система кэширования на основе Redis, с какими сложностями и тонкостями пришлось столкнуться разработчикам, и как в итоге им удалось создать действительно высокопроизводительное решение.

Сначала запрос адаптирован для работы в PostgreSQL 15.6.

Затем работа запроса проверена на достаточно объемной иерархии - в качестве источника данных использована структура архива jdk-master.zip из OpenJDK 22

Продолжение статьи, в которой предложено решение задачи визуализации иерархической структуры средствами SQL запросов, на примере MySQL и SQLite

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

В процессе тестирования одного курса по SQL на stepik.org встретилась задача, из которой сочинилась другая, более интересная:

Необходимо с помощью одного SQL запроса с использованием обобщенных табличных выражений отобразить иерархию, в соответствии с иллюстрацией выше

Привет, Хабр! Доводилось ли вам тратить долгие бесплодные часы в попытке настроить коннекторы Kafka Connect, чтобы добиться адекватного потока данных? Мне, к сожалению, доводилось. Представляю вашему вниманию перевод статьи "How to Tune Kafka Connect Source Connectors to Optimize Throughput" автора Catalin Pop. Это прекрасное руководство от Confluent, где подробно и с примером описывается, как настроить Source коннекторы.

В данной публикации я поделюсь двумя основными причинами, по которым я предпочитаю избегать использования автоинкрементных полей в PostgreSQL и MySQL в будущих проектах. Вместо этого я предпочитаю использовать UUID-поля, за исключением случаев, когда есть очень веские аргументы против этого подхода.

Как развернуть базу данных mysql в phpmyadmin с помощью docker.

Так как я не нашёл на русском нормальный материал, то решил написать самостоятельно.

Данная статья касается вопросов «софтостроения» (термин этот я подсмотрел у своего коллеги и друга Сергея Тарасова). Термин мне нравится. Всегда встаю в тупик по порядку изложения. В первую очередь сказать о техническом задании  (ТЗ) или о теоретических аспектах или продумывании как и что реализовать в программном коде? Ведь очевидно, что  прежде, чем что‑то писать программист должен хотя бы минуту подумать, что он напишет? Есть и другие варианты написания, но мы их касаться не будем и начнем все‑таки с ТЗ.

Вкратце ТЗ звучало так. Написать информационно‑справочную систему поиска и бронирования лекарственных препаратов с использованием телеграмм бота (ТБ) для сети аптек на основе 1С конфигурации.

Задача была написана на 1С и работает (или работала) под телеграмм ботом с именем @lotostatki_bot. Это не предмет статьи, но прототип. Почему 1С? Потому, что 1С это учетная система, а бронирование товара — это документ, который поступает в аптеку и резервирует товар на определенное время. Схема, по которой ведет диалог ТБ @lotostatki_bot следующая...

В этой статье я расскажу как установить на Repka Pi 3 полноценный WEB сервер на Nginx с php-fpm и MySQL для того, чтоб в конечном счете установить WordPress и начать делать и размещать Ваш сайт на данной платформе. Ставить будем на родную ОС Repka Pi от 11.12.23 (последняя актуальна прошивка на момент написания статьи).

Cразу уточню, это не гайд по созданию MMORPG на C++. Это нечто вроде моего дневника, куда я буду скидывать процесс разработки (Да, проект ещё не завершён, даже не близко, скорее только начат...). Почему я вообще тогда создал эту статью? Ну, коли ты крутой true‑программист, буду рад советам, критике, помощи, ругани, проще говоря всему, что может помочь мне улучшить это. С другой стороны, если ты сам захотел создать нечто похожее, то, быть может, сможешь избежать всех трудностей, с которыми столкнулся я.

Я потратил неделю, копаясь во внутренностях MySQL/MariaDB вместе с ещё примерно 80 разработчиками. Хотя MySQL и MariaDB — это, по большей части, одно и то же (я ещё к этому вернусь), я сосредоточился именно на MariaDB.

Раньше я никогда сам не собирал MySQL/MariaDB. В первый день «недели хакерства» я смог наладить локальную сборку MariaDB и твикнул код так, что запрос SELECT 23 возвращал 213. Сделал я и другой твик — такой, что запрос SELECT 80 + 20 возвращал 60. На второй день я смог заставить заработать простую UDF на C, благодаря которой запрос SELECT mysum(20, 30) давал 50.

Остаток недели я потратил, пытаясь разобраться с тем, как сделать минимальный движок для хранения данных в памяти. Именно о нём я и расскажу. Это — 218 строк кода на C++.

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

Не смотря на то, что книга написана еще в 2014-2016 годах (первое издание в O’Reilly вышло в 2018-м), «Кабанчик» не теряет, а только приобретает актуальность. Разрабатывая высоконагруженные приложения для финтеха и управляя разработкой таких систем, я нахожу много полезного в книге Клеппмана. При этом если отобрать дюжину разработчиков, то «Кабанчика» читали от силы несколько из них.

Причина — в сложном и обстоятельном подходе автора (и в том, что книга насчитывает почти 700 страниц). Читать «Кабанчика» непросто, не так трудно как Хофштадтера, но и не так просто, как Вольфрама. Но не смотря на то, что книга написана давно, в ней неплохо отзываются некоторые современные проблемы.

Привет! Меня зовут Данила Соловьёв, я руковожу направлением PHP — самым крупным подразделением в отделе разработки AGIMA. Поделюсь историей о том, как мы встроили новую CRM-систему в два абсолютно незнакомых нам IT-ландшафта и тем самым спасли сейлзов двух крупных интернет-магазинов от бесконечных табличек в почте. Подробно опишу, какие данные мы выгружали, как их дедуплицировали и какие сервисы использовали для их валидации. Поехали!

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

Как выявить и отладить такие проблемы? В этой статье будет показано решение наиболее распространённых проблем с производительностью БД, вызванных неправильной индексацией. Примеры будут приведены для Postgres, MySQL и SQLite.

MySQL продолжает наращивать инновации и теперь включает в себя богатые возможности процедурного программирования внутри базы данных. Отныне разработчики могут писать хранимые программы на языке JavaScript (функции и процедуры) в сервере баз данных MySQL. Хранимые программы будут выполняться с помощью GraalVM. Эта версия доступна в качестве "Preview" в MySQL Enterprise Edition и может быть загружена через Oracle Technology Network (OTN). MySQL-JavaScript также доступен в облачном сервисе MySQL Heatware на OCI, AWS и Azure.