мои 2 пенса стоят. Немного тоскует, но ... У меня было подобное требование в одном из моих инкубационных проектов. Как и ваши, мои ключевые требования, когда база данных документов (xml в моем случае) с управлением версиями документов. Это было для многопользовательской системы с множеством вариантов использования для совместной работы. Я предпочел использовать доступные решения с открытым исходным кодом, которые поддерживают большинство ключевых требований.
Вкратце: я не смог найти ни одного продукта, который обеспечивал бы и то, и другое, достаточно масштабируемым (количество пользователей, объемы использования, хранилище и вычислительные ресурсы). Я был склонен к git из-за всех многообещающих возможностей, и (вероятные) решения, которые можно было бы найти из этого. По мере того, как я больше играл с опцией git, переход от перспективы одного пользователя к перспективе нескольких (милли) пользователей стал очевидной проблемой. К сожалению, мне не удалось провести серьезный анализ производительности, как это сделали вы. (.. ленив / рано бросить .... для версии 2, мантра) Power to you !. Как бы то ни было, моя предвзятая идея с тех пор трансформировалась в следующую (все еще предвзятую) альтернативу: набор инструментов, которые являются лучшими в своих отдельных сферах, базах данных и контроле версий.
Пока работа еще продолжается (... и немного игнорируется), преобразованная версия просто такая.
- на интерфейсе: (пользовательский) использовать базу данных для хранения 1-го уровня (взаимодействовать с пользовательскими приложениями)
- на бэкэнде используйте систему контроля версий (VCS) (например, git) для управления версиями объектов данных в базе данных
По сути, это будет означать добавление в базу данных подключаемого модуля управления версиями с неким интеграционным клеем, который вам, возможно, придется разработать, но это может быть намного проще.
Как это будет (должно) работать, так это то, что основной обмен данными многопользовательского интерфейса осуществляется через базу данных. СУБД будет обрабатывать все забавные и сложные проблемы, такие как многопользовательский, параллелизм, атомарные операции и т. Д. На бэкэнде VCS будет выполнять контроль версий для одного набора объектов данных (без параллелизма или многопользовательских проблем). Для каждой действующей транзакции в базе данных контроль версий осуществляется только для тех записей данных, которые должны были эффективно измениться.
Что касается связующего клея, то он будет в форме простой функции взаимодействия между базой данных и VCS. С точки зрения дизайна, в качестве простого подхода будет интерфейс, управляемый событиями, с обновлением данных из базы данных, запускающим процедуры контроля версий (подсказка: предполагая , что Mysql, использование триггеров и sys_exec () бла-бла ...). С точки зрения сложности реализации, он будет варьироваться от простого и эффективного (например, создание сценариев) до сложного и замечательного (некоторый программный интерфейс коннектора). Все зависит от того, насколько сумасшедшим вы хотите пойти с этим, и сколько пота капитала вы готовы потратить. Я считаю, что волшебство должно творить простые сценарии. А для доступа к конечному результату, различным версиям данных, простой альтернативой является заполнение клона базы данных (скорее, клона структуры базы данных) данными, на которые ссылается тег версии / id / hash в VCS. опять же, этот бит будет простым запросом / переводом / отображением интерфейса.
Есть еще несколько проблем и неизвестных моментов, которые необходимо решить, но я полагаю, что влияние и актуальность большинства из них будут во многом зависеть от требований вашего приложения и вариантов использования. Некоторые могут просто перестать быть проблемами. Некоторые из проблем включают соответствие производительности между двумя ключевыми модулями, базой данных и VCS, для приложения с высокой частотой обновления данных, масштабированием ресурсов (хранилище и вычислительная мощность) с течением времени на стороне git в качестве данных и пользователей. рост: устойчивый, экспоненциальный или в конечном итоге плато
Из приведенного выше коктейля вот то, что я сейчас варию
- использование Git для VCS (изначально считалось старым добрым CVS из-за использования только наборов изменений или дельт между двумя версиями)
- с использованием mysql (из-за сильно структурированного характера моих данных xml со строгими схемами xml)
- возиться с MongoDB (чтобы попробовать базу данных NoSQl, которая близко соответствует структуре собственной базы данных, используемой в git)
Некоторые забавные факты - git на самом деле очищает вещи для оптимизации хранения, такие как сжатие и хранение только дельт между ревизиями объектов - ДА, git хранит только наборы изменений или дельты между ревизиями объектов данных, где это применимо (он знает когда и как) . Ссылка: packfiles, глубоко внутри Git
- Обзор хранилища объектов git (файловая система с адресацией по содержимому), показывает поразительное сходство (с точки зрения концепции) с базами данных noSQL, такими как mongoDB. Опять же, за счет пота капитала, он может предоставить более интересные возможности для интеграции 2 и настройки производительности.
Если вы зашли так далеко, позвольте мне, если вышеизложенное может быть применимо к вашему случаю, и предполагая, что это так, как это будет соответствовать некоторым аспектам вашего последнего всеобъемлющего анализа производительности.