Привет, я собрался свою карманную БД писать на основе Serde+Bincode

и std::fs, сами данные скорее всего будут представлять из себя вектор структур (например юзеров) обёрнутый в RwLock. кстати скажите, имеет ли смысл пытаться оборачивать каждый отдельный элемент вектора в RwLock/Mutex/Refcell (не определился пока), смогу ли я таким образом добиться параллельного доступа к разным данным из моего вектора?

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

в принципе можно, наверное, стараться всё держать в ОЗУ по возможности (я бы хотел реализовать частичную загрузку значений в память) и периодически делать запись всего вектора целиком в файл - таким образом всё должно будет последовательно лежать и не надо париться с разметкой (это если конечно я не упрусь в какие-то ограничения Serde в стиле "нет, чувак, RwLock ты сериализовать не будешь")

правда я пока ещё не знаю, как во фреймворке Rocket сделать систему, которая бы следила за периодической записью на диск значений из БД

ты что-нибудь слышал о транзакционной целостности? )

нет

Мне кажется, ты вперёд коня бежишь, когда сначала придумываешь имплементацию БД, а потом смотришь, какие проблемы и как она сможет решить. Если сначала поставить цели для БД, а потом от целей продумывать имплементацию, то будет намного проще. Правда, не всегда задачи сразу ясны, так что тут могут быть проблемы, да.

ну цель у меня просто хранить данные, чем быстрее и эффективнее тем лучше, конечно, но в рамках ограниченного времени на реализацию и ограниченного опыта программирования

1) Влезает в память? Если да, то нафиг БД, всё храним в памяти. 2) Нужна ли тебе полноценная БД вообще? Есть вариант взять какой-нибудь flatbuffers и просто на каждом апдейте переписывать весь файл с новым сериализованным рутом. 3) Если БД таки нужна, посмотри, не существует ли нужная БД где-нибудь. NoSQL баз хоть ложкой ешь, там под каждого найдётся своё. 4) Если таки обязательно надо писать самому, то лучше всего посмотреть на то, как реализована какая-нибудь похожая БД. Если похожих совсем нет, то всё равно есть похожие части, например реализация атомарности.

1) в какой-то момент серверу может понадобиться побыть выключенным (короче надо в ПЗУ записать энивэй) 2) что такое флэтбафферс, где посмотреть про это? 3) ну возможно монгодб, но мне тут интересно самому написать свою БД 4) вроде во время разведки недавно наткнулся на похожее, забыл правда, как называется, но думаю смогу найти снова

>в какой-то момент серверу может понадобиться побыть выключенным Ну тупо совмещаешь пункты 1 и 2 — всё хранишь в памяти, но при запуске читаешь из файла, а при закрытии пишешь в файл; и автосохранения с каким-нибудь гигантским интервалом в минуту можно (нужно) делать.

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

ты для общего развития или неиронично планируешь доморощенную бд в проде юзать?

ну прод тоже доморощенный так что да

прост я недавно в реальном продакшне потратил порядка 5 человеколет чтобы выпилить такую штуку и заменить на монгу

Лучше SQLite посмотри.

уже был опыт с ним - не понравилось

если ты серьезно планируешь писать то посмотри на инмемори распространенные: ravendb, tarantool, ...

окей

нашёл крейт похожий на то, что я хочу реализовать, только он не шибко распространён (300 звёзд) и вроде нет частичной загрузки (она не необходима, но с ней наверное лучше чем без)

ну 300 звезд это уже скорее всего экономия кучи месяцев работы, даже если подпиливать надо. Если будет недостаточно то поищи биндинги к распространенным популярным решениям вроде тех что я скинул. SQLite например хоть и корявенький но на голову выше самописных приколюх :) Но есть и документные более новые, они могут быть поинтереснее. — В общем, тебе +- формально надо все требования собрать заранее что нужно уметь - тогда и выбор нормальный можно будет сделать. А "погнали там разберемся" - тоже работает, но дорого очень) Можно дешевле, на существующем функционале Ну например: SQlite. почему нет? Что с ним не так? Надо минусы расписать, если они состоят из одного "чет мне не нравица, не знаю чем" то возможно стоит пересмотреть отношение)

кстати дедлайн у меня через несколько дней

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

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

дизель не компилится (не знаю, может я его prerequirments не удовлетворил) да и изучать его отдельно

изучать тебе нужно 1.5 запроса которые у тебя есть, остальное тебе не нужно. И сами запросы у тебя простые, так што там тоже ничег осложного. На крайняк юзай голвый параметризованный SQL и не учи ничего