Как я сделал mmap-базу для 4 миллионов товаров и 700 тысяч посадочных страниц

[legendasofizma]

Ого. Круто. Всячески поддерживаю подобные разработки, в таком стиле сделал пару работающих в большом интернете проектов, живущих уже годы, одному вообще 15 лет уже и помирать не собирается. Но я такое делал в основном на C++.

Но потом уже эволюционно пришёл к тому, что "движок таблиц" (то что называется "реляционная БД"), то есть движок способный хранить пачки одинаковых строк - это довольно сильная штука, потому что на неё ложится вообще любая схема данных. Если сделать один хороший движок таблиц, то мы потом получаем гибкость на все времена.

SQL как язык запросов тоже отличная штука, потому что когда твоя самодельная C++ БД может достать данные или дать покопаться в себе только через написание какого-то клиентского кода, то теряется оперативность некого дебага, дампа, бекапа и прочих сторонних задач "поковыряться в БД".

[ihar76]

Я давно заглядываюсь на С++, даже имел опыт работы на нем, в том числе как база для больших проектов. Поэтому приятно видеть единомышленников. Но поскольку я больше работаю с Go, сделал такой эксперимент. И действительно, как и вы, обнаружил, что гибкость такого рода решений находится на таком уровне... Правда очень сложно налаживать систему и много времени уходит на доведение.

[press_a_key]

SilentJSON рассчитан на другой сценарий. Если структура данных известна заранее, зачем каждый раз заново выяснять её устройство? Если тип известен, зачем относиться к нему как к неизвестному интерфейсу?

Почему тогда уж сразу не ptotobuf/messagepack и т.п. ? Вроде быстрее ничего не придумали. А сериализаторы для js на клиенте генерятся по схеме.

Почему не redis, riak, и куча других kv решений?

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

[ihar76]

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

Почему не Redis или Riak? Как минимум потому, что это уже совсем другой класс решения. В моём случае задача -- embedded-хранилище, где данные и индексы работают непосредственно в памяти процесса или через mmap. Поэтому здесь я в первую очередь пытаюсь минимизировать накладные расходы самого storage layer, а не сетевого взаимодействия с отдельным сервисом.

Это не значит, что Redis/Riak или protobuf плохие решения. Просто у них другие trade-off и другая область применения.

[press_a_key]

Это к тому, что движков для баз данных в 2026 году сделали очень много https://db-engines.com/en/ranking . И с большой долей вероятности сделали и такой, что подошел бы вам. И поэтому мне интересно, проводили ли вы сравнительную работу или нет?

[ihar76]

вопрос очень хороший. Я по сути не нашел среди баз подходящую. Одни из проверенных, как-то подходящих -- SQLLite, но тут нюанс, sql-overhead. По скорости она не может соревноваться. Как и по простоте. Я сделал решение для проекта, где нет ограничений по структуре данных, со схемой -- нативно работаем с индексами, документы отдаем как есть (as-is). т.е. напрямую запрос -> индексы -> json -> ответ. Даже система может не знать что внутри документа. Все это решается при подготовке данных в базу. т.е. полагаемся не на логику приложения, а на логику информации. При любом изменении меняем просто подготовку информации и если нужно индексы. все.

Вот такое было требование.