Używanie repozytorium git jako zaplecza bazy danych

Rzeczywiście ciekawe podejście. Powiedziałbym, że jeśli chcesz przechowywać dane, użyj bazy danych, a nie repozytorium kodu źródłowego, które jest przeznaczone do bardzo konkretnego zadania. Jeśli możesz użyć Git od zaraz, to jest w porządku, ale prawdopodobnie musisz zbudować na nim warstwę repozytorium dokumentów. Więc możesz zbudować ją na bazie tradycyjnej bazy danych, prawda? A jeśli interesuje Cię wbudowana Kontrola wersji, dlaczego nie użyć jednego z narzędzi open source repozytorium dokumentów ? Jest w czym wybierać.

Cóż, jeśli i tak zdecydujesz się na Git backend, to w zasadzie będzie on działał dla Twoich wymagań, jeśli zaimplementujesz go zgodnie z opisem. Ale:

1) wspomniałeś o "klastrze serwerów, które się pchają/ciągną" - myślałem o tym od jakiegoś czasu i nadal nie jestem pewien. Nie można naciskać/ciągnąć kilku repo jako operacji atomowej. Zastanawiam się, czy może być możliwość jakiegoś bałaganu scalania podczas jednoczesnej pracy.

2) może nie potrzebujesz to, ale oczywistą funkcjonalnością repozytorium dokumentów, którego nie wymieniłeś, jest kontrola dostępu. Możesz ograniczyć dostęp do niektórych ścieżek (=kategorii) za pomocą modułów podrzędnych, ale prawdopodobnie nie będziesz mógł łatwo przyznać dostępu na poziomie dokumentu.

Moje 2 pensy. Trochę tęskni, ale ...... Miałem podobny wymóg w jednym z moich projektów inkubacyjnych. Podobnie jak twoje, moje kluczowe wymagania, gdzie baza danych dokumentów (w moim przypadku xml), z wersjonowaniem dokumentów. Był to system dla wielu użytkowników z wieloma przypadkami współpracy. Preferowałem wykorzystanie dostępnych rozwiązań opensource, które obsługują większość kluczowych wymagań.

Aby przejść do sedna, nie mogłem znaleźć żadnego produktu, który pod warunkiem oba, w sposób wystarczająco skalowalny (liczba użytkowników, woluminy użycia, pamięć masowa i zasoby obliczeniowe).Byłem stronniczy w stosunku do Gita za wszystkie obiecujące możliwości i (prawdopodobne) rozwiązania, które można było z niego stworzyć. Gdy bawiłem się z opcją git, przejście z perspektywy pojedynczego użytkownika do perspektywy wielu (mili) użytkowników stało się oczywistym wyzwaniem. Niestety, nie udało mi się przeprowadzić istotnej analizy wydajności, tak jak ty. ( .. lazy / quit early ....dla wersji 2, mantra) moc dla Ciebie!. W każdym razie, mój tendencyjny pomysł przekształcił się w kolejną (wciąż tendencyjną ) alternatywę: siatkę narzędzi, które są najlepsze w swoich oddzielnych obszarach, bazach danych i kontroli wersji.

Póki jeszcze trwają prace ( ...i nieco zaniedbany) wersja morfowana jest po prostu taka .

• na frontendzie: (userfacing ) użyj bazy danych na 1. poziomie storage (interfacing z aplikacjami użytkownika)
• na zapleczu, użyj a system kontroli wersji (VCS) (jak git ) do wykonania wersjonowanie obiektów danych w bazie danych

W zasadzie byłoby to dodanie wtyczki kontroli wersji do bazy danych, z pewnym klejem integracyjnym, które być może trzeba będzie opracować, ale może być o wiele łatwiejsze.

Jak to (powinno ) działać jest to, że podstawowa wymiana danych interfejsu wielu użytkowników odbywa się za pośrednictwem bazy danych. DBMS zajmie się wszystkimi zabawnymi i złożonymi problemami, takimi jak multi-user, concurrency e, atomic operations itp. W backendzie VCS wykonywałyby kontrolę wersji na pojedynczym zestawie obiektów danych (bez współbieżności lub problemów z wieloma użytkownikami). Dla każdej efektywnej transakcji w bazie danych Kontrola wersji jest wykonywana tylko na rekordach danych, które zostałyby skutecznie zmienione.

Jeśli chodzi o klej interfejsowy, będzie on w formie prostej funkcji współdziałającej między bazą danych a VCS. Pod względem wzornictwa, jak proste podejście byłoby interfejsem sterowanym zdarzeniami, z aktualizacjami danych z bazy danych wyzwalającymi procedury kontroli wersji (podpowiedź: zakładając Mysql, użycie wyzwalaczy i sys_exec () bla bla...) .Pod względem złożoności implementacji będzie to zakres od prostego i skutecznego (np. skryptowanie) do skomplikowanego i wspaniałego (jakiś zaprogramowany interfejs złącza) . Wszystko zależy od tego, jak szalony chcesz iść z nim, i ile kapitału potu jesteś gotów wydać. Myślę, że proste skrypty powinny zadziałać. Aby uzyskać dostęp do wyniku końcowego, różnych wersji danych, prostą alternatywą jest wypełnienie klonu bazy danych (bardziej klon struktury bazy danych) danymi wskazywanymi przez tag/id/hash wersji w VCS. ponownie ten bit będzie prostym zapytaniem/tłumaczeniem / mapowaniem interfejsu.

Jest jeszcze kilka wyzwań i niewiadomych do rozwiązania, ale przypuszczam, że wpływ i znaczenie większość z nich w dużej mierze zależy od wymagań aplikacji i przypadków użycia. Niektóre mogą po prostu skończyć się nie problemy. Niektóre z problemów obejmują dopasowanie wydajności między kluczowymi modułami 2, bazą danych i VCS, dla aplikacji z aktywnością aktualizacji danych o wysokiej częstotliwości, skalowanie zasobów (pamięci masowej i mocy obliczeniowej ) w czasie po stronie git, a użytkownicy rosną: stały, wykładniczy lub ostatecznie plateau ' s

Z koktajlu powyżej, oto, co obecnie warzę

• używanie Git dla VCS (początkowo uważane za stare dobre CVS ze względu na użycie tylko zestawów zmian lub delt pomiędzy 2 wersjami)
W związku z tym, że moje dane są przetwarzane w celu uzyskania dostępu do danych osobowych, nie są one przetwarzane w celach marketingowych.]}
• pogrywanie z MongoDB (aby wypróbować bazę danych NoSQl, która jest ściśle zgodna z natywną strukturą bazy danych używaną w git )

Kilka ciekawostek - git rzeczywiście robi Wyczyść rzeczy, aby zoptymalizować przechowywanie, takie jak kompresja i przechowywanie tylko delt między rewizją obiektów - Tak, git przechowuje tylko changesets lub delty pomiędzy wersjami obiektów danych, gdzie to ma zastosowanie (wie kiedy i jak). Indeks: packfiles, deep in the guts of Git internals - Przegląd object storage Gita( content-addressable filesystem), pokazuje podobieństwa (z perspektywy koncepcji) z bazami noSQL takimi jak mongoDB. Ponownie, kosztem kapitału potu, może dostarczyć ciekawszych możliwości integracji 2 i ulepszania wydajności

Jeśli doszedłeś tak daleko, pozwól mi, czy powyższe może mieć zastosowanie do twojego przypadku, i zakładając, że tak będzie, jak będzie to dopasowane do niektórych aspektów w Twojej ostatniej kompleksowej analizie wydajności

Jak wspomniałeś, sprawa dla wielu użytkowników jest nieco trudniejsza w obsłudze. Jednym z możliwych rozwiązań byłoby użycie specyficznych dla użytkownika plików z indeksami Git w wyniku

• nie ma potrzeby tworzenia oddzielnych kopii roboczych (użycie dysku ogranicza się do zmienionych plików)
• nie ma potrzeby czasochłonnych prac przygotowawczych (na sesję użytkownika)

• git hash-obiekt
• git update-index
• git write-tree
• git commit-tree

Następuje zarys rozwiązania (rzeczywiste skróty SHA1 pominięte w poleceniach):

# Initialize the index
# N.B. Use the commit hash since refs might changed during the session.
$ GIT_INDEX_FILE=user_index_file git reset --hard <starting_commit_hash>

#
# Change data and save it to `changed_file`
#

# Save changed data to the Git object database. Returns a SHA1 hash to the blob.
$ cat changed_file | git hash-object -t blob -w --stdin
da39a3ee5e6b4b0d3255bfef95601890afd80709

# Add the changed file (using the object hash) to the user-specific index
# N.B. When adding new files, --add is required
$ GIT_INDEX_FILE=user_index_file git update-index --cacheinfo 100644 <changed_data_hash> path/to/the/changed_file

# Write the index to the object db. Returns a SHA1 hash to the tree object
$ GIT_INDEX_FILE=user_index_file git write-tree
8ea32f8432d9d4fa9f9b2b602ec7ee6c90aa2d53

# Create a commit from the tree. Returns a SHA1 hash to the commit object
# N.B. Parent commit should the same commit as in the first phase.
$ echo "User X updated their data" | git commit-tree <new_tree_hash> -p <starting_commit_hash>
3f8c225835e64314f5da40e6a568ff894886b952

# Create a ref to the new commit
git update-ref refs/heads/users/user_x_change_y <new_commit_hash>

W zależności od Twoich danych możesz użyć zadania cron, aby połączyć nowe refy z master, ale rozwiązanie konfliktu jest prawdopodobnie najtrudniejszą częścią tutaj.

Zaimplementowałem bibliotekę Ruby na górze libgit2, co sprawia, że jest to dość łatwe do zaimplementowania i zbadania. Istnieją pewne oczywiste ograniczenia, ale jest to również dość wyzwalający system, ponieważ otrzymujesz pełny łańcuch narzędzi git.

Dokumentacja zawiera kilka pomysłów dotyczących wydajności, kompromisów itp.