Справедливое замечание, и вы правы — Amadeus Ticket Changer действительно давно и хорошо автоматизирует пересчёт тарифа при voluntary/involuntary reissue (Category 31/33 ATPCO), это решённая задача, когда весь билет виден одному GDS. Не спорю с этим.
На практике мы так и делали: сначала смотрели, что предлагает каждый GDS сам по себе — это уже оптимальные, провалидированные через-тарифом связки, и в первую очередь оценивали именно их. А варианты из разных источников (self-connect) собирали и сравнивали уже отдельно, вторым шагом, как альтернативу — иногда через-тариф от одного GDS оказывается выгоднее, иногда комбинация из разных источников дешевле, и дальше вопрос уже в том, что важнее заказчику: гарантированная стыковка одним источником или экономия ценой риска и неудобства на пересадке.
Проблема, которую я описываю, начинается именно на этом втором шаге — там, где ATC сам предупреждает о своей границе: "tickets issued through other GDSs... are not guaranteed" Amadeus Fare Guarantee. Речь не о смене маршрута внутри одного билета, а о ситуации, когда решили, что self-connect выгоднее, и маршрут собран из трёх разных источников — три независимых билета, ни один GDS не видит два других. Замена одного плеча в такой конструкции — это не reissue внутри PNR, а согласование между источниками, которые друг о друге не знают. Ни один из GDS эту часть не решает и не может — у них просто нет данных о существовании билетов из соседних систем.
Спасибо за наводку — стоит явно назвать ATC и очертить эту границу в тексте, чтобы не создавалось впечатление, что я не в курсе существующих инструментов.
вообще интересная тема и решил покопаться, в помощь взял нейроку, и вот что вышло ____
Копнул — статья смешивает подтверждённые факты с довольно шаткой причинно-следственной теорией, и есть конкретная нестыковка по датам, которая рушит центральный тезис автора.
Что подтверждается независимо:
Водяной знак — реальный, задокументирован Fortune, TechTimes, Reuters-уровня источниками: с 2 августа 2026, статистическая метка на уровне модели (не невидимые символы), под требования Article 50 EU AI Act, применяется глобально, не только в ЕС. Это не выдумка блогера.
Opus 5 — реальная модель, вышла 24 июля 2026 (это позже, кстати, чем модели из моего собственного системного промпта — то есть для меня это тоже новость постфактум).
Жалобы на многословность и потерю смысла в Opus 5 — тоже реальные, задокументированы независимо (разбор MindStudio, тред на Hacker News, официальный GitHub issue в репозитории claude-code с конкретными измерениями).
А вот тут центральная теория автора (водяной знак → деградация Opus 5) рушится по датам. Жалобы на многословность Opus 5 фиксировались до 2 августа — материал MindStudio датирован примерно 1 августа, тред на HN старше двух недель на момент этой статьи. То есть модель уже жаловались как на "многословную и запутанную" раньше, чем вообще включили водяной знак — значит знак физически не может быть причиной того, что уже существовало до него. При этом в самом GitHub issue есть официальный анонс постмортема Anthropic с конкретными, раскрытыми причинами прошлых просадок качества (баг с уровнем effort, баг с историей размышлений, неудачное системное изменение под многословность) — то есть паттерн "нашли баг → объяснили → откатили" у них уже был, не "молчат и скрывают".
Про "уже вводили в заблуждение насчёт военного использования" — это не бьётся с тем, что реально задокументировано. По многочисленным источникам (CNN, Reuters, Al Jazeera) картина обратная: Anthropic публично и настойчиво отказывалась от неограниченного военного использования (автономное целеуказание, слежка за гражданами США), из-за чего Пентагон демонстративно понизил их статус, а компания в ответ подала в суд на правительство. Это не "скрывали военное использование", а ровно наоборот — публичный, судебный конфликт из-за того, что они слишком жёстко ограничивают именно такое использование. Автор этот пассаж явно не проверял.
Сама статья честно помечена автором как "Мнение" и "моя версия... возможно лишь частично верна" — то есть жанр разрешает спекуляцию. Но конкретно эти два места (причинность с водяным знаком и намёк на скрытое военное применение) не выдерживают проверки по датам и источникам, а не просто "спорное мнение".
Оба выловили не тестами, а на живом приложении: строили на этом же стеке своё — телеграм-бот через redb.Route.Telegram как фронт, а за ним LLM-часть, работающая с оперативными данными. Там и вылезло.
Тесты были — и в этом самое интересное. Они не покрыли эти кейсы, потому что писал их я же и ровно под тот способ использования, который держал в голове. У API несколько равноправных путей, а покрыт оказался мой.
Пример прямо из этого релиза: URI эндпоинтов я всегда писал строкой, а не fluent-строителем. Поэтому расхождение кодека строителя с парсером — значения с пробелами не переживали круговой обход — у меня физически не могло воспроизвестись: этой ветки в моём коде не было. Тест «маршрут работает» проходил, потому что проверял мой путь.
С деревьями последствия серьёзнее. WhereLeaves() замещал корневой CTE вместо того, чтобы быть предикатом поверх него, то есть запрос молча означал «свежайший лист схемы во всей базе». Ошибки нет, ответ правдоподобный — просто не про того. На одном собеседнике это невидимо в принципе; в боте со вторым пользователем видно сразу — человеку приезжает чужая история.
Сейчас оба пути закрыты тестами, фикс дерева ушёл во все шесть провайдерных комбинаций и в нативное расширение SQLite.
Могу тока добавить, что рассчитать стоимость по тарифной сетке, публичные и внутренние цены, плюс система скидок, тоже не простая задача, и связать всё это с 1С.
Понял, спасибо за ссылку — интересный подход с CRDT, особенно семантическая гранулярность вместо посимвольной. Хотя тут немного другая задача: redb.SQLite — это типизированное хранилище с SQL запросами и схемой, а outbox в статье — сознательно простой конфликт-хендлинг под контролем приложения. CRDT-синк — это скорее слой ниже/сбоку, не альтернатива типизированному стору. Возьму на заметку, спасибо.
Спасибо! А что вы имели в виду под "гипер базой" — можете уточнить? Тут в статье клиентское хранилище (SQLite прямо в приложении/браузере, без сервера), не совсем понимаю, в какой момент она бы пригодилась.
статья про клиентское хранилище: SQLite встроен прямо в приложение (на телефоне) или в браузер, без сервера вообще. HyperBase — это managed-хостинг для серверного Postgres, он для другого сценария (там, где redb.Postgres/redb.MSSql). Если интересно — у меня есть статьи и про серверную часть, там как раз к месту.
спасибо за уточнение — DETACH PARTITION перед DROP корректнее на нагруженных таблицах. Основная тема статьи — планировщик, пример очистки был иллюстративным.
@lazarus_net гоняю тесты с нейронкой, и я забыл вогнать поля, да и не было нужды в них, но тест дал варнинг, нейронка увидела и добавили и вот что пишет сама
Критика принята по части стиля — буду работать над этим. Однако мне либо код писать, либо стьатьи оформлять, я один и у меня нет за плечами корпораций и миллионов. НО, оно работает, и в компании один за другим переводят проекты на redb экосистему, потому что дешево. Бизнес не интересует как ты написал, бизнес интересует быстро кратко поддерживаемо расширяемо и много функционала.
По существу: redb.Core не скрывает SQL, а убирает необходимость писать DDL вручную. Под капотом — типизированные колонки (_Long bigint, Numeric numeric(38,18), DateTimeOffset timestamptz), FK с CASCADE, индексы, CTE для деревьев. Всё это видно через ToSqlStringAsync() и get_object_json() прямо из psql.
Два года в проде на реальной нагрузке (150k заказов/месяц, 3-нодовый кластер) — если интересно как это работает под капотом, серия "REDB изнутри" как раз об этом.
А redb.Route позволяет писать интеграции — и весь бэк — значительно быстрее. redb.Tsak разворачивает приложение сразу на уровне enterprise: hot-reload, кластер, дашборд из коробки.
Жду технической критики — именно её не хватает в комментариях. С тех. аргументами.
Да, я не копирайтер и не техWрайтер — пытаюсь поделиться с сообществом тем что реально работает и позволяет достигать цели значительно быстрее.
Дополню про концентрацию вендора — она тут слабее, чем кажется. Ядро, движок, коннекторы и рантайм открыты: заброшенность лечится форком, supply chain — аудитом (а в век LLM прошерстить всё дерево это вечер, а не неделя). Pro-слой закрыт бинарём, но, во-первых, раздаётся бесплатно и без лицензионного сервера на всей линии 3.x — «рубильника» у вендора нет; во-вторых, компаниям, которым нужен исходник, я отдаю его по запросу. Так что и тут это не lock-in, а обычный риск «поставщик может остановиться» — с открытым ядром и доступным по запросу Pro это не тупик, а форк.
Согласен с самим принципом: изоляция отказов реальна, и если бы обновление шины насильно тянуло за собой перевыпуск хранилища — это был бы антипаттерн. Но здесь смешаны две ортогональные вещи: изоляция в рантайме и связность версий на сборке.
В рантайме изоляция никуда не делась. Шина, БД и рантайм — по-прежнему отдельные процессы (и отдельные NuGet-пакеты). Регрессия в шине не роняет хранилище: откатываете один пакет/образ шины, база живёт дальше. Ровно ваш сценарий «слегла шина — база живёт» работает как есть, откат — один слой.
«Единый бамп» — это рекомендация, а не жёсткая связность. Пакеты версионируются независимо и совместимы по API внутри 3.x: redb.Route 3.3.0 спокойно едет с коннектором 3.2.x — просто без свежих фиксов конкурентности. То есть «чтобы починить шину, придётся перевыпускать хранилище» фактически не так — бампаете только тот пакет, который трогали. Единая линия версий нужна тем, кому удобно ехать всем стеком разом, а не обязаловка.
А главный плюс синхронного выпуска — он гоняется тестами комплексно. Вся линия 3.3.0 проходит сквозную матрицу: БД, шина, коннекторы, рантайм проверяются в связке, на одном прогоне. В зоопарке такого прогона нет в принципе — каждый вендор тестирует себя у себя, а стык между ними (та самая интеграция версий) не тестирует никто, кроме вас, в проде. Синхронный релиз ровно эту дыру и закрывает: совместимость слоёв — гарантия линии, а не ваша ночная проверка.
И про «клей, который чинишь по ночам». В зоопарке по ночам обычно чинится не вендорский компонент, а именно клей между ними — адаптеры, контракты сериализации, мосты транзакций. Это ваш код: без вендора, без тестов, без SemVer. Здесь этот клей — тестированные версионированные примитивы одной линии с общей CI-матрицей. Регрессию ловит один прогон по всему стеку, а не «а совместим ли драйвер vX с шиной vY».
И ещё про «болеют по отдельности». Так они и лечатся по отдельности — разным стеком, разными людьми. Kafka чинит один спец, Postgres — DBA, Redis — третий, шину — четвёртый. Изоляция отказов оплачивается фрагментацией экспертизы: держать надо не один навык, а зоопарк компетенций, и в 3 ночи нужный человек не всегда на смене. Единая экосистема — это один стек знаний на всё, и правит его один человек, а не эстафета из четырёх дежурных. ну и вся эта история открытый исходный код.
Где вы правы по-настоящему: реальный компромисс не в изоляции отказов (она сохранена), а в концентрации вендора. Один поставщик на весь стек — это единый источник и багов, и рисков (заброшенность, вектор supply chain). Это честная цена за отсутствие интеграционного клея и за один стек компетенций, и держать её в голове стоит. Но это уже другой аргумент, чем «синхронный бамп ломает откат».
но опят же открытый исходный код в век нейронок прошерстить не составляет труда.
Тут небольшая путаница — redb.dll это не замена sqlite3.dll и не «другой SQLite», а загружаемое расширение SQLite (.load / sqlite3_load_extension). Оно не заменяет движок, а грузится поверх обычного SQLite: при загрузке через sqlite3ext.h резолвит API хоста и добавляет в базу функции redb (get_object_json, pvt_*-компилятор запросов, soft-delete, view прав).
Поэтому по пунктам:
— Быстрее? Некорректное сравнение: redb.dll использует ваш sqlite3 как есть и в его скорости ничего не меняет. Ценность не в скорости SQLite, а в том, что он превращает SQLite в типизированное объектное хранилище (серверный материализатор + компилятор запросов внутри БД — ровно то, что у Free-тира на Postgres/MSSql живёт как PL/pgSQL).
— Совместимо/взаимозаменяемо? Совместимо с SQLite (грузится в любой sqlite3 ≥ 3.44 — Microsoft.Data.Sqlite, python sqlite3, sqlite3 CLI), но не взаимозаменяемо: сам sqlite3.dll по-прежнему нужен, redb.dll к нему добавляется, а не вместо.
Если совсем коротко: sqlite3.dll — это движок, redb.dll — плагин к нему.
ну и если честно мне тоже не нравятся лозунги - всё равно его не брошу потому что он хороший - этого не может быть, потому что не может быть - миграции это важный и сложный процесс
- риски потому что риски
здесь да, теряется из проекта что то такое большое сложное и важное, это БД с EF
если кто спросит а сколько у тебя таблиц в БД у тебя же сотни сущностей, то наверное да, ответить нечего..., да нисколько.
попробую тоже резюмировать я не призываю отказываться от EF и даппера и нет проблем, я просто показываю что это вполне рабочий вариант и как оно помогает достичь конечной цели бизнеса, быстрее и качественнее, а не строить БД ради БД
PS в моих словах нет критики или сарказма, наверное надо понимать что я вот это построил имея некоторые так сказать знания работы(и внутренностей) EF и прочих Hibernate
вся эта история прекрасно вяжется с redb.route - альтернатива MassTransit и прочих басов
redb.tsak - альтернатива karaf и прочих роуте контейнеров
и всё-же я ожидал не только критику, но странно почему нет вопросов, обычно если туда погрузится, тема не простая, и вопросов должно возникнуть масса...
спасибо, таки да и без нейронки общаемся, без заученных книжных оборотов.
почему я позиционирую как альтернативу EF конечно внутренности обсолютно разные но это призвано решать тот же класс бизнес задач только значительно меньше гемороя
и я не говорю что надо все делать, как раз подчеркиваю что плоские данные и тренды лучше хранить плоскими таблицами, не зачем пихать тренд температуры в redb однако сложные композитные объекты требуют ну очень много времени на написание кода и поддержки с кучей FK и багов и нужных индексов, и CRUD превращается для них ( а особенно если их сотни и тысячи идут) тыжелое бремя как в коде так и скорости выполнения... прредставьте вам пришел объект внутри классы массивы элементы справочников во внутренних классах массивы классов внутри тоже есть Dictionary таки еще с ключом tuple ну в примере я показал на сайте redb.ru, и его надо не только сохранить но найти в нем изменения и апдетить удалять что еще? ах да, кончно таблицы связей, кудаж без них то, вопрос сколько будет делаться интеграция? но вот вы наконец сделали всё и отладили с помощью нейронки быстрее да, и отнесли на прод и к вам приходит бизнес и говорит что вашу большую сущность надо расширить массивом строк массиовом чисел и массивом внутренних классов.... это стоит очень дорого потому как регресс.. полный...
в случае с redb ничего не стоит но если вам надо вывернуть плоско на бд таки это один запрос с одним join к таблице кеша RTTI ну или пару join соберите сами типы и структуры и схемы..
это очень просто, но чтоб не мучится в redb есть функции и их много и одна из низ get_object_json(id) вернет вам собранный граф за миллисекунды
тоесть пока делает проект команда слоя DAL, с redb давно делают бизнес функционал и презентуют в этот же день прототип..
подход разный с EF - но я сравниваю скорости какие запросы можно сделать на linq для redb, а тама не уступает но гдето возможно и превосходит, но есть элементы которые не реализованы по сравнению с EF
потому я исхожу из того что время деньги, бизнесу всё равно как вы храните, про риски, риски так же оценивали и другие - суть: это не понятно и не занкомо и возможно сложно. вот и всё. по сути данную систему в сложных проектах используют как гибрид с даппером, линейные таблицы таки да ...
но в redb есть не только crud но и разделение по доменам соединений, кеш даже с квотами, экспорт импорт (бэкап) , встроенные деревья с linq
отсечение на уровне объектов whereRedb и я уже не лпомню всего, этот проект уже давно в работе, новые фичи, вот выпускаю для sqlite, но там много фич в планах я просто всё не успеваю физически, на подходе идентити сервер, но он пока на тестах на прод не несли
не много не согласен похож на EAV но всё же не так подход несколько другой RTTI на уровне бд примеры и архитектура если это
redb examplt
разложить на классические таблицы + справочники+ таблицы связей+FK+индексы на FK+бизнес индексы, то получим, да серьезное приложение вместо одного SaveAsync(IEnumerable)
на одном реальном проекте(построенном на redb.route и redb.tsak) и классическом EF, есть внутри три проекта
Абстракция EF слоя DAL
Реализация слоя DAL на PG EF с DBContext конечно
Проект внутри интеграции с системой САП три точки интеграции
это всё много тысяч строк кода + не один месяц работы = деньги бизнеса
все это еще надо поддерживать и отлаживать
по интеграции не приходят CRUD надо самому выравнивать с БД потому появились поля хешей с индексами конечно. и занимает сохранение на три ноды сотню объектов(весьма сложных) до >10 сек, проект большой делался более года. кто этим занимался поймёт.
вся эта шляпа вместо одного SaveAsync(IEnumerable), да именно так.
теперь другой проект с кучей интеграций тоже на redb.routeredb.tsak но вот бд полностью redb
проект весьма не простой по бизнесу, тока вот бизнес не успевал с идеями за нами.
и сделан он буквально за месяц = деньги
считаем человеко-часы не тока на разработку но и на поддержку, добавmте пару полей или таблицы в интеграции к проду... весело, однако у нас это занимает 10-15 минут. далее немного картинок, данные собрались за ~месяц
redb.Objects
redb.Values
к этим показанным выше значениям рест запрос на бэкенд, 6 агрегаций(весьма сложных) сортировки, фильтрация не по одному полю, время выполнения всего рест запроса 0.16 сек
redb prod
сохранение пришедших по интеграции объектов(композитных и весьма),
1447 объектов заняло 1.3 сек да, я даже не замарачиваюсь что тама поменялось, оно само всё сравнит и сделает потоки балк на сохранения, просто вызываю SaveAsync(IEnumerable(1447))
redb prod
и никаких EF и DBContext и миграций и никаких всё в строчку, и никаких DAL, но строго типизировано, потому и быстро индексы отрабатывают , здеся про это расказано
аудит пользователей реализован плоской таблицей, пихать его в redb.object антипаттерн
Джуны собрали проект за день с БД LDAP сессиями и прочее.
я помог засунуть в redb.tsak и вот у них хоть и простое решение, но оно сразу готово интегрироваться в систему предприятия, утром постановка задачи вечером презентация, и с БД полноценно, причем сразу с управлением с графанами прометеусами OTel джагерами и докерами, то есть уровень Enterprise , с хвостом для k8
redb.tsak
к сожалению картинок более старых проектов (для WB\Озон\RealEsatet делалось) у меня нет, не коллекционирую, показываю вот прям что счас у меня есть (без всяких яких).
если кому интересно могу нарезать с прода много картинок, с замерами всякими.
но есть нюанс, с нейронкой если ей всё грамотно показать, проекты делаются в разы еще быстрее, потому что работа только с бизнес сущностями и бизнес процессами.
Granulex Спасибо за развёрнутый ответ — взял в работу. В 3.1.1 (CHANGELOG уже обновлён) добавил per-message аудит-поля на MessageProps, проставляются движком на каждый persist:
PromptTemplateName + PromptTemplateVersion — на всех строках прогона, если caller передал managed template.
ToolSetHash — SHA-256 канонического набора {name, description, InputSchema} (отсортирован по имени), на assistant-строках. Меняется набор/схема инструмента — меняется хеш.
ProviderSystemFingerprint — system_fingerprint из ответа провайдера (OpenAI/xAI/Together эхо-возвращают; Anthropic-compat / Gemini-compat / Ollama чаще null).
Про закрытые модели честно: фингерпринта от Anthropic нет → bit-exact replay невозможен в принципе, фиксируем (model_id, params, tool_set_hash, prompt_template) и помечаем как best-effort. Для жёсткого compliance — self-hosted (Ollama / vLLM / llama.cpp), там воспроизводимость честная.
Миграции не было — REDB схему props подхватывает автоматически, просто добавил поля в класс.
Детали и code-paths: CHANGELOG.md → раздел 3.1.1, per-message audit fields on MessageProps
Справедливое замечание, и вы правы — Amadeus Ticket Changer действительно давно и хорошо автоматизирует пересчёт тарифа при voluntary/involuntary reissue (Category 31/33 ATPCO), это решённая задача, когда весь билет виден одному GDS. Не спорю с этим.
На практике мы так и делали: сначала смотрели, что предлагает каждый GDS сам по себе — это уже оптимальные, провалидированные через-тарифом связки, и в первую очередь оценивали именно их. А варианты из разных источников (self-connect) собирали и сравнивали уже отдельно, вторым шагом, как альтернативу — иногда через-тариф от одного GDS оказывается выгоднее, иногда комбинация из разных источников дешевле, и дальше вопрос уже в том, что важнее заказчику: гарантированная стыковка одним источником или экономия ценой риска и неудобства на пересадке.
Проблема, которую я описываю, начинается именно на этом втором шаге — там, где ATC сам предупреждает о своей границе: "tickets issued through other GDSs... are not guaranteed" Amadeus Fare Guarantee. Речь не о смене маршрута внутри одного билета, а о ситуации, когда решили, что self-connect выгоднее, и маршрут собран из трёх разных источников — три независимых билета, ни один GDS не видит два других. Замена одного плеча в такой конструкции — это не reissue внутри PNR, а согласование между источниками, которые друг о друге не знают. Ни один из GDS эту часть не решает и не может — у них просто нет данных о существовании билетов из соседних систем.
Спасибо за наводку — стоит явно назвать ATC и очертить эту границу в тексте, чтобы не создавалось впечатление, что я не в курсе существующих инструментов.
вообще интересная тема и решил покопаться, в помощь взял нейроку, и вот что вышло
____
Копнул — статья смешивает подтверждённые факты с довольно шаткой причинно-следственной теорией, и есть конкретная нестыковка по датам, которая рушит центральный тезис автора.
Что подтверждается независимо:
Водяной знак — реальный, задокументирован Fortune, TechTimes, Reuters-уровня источниками: с 2 августа 2026, статистическая метка на уровне модели (не невидимые символы), под требования Article 50 EU AI Act, применяется глобально, не только в ЕС. Это не выдумка блогера.
Opus 5 — реальная модель, вышла 24 июля 2026 (это позже, кстати, чем модели из моего собственного системного промпта — то есть для меня это тоже новость постфактум).
Жалобы на многословность и потерю смысла в Opus 5 — тоже реальные, задокументированы независимо (разбор MindStudio, тред на Hacker News, официальный GitHub issue в репозитории claude-code с конкретными измерениями).
А вот тут центральная теория автора (водяной знак → деградация Opus 5) рушится по датам. Жалобы на многословность Opus 5 фиксировались до 2 августа — материал MindStudio датирован примерно 1 августа, тред на HN старше двух недель на момент этой статьи. То есть модель уже жаловались как на "многословную и запутанную" раньше, чем вообще включили водяной знак — значит знак физически не может быть причиной того, что уже существовало до него. При этом в самом GitHub issue есть официальный анонс постмортема Anthropic с конкретными, раскрытыми причинами прошлых просадок качества (баг с уровнем effort, баг с историей размышлений, неудачное системное изменение под многословность) — то есть паттерн "нашли баг → объяснили → откатили" у них уже был, не "молчат и скрывают".
Про "уже вводили в заблуждение насчёт военного использования" — это не бьётся с тем, что реально задокументировано. По многочисленным источникам (CNN, Reuters, Al Jazeera) картина обратная: Anthropic публично и настойчиво отказывалась от неограниченного военного использования (автономное целеуказание, слежка за гражданами США), из-за чего Пентагон демонстративно понизил их статус, а компания в ответ подала в суд на правительство. Это не "скрывали военное использование", а ровно наоборот — публичный, судебный конфликт из-за того, что они слишком жёстко ограничивают именно такое использование. Автор этот пассаж явно не проверял.
Сама статья честно помечена автором как "Мнение" и "моя версия... возможно лишь частично верна" — то есть жанр разрешает спекуляцию. Но конкретно эти два места (причинность с водяным знаком и намёк на скрытое военное применение) не выдерживают проверки по датам и источникам, а не просто "спорное мнение".
а можно пример текста с меткой и пояснением?
Оба выловили не тестами, а на живом приложении: строили на этом же стеке своё — телеграм-бот через
redb.Route.Telegramкак фронт, а за ним LLM-часть, работающая с оперативными данными. Там и вылезло.Тесты были — и в этом самое интересное. Они не покрыли эти кейсы, потому что писал их я же и ровно под тот способ использования, который держал в голове. У API несколько равноправных путей, а покрыт оказался мой.
Пример прямо из этого релиза: URI эндпоинтов я всегда писал строкой, а не fluent-строителем. Поэтому расхождение кодека строителя с парсером — значения с пробелами не переживали круговой обход — у меня физически не могло воспроизвестись: этой ветки в моём коде не было. Тест «маршрут работает» проходил, потому что проверял мой путь.
С деревьями последствия серьёзнее.
WhereLeaves()замещал корневой CTE вместо того, чтобы быть предикатом поверх него, то есть запрос молча означал «свежайший лист схемы во всей базе». Ошибки нет, ответ правдоподобный — просто не про того. На одном собеседнике это невидимо в принципе; в боте со вторым пользователем видно сразу — человеку приезжает чужая история.Сейчас оба пути закрыты тестами, фикс дерева ушёл во все шесть провайдерных комбинаций и в нативное расширение SQLite.
Могу тока добавить, что рассчитать стоимость по тарифной сетке, публичные и внутренние цены, плюс система скидок, тоже не простая задача, и связать всё это с 1С.
Понял, спасибо за ссылку — интересный подход с CRDT, особенно семантическая гранулярность вместо посимвольной. Хотя тут немного другая задача: redb.SQLite — это типизированное хранилище с SQL запросами и схемой, а outbox в статье — сознательно простой конфликт-хендлинг под контролем приложения. CRDT-синк — это скорее слой ниже/сбоку, не альтернатива типизированному стору. Возьму на заметку, спасибо.
Спасибо! А что вы имели в виду под "гипер базой" — можете уточнить? Тут в статье клиентское хранилище (SQLite прямо в приложении/браузере, без сервера), не совсем понимаю, в какой момент она бы пригодилась.
статья про клиентское хранилище: SQLite встроен прямо в приложение (на телефоне) или в браузер, без сервера вообще. HyperBase — это managed-хостинг для серверного Postgres, он для другого сценария (там, где redb.Postgres/redb.MSSql). Если интересно — у меня есть статьи и про серверную часть, там как раз к месту.
Да, действительно верно.
спасибо за уточнение — DETACH PARTITION перед DROP корректнее на нагруженных таблицах. Основная тема статьи — планировщик, пример очистки был иллюстративным.
@lazarus_net
гоняю тесты с нейронкой, и я забыл вогнать поля, да и не было нужды в них, но тест дал варнинг, нейронка увидела и добавили и вот что пишет сама
тесты от
____
oidcc-basic-certification-test-plan
redb.Identity Basic OP (manual)
Variant:
server_metadata=discovery, client_registration=static_client
Alias:
redb-final-0043
Plan ID:
hdV2kmVNvRuK1
Plan Version:
5.2.0
Started:
14.07.2026, 00:43:15
Test Owner:
developer
Certification profile:
Basic OP
я не поленился и...
Вот выжимка от нейронки:
redb.Route — Apache Camel для .NET. Суть за 1 минуту.
Любая интеграция = три строки:
csharp
Что внутри:
22 транспорта — Kafka, RabbitMQ, IBM MQ, AMQP, MQTT, HTTP, gRPC, SignalR, SFTP, S3, SQS, Telegram, LDAP и ещё
30+ EIP паттернов — Choice, Splitter, Aggregator, WireTap, Saga, Circuit Breaker, Idempotent Consumer
Compiled expression engine —
${header.x++}, JSONPath, XPath →Func<IExchange, T>без интерпретатораOpenTelemetry из коробки — трейсы и метрики на каждом шаге
Транзакции через
.Transacted()— Kafka EOS, RabbitMQ confirms, IBM MQVs конкуренты:
MassTransit — 5 транспортов, нет EIP, message bus (не ESB)
NServiceBus — коммерческий после 2 эндпоинтов
Apache Camel — то же самое но на JVM
Production runtime: redb.Tsak — hot-reload, кластер, Blazor dashboard, REST API
Apache 2.0. Без per-endpoint лицензий.
Критика принята по части стиля — буду работать над этим. Однако мне либо код писать, либо стьатьи оформлять, я один и у меня нет за плечами корпораций и миллионов.
НО, оно работает, и в компании один за другим переводят проекты на redb экосистему, потому что дешево. Бизнес не интересует как ты написал, бизнес интересует быстро кратко поддерживаемо расширяемо и много функционала.
По существу: redb.Core не скрывает SQL, а убирает необходимость писать DDL вручную. Под капотом — типизированные колонки (
_Long bigint,Numeric numeric(38,18),DateTimeOffset timestamptz), FK с CASCADE, индексы, CTE для деревьев. Всё это видно черезToSqlStringAsync()иget_object_json()прямо из psql.Два года в проде на реальной нагрузке (150k заказов/месяц, 3-нодовый кластер) — если интересно как это работает под капотом, серия "REDB изнутри" как раз об этом.
А redb.Route позволяет писать интеграции — и весь бэк — значительно быстрее. redb.Tsak разворачивает приложение сразу на уровне enterprise: hot-reload, кластер, дашборд из коробки.
Жду технической критики — именно её не хватает в комментариях. С тех. аргументами.
Да, я не копирайтер и не техWрайтер — пытаюсь поделиться с сообществом тем что реально работает и позволяет достигать цели значительно быстрее.
и оно всё открыто github
и redb.Identity это в следующей статье
я бы вообще рекомендовал скармливать readme с github нейронке, она сделает выжимку, суть. и попросить нейронку покапаться поглубже. дело 5 минут.
Дополню про концентрацию вендора — она тут слабее, чем кажется. Ядро, движок, коннекторы и рантайм открыты: заброшенность лечится форком, supply chain — аудитом (а в век LLM прошерстить всё дерево это вечер, а не неделя). Pro-слой закрыт бинарём, но, во-первых, раздаётся бесплатно и без лицензионного сервера на всей линии 3.x — «рубильника» у вендора нет; во-вторых, компаниям, которым нужен исходник, я отдаю его по запросу. Так что и тут это не lock-in, а обычный риск «поставщик может остановиться» — с открытым ядром и доступным по запросу Pro это не тупик, а форк.
Согласен с самим принципом: изоляция отказов реальна, и если бы обновление шины насильно тянуло за собой перевыпуск хранилища — это был бы антипаттерн. Но здесь смешаны две ортогональные вещи: изоляция в рантайме и связность версий на сборке.
В рантайме изоляция никуда не делась. Шина, БД и рантайм — по-прежнему отдельные процессы (и отдельные NuGet-пакеты). Регрессия в шине не роняет хранилище: откатываете один пакет/образ шины, база живёт дальше. Ровно ваш сценарий «слегла шина — база живёт» работает как есть, откат — один слой.
«Единый бамп» — это рекомендация, а не жёсткая связность. Пакеты версионируются независимо и совместимы по API внутри 3.x:
redb.Route3.3.0 спокойно едет с коннектором 3.2.x — просто без свежих фиксов конкурентности. То есть «чтобы починить шину, придётся перевыпускать хранилище» фактически не так — бампаете только тот пакет, который трогали. Единая линия версий нужна тем, кому удобно ехать всем стеком разом, а не обязаловка.А главный плюс синхронного выпуска — он гоняется тестами комплексно. Вся линия 3.3.0 проходит сквозную матрицу: БД, шина, коннекторы, рантайм проверяются в связке, на одном прогоне. В зоопарке такого прогона нет в принципе — каждый вендор тестирует себя у себя, а стык между ними (та самая интеграция версий) не тестирует никто, кроме вас, в проде. Синхронный релиз ровно эту дыру и закрывает: совместимость слоёв — гарантия линии, а не ваша ночная проверка.
И про «клей, который чинишь по ночам». В зоопарке по ночам обычно чинится не вендорский компонент, а именно клей между ними — адаптеры, контракты сериализации, мосты транзакций. Это ваш код: без вендора, без тестов, без SemVer. Здесь этот клей — тестированные версионированные примитивы одной линии с общей CI-матрицей. Регрессию ловит один прогон по всему стеку, а не «а совместим ли драйвер vX с шиной vY».
И ещё про «болеют по отдельности». Так они и лечатся по отдельности — разным стеком, разными людьми. Kafka чинит один спец, Postgres — DBA, Redis — третий, шину — четвёртый. Изоляция отказов оплачивается фрагментацией экспертизы: держать надо не один навык, а зоопарк компетенций, и в 3 ночи нужный человек не всегда на смене. Единая экосистема — это один стек знаний на всё, и правит его один человек, а не эстафета из четырёх дежурных. ну и вся эта история открытый исходный код.
Где вы правы по-настоящему: реальный компромисс не в изоляции отказов (она сохранена), а в концентрации вендора. Один поставщик на весь стек — это единый источник и багов, и рисков (заброшенность, вектор supply chain). Это честная цена за отсутствие интеграционного клея и за один стек компетенций, и держать её в голове стоит. Но это уже другой аргумент, чем «синхронный бамп ломает откат».
но опят же открытый исходный код в век нейронок прошерстить не составляет труда.
точно, это русский фольклор, не переводимая игра слов
task -> tsak = ЦАК
колокольчик
- у apach camel - apach karaf = кувшин.
Мне нравится этот фильм. "Кин-дза-дза" Георгия Данелии.
Глубокий философский смысл несет он в себе.
Тут небольшая путаница — redb.dll это не замена sqlite3.dll и не «другой SQLite», а загружаемое расширение SQLite (.load / sqlite3_load_extension). Оно не заменяет движок, а грузится поверх обычного SQLite: при загрузке через sqlite3ext.h резолвит API хоста и добавляет в базу функции redb (get_object_json, pvt_*-компилятор запросов, soft-delete, view прав).
Поэтому по пунктам:
— Быстрее? Некорректное сравнение: redb.dll использует ваш sqlite3 как есть и в его скорости ничего не меняет. Ценность не в скорости SQLite, а в том, что он превращает SQLite в типизированное объектное хранилище (серверный материализатор + компилятор запросов внутри БД — ровно то, что у Free-тира на Postgres/MSSql живёт как PL/pgSQL).
— Совместимо/взаимозаменяемо? Совместимо с SQLite (грузится в любой sqlite3 ≥ 3.44 — Microsoft.Data.Sqlite, python sqlite3, sqlite3 CLI), но не взаимозаменяемо: сам sqlite3.dll по-прежнему нужен, redb.dll к нему добавляется, а не вместо.
Если совсем коротко: sqlite3.dll — это движок, redb.dll — плагин к нему.
смотри на redb.ru
ну и если честно мне тоже не нравятся лозунги
- всё равно его не брошу потому что он хороший
- этого не может быть, потому что не может быть
- миграции это важный и сложный процесс
- риски потому что риски
здесь да, теряется из проекта что то такое большое сложное и важное, это БД с EF
если кто спросит а сколько у тебя таблиц в БД у тебя же сотни сущностей, то наверное да, ответить нечего..., да нисколько.
попробую тоже резюмировать
я не призываю отказываться от EF и даппера и нет проблем,
я просто показываю что это вполне рабочий вариант и как оно помогает достичь конечной цели бизнеса, быстрее и качественнее, а не строить БД ради БД
PS в моих словах нет критики или сарказма, наверное надо понимать что я вот это построил имея некоторые так сказать знания работы(и внутренностей) EF и прочих Hibernate
вся эта история прекрасно вяжется с
redb.route - альтернатива MassTransit и прочих басов
redb.tsak - альтернатива karaf и прочих роуте контейнеров
и всё-же я ожидал не только критику, но странно почему нет вопросов, обычно если туда погрузится, тема не простая, и вопросов должно возникнуть масса...
деревья с linq, самый смак тама в них, есть и полиморфные деревья
самое интересное я знаю во сколько обошлась компании экономя средств на проекте на большом, реально даже не один лям.
спасибо, таки да и без нейронки общаемся, без заученных книжных оборотов.
почему я позиционирую как альтернативу EF
конечно внутренности обсолютно разные
но это призвано решать тот же класс бизнес задач только значительно меньше гемороя
и я не говорю что надо все делать, как раз подчеркиваю что плоские данные и тренды лучше хранить плоскими таблицами, не зачем пихать тренд температуры в redb однако сложные композитные объекты требуют ну очень много времени на написание кода и поддержки с кучей FK и багов и нужных индексов, и CRUD превращается для них ( а особенно если их сотни и тысячи идут) тыжелое бремя как в коде так и скорости выполнения...
прредставьте вам пришел объект внутри классы массивы элементы справочников во внутренних классах массивы классов внутри тоже есть Dictionary таки еще с ключом tuple ну в примере я показал на сайте redb.ru, и его надо не только сохранить но найти в нем изменения и апдетить удалять что еще? ах да, кончно таблицы связей, кудаж без них то, вопрос сколько будет делаться интеграция?
но вот вы наконец сделали всё и отладили с помощью нейронки быстрее да, и отнесли на прод
и к вам приходит бизнес и говорит что вашу большую сущность надо расширить массивом строк массиовом чисел и массивом внутренних классов.... это стоит очень дорого потому как регресс.. полный...
в случае с redb ничего не стоит
но если вам надо вывернуть плоско на бд таки это один запрос с одним join к таблице кеша RTTI ну или пару join соберите сами типы и структуры и схемы..
это очень просто, но чтоб не мучится в redb есть функции и их много и одна из низ get_object_json(id) вернет вам собранный граф за миллисекунды
тоесть пока делает проект команда слоя DAL, с redb давно делают бизнес функционал и презентуют в этот же день прототип..
подход разный с EF - но я сравниваю скорости какие запросы можно сделать на linq для redb, а тама не уступает но гдето возможно и превосходит, но есть элементы которые не реализованы по сравнению с EF
потому я исхожу из того что время деньги, бизнесу всё равно как вы храните,
про риски, риски так же оценивали и другие - суть: это не понятно и не занкомо и возможно сложно.
вот и всё.
по сути данную систему в сложных проектах используют как гибрид с даппером, линейные таблицы таки да ...
но в redb есть не только crud но и разделение по доменам соединений, кеш даже с квотами, экспорт импорт (бэкап) , встроенные деревья с linq
отсечение на уровне объектов whereRedb и я уже не лпомню всего, этот проект уже давно в работе, новые фичи, вот выпускаю для sqlite, но там много фич в планах
я просто всё не успеваю физически, на подходе идентити сервер, но он пока на тестах на прод не несли
днем основная работа, никто не отменял
не много не согласен
похож на EAV но всё же не так
подход несколько другой RTTI на уровне бд
примеры и архитектура
если это
разложить на классические таблицы + справочники+ таблицы связей+FK+индексы на FK+бизнес индексы, то получим, да серьезное приложение вместо одного SaveAsync(IEnumerable)
на одном реальном проекте(построенном на redb.route и redb.tsak) и классическом EF, есть внутри три проекта
Абстракция EF слоя DAL
Реализация слоя DAL на PG EF с DBContext конечно
Проект внутри интеграции с системой САП три точки интеграции
это всё много тысяч строк кода + не один месяц работы = деньги бизнеса
все это еще надо поддерживать и отлаживать
по интеграции не приходят CRUD надо самому выравнивать с БД потому появились поля хешей с индексами конечно. и занимает сохранение на три ноды сотню объектов(весьма сложных) до >10 сек, проект большой делался более года.
кто этим занимался поймёт.
вся эта шляпа вместо одного SaveAsync(IEnumerable), да именно так.
теперь другой проект с кучей интеграций тоже на redb.route redb.tsak но вот бд полностью redb
проект весьма не простой по бизнесу, тока вот бизнес не успевал с идеями за нами.
и сделан он буквально за месяц = деньги
считаем человеко-часы не тока на разработку но и на поддержку, добавmте пару полей или таблицы в интеграции к проду... весело, однако у нас это занимает 10-15 минут.
далее немного картинок, данные собрались за ~месяц
к этим показанным выше значениям рест запрос на бэкенд, 6 агрегаций(весьма сложных) сортировки, фильтрация не по одному полю, время выполнения всего рест запроса 0.16 сек
сохранение пришедших по интеграции объектов(композитных и весьма),
1447 объектов заняло 1.3 сек да, я даже не замарачиваюсь что тама поменялось, оно само всё сравнит и сделает потоки балк на сохранения, просто вызываю SaveAsync(IEnumerable(1447))
и никаких EF и DBContext и миграций и никаких всё в строчку, и никаких DAL, но строго типизировано, потому и быстро индексы отрабатывают , здеся про это расказано
аудит пользователей реализован плоской таблицей, пихать его в redb.object антипаттерн
Джуны собрали проект за день с БД LDAP сессиями и прочее.
я помог засунуть в redb.tsak и вот у них хоть и простое решение, но оно сразу готово интегрироваться в систему предприятия, утром постановка задачи вечером презентация, и с БД полноценно, причем сразу с управлением с графанами прометеусами OTel джагерами и докерами, то есть уровень Enterprise , с хвостом для k8
к сожалению картинок более старых проектов (для WB\Озон\RealEsatet делалось) у меня нет, не коллекционирую, показываю вот прям что счас у меня есть (без всяких яких).
если кому интересно могу нарезать с прода много картинок, с замерами всякими.
но есть нюанс, с нейронкой если ей всё грамотно показать, проекты делаются в разы еще быстрее, потому что работа только с бизнес сущностями и бизнес процессами.
Granulex Спасибо за развёрнутый ответ — взял в работу. В
3.1.1(CHANGELOG уже обновлён) добавил per-message аудит-поля наMessageProps, проставляются движком на каждый persist:Temperature,MaxTokens,TopP— эффективные сэмплинг-параметры (override запроса → дефолт фабрики), на assistant-строках.PromptTemplateName+PromptTemplateVersion— на всех строках прогона, если caller передал managed template.ToolSetHash— SHA-256 канонического набора{name, description, InputSchema}(отсортирован по имени), на assistant-строках. Меняется набор/схема инструмента — меняется хеш.ProviderSystemFingerprint—system_fingerprintиз ответа провайдера (OpenAI/xAI/Together эхо-возвращают; Anthropic-compat / Gemini-compat / Ollama чащеnull).Про закрытые модели честно: фингерпринта от Anthropic нет → bit-exact replay невозможен в принципе, фиксируем (model_id, params, tool_set_hash, prompt_template) и помечаем как best-effort. Для жёсткого compliance — self-hosted (Ollama / vLLM / llama.cpp), там воспроизводимость честная.
Миграции не было — REDB схему props подхватывает автоматически, просто добавил поля в класс.
Детали и code-paths: CHANGELOG.md → раздел 3.1.1, per-message audit fields on
MessageProps