А не проще ли ChatGPT дать доступ к репе Github, где держать базу знаний и другие сервисы прикрутить типа календаря и что ещё там можно? Он даже может PR делать, правда создавая и редактируя файлы по одному и каждый раз спрашивая.
Я это начал использовать, когда кончается недельная квота Codex, чтобы в это время составлять и прорабатывать задачи.
Я как раз из тех, кто за 16 лет разработки, из которых 8 лет профессионально, почти никогда не писал тесты, искренне не понимая, зачем они, так как на отладку тратил всегда мало времени и без них.
У меня свои проекты, на работе тоже проект библиотеки, который начинал сам с нуля, на которой крутятся рабочие проекты, которые создают другие. Обычно баг ловится сразу - запускаю рабочий проект, и ничего не рисуется или рисуется коряво. А дальше ртладчиком смотрю туда, где недавно что-то менял, и быстро нахожу причину.
За всё время получилась только пара smoke/fuzz тестов с кастомным сетевым протоколом и ещё одном месте, где ловил много багов, но я изначально ожидал их там встретить.
Помогает продуманная архитектура без дублирования кода и раскиданные по функциям ассерты-контракты. Код максимально переиспользуется благодаря универсальным абстракциям, поэтому кода, который нужно отлаживать, довольно мало, и почти все ветки кода ядра задействуются сами собой.
Если писать юнит-тесты, то при каждой итерации рефакторинга их придётся переписывать, а на это всегда было лень тратить время с учётом того, как мало его уходило на отладку и много на продумывание архитектуры.
Но с внедрением ИИ агентов стал покрывать тестами, и при обнаружении бага требовать воспроизводить его падающим тестом. Теперь ИИ агенты навёрстывают, покрывая код, и если надо, перепишут сами при рефакторинге, а потом сами будут их вызывать, подтверждая, что они действительно сделали задачу, а не сломали всё. Тут тесты реально стали нужны, чтобы вручную не просить агента переделывать по 10 раз по кругу.
А как модель по сравнению с Kimi k2.5? Про неё читал, что чуть ли не Sonnet 4.6. В Windsurf её дают бесплатно. Я её пробовал в Windsurf, тупит хуже, чем GPT 5.2 Low.
У меня все вкладки пустые были. Он мог как-то висеть в фоне даже при закрытии всех вкладок и окна терминала, и прибиться по Cmd+Q вместе с терминалом? Я думал, что никаких процессов там не выполнялось, и память жрал сам терминал.
А можно подробнее, что даёт GPT, что Opus? Я пробовал только GPT в Codex, так как не готов много платить, и получаю хороший результат.
Ещё немного сравнивал Opus 4.6 с GPT 5.4 в Windsurf на паре промптов в одной задаче. Оба одинаково сломали работающий код, но первый жрал квоту в 2 раза быстрее. Оба использовал с medium reasoning без повышенного контекста. Там задача была довольно локальная, с CSS надо было добиться нужного вида.
А почему все пишут про Claude Code, но никто не пишет про Codex? У последнего же вроде квоты намного лучше за те же деньги? Или Claude Code настолько лучше по качеству или ещё чему-то, что затмил всех конкурентов?
Просто я не пробовал Claude Code, там сложнее регистрироваться из РФ, а Codex для меня и так очень хорош. Есть что-то ради чего стоит попробовать кроме может слегка лучшего качества?
В Windsurf бесплатно и безлимитно с недавних пор дают Kimi k2.5. Где-то читал, что она якобы не хуже Sonnet 4.5, по моему опыту она неплоха, но даже GPT 5.2 Low, доступная в Windsurf Free с ограниченной квотой, её уделывает. Думал купить там подписку, но пока был на триале, они ввели дебильную систему дневных и недельных квот для платных моделей, которые слишком быстро заканчивались даже на GPT 5.4, не говоря уже о Claude, который жрёт квоту как не в себя.
Ещё Codex на бесплатном тарифе есть, но это временно. А если подключить зарубежную карту (в РФ я завёл виртуальную по цене месяца подписки), то дают триал Plus на месяц с удвоенной квотой - временно, как они утверждают на сайте. Но даже удвоенную недельную квоту я потратил за два дня, сидя по 12 часов в день и документируя, покрывая тестами и добавляя инфраструктурные фичи в два моих проекта.
Мне интересно, почему все везде пишут только про Claude Code? Я его не пробовал, так как говорят, что там квоты улетают в миг, и нужно платить кучу денег, а у меня хороший опыт с Codex, а бесплатный Windsurf помогает дотянуть до восстановления недельной квоты Codex'а, за которую многое успеваю сделать и претензий к качеству не имею.
Не понял, откуда гарантия, что младшие биты свободны? Указатель же void*, значит не подразумевает никакого выравнивания данных. По указателю может храниться например строка или бинарный массив, не выровненный на 4 байта. А то, что сам указатель в структуре выравнивается, к этому вообще отношения не имеет.
По поводу битовых полей не понимаю, зачем их избегать. Вроде они везде одинаково работают кроме big/little-endian. Я проверял в compiler explorer на распространённых платформах и всех основных компиляторах. Кажется, только были какие-то нюансы между big и little-endian, но лучше их учесть, чем городить портянку с private и геттерами-сеттерами.
А для сериализации можно завести тип с перевёрнутым порядком байт для big-endian архитектур, не переворачивая для little-endian. Назвать типа uint32LE/uint16LE. Тогда можно будет просто писать структуры на диск.
Ну наверное больше десятка видел статей про алготрейдинг с использованием только индикаторов. А из фигур видел только один урок по поиску чего-то похожего на ГиП, но который находил не далеко не все ГиП, а только в небольшом окне из нескольких свечей. И дальше не было никакого алгоритма с бектестами.
Я полгода назад искал в гугле алготрейдинг с фигурами, но попадается либо просто базовое неформализованное описание фигур без алгоритма, либо алготрейдинг с индикаторами. Статью на Хабре, про которую вы говорите, не находил.
Меня интересуют фигуры не сами по себе, а с точками входа и стопами за линии поддержки. Если фигура сработала, то заработал, если нет - закрылся по маленькому стопу. В итоге в среднем можно неплохо зарабатывать, мне кажется. По крайней мере, некоторые курсы по трейдингу так учат. И их авторы побеждают на турнирах и ЛЧИ с сотнями процентов доходности за несколько месяцев. Но они торгуют руками, попыток сделать такое в алгоритмах я не видел.
То, что рынок - разводняк, не спорю. Скорее всего, им крутят большие дяди с огромными капиталами, провоцируя толпу на выгодные для них действия, которые ведут к перетеканию денег от толпы к ним. Должны быть какие-то правила, по которым они действуют, инициируют движения, которые психологически заставляют толпу продавать и покупать тогда, когда это выгодно им. Если разгадать хотя бы их часть, можно к ним присоединиться и тоже себе часть этого потока забрать. Я думаю, это возможно, но не сводится к простым индикаторам. И как только заметная для них часть потока начнёт утекать посторонним, они эти правила усложняют, поэтому старая информация в интернете и книгах не работает или становится неполной.
Везде вижу уроки, что в алготрейдинге используют только тупые индикаторы. Но никогда не слышал, чтобы кто-то пытался сделать алгоритмы, которые торгуют те же идеи, что и люди: фигуры типа флагов, головы и плечей, бэтменов, волн Эллиотта или Вульфа и т.п..
И свечные модели, всякие price action тоже в алгоритмах не видел, хотя то, что рассказывают на Ютубе, вроде неплохо формализуется на первый взгляд. Конечно наверняка большинство - это инфоцыгане, но бэктест бы это сразу показал.
Уже давно вынашиваю идею создания своего языка для хранения и обработки данных - чего-то типа убийцы JSON, protobuf, flatbuffers, TOML и SQL в одном флаконе. Думал, как делать JIT для него. Хотел что-то легковесное, при этом кроссплатформенное, думал делать своё: IR на основе ARM64 и упрощённую аллокацию регистров. И тут вы как раз такое сделали, да ещё и с человеческим лицом. Теперь как руки дойдут до JIT, буду знать, куда смотреть.
А поддержка SSE для процессоров без AVX планируется? У меня несколько таких девайсов есть, причём два из них относительно свежие, например, мини-ПК на Celeron N5095. Ещё есть VPS, где только SSE2 вроде или SSE3 - не выше.
В РФ мало знать английский, надо ещё умудриться работать в условиях санкций. Конечно проще, если рассматривать релокацию. Я язык знаю, но уезжать не готов, а с удалёнкой сложнее.
А можно поставить Coolify так, чтобы сборка шла локально, а на VPS только само приложение? И захостить на самой дешёвой VPS 512 МБ ОЗУ и 1 vCPU, которой более чем достаточно для запуска всех моих приложений?
Или может есть аналог Coolify, если он так не может?
В TS с тем же успехом можно сделать аргумент типа number|string|object. И в контексте тех же дженериков те же сбросы оптимизированного кода происходят, в отличие от шаблонов C++, где создаётся специализированная для типа оптимизированная функция. И наоборот, можно сам JS писать так, чтобы не допустить такой ситуации.
TS сам по себе не влияет на производительность, но может быть инструментом, который поможет своими подсказками и ограничениями упорядочить типы в коде, чтобы не только избежать багов в коде, но и избежать ситуации, когда V8 сбрасывает оптимизированный код. Всё равно это задача того, кто пишет код, которую он должен держать в уме, ограничивая типы.
У меня немало проектов с фронтендом, но из всего перечисленного в статье использую только TypeScript. И не понимаю, что у вас там за дженерики на дженериках и зачем они?
Другое дело C++, там можно нагородить многоэтажных и сложных шаблонов ради того, чтобы потом всё заинлайнилось и оптимизировалось компилятором, сгенерировав наиболее оптимальный код алгоритма или структуры данных для каждого типа.
Но в экосистеме JS типы TS - просто ограничения, проверки и подсказки, не влияющие на производительность. Не вижу смысла усложнять.
Я пытаюсь сделать именно СУБД с таблицами и с запросами по одной таблице - хотя бы уровня SELECT без JOIN'ов и GROUP BY по функционалу - сам язык SQL для этого необязательно делать. Каждая таблица - это директория с набором файлов-сегментов типа 0.seg, 1.seg, 2.seg, и т.д. по мере накопления данных. Когда файл вырастает большой, начинаем писать новый, а старый сжимается блоками и фиксируется навсегда как read-only файл - его можно раздавать и кешировать. Если элемент обновился, он уже попадёт в новый сегмент, а в архиве зависнет старая версия. Чтобы найти именно последнюю версию, надо у сервера спросить карту, которая скажет, в каком архиве последняя версия или она ещё в живом сегменте.
По сути, сегмент таблицы - это массив байт в начале и массив смещений элементов в конце плюс другие метаданные для поиска (даты и т.п.). Первым запросом читаем конец файла - смещения и другие метаданные сегмента, проходимся по ним на клиенте, а вторым по найденному смещению достаём сами данные сжатого блока, где лежит искомый элемент. В своей СУБД сразу делаю VFS, чтобы можно было работать как с БД в памяти, так и в локальном файле или удалённом сервере без необходимости что-то монтировать в ОС.
SQLite через абстракцию от ФС тоже можно заставить работать, но это будет медленно, так как она не приспособлена для таких задержек. Там B-деревья и сканирование по строкам с множеством чтений файла друг за другом - пинг будет складываться. И её неудобно пилить на много файлов, потому что каждый станет своей отдельной БД. Там оверхед на метаданные, и сжатие только через плагины, причём менее эффективное, так как вроде мелкими блоками работает.
Другое дело - своя СУБД, специально предназначенную для поиска элементов за минимальное количество прыжков по файлу - за 2, и автоматическую упаковку старых данных в отдельные read-only файлы. Постепенно такие архивные файлы будут копиться, но сервер БД всегда будет работать только с текущим не дописанным сегментом и держать компактную карту с интервалами ключей, по которым можно определить какие файлы-архивы стоит смотреть для запроса. А в архивах будет искать сам клиент, предварительно получив актуальную карту с сервера. Большую часть карты можно тоже хранить в архивах, а с сервера только получать дельту, можно даже в режиме реал-тайм подписки.
Cloudflare бесплатно проксирует же, правда в РФ с ним проблемы, но я нашёл некоторые костыли, чтобы только для блокирующих его провайдеров использовалась прокси-VPS. Конечно при большой нагрузке Cloudflare может прийти с требованием платить, но это вроде очень большая нагрузка должна быть. Вряд ли это случится до того, как я хорошо заработаю на своём проекте, и это станет неважным. А если не заработаю, то и не придут, смогу поддерживать его в рабочем состоянии практически бесплатно. Как минимум, не надо платить за вычисления, можно захостить всё на слабом серваке с большими дисками и быстрой сетью. И моя СУБД хорошо экономит место и трафик за счёт блочного сжатия большей части данных и упаковки метаданных. Если традиционные БД весят намного больше, чем сырые данные, которые там лежат, то у меня будет в разы меньше. Не понял, зачем мне минус поставили. Неужели такая архитектура никому не интересна? Даже если идея выкладывать данные на всеобщее обозрение кажется стрёмной, можно ведь захостить её внутри контура компании, а клиентами сделать бекенд, любое количество микросервисов и т.п., и БД не будет боттлнеком даже если вырастет до терабайтов.
Не шутка. Я пишу свою соцсеть, где пользователи смогут писать код шейдеров и не только, всё выполняться в браузере и публиковаться как посты. В общем , убийца ShaderToy. Искал решения, как сделать это, чтобы потом практически не платить за инфраструктуру. Придумал такую СУБД, публичные фрагменты которой можно выложить на CDN и по HTTP Range-запросами находить всё, что надо, прямо с клиента. Бекенд только будет изредка выдавать карту, чтобы клиент знал, где искать актуальную версию данных, а также для записи и данных, требующих контроля. И то скорее всего такие данные будут тоже на CDN, но в зашифрованном виде, а бекенд будет только ключи выдавать.
В России как минимум мобильные операторы блочат Cloudflare. Мне пришлось для них настраивать редирект напрямую на свою VPS, которая проксировала с Cloudflare.
А не проще ли ChatGPT дать доступ к репе Github, где держать базу знаний и другие сервисы прикрутить типа календаря и что ещё там можно? Он даже может PR делать, правда создавая и редактируя файлы по одному и каждый раз спрашивая.
Я это начал использовать, когда кончается недельная квота Codex, чтобы в это время составлять и прорабатывать задачи.
Это оно будет циклы гонять или питание от адаптера берётся ровно то, которое нужно для работы, без зарядки?
Я как раз из тех, кто за 16 лет разработки, из которых 8 лет профессионально, почти никогда не писал тесты, искренне не понимая, зачем они, так как на отладку тратил всегда мало времени и без них.
У меня свои проекты, на работе тоже проект библиотеки, который начинал сам с нуля, на которой крутятся рабочие проекты, которые создают другие. Обычно баг ловится сразу - запускаю рабочий проект, и ничего не рисуется или рисуется коряво. А дальше ртладчиком смотрю туда, где недавно что-то менял, и быстро нахожу причину.
За всё время получилась только пара smoke/fuzz тестов с кастомным сетевым протоколом и ещё одном месте, где ловил много багов, но я изначально ожидал их там встретить.
Помогает продуманная архитектура без дублирования кода и раскиданные по функциям ассерты-контракты. Код максимально переиспользуется благодаря универсальным абстракциям, поэтому кода, который нужно отлаживать, довольно мало, и почти все ветки кода ядра задействуются сами собой.
Если писать юнит-тесты, то при каждой итерации рефакторинга их придётся переписывать, а на это всегда было лень тратить время с учётом того, как мало его уходило на отладку и много на продумывание архитектуры.
Но с внедрением ИИ агентов стал покрывать тестами, и при обнаружении бага требовать воспроизводить его падающим тестом. Теперь ИИ агенты навёрстывают, покрывая код, и если надо, перепишут сами при рефакторинге, а потом сами будут их вызывать, подтверждая, что они действительно сделали задачу, а не сломали всё. Тут тесты реально стали нужны, чтобы вручную не просить агента переделывать по 10 раз по кругу.
А как модель по сравнению с Kimi k2.5? Про неё читал, что чуть ли не Sonnet 4.6. В Windsurf её дают бесплатно. Я её пробовал в Windsurf, тупит хуже, чем GPT 5.2 Low.
Вот думаю, стоит ли пробовать Qwen...
У меня все вкладки пустые были. Он мог как-то висеть в фоне даже при закрытии всех вкладок и окна терминала, и прибиться по Cmd+Q вместе с терминалом? Я думал, что никаких процессов там не выполнялось, и память жрал сам терминал.
А можно подробнее, что даёт GPT, что Opus? Я пробовал только GPT в Codex, так как не готов много платить, и получаю хороший результат.
Ещё немного сравнивал Opus 4.6 с GPT 5.4 в Windsurf на паре промптов в одной задаче. Оба одинаково сломали работающий код, но первый жрал квоту в 2 раза быстрее. Оба использовал с medium reasoning без повышенного контекста. Там задача была довольно локальная, с CSS надо было добиться нужного вида.
А почему все пишут про Claude Code, но никто не пишет про Codex? У последнего же вроде квоты намного лучше за те же деньги? Или Claude Code настолько лучше по качеству или ещё чему-то, что затмил всех конкурентов?
Просто я не пробовал Claude Code, там сложнее регистрироваться из РФ, а Codex для меня и так очень хорош. Есть что-то ради чего стоит попробовать кроме может слегка лучшего качества?
В Windsurf бесплатно и безлимитно с недавних пор дают Kimi k2.5. Где-то читал, что она якобы не хуже Sonnet 4.5, по моему опыту она неплоха, но даже GPT 5.2 Low, доступная в Windsurf Free с ограниченной квотой, её уделывает. Думал купить там подписку, но пока был на триале, они ввели дебильную систему дневных и недельных квот для платных моделей, которые слишком быстро заканчивались даже на GPT 5.4, не говоря уже о Claude, который жрёт квоту как не в себя.
Ещё Codex на бесплатном тарифе есть, но это временно. А если подключить зарубежную карту (в РФ я завёл виртуальную по цене месяца подписки), то дают триал Plus на месяц с удвоенной квотой - временно, как они утверждают на сайте. Но даже удвоенную недельную квоту я потратил за два дня, сидя по 12 часов в день и документируя, покрывая тестами и добавляя инфраструктурные фичи в два моих проекта.
Мне интересно, почему все везде пишут только про Claude Code? Я его не пробовал, так как говорят, что там квоты улетают в миг, и нужно платить кучу денег, а у меня хороший опыт с Codex, а бесплатный Windsurf помогает дотянуть до восстановления недельной квоты Codex'а, за которую многое успеваю сделать и претензий к качеству не имею.
Не понял, откуда гарантия, что младшие биты свободны? Указатель же void*, значит не подразумевает никакого выравнивания данных. По указателю может храниться например строка или бинарный массив, не выровненный на 4 байта. А то, что сам указатель в структуре выравнивается, к этому вообще отношения не имеет.
По поводу битовых полей не понимаю, зачем их избегать. Вроде они везде одинаково работают кроме big/little-endian. Я проверял в compiler explorer на распространённых платформах и всех основных компиляторах. Кажется, только были какие-то нюансы между big и little-endian, но лучше их учесть, чем городить портянку с private и геттерами-сеттерами.
А для сериализации можно завести тип с перевёрнутым порядком байт для big-endian архитектур, не переворачивая для little-endian. Назвать типа uint32LE/uint16LE. Тогда можно будет просто писать структуры на диск.
Ну наверное больше десятка видел статей про алготрейдинг с использованием только индикаторов. А из фигур видел только один урок по поиску чего-то похожего на ГиП, но который находил не далеко не все ГиП, а только в небольшом окне из нескольких свечей. И дальше не было никакого алгоритма с бектестами.
Я полгода назад искал в гугле алготрейдинг с фигурами, но попадается либо просто базовое неформализованное описание фигур без алгоритма, либо алготрейдинг с индикаторами. Статью на Хабре, про которую вы говорите, не находил.
Меня интересуют фигуры не сами по себе, а с точками входа и стопами за линии поддержки. Если фигура сработала, то заработал, если нет - закрылся по маленькому стопу. В итоге в среднем можно неплохо зарабатывать, мне кажется. По крайней мере, некоторые курсы по трейдингу так учат. И их авторы побеждают на турнирах и ЛЧИ с сотнями процентов доходности за несколько месяцев. Но они торгуют руками, попыток сделать такое в алгоритмах я не видел.
То, что рынок - разводняк, не спорю. Скорее всего, им крутят большие дяди с огромными капиталами, провоцируя толпу на выгодные для них действия, которые ведут к перетеканию денег от толпы к ним. Должны быть какие-то правила, по которым они действуют, инициируют движения, которые психологически заставляют толпу продавать и покупать тогда, когда это выгодно им. Если разгадать хотя бы их часть, можно к ним присоединиться и тоже себе часть этого потока забрать. Я думаю, это возможно, но не сводится к простым индикаторам. И как только заметная для них часть потока начнёт утекать посторонним, они эти правила усложняют, поэтому старая информация в интернете и книгах не работает или становится неполной.
Везде вижу уроки, что в алготрейдинге используют только тупые индикаторы. Но никогда не слышал, чтобы кто-то пытался сделать алгоритмы, которые торгуют те же идеи, что и люди: фигуры типа флагов, головы и плечей, бэтменов, волн Эллиотта или Вульфа и т.п..
И свечные модели, всякие price action тоже в алгоритмах не видел, хотя то, что рассказывают на Ютубе, вроде неплохо формализуется на первый взгляд. Конечно наверняка большинство - это инфоцыгане, но бэктест бы это сразу показал.
Уже давно вынашиваю идею создания своего языка для хранения и обработки данных - чего-то типа убийцы JSON, protobuf, flatbuffers, TOML и SQL в одном флаконе. Думал, как делать JIT для него. Хотел что-то легковесное, при этом кроссплатформенное, думал делать своё: IR на основе ARM64 и упрощённую аллокацию регистров. И тут вы как раз такое сделали, да ещё и с человеческим лицом. Теперь как руки дойдут до JIT, буду знать, куда смотреть.
А поддержка SSE для процессоров без AVX планируется? У меня несколько таких девайсов есть, причём два из них относительно свежие, например, мини-ПК на Celeron N5095. Ещё есть VPS, где только SSE2 вроде или SSE3 - не выше.
В РФ мало знать английский, надо ещё умудриться работать в условиях санкций. Конечно проще, если рассматривать релокацию. Я язык знаю, но уезжать не готов, а с удалёнкой сложнее.
А можно поставить Coolify так, чтобы сборка шла локально, а на VPS только само приложение? И захостить на самой дешёвой VPS 512 МБ ОЗУ и 1 vCPU, которой более чем достаточно для запуска всех моих приложений?
Или может есть аналог Coolify, если он так не может?
В TS с тем же успехом можно сделать аргумент типа number|string|object. И в контексте тех же дженериков те же сбросы оптимизированного кода происходят, в отличие от шаблонов C++, где создаётся специализированная для типа оптимизированная функция. И наоборот, можно сам JS писать так, чтобы не допустить такой ситуации.
TS сам по себе не влияет на производительность, но может быть инструментом, который поможет своими подсказками и ограничениями упорядочить типы в коде, чтобы не только избежать багов в коде, но и избежать ситуации, когда V8 сбрасывает оптимизированный код. Всё равно это задача того, кто пишет код, которую он должен держать в уме, ограничивая типы.
У меня немало проектов с фронтендом, но из всего перечисленного в статье использую только TypeScript. И не понимаю, что у вас там за дженерики на дженериках и зачем они?
Другое дело C++, там можно нагородить многоэтажных и сложных шаблонов ради того, чтобы потом всё заинлайнилось и оптимизировалось компилятором, сгенерировав наиболее оптимальный код алгоритма или структуры данных для каждого типа.
Но в экосистеме JS типы TS - просто ограничения, проверки и подсказки, не влияющие на производительность. Не вижу смысла усложнять.
Я пытаюсь сделать именно СУБД с таблицами и с запросами по одной таблице - хотя бы уровня SELECT без JOIN'ов и GROUP BY по функционалу - сам язык SQL для этого необязательно делать. Каждая таблица - это директория с набором файлов-сегментов типа 0.seg, 1.seg, 2.seg, и т.д. по мере накопления данных. Когда файл вырастает большой, начинаем писать новый, а старый сжимается блоками и фиксируется навсегда как read-only файл - его можно раздавать и кешировать. Если элемент обновился, он уже попадёт в новый сегмент, а в архиве зависнет старая версия. Чтобы найти именно последнюю версию, надо у сервера спросить карту, которая скажет, в каком архиве последняя версия или она ещё в живом сегменте.
По сути, сегмент таблицы - это массив байт в начале и массив смещений элементов в конце плюс другие метаданные для поиска (даты и т.п.). Первым запросом читаем конец файла - смещения и другие метаданные сегмента, проходимся по ним на клиенте, а вторым по найденному смещению достаём сами данные сжатого блока, где лежит искомый элемент.
В своей СУБД сразу делаю VFS, чтобы можно было работать как с БД в памяти, так и в локальном файле или удалённом сервере без необходимости что-то монтировать в ОС.
SQLite через абстракцию от ФС тоже можно заставить работать, но это будет медленно, так как она не приспособлена для таких задержек. Там B-деревья и сканирование по строкам с множеством чтений файла друг за другом - пинг будет складываться. И её неудобно пилить на много файлов, потому что каждый станет своей отдельной БД. Там оверхед на метаданные, и сжатие только через плагины, причём менее эффективное, так как вроде мелкими блоками работает.
Другое дело - своя СУБД, специально предназначенную для поиска элементов за минимальное количество прыжков по файлу - за 2, и автоматическую упаковку старых данных в отдельные read-only файлы. Постепенно такие архивные файлы будут копиться, но сервер БД всегда будет работать только с текущим не дописанным сегментом и держать компактную карту с интервалами ключей, по которым можно определить какие файлы-архивы стоит смотреть для запроса. А в архивах будет искать сам клиент, предварительно получив актуальную карту с сервера. Большую часть карты можно тоже хранить в архивах, а с сервера только получать дельту, можно даже в режиме реал-тайм подписки.
Cloudflare бесплатно проксирует же, правда в РФ с ним проблемы, но я нашёл некоторые костыли, чтобы только для блокирующих его провайдеров использовалась прокси-VPS. Конечно при большой нагрузке Cloudflare может прийти с требованием платить, но это вроде очень большая нагрузка должна быть. Вряд ли это случится до того, как я хорошо заработаю на своём проекте, и это станет неважным. А если не заработаю, то и не придут, смогу поддерживать его в рабочем состоянии практически бесплатно.
Как минимум, не надо платить за вычисления, можно захостить всё на слабом серваке с большими дисками и быстрой сетью. И моя СУБД хорошо экономит место и трафик за счёт блочного сжатия большей части данных и упаковки метаданных. Если традиционные БД весят намного больше, чем сырые данные, которые там лежат, то у меня будет в разы меньше.
Не понял, зачем мне минус поставили. Неужели такая архитектура никому не интересна? Даже если идея выкладывать данные на всеобщее обозрение кажется стрёмной, можно ведь захостить её внутри контура компании, а клиентами сделать бекенд, любое количество микросервисов и т.п., и БД не будет боттлнеком даже если вырастет до терабайтов.
Не шутка. Я пишу свою соцсеть, где пользователи смогут писать код шейдеров и не только, всё выполняться в браузере и публиковаться как посты. В общем , убийца ShaderToy. Искал решения, как сделать это, чтобы потом практически не платить за инфраструктуру. Придумал такую СУБД, публичные фрагменты которой можно выложить на CDN и по HTTP Range-запросами находить всё, что надо, прямо с клиента. Бекенд только будет изредка выдавать карту, чтобы клиент знал, где искать актуальную версию данных, а также для записи и данных, требующих контроля. И то скорее всего такие данные будут тоже на CDN, но в зашифрованном виде, а бекенд будет только ключи выдавать.
В России как минимум мобильные операторы блочат Cloudflare. Мне пришлось для них настраивать редирект напрямую на свою VPS, которая проксировала с Cloudflare.