О вреде ООП надо говорить! Это - слишком важная тема, чтобы отмалчиваться.

это не отменяет моего наброса))))

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

увы я давно просрал кучу знаний за сиюминутной ненадобностью :)

Реквизит объекта может быть массивом или ассоциативным массивом.

BLOB, btree

Или даже функцией.

TEXT

Если это считать значением и складывать на стек, всё равно векторизовать не получится.

Я дал не очень хороший пример. В С++, благодаря его нулевым абстракциям, можно колбасить «свой ООП» (с ограничениями ессно, если не хакать компилятор). И можно на вьюшках писать SoA-style код, который удобен для векторизации. Но там при этом все равно инкапсуляция будет нарушаться. Можно, правда, используя атрибуты, подсказать оптимизатору, как лучше векторизовать код для конкретных классов, но это уже специфика компилятора.

наследование в ORM делается жуткими извратами.

А никто и не обещал, что будет легко. Это не жуткие извраты, а необходимость самому дизайнить низкоуровневые структуры данных, впихивая их в прокрустово ложе реляционной модели. Мы с внешней памятью имеем дело, а не с RAM, где pointer chasing имеет сложность O(1) с низкими скрытыми константами. В БД у тебя кучи нет, если это не in-memory DB и не mmap, поэтому связывание сущностей по любому пойдет через joins и b-tree.

BLOB, btree

btree может быть значением SQL поля? В BLOB можно изменить пятый элемент массива из 100500 элементов и не переписывать весь BLOB? Не говоря уж про запросы типа select o where o.f[5].c[10].d = 1.

TEXT

Читать в массив и приводить к типу функции? Или скриптовый язык использовать? Или Lisp?

Но там при этом все равно инкапсуляция будет нарушаться.

С чего? Пользователю даёшь только вьюшки и API, а все классы *_data_impl только в библиотеке.

Это не жуткие извраты, а необходимость самому дизайнить низкоуровневые структуры данных, впихивая их в прокрустово ложе реляционной модели.

Ну вот. Уже прокрустово ложе. А нормальная ООБД хранит произвольные объекты. Хотя бы как Mnesia.

Мы с внешней памятью имеем дело, а не с RAM, где pointer chasing имеет сложность O(1) с низкими скрытыми константами. В БД у тебя кучи нет, если это не in-memory DB и не mmap, поэтому связывание сущностей по любому пойдет через joins и b-tree.

Вот это тоже непонятно почему. В SQL каждый запрос делается с нуля. Если хочешь сделать нормальный pointer chasing, строишь поверх сервер приложений, если хочешь кэш, то memcached. В результате любая программа на DBF-таблицах на порядки быстрее аналога на SQL.

btree может быть значением SQL поля?

Все может быть, если предусмотреть это в высокоуровневой системе типов. Низкоуровневая принципиальных ограничений на такие вещи не накладывает. Писать ради таких вещей аж целый новый класс СУБД смысла нет. БД-строение — область ооочень консервативная.

С чего?

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

А нормальная ООБД хранит произвольные объекты.

Она не хранит произвольные объекты. Она предоставляет достаточно много низкоуровневых on-disc структур данных, чтобы над ними построить нужные высокоуровневые типы данных а-ля объекты для конкретного ЯП. Но ничего такого магического, что умеют ООСУБД, но не имеют РСУБД, они не могут.

Если хочешь сделать нормальный pointer chasing, строишь поверх сервер приложений

CTE и With Recursive же. Но тут дело совсем в другом. Если ты хочешь нормальные pointer chasing, то тебе нужна in-memory DB с O(1) навигацией. На Btree это будет на порядок медленнее, хорошо если.

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

Проблема, которую ты описываешь, — это общая слабость и плохая расширяемость систем типов существующих РСУБД. ООБД тут могут изначально дизайнится под более дружественную к ООЯП систему типов, но и у них тоже будут свои проблемы. Потому что, как только тебе надо что-то, что базовой системой типов не предусмотрено, например, какой-нибудь хитрый индекс, начинаются проблемы. СУБД не дают тебе себя хакать. PostgreSQL тут — приятное исключение, но и его возможности в этом смысле ограничены.

Та же самая проблема и у высокоуровневых языков типа Java. Они не дают доступа к памяти напрямую. И что-то за пределами стандартной системы типов требует злостных хаков.

Достаточно гибкая СУБД должна быть примерно как С++ — позволять хакать себя по всему стеку, вплоть до железа.

(Postgresql — приятное исключение, но и он страдает).

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

Т.е., вот, предположим, что у нас есть NVRAM достаточного размера, чтобы вмещать все наши данные, и что мы решили проблему атомарности групповых операций над ней (persistent data structures нам в помощь) для фейловера. Вот какой-нибудь условный Rust (или С++ и тегированная память) станет «той самой СУБД-мечты».

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

Так вьюшки — расширение реализации. По отношению к ним инкапсуляции быть не должно. А пользователь будет видеть только вьюшки.

Но ничего такого магического, что умеют ООСУБД, но не имеют РСУБД, они не могут.

Только что же писал про прокрустово ложе. В РСУБД нельзя в значение поля воткнуть тип-объединение, нельзя коллекцию, нельзя замыкание. Любая бухгалтерия на РСУБД из-за этого городить что-то монструозное для реализации обычного журнала проводок с аналитикой (либо сотни колонок, которые почти все пустые, либо при запросе JOIN с сотней баз). Спасибо 1С, они свой компилятор запросов по метаданным написали, но в профайлере смотреть на результат компиляции без содрогания сложно. И это 1С, где нельзя сделать наследника произвольного класса.

Но ничего такого магического, что умеют ООСУБД, но не имеют РСУБД, они не могут

add_plans() ->
    D1 = #design{id = {joe,1},
        plan={circle,10}},
    D2 = #design{id = fred,
        plan={rectangle,10,5}},
    D3 = #design{id = {jane,{house,23}},
        plan = {house,
            [{floor,1,
                [{doors,3},
                 {windows,12},
                 {rooms,5}]},
             {floor,2,
                [{doors,2},
                 {rooms,4},
                 {windows,15}]}]}},
    F = fun() ->
        mnesia:write(D1),
        mnesia:write(D2),
        mnesia:write(D3)
    end,
    mnesia:transaction(F).

Покажи, как запишешь в РСУБД.

CTE и With Recursive же.

Он же только до конца запроса живёт.

DBF выигрывает за счет того, что нет сетевой задержки.

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

Потому что, как только тебе надо что-то, что базовой системой типов не предусмотрено, например, какой-нибудь хитрый индекс, начинаются проблемы.

Mnesia держит все типы. https://prevayler.org/ все сериализуемые.

А пользователь будет видеть только вьюшки.

А если пользователь хочет сам делать вьюшки?

В РСУБД нельзя в значение поля воткнуть тип-объединение, нельзя коллекцию, нельзя замыкание.

Это не проблема РСУБД как класса, а проблема конкретных РСУБД. Если у тебя Postgresql, то бухгалтерия идет контрактует меня, и я пишу поддержку нужных типов данных. Это не дешево, но по итогам окажется дешевле, чем оплачивать мучения разработчиков со стандартной системой типов. Если не хочет контрактовать индивидуала, идет и заказывает у консалтеров типа PgPro с поддержкой. Если же бухгалтерия плотно сидит на MSSQL, или, упаси нас ЖГ, купила Oracle, то кто ей виноват?

Покажи, как запишешь в РСУБД.

Что там? Иерархические структуры? Документные расширения типа jsonb в Pg могут это.

Он же только до конца запроса живёт.

Так а дольше и не надо. Запрос будет продолжаться столько, сколько длится обход твоей структуры. «Resursive» же.

Mnesia держит все типы.

Rank/select dictionary она мне будет держать? Или разреженный тензор, чтобы эффективное умножение поддерживал?

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

Ну так всё правильно, но я не думал, что до этого дойдёт так быстро.

Дык не ООП виновато, а говнокодеры

Так что угодно не виновато, а говнокодеры.

В случае ООП раздутие привело к тому, что код действительно легче сопровождать

У меня вышло кода на жс меньше чем на жабке в 10 раз. Что легче сопровождать вопрос риторический. Может на огромных проектах это и решает но там разница между «вообще невозможно ничего сделать» и «можно сделать с продираясь через абстрактные фабрики стратегий».

А если пользователь хочет сам делать вьюшки?

Значит он разработчик библиотеки. В общем-то пользователь любой библиотеки на C++ вполне может влезть в код, если очень приспичит.

Если у тебя Postgresql, то бухгалтерия идет контрактует меня, и я пишу поддержку нужных типов данных.

Ха. 1С не смог. Хотя денег и программистов у них хватает.

Документные расширения типа jsonb в Pg могут это.

А индекс на поля этого json’а как делать?

Запрос будет продолжаться столько, сколько длится обход твоей структуры. «Resursive» же.

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

Rank/select dictionary она мне будет держать? Или разреженный тензор, чтобы эффективное умножение поддерживал?

Что угодно, что сможешь написать на Erlang’е.

Значит он разработчик библиотеки.

Лютобешеное нарушение инкапсуляции же, если чтобы добавить вьюшку, мне надо либу патчить)))

Ха. 1С не смог. Хотя денег и программистов у них хватает.

У корпораций тоже денег и своих программистов хватает. Но они предпочитают стартапы скупать.

А индекс на поля этого json’а как делать?

GIN index, как обычно.

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

Вся структура уже в БД и закеширована в блоках памяти. А если не закеширована, до добавляем памяти и кэшируем. Это же pointer chasing.

Что угодно, что сможешь написать на Erlang’е.

Ну окей. Я таки написал большой битмап на эрланговском массиве и изменил в нем 1 бит. Что произойдет дальше?

Лютобешеное нарушение инкапсуляции же, если чтобы добавить вьюшку, мне надо либу патчить)))

Гм… Зависит от точки зрения. В GTK чтобы ввод emoji в любом текстовом поле убрать тоже приходится либу патчить.

Если чему-то для работы необходимо внутреннее устройство либы, то это часть либы.

GIN index, как обычно.

Посмотрел. Не понял. Что написать, чтобы работало SELECT * from plan where plan.house.floor[1].doors = 3 с использованием индекса по doors? То есть как добавить индекс на house.floor[1].doors.

Вся структура уже в БД и закеширована в блоках памяти.

С чего это? Он данные CTE на каждый запрос заново с нуля строит.

Ну окей. Я таки написал большой битмап на эрланговском массиве и изменил в нем 1 бит. Что произойдет дальше?

Да. Понял. Для таких операций действительно только на основании mmap что-то делать. Массив будет одним значением.

Если чему-то для работы необходимо внутреннее устройство либы, то это часть либы.

Ну вот о чем и речь. Тут мы подходим к пределам применимости ООП уже как метода, так как он изначально заранее предполагает, что доступ к состоянию объектов будет происходить через «узкие каналы» (что и есть инкапсуляция). Т.е. что большая часть активных связей по данным локализована внутри объекта. А вот если такая статистика не выполняется (а она не выполняется, например, для БД), то нам нужно открывать состояние объекта наружу и инкапсуляция ослабляется.

Посмотрел. Не понял. Что написать, чтобы работало

Я ХЗ. Дока говорит, что индексирование поддерживается, а как и с какими ограничениями — я не смотрел). Синтаксис вида 'a.b.c = d' не взлетит. Нужен XPath.

А вот если такая статистика не выполняется (а она не выполняется, например, для БД)

С точки зрения ООП вокруг БД должен быть класс, предоставляющий только те запросы, которые использует остальная программа. Тогда в случае замены БД или изменения её структуры меняется только один класс. Паттерн data mapper.

Твои вьюшки – полный аналог такого класса. Реализация данных доступна только вьюшкам. Вся остальная программа использует только вьюшки.

необходимость самому дизайнить низкоуровневые структуры данных, впихивая их в прокрустово ложе реляционной модели

Зачем такие извраты?

С чего это? Он данные CTE на каждый запрос заново с нуля строит.

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

Для таких операций действительно только на основании mmap что-то делать

Mmap не годится для мутабельных данных, хотя раньше на нем БД делали. На MMap сложно добиться отказоустойчивости, и очень сложно контроллировать сброс страниц на диск. Т.е. технически оно всё осуществимо, но лучше не надо. У меня в Мемории, правда, SWMRStore в одной из вариаций работает над MMap, но там перезаписи блоков нет. Там лог-структурированный циркулярный буфер. Тут можно добиться отказоустойчивости, но со всем остальным жепа останется.

Массив будет одним значением.

Всё еще хуже. Если говорить про Erlang, то массивы там иммутабельные. Т.е. если хочется каноничности, то придется делать CoW-массивы, и Mnesia превратится в Memoria, гы.

В Мемории проблем, которые ты описываешь, действительно, нет. Все типы динамические, все можно эффективно обновлять, как точечно, так и пакетно. Есть и jsonb-подобные структуры на основе ссылочной модели, но у них размер ограничен и оптимизирован на небольшие документы, которые в блок влезают (4K-1M), тогда будет zero-copy.

Mnesia, кстати, в какой-то мере модель для Memoria. Но не конкретно как БД, а в контексте всей эрланговской платформы. Я тоже затачиваюсь по CSP-модель в качестве операционной надстройки. И считаю, что ЯП с платформой должен иметь хорошую гибкую встраиваемую БД, над которой эту платформу и строить.

btree может быть значением SQL поля?

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

А нормальная ООБД хранит произвольные объекты. Хотя бы как Mnesia.

Если БД - помойка разнотипных объектов, то, как правило, появляются проблемы с производительностью.

любая программа на DBF-таблицах на порядки быстрее аналога на SQL.

Это быстрота не бесплатно. Если ты захочешь тот же уровень надежности изоляций и т.п. то быстрее не будет.

Зачем такие извраты?

Жизнь заставляет)

Вся остальная программа использует только вьюшки.

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

Так вот, в случае БД у тебя уже состояние экспортируется в «стандартном виде», пригодном для выполнения запросов по нему. В случае же просто обычных объектов, их состояние «сырое», и в к выполнению непредвиденных запросов не приспособленное.

Чтобы оно стало приспособленным, эти данные должны стать «типизированными». А это уже будет БД, по определению. (БД = хранилище + система типов).

Вот об этом и тема, что ООП не обеспечивает достаточной гибкости для БД-подобных сценариев. Чтобы обеспечивало, то каждый объект нужно будет снабдить особым методом, принимающим и выполняющим запросы над состоянием объекта на некоем стандартном языке запросов.

На MMap сложно добиться отказоустойчивости, и очень сложно контроллировать сброс страниц на диск. Т.е. технически оно всё осуществимо, но лучше не надо.

Что не так с msync?

Все типы динамические, все можно эффективно обновлять, как точечно, так и пакетно. Mnesia, кстати, в какой-то мере модель для Memoria.

Кстати, смотрел capnproto? Файлы в этом формате технически являются объектной БД при чтении. С записью, конечно, есть нюансы, так как формат про сериализацию, а не про транзакции.

не думал, что до этого дойдёт так быстро.

Просто я не настоящий оопэшник, наверное, в этом все дело.

Что не так с msync?

С ним самим всё так. Вот только полагаться, что в ядре условной ОС всё реализовано корректно с плане упорядочивания запросов относительно такого барьера не стоит. Ну не дизайнился он именно для БД. В LMDB куча хаков на тему поведения mmap на конкретной платформе.

Кстати, смотрел capnproto? Файлы в этом формате технически являются объектной БД при чтении.

Да, я знаю про него. У меня в Мемории есть свой формат на эту тему — LinkedData. Там обычная ссылочная модель, только ссылки относительно начала блока памяти. Поэтому эти блоки можно хранить где угодно, использовать в месте хранения, передавать в акселераторы и т.п., а сам блок является ареной. Если что-то меняется, то изменения идут в конец блока, а потом простейшая «сборка мусора», когда весь объект данных переписывается в новый блок. На сколько я знаю, такая же схема в CapNProto, но множество типов в последнем сильно проще, чем в Мемории.

Это быстрота не бесплатно. Если ты захочешь тот же уровень надежности изоляций и т.п. то быстрее не будет.

Будет быстрее. Но все блокировки или версии придётся делать вручную.

У меня в Мемории есть свой формат на эту тему — LinkedData.

Так это та самая ООБД, про которую ты только что писал, что ничуть не лучше, чем PostgreSQL.

Будет быстрее. Но все блокировки или версии придётся делать вручную.

Оставлю тебя с твоими заблуждениями

Оставлю тебя с твоими заблуждениями

У меня есть 1С 7.7 (многопользовательская) на DBF и идентичный алгоритм расчёта амортизации на 1С 8 MSSQL. Разница в скорости примерно в 10 раз (5 секунд и больше минуты).

В это я верю. Файловые операции эффективнее схожих в СУБД. Только сравни уровень гарантий отказоустойчивости.

Вот прямо сейчас ковыряю попытку ООП нашлепки на СУБД. Оверинжиниг и еще какой.

Но ООП тут не виноват. Виноваты те, кто его использует не по назначанию.

Только сравни уровень гарантий отказоустойчивости.

Реальный уровень примерно одинаковый. Что у файловой в случае внезапной перезагрузки индексы надо обновлять, что у SQL checkdb делать. Транзакции в обоих случаях или проходят целиком или не проходят вообще.

Что у файловой в случае внезапной перезагрузки индексы надо обновлять что у SQL checkdb делать.

Ога

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

То есть в случае dbf это авария, а в случае SQL-сервера это штатная работа.

Или у вас там клиент работает на том же компе, где крутится mssql?

Тады ой.

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

да щас. все зависит не о того, что как называется, а от того, как работает. некоторые живут без WAL и норм, man mdbx.

некоторые живут без WAL и норм, man mdbx.

акелло промахнулся

идентичный алгоритм расчёта амортизации на 1С 8 MSSQL

какой такой mdbx?

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

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

файлсерверной даже транзакция завершится,

Чудеса какие-то. И кто ее завершит у файлсерверного клиента?

Разница в скорости примерно в 10 раз (5 секунд и больше минуты).

ЕМНИП, 1C 8 работал с MSSQL как с DBF, так? Т.е. просто открывал курсор по записям и лопатил?

В это я верю. Файловые операции эффективнее схожих в СУБД.

Зависит от СУБД. SQLite клянется, что он быстрее. LMDB-подобные схемы тоже будут, как минимум, не медленнее (если не на mmap делать). Особенно, если AIO задействовать.

СУБД с WAL или журналом будут фундаментально медленнее на запись, потому что она 2 раза делается. Но ФС тоже может работать в режиме журналирования данных, так что, как придется.

Так это та самая ООБД, про которую ты только что писал, что ничуть не лучше, чем PostgreSQL.

Не совсем та самая.

LD — это всего лишь один из типов поддерживаемых контейнерами данных и, до кучи, легковесный формат нуль-сериализации а-ля capnproto. Мемория построена по data-oriented design и использует модель Structure-of-Arrays, который хорошо подходит для линейного поиска, но плохо — для pointer chasing. Вот специально для второго случая и сделан LD, потому что он обеспечивает О(1) для перехода по ссылкам для тех алгоритмов, для которых это критично. Например, для generic graph traversal.

Объекты не хранятся в LD-документах. Там внутри тоже DOD, в котором, в отличие от ООП, фиксируются не интерфейсы объектов, а схемы типизированных данных в заданной модели памяти. Под капотом, LD-enabled типы, — POD-состояния или TriviallyCopyable StandardLayout-состояния, для которых высокоуровневые объектные вьюшки создаются на лету, потому что так удобнее обращаться к хранимым данным из ООЯП. Ну и человеку тоже так во многих случаях удобнее.

Т.е. это все же не ООБД, так как ОО-уровень там создается динамически в момент обработки этих данных. А на уровне репрезентаций там все равно DOD.

В LD-документе нельзя сохранить произвольный объект С++. Полиморфные объекты там не поддерживаются вообще, а для остальных нужно отдельно определять state и view, и держать эти вещи согласованными через систему type traits. Последнее весьма геморно (TMP весьма плох в плане представления структур данных списками типов), и специально для этого я приделал к Мемории кодогенератор на основе библиотек Clang, который возьмет на себя низкоуровневую кодогенерацию по декларативным описаниям LD-типов данных.

Короче, если ты хочешь классификации, то это всё же не ООБД, так как хранятся не объекты, а их репрезентации. А объектные представления создаются «на лету» во время обращения к этим данным из ОО-кода. Т.е. это по сути легковесный DOD-OOP mapping.

Но для программиста всё в конечном итоге (с учетом наличия проектно-специфичного кодогенератора) может выглядеть как будто Мемория — это ООБД. Но «внутри» оно — нет)

Чудеса какие-то. И кто ее завершит у файлсерверного клиента?

1С в сессии RDP.

ЕМНИП, 1C 8 работал с MSSQL как с DBF, так? Т.е. просто открывал курсор по записям и лопатил?

Нет. В 1С 8 как раз всё переписали по рекомендациям лучших собаководов через временные таблицы и весь алгоритм расчёта в SQL запросе. Стало в 10 раз медленнее.

Т.е. это все же не ООБД, так как ОО-уровень там создается динамически в момент обработки этих данных. А на уровне репрезентаций там все равно DOD.

В ORM тоже динамически. Но в ORM половины необходимых типов нет и pointer chasing тормозной на костылях. А в LD, судя по описанию, ссылки это ссылки, массивы есть, персистентность есть. То есть ООБД поверх этого строится почти тривиально (по сравнению с ORM) даже если считать, что сам по себе он не ООБД.

Короче, если ты хочешь классификации, то это всё же не ООБД, так как хранятся не объекты, а их репрезентации.

Но гораздо ближе к ней чем ORM/SQL.

может выглядеть как будто Мемория — это ООБД. Но нет)

Если что-то выглядит, крякает … как ООБД, то это таки ООБД.

Если что-то выглядит, крякает … как ООБД, то это таки ООБД.

LD — да. Если кто-то хочет его считать ООБД, я спорить не буду. Тем более, что преобразование DOD->OO там очень легковесное, хотя и не нулевое (создать вьюшку).

Мемория же сама — это всё же DOD, просто это OO-friendly DOD. Она позволяет, в зависимости контекста, интерпретировать хранимую информацию или как схематизированные данные, или как объекты ООЯП.

С этим полностью согласен. Кстати, есть хоть какой-то проект, который её использует? Хотя бы игрушечный. Сложные библиотеки проще на примерах понимать.

В Мемории фокус именно на схемах данных для того, чтобы эти данные можно было прочитать и сегодня, и завтра, и через миллион лет. У CapNProto и ProtocolBuffers такой цели (долгосрочное хранение данных) нет. Это versioned wire protocols, а не storage formats. Я хотел сначала взять CnP в качестве легковесного документного формата, но потом понял, что мне для того, чтобы гарантировать долгосрочную стабильность схем, нужно делать свой формат. А CnP, PB или flatbuffers — это сторонние инструменты с совсем другим фокусом.

Сложные библиотеки проще на примерах понимать.

Будет проект по созданию интегрированной билд-системы для С++ с объектной моделью проекта (гы))), сделанной поверх Мемории и SWMRStore (с экпортом состояния по FUSE для внешних инструментов). Это будет своеобразная build-system-as-a-backend, к которой IDE-шки смогут подключаться по RESTful-подобному API. Этакий Language Server on steroids.

Еще у меня был экспериментальный проект аналитической дата-платформы. Там старая версия Мемории тогда использовалась в качестве облачного хранилища. Но система типов там на Java была и в качестве SQL-движка — Presto. Но как работали персистентные структуры данных в даспределенном режиме в облаке — всем понравилось. Закоммиченные данные иммутабельны, поэтому их очень легко кэшировать, поэтом waif-free доступ к данным для аналитики. Бонусом получались бранчики (data sandboxing).

Но там очень старая версия Мемории, которую я на коленках допилил до стабильного подмножества, чтобы их платформу «оживить». С тех пор много воды ушло. Если ты хочешь современных примеров, то можно подождать 2-3 месяца, пока я стабилизирую последнюю версию, и там всё буде. Плюс система сборки, о которой я сказал выше. И которую я планирую как showcase для Мемории как storage технологии.