SQLite *

Забыли забрать ежедневные гемы или потеряли счёт круткам до гаранта? Рассказываю, как я решил собственную проблему и разработал GachaPoint — бесплатный офлайн‑компаньон для Genshin Impact, Honkai: Star Rail и Zenless Zone Zero без бэкенда и рекламы.

В статье разбираю техническую изнанку проекта для Android (Java / Architecture Components): Зачем использовал «плоскую» таблицу в SQLite (Room) для календаря и как это ускоряет выборки за один запрос, Почему для сетки дней кастомный GridLayout оказался удобнее RecyclerView, Как настроить точные ежедневные напоминания через WorkManager с учётом жестких ограничений Doze Mode в Android 12/13+.

Исходники проекта открыты, буду рад обсудить архитектуру и UI‑решения в комментариях!

Последние несколько лет я, похоже, одержим двумя темами: а) Nix в качестве инструмента для исследования новаторских идей, требующих возможностей перестройки мира; б) замена ELF на SQLite в качестве формата исполняемых файлов. Возможно, вы заметили, что эти две идеи хорошо сочетаются друг с другом.

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

Одним из результатов этого исследования стал инструмент sqlelf, позволяющий декларативно исследовать файл ELF при помощи SQL. [Я написал статью arXiv:2405.03883, которую мне не удалось опубликовать]. SELECT name FROM elf_symbols вместо возни с readelf и grep. Это оказалось на удивление просто благодаря использованию виртуальных таблиц для ELF, однако мне всё равно было интересно исследовать формат файлов ELF. Но всё же я понимал, что можно сделать нечто гораздо большее.

Меня всё не покидала эта мысль, а в свете прогресса LLM мне показалась привлекательной идея исследовать эту тему глубже. В частности, мне было любопытно, что будет, если мы заменим ELF на SQLite в качестве формата исполняемых файлов?

Не просто «база данных, описывающая исполняемый файл», а реальный файл, с которым можно сделать chmod +x и запустить его.

Сайт не сломан. Он открывается. В логах чисто, ошибок нет — просто ты кликаешь по вкладке и успеваешь заметить, что кликнул.

Я померил: страница кабинета грузилась 2,1 секунды. При этом сервер отдавал HTML за 30 миллисекунд. Первый час я искал не там — потому что померил не ту страницу.

Всё решил один замер. Я дёрнул один и тот же CSS-файл десять раз с кукой сессии и десять раз без неё: 55 мс против 14 мс. За файл с диска. Оказалось, аутентификация делала SELECT, UPDATE и COMMIT в SQLite на каждую картинку и каждый скрипт — сорок раз за страницу, чтобы сорок раз переписать один и тот же таймстамп.

Вторым тормозом был Tailwind, который компилировал стили в браузере у каждого посетителя. Стало 0,9 секунды.

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

Код открыт

Цена запроса не зависела от того, что ищешь: фильтр стоял над GROUP BY. Теперь отсечение идёт до агрегата, на трёх движках, без единой правки в коде приложения. До 100 раз на диапазоне по дате и в 5,3 раза на полной выборке в MS SQL Server.

Есть класс проблем производительности, который не видно на маленьких данных и невозможно не заметить на больших. Наш выглядел так: запрос искал один редкий номер заказа среди сотни тысяч объектов ровно столько же, сколько поиск, не находящий ничего. Избирательность условия не влияла на время. Совсем.

Причина оказалась в форме сгенерированного SQL. Значения props живут построчно, и запрос сначала сворачивает их в широкую строку через GROUP BY, а уже потом применяет фильтр. Условие стояло над агрегатом, то есть фильтровало результат свёртки, а не колонку. Индексу там зацепиться не за что: к моменту проверки движок уже прочитал и свернул все значения всех объектов схемы. Триграммный индекс по строкам лежал без дела.

В 3.7.1 появился шаг, который ...

И так, что мы имеем и для чего же собственно эта статья? Когда человеку ставят задачу в духе «Придумай пароль» — он берет и генерирует самостоятельно некую псевдослучайную последовательность, что в будущем именуется паролем (или с помощью генераторов паролей, которые встроены во все популярные браузеры, или с помощью установленных утилит). Казалось бы, можно и так понять, что самые часто используемые слова в духе «мама», «папа», «пароль» и другие — вполне объяснимы. Это то, что нас в большинстве своем объединяет, а потому может намного чаще встречаться в паролях. Не все люди хотят заморачиваться и отказываться от простых и понятных аналогиях. На примере старшего поколения моей семьи (бабуле) могу хоть сколько раз подтвердить, что ее излюбленный пароль был именем дочери и годом ее рождения.

А ведь в таких псевдо случайных генерациях можно встретить «проблему раскладки» (то, что проанализировано было в русском сегменте только в 2025 году следующими лицами: Леа Мюллер, Аушриус Юозапавичюс, Владимир Охримчук, Стефан Зюттерлин в работе «Поиск в словаре с использованием преобразованных русских слов на клавиатуре QWERTY», P. S. я мог допустить ошибки в переводе информации, за что прошу прощения). Если кратко, то это создает некую «маску», зная которую можно облегчить взлом. Подобные словари встречаются в открытом доступе, и еще чаще встречаются в недоброжелательном сообществе за разные суммы денег.

Широкое распространение СМИ в сети привело к формированию группы тематических экспертов — лидеров общественного мнения — блогеров. Их задача — оценка и анализ фактов, подача информации через призму собственного мнения.

Закономерно, мысленное упражнение, как человек, оставивший след в истории, оценил бы тот или иной современный факт.

Офлайн-хранилище со сложным графом и outbox: быстрый старт в MAUI и в браузере, базовые операции и почему в этой роли EF Core только мешает.

Курьер спустился в подвал склада — связи нет. Кладовщик третий час принимает поставку в зоне, где вайфай добивает через раз. Пользователь заполнил форму на четыре экрана и нажал «Сохранить» в момент, когда сервер уехал на деплой.

Приложение должно продолжать работать. Значит ему нужна своя база на устройстве: не кеш ответов, а полноценное локальное хранилище, где живут незавершённые документы, локальные состояния и очередь изменений на отправку — тот самый outbox, который дошлёт всё, когда связь вернётся.

И вот тут начинается знакомое.

История о том, как сервис логирования Discord-серверов прошёл путь от сложной связки MySQL + PHP + Python до простого решения на Python + SQLite в одном Docker-контейнере — и почему упрощение стека того стоило.

Когда говорят «энтерпрайз-стек на .NET», обычно имеют в виду зоопарк: база от одного вендора, шина от другого, ORM с миграциями, отдельный оркестратор, ещё что-нибудь для наблюдаемости — и клей между всем этим, который пишешь сам и потом сам же чинишь по ночам.

Мы пошли другим путём и последние полгода собираем это как одну согласованную экосистему: типизированное хранилище redb поверх Postgres/MSSQL/SQLite, интеграционный движок redb.Route (наш ответ Apache Camel под .NET) и рантайм redb.Tsak с дашбордом, hot-reload и кластером. Три слоя, один код, один стиль.

Сегодня вышла версия 3.3.0 — синхронный бамп всей экосистемы. Это не «добавили пару фич»: это релиз, в котором мы починили то, что молча не работало под нагрузкой (и это, пожалуй, главное), добавили два новых транспорта, довели до конца RAG-петлю для LLM и сделали конкурентность на любом источнике. Ниже — по делу, с кодом.

И сразу главное: с версии 3.3.0 все Pro-решения бесплатны. Никаких лицензий, никаких ключей, никакой регистрации — просто ставишь пакет и юзаешь. Change tracking, bulk, продвинутый кэш, аналитика, кластер Tsak с координатором и failover — всё включено из коробки, в разработке и в проде одинаково. dotnet add package redb.Postgres.Pro — и оно работает. Никакого пейволла, никакого лицензионного сервера, ничего активировать не надо.

Эта статья прежде всего будет полезна студентам и начинающим специалистам.

В отрасли разработки программного обеспечения под системным дизайном (System Design) понимают процесс проектирования архитектуры, компонентов, баз данных и связей информационной системы. Цель системного дизайна - обеспечить масштабируемость, отказоустойчивость и высокую производительность системы, в том числе при росте нагрузки. В этой статье я затрону базовые задачи системного дизайна - как спроектировать и разработать систему так, чтобы она обладала архитектурой, чтобы развитие и поддержка системы не приносила много страданий, чтобы доработки не ломали действующий функционал.

"Если вашего бизнеса нет в Интернете, то вас нет в бизнесе! Скоро на рынке останется два вида компаний: те, кто в Интернете и те, кто вышел из бизнеса." 

А потом вдруг интернета не стало и нужно было срочно что-то придумать для работы нашей ERP-системы оффлайн

Серия: redb ecosystem (инженерный разбор после анонса 3.2.1)

Когда вышел SQLite-провайдер 3.2.1, анонс был на пару абзацев: «тот же LINQ, одна строка в DI». Эта статья — противоположность анонса. Здесь не «что вышло», а как оно устроено и где у нас потекло. Конкретно: как движок запросов redb переехал в нативное C-расширение там, где у базы нет хранимок; как мы храним DateTimeOffset в базе, у которой нет типа «дата»; и три бага из этого релиза, разобранные с фильтр-JSON, сгенерированным SQL и фиксом.

Это длинно и с кодом. Если хочется коротко — читайте анонс по ссылке выше. Если интересно, что под капотом «одной строки в DI», — устраивайтесь.

Я хотел написать маленький локальный RAG для научных статей: графы, hybrid search, HyDE, reranker, всё красиво. В итоге Full Pipeline проиграл почти всем простым baseline’ам, графы начали портить контекст, HyDE вредил, а локальная LLM уверенно делала вид, что всё хорошо. Потом я разобрался, что ломалось, выкинул лишние LLM‑вызовы, починил trimming и получил систему, которая, наконец, начала выигрывать там, где должна.

"О спорт, ты — мир!" — это замечательная фраза основателя современных Олимпийских игр Пьера де Кубертена.

И с этим трудно не согласиться, ведь спорт, не только укрепляет здоровье но и объединяет людей. В этой статье я хочу рассказать, как я объединил некогда популярный вид состязаний "Охота на лис" с современными технологиями, ведь его основные принципы лежали в плоскости геолокации и радионаблюдения. Рожденный ещё в далекие 50-е, этот вид спорта неумолимо двигался по планете привлекая все больше и больше своих поклонников.

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

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

Полторы недели назад я выложил на Habr бота с лентой хороших новостей на sqlite-vec за $5/мес. Потом пришли живые юзеры — и началось самое интересное. Не код. Эксплуатация.

За 10 дней в проде:

🪦 Бот дважды умирал незаметно — поллил Telegram и казался живым, но не создавал ни одной новости по 4–5 дней. Один раз — OOM на загрузке модели, другой — feedparser.parse(url) без таймаута заморозил весь пайплайн.

📉 Метрика релевантности «рухнула» до 30% — и я чуть не откатил рабочую фичу. Оказалось, один юзер поставил 106 дизлайков из 228 и отравил и метрику, и приор источников. Починил, считая по уникальным юзерам — правда оказалась 42%.

🎯 Реакции 78 человек сами показали, какие источники выкинуть: tech-аудитория отвергает общие новости и любит курируемое.

Внутри — реальные логи, код фиксов (httpx-таймаут, watchdog, робастные метрики) и уроки про надёжность воркеров и доверие к цифрам.

👉 @futur_e_news_bot

В базах данных в качестве первичных ключей часто используют случайные UUID. Один из известных недостатков случайных UUID заключается в том, что их неупорядоченность (UUID4) может вызывать большое количество дополнительных обращений к страницам кластеризованных индексов (clustered index), потому что строки вставляются в случайные места B-дерева, и его приходится постоянно перебалансировать. В этой статье я попытаюсь помочь вам выработать более интуитивное понимание того, как влияют на производительность все эти дополнительные операции со страницами.

Хотя статья посвящена конкретно SQLite, проблема случайных UUID касается и других баз данных, использующих кластеризованные индексы.

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

Поэтому я сделал Hermes Codex Plugin — плагин, который хранит правила, summaries и прошлые решения в SQLite, ищет их через FTS5 и подкладывает Codex только маленький релевантный кусок контекста.

Если вы работаете с базами данных и используете ORM, вы, вероятно, сталкивались с той же проблемой, что и я. ORM отлично подходят для отображения таблиц на объекты. Но они начинают мешать, когда запрос становится сложным: агрегации, тщательно продуманные JOIN’ы, формы отчетов, которые не соответствуют одной модели на таблицу. Вы боретесь с ORM, переходите на сырой SQL, а затем вручную пишете связующий код (маппинг).

Не каждый SELECT возвращает то, что подходит под одну ORM-модель. SQL - это лучший язык для доступа к данным. Лучшие ORM, которые я использовал, такие как Drizzle, побеждают, потому что они остаются близки к SQL. Я хотел пойти дальше: хранить SQL в системе контроля версий и генерировать из него типизированный Python.

Именно поэтому я создал nORM (no ORM - не ORM) и выпустил версию v0.1.0 на этой неделе (мой первый опенсорс проект).

Хотел ленту новостей без двух вещей: дублей (одно событие из пяти каналов с разными заголовками) и потока негатива по утрам.

Получился Telegram-бот, который по умолчанию показывает только хорошие и нейтральные новости — а тяжёлый контент включается в настройках на 4 уровнях. Плюс он убирает дубли, переводит RU↔EN и подстраивает выдачу под твои реакции 🔥 ❤️ 😢.

Но самое интересное — он живёт на одной машине Fly.io за ~$5 в месяц. В статье разбираю, как:

заменил Postgres + pgvector на встраиваемый sqlite-vec и убрал отдельную БД-машину;

гоняю типизацию, перевод и оценку тональности через бесплатные LLM на OpenRouter (счёт $0–1/мес);

считаю эмбеддинги локально на fastembed/ONNX без внешних API;

собрал рекомендательное ядро на «векторе вкуса» с EWMA и анти-баблом.

И, конечно, грабли: sqlite-vec, который ломался на arm64; vec0 без INSERT OR REPLACE; fastembed, сменивший пулинг между версиями; и LLM, которая «подкручивала» оценки негатива, пока я не дал ей чёткую рубрику.

👉 Бот живой, можно потрогать: @futur_e_news_bot

Мне нравится чистый SQL.

Не «нравится, потому что пришлось», а правда нравится. В хорошем SQL‑запросе видно, что происходит с данными: откуда берём, как фильтруем, где соединяем, что агрегируем и в каком порядке отдаём наружу.

Но как только в API появляются фильтры, сортировка, пагинация и отдельный COUNT(*) с тем же WHERE, чистый SQL быстро обрастает ручной бухгалтерией: args, placeholder«ы, fmt.Sprintf и копирование условий между запросами.»

В какой‑то момент я понял, что меня раздражает не SQL. Меня раздражает работа вокруг SQL.

Так появился qrafter — небольшой type‑safe SQL query builder для Go: без ORM, без codegen, с типизированными колонками, зависимым от диалекта рендером и обычным SQL + аргументами на выходе.