SQL *

Небольшая команда сделала мод-социальную-сеть для Minecraft, который объединяет в общий граф друзей игроков на любых поддерживаемых версиях клиента — от 1.7.10 до 1.21.1. Поддерживаются три популярных загрузчика модов и любые клиенты Minecraft, как лицензионные, так и офлайн. Серверная часть, веб-админка, обвязка и документация — всё своё.

Главное, что хотелось рассказать: дисциплина (не скорость) была решающим ресурсом, и категория продукта изменила правила игры настолько, что классическая формула «MVP на одной версии — потом расширяемся» оказалась контрпродуктивной.

/В последней версии HQBird Server 5.0.4 появились так называемые материализованные представления. В данном вебинаре мы поговорим о том, что это такое, как с ними работать, как вы можете использовать их у себя для ускорения некоторых аналитических выборок. Будет представлен небольшой бенчмарк, который показывает, как материализованные представления могут ускорять некоторые аналитические выборки.

Я делаю мессенджер ONEMIX на React Native. К моменту, когда я начал писать этот пост, в нём уже больше десятка экранов, групповые WebRTC-звонки через LiveKit, E2E на Double Ratchet + Sealed Sender, push-нотификации с cold-start навигацией и десктоп-версия на Electron. Но самым важным куском, который определяет ощущение от приложения, оказался не звук и не видео. А то, насколько быстро открывается чат.

Если вы хоть раз делали список сообщений на React Native, вы знаете эту боль: открыл чат — пустой экран на 200–800 мс, потом подгрузка, потом скачок при докрутке наверх. В Telegram такого не бывает: открыл — мгновенно увидел последние сообщения, прокрутил наверх — никаких пустот, история идёт сплошной лентой.

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

bigram_index можно использовать для разных задач, но в этой статье мы говорим именно о производительности поиска фраз: в приведённом ниже бенчмарке на 1 млн документов bigram_index='all' повысил QPS примерно в 2.9x и сократил среднее время ответа фразовых запросов примерно в 3.2x.

Если ваша основная проблема — сопоставление xt850 с xt 850, а не ускорение поиска фраз, см. Как заставить xt850 совпадать с xt 850 .

Поиск по фразам бывает дорогим. Даже если запрос короткий, движку всё равно нужно проверять порядок слов и стоят ли они рядом, и это особенно заметно, когда:

Хочу рассказать про баг, который я искал полтора дня и который оказался опечаткой длиной в одну инструкцию. Если коротко: PostgreSQL (16.4 в моём случае, но воспроизводится начиная с 12-й) не разрешает UNION ALL сразу после ORDER BY ... LIMIT N без круглых скобок. И самое неприятное - ошибку об этом я узнал последним, потому что между моим SQL-запросом и логами стояло пять промежуточных слоёв, каждый из которых её по-своему проглотил.

Расскажу как нашёл, как фиксил, и что в итоге добавил в pre-deploy чек-лист.

Книги по SQL — стабильные бестселлеры в мире компьютерной литературы. Они нужны начинающим аналитикам, бэкэнд-разработчикам, тестировщикам, инженерам по автоматизации и всем, кто работает с данными. Но при этом у большинства таких книг есть одна проблема: они либо слишком академические, либо слишком фрагментарные. В итоге новичок вроде бы читает про операторы SELECT, JOIN и GROUP BY, но не чувствует, что может уверенно применять язык SQL в реальной работе.

1. Введение. Trino: ключевые задачи и главные преимущества

В современной архитектуре управления данными ETL‑процессы рассматриваются не как вспомогательный инструмент, а как базовый механизм интеграции, трансформации и подготовки данных, поступающих из множества гетерогенных источников. Ключевая цель этих процессов — избавиться от хаоса и разрозненности данных, которые почти всегда появляются в больших распределенных компаниях [1].

В рамках ETL‑конвейера выполняется автоматизированное извлечение данных из различных источников, их очистка, нормализация и приведение к единой модели, после чего подготовленные данные загружаются в централизованное аналитическое хранилище. Это даёт три главных преимущества: обеспечивает высокое качество и согласованность данных, структурирует информацию под нужды бизнес‑отчетности, а также отделяет аналитическую нагрузку от операционных систем, повышая таким образом производительность системы в целом.

ETL возник как вынужденная мера, так как во время его появления (1970–1990-е) не было ни высокоскоростных сетей, ни мощных распределенных движков аналитики, ни концепции Data Lake. Единственным надёжным способом построить аналитическую отчетность было физически извлекать данные из операционных систем и копировать их в отдельную специализированную базу. Именно поэтому ETL закрепился как основной архитектурный паттерн аналитических систем на долгие десятилетия.

Увы, такой подход породил и массу проблем: это дублирование данных, долгие пайплайны, сложные зависимости, задержки обновления и огромные затраты на поддержку. Традиционным ETL‑процессам становится всё труднее справляться с постоянно растущим объемом поступающих данных. Более того, большие сложности возникают при работе с уже накопленной информацией, ведь её требуется хранить на протяжении многих лет, а значит — сохранять возможность глубокого анализа по всей доступной истории.

Привет, Хабр! Несмотря на то, что Cursor в начале «ИИ революции» условно был впереди, сейчас общепринятым ИИ инструментом во многом можно считать Claude, я также пользуюсь Claude как основным инструментом. Но годовая личная подписка Cursor осталась, и токены каждый месяц обновляются, нужно их потратить :) На остатки токенов за выходные решил заняться вайб-кодингом движка DAX на C# — простейший аналог VertiPaq, причем в режиме Auto в Cursor. В результате получился работоспособный движок DAX, естественно, поддерживающий только подмножество языка, а не весь DAX, но зато не привязанный к Windows — не требуется ни Tabular Server, ни Power BI Desktop, ни облачные сервисы, ни виртуальные машины с Windows — DAX движок работает на всех ОС. Интересующимся экспериментами с ИИ генерацией BI движков — добро пожаловать под кат :)

Объектный построитель SQL-запросов без ORM и моделей. Позволяет писать сложные SQL-запросы в виде цепочек Python-методов (table[‘person’].filter(…).join(…).get()) и получать результат в виде списка словарей. Под капотом — параметризованные запросы для защиты от инъекций, продуманная система кеширования с инвалидацией по таблицам (in-memory и Redis), поддержка синхронного и асинхронного кода из коробки. Для тех случаев, когда ORM избыточна, а сырой SQL небезопасен.

Продолжаем серию публикаций «Адаптивное администрирование Sigla Vision». Часть наших подходов будет полезна и другим ИТ-специалистам, которые развивают или сопровождают аналитические системы — особенно те, что хранят метаданные во внешних СУБД.

В этой статье подробно разберем объектную модель BI-системы. Она помогает лучше понимать работу системы, следить за ее состоянием и контролировать изменения.

В предыдущей статье «Адаптивное администрирование Sigla Vision» мы посмотрели на BI-систему «из коробки» глазами тех, кто ее сопровождает: объяснили, зачем нужны дополнительные данные о работе системы и для чего создавать объектную модель, привели примеры задач, где она используется.

Тема нынешней статьи — основа всего нашего дальнейшего опыта работы с Sigla Vision. 

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

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

В этой статье мы не собираемся доказывать, что jsonb плохой тип данных. Наоборот: jsonb – один из самых полезных инструментов PostgreSQL. Хотелось бы разобраться в более узком вопросе:

что именно происходит, когда мы обновляем один ключ внутри большого JSONB-документа, и чем это отличается от обновления обычной колонки рядом с таким же большим документом?

У меня школа тестировщиков. SQL — обязательный блок, потому что без него на собеседовании в любую серьёзную компанию делать нечего, и в реальной работе тестировщику регулярно нужно залезать в базу. На рынке уже существуют (хоть и не так много) SQL‑тренажеры, но мне хотелось сделать удобнее и иметь возможность полностью управлять сервисом и адаптировать под наши нужды. Собственно, ниже, моя разработка.

Привет, Хаброжители! Исправление ошибок в базах данных PostgreSQL может быть трудоемким и рискованным процессом — особенно при внесении изменений в работающую систему в реальном времени. К счастью, можно учиться на ошибках, которые уже совершили другие! Автор подробно описывает, как выявлять и предотвращать самые распространенные, опасные и скрытые антипаттерны проектирования при работе с PostgreSQL.

Думал, зайду в крипту и буду просто дёргать API блокчейна. Не вышло.

Захожу в проект. Стек: FastAPI, PostgreSQL, Redis как Celery broker, Celery workers, Docker, Web3. Стартап на хайпе, деньги реальные, архитектура собрана на коленке. Смотрю на архитектуру платёжного процессинга и первая мысль: ребята, вы серьёзно? Финансовые операции с реальными деньгами, без idempotency вообще, Redis как брокер без persistence, Web3.py синхронные вызовы внутри Celery тасков.

Разговор был короткий: задача такая, чини что есть. Сроки горели.

Привет, Хабр! Меня зовут Евгений Грибков, я ведущий разработчик в центре технологий VK. В этой статье я покажу решение, к которому мы с коллегами пришли при работе над одной из наших внутренних систем.

Достаточно часто бывает так, что нужно сохранить стабильность работы системы вне зависимости от того, какие запросы выполняются в СУБД. Достичь этого можно разными способами. Я покажу одно из специфических решений — реализацию автокиллера: удаление сессий, которые достаточно долго блокируют запросы других сессий, исходящие от пользователей информационной системы.

Всем привет!

На одном из проектов я настраивал дашборд в Yandex DataLens, который объединяет данные о трафике из Яндекс Метрики с данными о заказах из CRM и позволяет анализировать доход в разрезе источников трафика.

В этой статье расскажу, как был выстроен процесс обработки данных и к какому результату в итоге пришёл.

Привет, Хабр! В этой статье я хочу поделиться опытом проведения внешнего black-box пентеста и разобрать методологию, которая позволяет находить критические уязвимости даже при минимальном входном скоупе. Статья будет разбита на две части, про внешний расскажу я, а про внутренний расскажет мой коллега.

Black-box подразумевает, что у пентестера нет никакой внутренней информации: ни списков IP, ни учётных данных, ни описания архитектуры. Только доменное имя - и вперёд. Звучит как ограничение, но на практике это зачастую преимущество: вы смотрите на инфраструктуру глазами реального злоумышленника.

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

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

EXPLAIN ANALYZE часто воспринимается как инструмент, который показывает план выполнения запроса. Но если посмотреть внимательнее на блок BUFFERS, он начинает отвечать на более прикладной вопрос — где именно запрос упёрся в I/O и почему это произошло. В этой статье разберём, как читать эту статистику на уровне отдельных узлов плана, как интерпретировать hit/read в контексте нагрузки и почему сами числа почти ничего не значат без сравнения во времени.

Метрики могут «упасть» даже если вы ничего не меняли в модели.
Разбираемся, как распознать distribution shift и что с ним делать в продакшене.