Злоупотребление Git для реализации архитектуры Event Store? - PullRequest
0 голосов
/ 19 июня 2019

Git - это, по сути, реализация хранилища событий, в котором хранящиеся данные представляют собой файлы в структуре каталогов.Известно, что надежно решают проблемы:

  • Сохранение истории изменений
  • Передача минимальных данных клиенту для получения самых последних данных
  • Может откат к предыдущему состоянию

Можно создать хранилище событий, написав обертку над Git.

Предположим, мои бизнес-потребности заключаются в том, что мне нужно хранить данные клиентов, которые могут быть представлены в формате JSON.Данные могут быть изменены одной или несколькими службами в системе.Я мог бы иметь выделенную Git-репо Customer-Data с плоской структурой и файлами с именем {customer-id} .json.Когда служба изменяет данные, она включает полезное сообщение о коммите.

Это решение не масштабируется (если слишком много клиентов с слишком частыми изменениями, удаленная служба Git, например GitHub, будет засыпана запросами и дросселем), но при условии, что я знаю, что у меня будет ~1000 клиентов и изменения данных 1 на ~ 10 часов на клиента, есть ли другие проблемы с решением?

Ответы [ 2 ]

1 голос
/ 20 июня 2019

Использование Git в качестве базы данных, как правило, плохая идея. Он не особенно оптимизирован для этого варианта использования, поскольку он записывает больше данных, чем обычно требуется для транзакции базы данных, обычно хочет, чтобы все дерево было извлечено, и его трудно разделить, если вам потребуется масштабирование в будущем. Он также не может работать в режиме с несколькими хозяевами для репликации и масштабируемости.

Более того, если вы все равно это сделаете, ваша история будет расти патологически, что делает упаковку и переупаковку чрезвычайно дорогими с точки зрения ЦП и памяти из-за того, как Git делит объекты. В этот момент ваш хостинг-провайдер Git заметит и попросит вас перейти в другое место, после чего вам нужно будет переключиться на реальную базу данных.

0 голосов
/ 19 июня 2019

Git - это, по сути, реализация хранилища событий, где хранящиеся данные представляют собой файлы в структуре каталогов.

В некотором роде - репозиторий git предоставляет вам снимки рабочего дерева со связями happens-before, которые позволяют отслеживать происхождение.

Само по себе это не особохорош в семантике.См. Обсуждение task-based-ui , если вам нужно больше контекста, но фактически у вас есть аналог "написания хороших сообщений фиксации", чтобы описать изменения, которые вы вносите в представления снимка.

Это также децентрализовано, по замыслу - что потенциально неудобно, когда то, что вы хотите, является центральным авторитетом для капитала-T Истины.С децентрализованной властью вы обязательно больше полагаетесь на воспоминания, догадки и извинения .Это не обязательно плохо , обязательно, но это может быть неприятным сюрпризом, если вы еще не планировали для этого бюджет.

Когда есть четкая ответственность за отдельные документы в рабочем дереве,это может снять некоторое давление - при условии, что задержка между изменениями в разных частях дерева является приемлемой.

...