![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
LSM tree и иммутабельные данные
Настолько я понимаю, 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 не очень хорошо умеет в реюз кода (т.е. вынести весь код управления версионностью в один модуль для всех таблиц, скорее всего, не выйдет). И вопросы с репликацией, а особенно историей редактирования каких-нибудь графов остаются - неудобно оно все.
no subject
no subject
no subject
no subject
no subject
по-моему, это datomic называется
no subject
Вдруг стало любопытно - не пробовали ли какие-нибудь особо безумные фрики в последнее время написать нормальный современный язык, заточенный на реляционные БД напрямую (не orm-говнища), но без безумных sql-идей о "почти естественном языке чтоб менеджеры писали запросы" и с учетом достижений прогресса.
Datalog-ом вдохновляясь или типа того.
no subject
no subject
А существует ли схожий алгоритм для случая, когда старые версии должны быть доступны для приложения?
Бекапы - это уровень администратора. Если приложение должно бегать по старым записям, то тут они ни при чём, и надо хранить историю в старых таблицах. Насколько понимаю, наиболее популярны - это пометки от и до какого времени данная запись была действительной. Хотя, я с базами работаю редко.
no subject
Чтобы посмотреть, как устраивают (относительно компактное) хранение данных с историей, можно обратиться к VCS . Я знаю о двух вариантах - либо хранятся все деревья файлов, с по-возможностью расшаренными узлами, либо хранится небольшое число снапшотов, а состояния между снапшотами восстанавливаются по диффам. Одно из приложений второго подхода к программированию известно как difference list.
no subject
no subject
Готовых решений для вашей задачи я не встречал, из похожего вспомнился только Facebook Haystack https://www.facebook.com/note.php?note_id=76191543919
no subject