Оптимизация поиска выхода из лабиринта представляется относительно простой задачей. Но она подразумевает накопление данных, обучение, если угодно.
Как только возникает потребность накапливать данные, стоит исходить из того, что этих данных станет много и придётся прибегнуть к технологиям из области баз данных.
Здесь представлена робкая попытка разобраться в теме.
Простой вопрос, который разделяет инженеров и «операторов фреймворков»
Дисклеймер для опытных: если вы знаете ответ – внутри реальный кейс, как этот баг сломал мой паспорт в проде, и история с собеседования, от которой хочется плакать.
Приемная кампания в российских колледжах и вузах сопровождается публикацией обширных массивов данных на официальных сайтах. С одной стороны, это требование прозрачности процедуры зачисления. С другой стороны, существующий подход к обезличиванию информации содержит системную уязвимость, которая позволяет стороннему наблюдателю с высокой точностью сопоставить ФИО абитуриента с его номером СНИЛС.
Я провел анализ открытых источников 100 учебных заведений (вузы и колледжи) и выяснил, что 87 из них оставляют возможность такой деанонимизации. Причем данные за предыдущие годы остаются в открытом доступе, формируя устойчивый архив персональной информации.
Проблема публичного идентификатора
Подавляющее большинство учебных заведений размещает конкурсные списки в формате, где для идентификации абитуриента используется не случайный код, а его номер СНИЛС. Обоснование у разработчиков таких систем прагматичное: СНИЛС уникален, абитуриент знает его наизусть, поиск по списку упрощается.
Однако СНИЛС — это не просто номер. Это ключевой идентификатор гражданина в системе межведомственного взаимодействия. В связке с фамилией и инициалами он позволяет:
Достаточно большое количество проблем производительности в backend-приложениях на самом деле находятся не в коде. За последние пару лет мне несколько раз приходилось разбирать системы, где:
• API отвечало слишком долго
• CPU базы был загружен почти на 100%
Коротко для ленивых
В MariaDB 12.3 binlog можно хранить внутри InnoDB через binlog_storage_engine=innodb.
Главный эффект: вместо двух fsync() на commit остаётся один, поэтому на write-heavy нагрузке резко растут TPS и снижается tail latency.
В тестах из статьи прирост на полном durability-профиле составил примерно 2.4x–3.3x.
Backup, restore и ресинк реплик становятся проще, потому что binlog и данные теперь консистентны на уровне одного механизма хранения.
Цена за это: обязателен GTID, Galera пока не поддерживается, а innodb_log_file_size нужно подбирать внимательнее из-за роста объёма redo.
Если у вас обычная схема primary + async replica на InnoDB, эту возможность точно стоит хотя бы протестировать.
Более 5 лет я работаю ClickHouse DBA и помогаю командам разработки и аналитики эффективно использовать ClickHouse. Неизменным помощником в этом мне служит хеш-функция cityHash64(). В данной статье мы поговорим в основном про оптимизацию SQL запросов с помощью хеш-функций. Вероятно, рассматриваемые приемы в той или иной степени актуальны не только для ClickHouse, но и для других баз данных, и могут быть полезны любому, кто пишет SQL запросы.
Мы рассмотрим только те применения хеш-функций, которые регулярно встречаются в практике, а не что-то из разряда "100 способов измерения высоты здания с помощью барометра".
Я перепробовал несколько способов вести документацию по базе данных — и у каждого были свои проблемы: информации недостаточно, сложно поддерживать, непонятна команде. Хуже всего, что плохая документация по БД тянет за собой проблемы с требованиями к данным — а это не только таблицы, но и миграции, и данные в коде. В какой-то момент я понял, что пытался решить одним документом три разные задачи.
VACUUM в PostgreSQL принято считать универсальным средством поддержания порядка: он очищает мёртвые кортежи, обновляет статистику и вроде бы держит базу «в форме». Но с индексами всё сложнее. В какой-то момент они начинают расти и деградировать так, что это уже влияет на планы запросов и поведение оптимизатора — при том, что формально всё обслуживается корректно.
Разберёмся, где именно возникает это расхождение между ожиданиями и реальностью и что на самом деле происходит внутри B-дерева.
Привет, Хабр!
В прошлой статье мы заглянули под капот ClickHouse и разобрались, как работает движок MergeTree. Мы узнали, как хранятся данные и что такое парт, зачем нужен разреженный индекс и как работает фоновое слияние.
В этой статье мы рассмотрим один из мощнейших инструментов ClickHouse — Materialized View.
Распараллеливаем процесс вставки данных в PostgreSQL при помощи Spring с сохранением атомарности всей операции
Разработчики часто сталкиваются с проблемами производительности своих систем. Один из привычных способов ускорить медленный бизнес-процесс — распараллелить его. Это почти всегда работает: чем больше потоков обслуживают задачу, тем быстрее она выполняется.
Но когда речь заходит о вставке данных в PostgreSQL, возникает проблема: распараллеливание действительно ускоряет операцию, но ломает ее атомарность. Данные начинают появляться в таблице частями. Для многих бизнес-процессов это неприемлемо — нужно, чтобы вся пачка данных становилась доступной одновременно.
В этой статье расскажу о том, как сделать вставку данных одновременно многопоточной и атомарной.
В статье рассматриваем что такое хранилище данных, основы их разработки: архитектура, основные слои данных и подходы для работы с ними, ETL и ELT, а также основные модели данных. Материал поможет начинающим разработчикам понять принципы построения аналитических систем и роль разработчика DWH.
Для обычного пользователя разрешать уходить в минус по балансу - не может позволить себе ни одна организация, как говорилось в одном известном фильме - утром деньги, вечером стулья. Но для больших корпораций остановка платежей даже на секунду - это уже не проблема корпорации, а всего государства. Невозможно приостановить работу концерна (например Росатом) только потому, что в данный момент у него нет средств. На перезапуск может уйти куда как больше ресурсов.
Поэтому пора исправлять эту проблему в MireaPay и наконец-то добавить работу с крупными юр. лицами, которые будут называться корпоративными пользователями!
Это текстовая версия доклада с Java Rock Star Meetup, с которым выступал Дмитрий Фатов (@FatOFF ) — руководитель разработки Газпромбанка с опытом разработки приложений более 13 лет. Дмитрий работал как backend-, так и fullstack-разработчиком на языках Java, Kotlin, JS, TS, 1С и имеет большой опыт работы с SQL-базами данных.
Привет, Хабр! Я Владимир, архитектор департамента больших данных в РСХБ. В команде РСХБ.Цифра руковожу проектом по внедрению решения для CDC-репликации данных на базе отечественного программного продукта Датафлот Репликация. Наступила эпоха импортозамещения, и в последние годы большинство компаний столкнулось с необходимостью отказаться от привычных классических инструментов и архитектурных решений. Для нас, Россельхозбанка, 100% которого принадлежат государству, по очевидным причинам проблема импортозамещения особенно актуальна.
Нашей целью было обеспечить бесшовное переключение систем с замещаемых СУБД, миграция их данных, замена cdc-инструментов поставки данных в ХД в рамках задачи импортозамещения иностранного ПО в банке. В этой статье расскажу про наш подход к этому вопросу с практической точки зрения. Про и контра — с точки зрения не маркетинговых фраз, а сугубо практического «вам шашечки или ехать?». Возможно, не все согласятся с приведёнными критериями и аргументами, что повлечёт холивары в комментах, но… тем лучше. Будет больше осознанности при выборе правильного решения.
WAL — один из ключевых компонентов внутреннего устройства Postgres. Файлы WAL для истории бэкапов ужимаются в несколько раз, что говорит об избыточности. Изменяя физические параметры кластера, можно существенно повысить и эффективность локальной записи, и пропускную способность репликации, а можно создать неприятные инциденты.
Привет, Хабр! Я — Андрей Бородин, работаю над Postgres и Apache Cloudberry для Yandex Cloud и вообще. Поддерживаю WAL-G, SPQR, Odyssey и всякое такое. В этой статье на основе доклада для конференции Saint HighLoad++ я расскажу о причинах избыточности, о действиях сообщества, а также о своей работе в рамках подсистемы WAL. Понимание работы WAL поможет вам проектировать ваши сервисы с учетом специфики этой подсистемы.
10 марта Google выкатил Gemini Embedding 2 - embedding-модель, которая умеет превращать в векторы не только текст, но и картинки, видео, аудио и PDF. Причем все это ложится в одно векторное пространство. Раньше если вы хотели искать по видеобиблиотеке через RAG, приходилось городить огород: транскрибировать аудиодорожку, описывать кадры через Vision LLM, склеивать в текст, и только потом эмбеддить. Каждый шаг - потеря информации. Теперь можно скормить модели MP4 напрямую, и текстовый запрос «как настроить авторизацию» найдёт и статью из базы знаний, и фрагмент видеоинструкции.
Но сама по себе модель не решает проблему. LLM не может «прочитать» MP4, поэтому найденное видео без текстового описания - может быть бесполезно. Ключ - в правильной архитектуре: нативный эмбеддинг для поиска + параллельная генерация текстового описания для LLM: два канала, которые работают вместе и выводят мощь RAG наполную катушку.
В этой статье разберем что нового в Gemini Embedding 2 и построим полноценный мультимодальный RAG с нуля - Python, Supabase, Gemini API.
P.S. С кодом.
Есть один миф про ClickHouse - он плохо джойнит. Подавляющее большинство не знает, с чем это утверждение связано, и просто верят на слово. А дальше срабатывает эффект сарафанного радио. В итоге в IT-сообществе есть твердое убеждение, что ClickHouse плохо джойнит. Но для меня апогеем стала статья от школы обучения программированию, в которой написано, что ClickHouse вообще не умеет джойнить:
Российский бизнес переживает эпоху «Великого перехода». Санкционное давление и уход западных вендоров заставили компании в спешке мигрировать на отечественное ПО. Но гонка за новыми платформами обнажила старую как мир проблему: наши системы полны «мусора».
На многочисленных проектах по миграции с SAP и западных CRM на российские решения наблюдается одна и та же картина: бизнес ждет «магии» от новой системы, а получает перенос хаоса. Аналитики и ИТ-специалисты приходят к выводу: битва за качество данных проигрывается не из-за отсутствия талантливых разработчиков, а потому что бизнес-анализ как дисциплина в России до сих пор не воспринимает данные как стратегический актив.
В этом цикле будут разобраны три фатальные ловушки, в которые попадают компании, и главное — предложены пошаговые рецепты спасения, основанные на реальной практике и современных методологиях.
Почему SUM() OVER (ORDER BY ...) иногда даёт неожиданный результат, даже когда запрос синтаксически правильный? В статье на практических примерах разбираю, как работают оконные фреймы в SQL, чем отличаются ROWS, RANGE и GROUPS, где чаще всего возникает путаница и как писать накопительные итоги и скользящие метрики без сюрпризов. Если используете оконные функции в аналитике, этот разбор поможет сделать их поведение предсказуемым и управляемым.
Всем привет! Я Игорь Эльяс — бэкенд-разработчик, сейчас работаю в МТС Веб Сервисы. Однажды мне досталась задача «перенести приложение в другую БД, за XX времени», где ХХ — короткий интервал с точки зрения потенциального объема работ при подходе «переделываем все по-нормальному — на Entity Framework» :-)
Проект на C#, изначальная БД — MS SQL + мы использовали самодельный ORM. Возможно, вы сейчас подумали — «очередное легаси!». И да и нет. Проект родился еще во времена Framework 2.0, но регулярно обновлялся и сейчас работает на .NET8. Он пережил десятки циклов рефакторинга, поэтому не безнадежен для доработок.
В материале расскажу, что мы в итоге решили со всем этим делать, почему и для чего выбрали именно Dapper, а еще — познакомлю вас с мощным, но малоизвестным инструментом Dynamitey, благодаря которому удалось выполнить все в срок и без лишний приключений.
