История изменений

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

Не, это просто один частный эпизод. Если говорить про параллельную мультипроцессорную обработку, то я предлагаю использовать функциональные структуры данных (ФСД). Только не те, что идут вместе со Scala, а более развитые в плане моделирования моделирования прикладных данных (таблицы в разных ипостасях, всякие индексы, включая постранственные, распределения вероятностей и т.п.).

ФСД интересны тем, что позволяют практически забесплатно получить эквивалент wait-free snapshot isolation аж над EC (это еще не транзакции). Плюс кучу дополнительных фишек типа графа версий. В общем, и функций много, и настройки по консистентности получаются довольно гибкие. ФСД, разумеется, имеют фундаментальный оверхед, выражающийся в том, что O(1) превращается в O(log(N)). Но там можно этот оверхед амортизировать оптимизациями. Параллельность имеет свою цену вопроса.

Серьезное ограничение ФСД, о которых обычно не говорят, — это необходимость сборщика мусора. В случае RAM это может быть обычный детерминированный GC через подсчет атомарных ссылок. А вот в распределенном случае всё становится сильно сложнее. Нужны атомарные идемпотентные счетчики, и строгая консистентность для них. Можно, конечно, делать обычный сканирующий GC, но это тоже некое ограничение по масштабированию. Другие (не-ФСД) дизайны тоже требуют GC так или иначе.

SWMR-CoW — это просто режим работы ФСД, при котором можно атомарно сбрасывать состояние RAM во внешнюю память (с минимумом прослоек). При этом там тоже возможны оптимизации. Например, писатель может сам быть внутри параллельным (и, например, молотить данные в 64 руки), но вот коммититься это будет всё одновременно, а не индивидуально. Отсюда и Single Writer.

Если же нет задачи сбрасывать коммиты на диск (inmem), или можно работать над тем же RocksDB или облачным K/V, то возможен и полноценный MWMR с множеством параллельных пистателей, коммитящих независимо. Но и стек данных будет уже куда более тяжеловесным. Меня просто сейчас интересует scale-down: запихнуть SWMRStore прямо в SSD, чтобы работать сразу с флешем, минуя FTL. Он для этого идеально подходит.

----

Чтобы пресечь потенциальное недопонимание. ФСД сами по себе не масштабируемы в том смысле, в котором это обычно понимается. Каждая запись в ФСД создает новую версию всего датасета (снепшот), которую могут увидеть читатели как только они получат ID корневого блока ФСД для этого коммита. Эта часть — 2PSet CRDT и масштабируема до сколько сможешь.

А вот если надо сливать версии (merge) в единую историю, то это уже будет масштабируемо на столько, на сколько «строгими» будут правила слияния версий.

Удаление версий из ФСД требует сборки мусора и мастабируемо на столько, на сколько масштабируем сборщик.

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

Не, это просто один частный эпизод. Если говорить про параллельную мультипроцессорную обработку, то я предлагаю использовать функциональные структуры данных (ФСД). Только не те, что идут вместе со Scala, а более развитые в плане моделирования моделирования прикладных данных (таблицы в разных ипостасях, всякие индексы, включая постранственные, распределения вероятностей и т.п.).

ФСД интересны тем, что позволяют практически забесплатно получить эквивалент wait-free snapshot isolation аж над EC (это еще не транзакции). Плюс кучу дополнительных фишек типа графа версий. В общем, и функций много, и настройки по консистентности получаются довольно гибкие. ФСД, разумеется, имеют фундаментальный оверхед, выражающийся в том, что O(1) превращается в O(log(N)). Но там можно этот оверхед амортизировать оптимизациями. Параллельность имеет свою цену вопроса.

Серьезное ограничение ФСД, о которых обычно не говорят, — это необходимость сборщика мусора. В случае RAM это может быть обычный детерминированный GC через подсчет атомарных ссылок. А вот в распределенном случае всё становится сильно сложнее. Нужны атомарные идемпотентные счетчики, и строгая консистентность для них. Можно, конечно, делать обычный сканирующий GC, но это тоже некое ограничение по масштабированию. Другие (не-ФСД) дизайны тоже требуют GC так или иначе.

SWMR-CoW — это просто режим работы ФСД, при котором можно атомарно сбрасывать состояние RAM во внешнюю память (с минимумом прослоек). При этом там тоже возможны оптимизации. Например, писатель может сам быть внутри параллельным (и, например, молотить данные в 64 руки), но вот коммититься это будет всё одновременно, а не индивидуально. Отсюда и Single Writer.

Если же нет задачи сбрасывать коммиты на диск (inmem), или можно работать над тем же RocksDB или облачным K/V, то возможен и полноценный MWMR с множеством параллельных пистателей, коммитящих независимо. Но и стек данных будет уже куда более тяжеловесным. Меня просто сейчас интересует scale-down: запихнуть SWMRStore прямо в SSD, чтобы работать сразу с флешем, минуя FTL. Он для этого идеально подходит.

----

Чтобы пресечь потенциальное недопонимание. ФСД сами по себе не масштабируемы в том смысле, в котором это обычно понимается. Каждая запись в ФСД создает новую версию всего датасета (снепшот), которую могут увидеть читатели как только они получат ID корневого блока ФСД для этого коммита. Эта часть — 2PSet CRDT и масштабируема до сколько сможешь.

А вот если надо сливать версии (merge) в единую историю, то это уже будет масштабируемо на столько, на сколько «строгими» будут правила слияния версий.