Исправление aist1, (текущая версия) :
Например, если несколько версий записи закэшировать в развернутом виде. то при небольшом их количестве БД уже будет бегать весьма бодро.
Это да. Оптимизации по месту проблемы не представляют, если это CoW-tree.
Но я про другое. В той статье, что ты привел, там говорится о MVCC, а там есть своя, весьма важная, особенность — количество версий ограничено сверху количеством параллельных транзакций. И версии — короткоживущие. За исключением какого-нибудь искусственного граничного случая, количество версий одной и той же строки будет небольшим, и много метаданных можно тупо держать в памяти. Ну, например, 1000 — это уже очень много. И версии быстро выметаются сборщиком мусора.
Вот если тебе нужно много долгоживущих версий, то тут начнутся проблемы. А если ты хочешь несколько веток времени (бранчи для data sandboxing), то ты этого без CoW-btree как базовой структуры данных не получишь.
Во времена, когда базы данных сидели на HDD, CoW-btree-подобные схемы хранилища для БД не применялись, так как они быстро приводят к сильной фрагментации линейных структур, убивая scan. На SSD оно совсем по другому, и тут я не знаю, что сейчас делают или задумывают.
Исходная версия aist1, :
Например, если несколько версий записи закэшировать в развернутом виде. то при небольшом их количестве БД уже будет бегать весьма бодро.
Это да. Оптимизации по месту проблемы не представляют, если это CoW-tree.
Но я про другое. В той статье, что ты привел, там говорится о MVCC, а там есть своя, весьма важная, особенность — количество версий ограничено сверху количеством параллельных транзакций. И версии — короткоживущие. За исключением какого-нибудь искусственного граничного случая, количество версий одной и той же строки будет небольшим, и много метаданных можно тупо держать в памяти. Ну, например, 1000 — это уже очень много. И версии быстро выметаются сборщиком мусора.
Вот если тебе нужно много долгоживущих версий, то тут начнутся проблемы. А если ты хочешь несколько веток времени (бранчи для data sandboxing), то ты этого в без CoW-btree как базовой структуры данных не получишь.
Во времена, когда базы данных сидели на HDD, CoW-btree-подобные схемы для БД не применялись, так как они быстро приводят к сильной фрагментации линейных структур, убивая scan. На SSD оно совсем по другому, и тут я не знаю, что сейчас делают или задумывают.