![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
LSM tree и иммутабельные данные
Feb. 15th, 2015 01:04 amНастолько я понимаю, LSM-tree является вариантом реализации MVCC, в которой обновления/удаления данных создают новые версии, разбитые на несколько слоев в памяти и на диске и по достижении некоего порога количества версий (или "слоев" в хранилище) включается сборщик мусора-компактификатор, который старые версии вычищает, уменьшая количество слоев и размер БД.
А существует ли схожий алгоритм для случая, когда старые версии должны быть доступны для приложения? Например, если мы хотим хранить всю предысторию изменений состояния системы, для аудита и/или репликации, мемоизации каких-нибудь хранимых аггрегатов с пересчетом по мере необходимости и прочего такого.
Причем, если по-хорошему, это дело должно еще поддерживать partitioning, инкрементальные бэкапы, и прочее такое БД-админство, чтобы когда это дело будет хранить историю жизни за 10-15 лет, обслуживание его не выродилось в кошмар.
Вообще, откуда возникла такая идея: если реализовывать "историю"(== аудит, репликацию, пересчеты мемоизированных агрегатов) триггерами в SQL базе (если СУБД сама не умеет логи изменений), если по сути бизнес-логики нужна история изменений/версионность данных (редактирование проводок, исторические атрибуты контрагентов, изменение структуры предприятия) и не дай бог, туда надо маппить какие-нибудь графы, это дело вырождается в какую-то откровенную чернь, которая на SQL выглядит очень грустно.
В принципе, используя описанное в этой книжке: http://www.assertedversioning.com/ http://www.amazon.com/Managing-Time-Relational-Databases-Temporal/dp/0123750415 и http://www.postgresql.org/docs/9.2/static/rangetypes.html можно было бы сделать более-менее эффективное решение, но SQL не очень хорошо умеет в реюз кода (т.е. вынести весь код управления версионностью в один модуль для всех таблиц, скорее всего, не выйдет). И вопросы с репликацией, а особенно историей редактирования каких-нибудь графов остаются - неудобно оно все.
А существует ли схожий алгоритм для случая, когда старые версии должны быть доступны для приложения? Например, если мы хотим хранить всю предысторию изменений состояния системы, для аудита и/или репликации, мемоизации каких-нибудь хранимых аггрегатов с пересчетом по мере необходимости и прочего такого.
Причем, если по-хорошему, это дело должно еще поддерживать partitioning, инкрементальные бэкапы, и прочее такое БД-админство, чтобы когда это дело будет хранить историю жизни за 10-15 лет, обслуживание его не выродилось в кошмар.
Вообще, откуда возникла такая идея: если реализовывать "историю"(== аудит, репликацию, пересчеты мемоизированных агрегатов) триггерами в SQL базе (если СУБД сама не умеет логи изменений), если по сути бизнес-логики нужна история изменений/версионность данных (редактирование проводок, исторические атрибуты контрагентов, изменение структуры предприятия) и не дай бог, туда надо маппить какие-нибудь графы, это дело вырождается в какую-то откровенную чернь, которая на SQL выглядит очень грустно.
В принципе, используя описанное в этой книжке: http://www.assertedversioning.com/ http://www.amazon.com/Managing-Time-Relational-Databases-Temporal/dp/0123750415 и http://www.postgresql.org/docs/9.2/static/rangetypes.html можно было бы сделать более-менее эффективное решение, но SQL не очень хорошо умеет в реюз кода (т.е. вынести весь код управления версионностью в один модуль для всех таблиц, скорее всего, не выйдет). И вопросы с репликацией, а особенно историей редактирования каких-нибудь графов остаются - неудобно оно все.
