SQL *

Если говорить о внедрении систем видеомониторинга на стройку, то здесь стоит отметить важный фактор. Речь идёт об обучении модели непосредственно для внедрения на объект. В этом материале расскажу про данные, классы, разметку, особенности датасета и другие параметры, которые стоит учитывать при масштабировании системы.

Минимальный объём данных, необходимых для работы

Основываясь на своём опыте, скажу, что для обучения одного класса необходимо примерно 3-4 тысячи размеченных изображений. Это число не будет универсальным минимумом для любой нейросети, это больше рекомендуемый стартовый объём в рамках того подхода, с которым мы работаем.

Сложность классов, а также разнообразие условий здесь играют важную роль. Если объект крупный и его легко различить, то нам потребуется одно покрытие. Если же объект маленький и находится на заднем плане, то в таком случае необходимо другое покрытие. Иногда приходится использовать сотни тысяч реальных размеченных кадров, и тогда, как правило, применяется аугментация. Чтобы проверить, готова ли модель к production, нужно прогнать её на тестовой выборке. Если данных много - это хорошо, но важно понимать, представлены ли в этих данных условия, в которых системе предстоит работать.

Я работал над архитектурой LibreDB Studio — IDE для баз данных на TypeScript, которая поддерживает несколько SQL/NoSQL баз данных.

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

Я долго ходил по конференциям, у меня хороший нетворк, и все это длительное время я наполнял CRM контактами, результатами звонков, переписками, договорённостями и тд.
В какой-то момент в ней оказалось почти 10К человек и вся моя история отношений с ними.
Но накопить данные конечно легче чем применять их так, чтобы была максимальная польза. Чтобы CRM приносила эту пользу, я должен помнить, кого и как там  искать, какие фильтры включить, что делать дальше и как масштабировать это.

Я хотел автоматизировать почти всё.

Привет, Хабр. Я хочу рассказать историю, которую вы уже, наверняка, где-то слышали. Только с другой стороны.

Пару месяцев назад я сидела на созвоне с техдиром стартапа, который делал RAG-систему для юридических документов. Он сказал, что они уходят с Postgres на Pinecone, потому что Postgres для векторов не тянет, это же очевидно. Я спросила, сколько у них векторов. Оказалось, тысяч двести, может, триста. Я уточнила, пробовали ли они вообще pgvector. Выяснилось, что нет, решение приняли по общему ощущению, что Postgres для этого не годится. Ощущение было не на пустом месте, два года назад так и было. Я не стала спорить. Просто открыла документацию pgvector и скинула ссылку. Через неделю он написал, что оно работает. Даже быстрее, чем они думали. Ещё через месяц они запустили прод. На одном Postgres. Без Pinecone. Без отдельной векторной базы. Без трёх месяцев инфраструктурной работы, которую они уже успели запланировать.

И это не единичный случай. Мне кажется, что это паттерн. И я хочу разобрать его по частям, потому что за последние пару лет я видела этот сценарий минимум пять раз в разных вариациях, и каждый раз он заканчивался одинаково.

В прошлой статье про PostgreSQL я разбирал три инцидента на стороне базы — блокировки, bloat и ночные пересчёты. В комментариях несколько человек написали примерно одно и то же: «база базой, а покажи, что творилось на стороне приложения — пул-то небось тоже горел».

Горел. Ещё как.

Это продолжение того же разбора, но на слой выше — про HikariCP, дефолтный пул соединений в Spring Boot. Тот самый, который «просто работает», пока не перестаёт. Проекты те же, что и в статье про миграцию и в статье про PostgreSQL: банковская система после переезда с Oracle (терабайт, 70+ таблиц, 500–3000 RPS на чтение и 50–300 на запись в пике) и enterprise-платформа на Java/Spring, где PostgreSQL жил под Hibernate. Разные команды, разные нагрузки, но сюжет один: сервис встаёт, в логах Connection is not available, и первое, что делает любой человек, — лезет крутить maximumPoolSize. И почти всегда делает хуже.

Это не туториал «как настроить HikariCP за 10 строк». Таких на Хабре хватает, и половина из них сводится к «поставьте пул побольше». Здесь — список мест, где у нас всё ломалось, в порядке от «это все знают, но всё равно наступают» до «поняли только в проде под нагрузкой».

Если вы сейчас живёте на HikariCP — читайте как чеклист. Если уже прошли через это — сверьте, сколько совпало.

Дисклеймер: проекты под NDA, названия, точные объёмы и часть деталей изменены. Порядок величин, конфиги и сами инциденты — настоящие.

SQL-запрос выполнился без ошибок, дашборд обновился, цифры выглядят правдоподобно — и всё же выручка внезапно выросла на треть. Причина может скрываться в одном JOIN, незаметном NULL или неверной границе периода. Разбираем семь ошибок в SQL-агрегациях, которые не ломают запросы, зато вполне способны сломать выводы из данных.

Сразу оговорюсь: я из команды LibreDB Studio, и статья — про наши собственные грабли. LibreDB Studio — это self-hosted IDE для СУБД, работающая в браузере: один инстанс разворачивается рядом с базами, а не устанавливается на ноутбук каждого разработчика. Команда открывает URL — и почти сразу упирается в вопрос, который сожрал у нас не один спринт: как показать результат из четырнадцати принципиально разных движков в одной таблице и при этом не начать выдавать пользователю выдумки за реальные данные.

В прошлой статье я рассказывал, как мы перевозили терабайт банковской базы с Oracle на PostgreSQL без даунтайма. Там был раздел про производительность, и в комментариях несколько человек спросили примерно одно и то же: «а что конкретно вы дебажили и как?».

Это продолжение. Три инцидента из двух разных проектов — банковской системы после миграции и enterprise-платформы на Java/Spring, где PostgreSQL жил под Hibernate. Разные домены, разные команды, но сюжет один: запрос, который вчера работал, сегодня не работает, а EXPLAIN показывает, что всё хорошо.

Если вы пришли в PostgreSQL из Oracle или из мира, где база — это «то, куда ORM пишет», три четверти статьи будут про вещи, о существовании которых вы не подозревали. Я тоже не подозревал.

Дисклеймер: проекты под NDA, названия, объёмы и часть деталей изменены. Порядок величин и сами инциденты — настоящие.

Разбираем на практическом примере, как в Manticore Search выбрать несколько последних элементов из каждой группы и собрать их в одну строку.

На Apache Superset я перенёс один отчёт. Одна таблица, пара графиков, день работы. Это была годовая цель: показать, что умею. Пользуются при этом по-прежнему исходной версией в Power BI.

Перенос в компании идёт всерьёз: есть коллеги, которые публикуют на Superset отчёты десятками. И чем ближе отчёт к одной таблице, тем легче он едет. Мои — не такие.

Поэтому я открыл свою самую тяжёлую модель — 22 таблицы, 206 колонок, 86 мер — и прочитал её целиком. Двадцать мер из восьмидесяти шести меняют расчёт в зависимости от того, до какого уровня развернули матрицу: из-за них сверка «итог в итог» после переноса сходится идеально и ничего не доказывает. Шесть производственных договорённостей зашиты прямо в формулы и не описаны больше нигде.

Разбираю, что на самом деле переносится при миграции BI и почему документацию в ландшафте на 800+ отчётов придётся отдавать машине.

Маркетолог прислал мне скрин дашборда и одно слово: «пусто».

На скрине — панель «Количество пришедших по реферальной ссылке за период». Ноль. Под ней — график регистраций. Тоже ноль. Ссылка, по которой он пришёл, вела на дашборд с фильтром по конкретному slug — тому самому, который он неделю крутил в закупке.

Я открыл ту же ссылку, поменял в урле from=now-6h на from=now-30d и увидел 16 регистраций.

Дефолтный интервал в Grafana — 6 часов. У бота ночью в этой гео никого нет. Аналитика работала идеально и показывала абсолютно честный ноль.

Это самая безобидная из историй, которые тут будут. Дальше — про то, как мы строили продуктовую аналитику для Telegram-бота с AI-персонажами на ~300K MAU, ~75 RPS в пике и ~1.5M событий в день: без ClickHouse, без Amplitude, без единой event-таблицы. Двенадцать дашбордов в Grafana поверх боевой MySQL. Три из них какое-то время врали, и это выяснилось не сразу.

Главный парадокс всего проекта помещается в одну строку: через систему проходит полтора миллиона событий в день, и ни одно из них не записано как событие. Есть только строки в продуктовых таблицах и их created_at. Всё, что вы прочитаете ниже, — следствие этого факта.

Статья — не туториал «подключите MySQL к Grafana за 10 шагов». Это разбор того, что происходит, когда продуктовые метрики приходится доставать из схемы, которую проектировали под продукт, а не под аналитику, — и когда по этим метрикам прямо сейчас решают, лить трафик дальше или нет.

Дисклеймер: проект под NDA, поэтому названия, точные объёмы и часть деталей изменены. Порядок величин, схема и сами проблемы — настоящие.

Как организовать регулярную выгрузку данных из 1С, если ручной экспорт уже не справляется с объемом и частотой обновлений? В статье сравниваются два подхода: прямой доступ к базе через SQL и использование готового ETL-инструмента. Разбираем скорость, сложность настройки, требования к специалистам, риски для безопасности и сопровождения системы. Также показываем, в каких случаях оправдан SQL, а когда удобнее использовать готовый инструмент для автоматической выгрузки данных по расписанию без постоянного участия разработчика.

Инженеры данных построили агрегат — маленькую таблицу «продажи по магазинам по дням». Отчёт из неё собирается за доли секунды. А сводная в Excel всё равно ждёт двадцать секунд и читает миллиард строк.

Разбираемся на живом ClickHouse, почему база не видит предагрегат, который для неё построили, какая форма запроса это лечит (одна и та же для ClickHouse, Snowflake и BigQuery) и почему в итоге вопрос не к базе, а к семантическому слою. Внутри — замер на миллиарде строк: 3 секунды против 37 миллисекунд, сравнение восьми баз и одно правило, которое стоит проверить в своём BI.

Практическое руководство по поиску длинных хешей, event ID, message ID и email в Manticore Search: лимиты, точное сравнение, wildcard-поиск, токенизация, миграция и ограничения.

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

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

Я уже думал писать статью, но решил мимолетом запустить 175 воркеров. Это решение создало неожиданную проблему - задача оказалась обработана за 11 секунд до ее создания.

Привет, на связи команда BI-разработчиков коммерческого департамента: Алексей Дубинец и Павел Беспалов. 

В статье расскажем, как построили пайплайн миграции наших витрин с помощью локальной LLM. 

Сразу оговорюсь: это не история про то, как мы дали в Codex или Claude Code, написали скилл и получили магический результат. Покажем инженерную часть задачи: где локальная модель срабатывает не так, какие наивные решения не работают и что пришлось построить вокруг неё, чтобы перевод стал воспроизводимым.

ora2pg переносит схему с Oracle на PostgreSQL, и в целом переносит хорошо. Интересное начинается там, где он чего-то не осилил: он не падает и не ругается, а молча делает не то.

Процедура с AUTHID исчезает из вывода целиком, без ошибки и без строки в логе. TO_DATE с форматом RR молча возвращает 1 год до нашей эры. LONG RAW превращается в text, хотя сам ora2pg документирует bytea. Обработчик исключений после конвертации ловит SQLSTATE, которого PostgreSQL не возбуждает никогда.

Двадцать таких мест, все проверены на реальном ora2pg 25.0 и живом PostgreSQL 16, по каждому написано чем чинить.

Большой текст пугает: часть читателей уходит на середине, часть пролистывает не читая. Поэтому дальше — только факты, действия и последствия: что изменилось в метаданных, как это изменение попало в production и что в итоге получилось — результат, который до сих пор помогает находить источник проблем.

1. Зачем это нужно

Моя боль как автора (а я не только программист и к. т. н, но еще и писатель в жанре фантастики) – это отсутствие на сайте автор.тудей полноценного анализа статистики. Вся статистика ограничивается просмотрами, временем и средним временем прочтений по дням и главам, в виде шахматки:

В статье разбираем реальное тестовое задание на позицию аналитика DWH: четыре коротких SQL-запроса. Все синтаксически корректны, все дают верный результат на контрольных данных. И в каждом спрятана предпосылка, при нарушении которой цифры в витрине становятся неверными — без ошибок, без предупреждений, просто другие числа в отчёте