Skalierbares (halbe Millionen Dateien) Versionskontrollsystem

Wir verwenden SVN für unsere Quellcode-Versionskontrolle und experimentieren mit diesem Programm für Nicht-Quellcode-Dateien.Skalierbares (halbe Millionen Dateien) Versionskontrollsystem

Wir arbeiten mit einem großen Satz (300-500k) kurzer (1-4kB) Textdateien, die regelmäßig aktualisiert werden und eine Versionskontrolle benötigen. Wir haben versucht, SVN im Flat-File-Modus zu verwenden, und es hat Schwierigkeiten, den ersten Commit (500k Dateien eingecheckt) zu bewältigen, der ungefähr 36 Stunden dauert.

Auf einer täglichen Basis benötigen wir das System in der Lage, 10k modifizierte Dateien pro Commit-Transaktion in kurzer Zeit (< 5 min) zu behandeln.

Meine Fragen:

Ist SVN die richtige Lösung für meine Zwecke. Die Anfangsgeschwindigkeit scheint für den praktischen Gebrauch zu langsam zu sein.
Wenn ja, gibt es eine bestimmte SVN-Server-Implementierung, die schnell ist? (Wir sind derzeit mit dem GNU/Linux-Standard-SVN-Server und Kommandozeilen-Client.)
Falls nein, was sind die besten f/oss/kommerziellen Alternativen

Dank

bearbeiten 1: Ich brauche eine Versionskontrolle, weil mehrere Personen gleichzeitig die gleichen Dateien modifizieren und manuelle Diff/Merge/Resolve-Konflikte auf die gleiche Weise wie Programmierer Quellcode bearbeiten werden. Daher brauche ich ein zentrales Repository, in das die Leute ihre Arbeit einchecken und die Arbeit anderer überprüfen können. Der Arbeitsablauf ist praktisch identisch mit einem Programmier-Workflow, außer dass die Benutzer keine Programmierer sind und der Dateiinhalt kein Quellcode ist.

Update 1: Es stellt sich heraus, dass das primäre Problem eher ein Dateisystem Problem als ein SVN Problem. Für SVN wurde die Übertragung eines einzelnen Verzeichnisses mit einer halben Million neuen Dateien auch nach 24 Stunden nicht beendet. Die Aufteilung auf 500 Ordner in einem 1x5x10x10-Baum mit 1000 Dateien pro Ordner führte zu einer Commit-Zeit von 70 Minuten. Die Commit-Geschwindigkeit sinkt im Laufe der Zeit für einzelne Ordner mit einer großen Anzahl von Dateien erheblich. Git scheint viel schneller. Wird mit den Zeiten aktualisiert.

Quelle

2010-03-31 hashable

Wenn Sie tun, was ich denke, tun Sie, würde ich in eine Art CMS suchen. – erikkallen

Wie andere darauf hingewiesen haben: Es könnte sich lohnen zu erklären, was Sie im Allgemeinen zu lösen versuchen, da ein Versionskontrollsystem * möglicherweise die falsche (zumindest nicht die effizienteste) Lösung für Ihr Problem sein könnte. – paprika

Entweder was erikkallen oben gesagt hat, oder ein Dateisystem mit eingebauter Snapshot-Unterstützung. Weitere Details zu dem Problem wären gut, um festzustellen, ob die Versionskontrolle die richtige Lösung für das Problem ist. – Juliano

ist SVN geeignet? Solange Sie nicht das gesamte Repository auschecken oder aktualisieren, ist es ja so.

SVN ist sehr schlecht mit dem Commit sehr große Anzahl von Dateien (besonders unter Windows) wie all diese .svn Verzeichnisse geschrieben werden, um eine Sperre zu aktualisieren, wenn Sie auf dem System arbeiten. Wenn Sie eine kleine Anzahl von Verzeichnissen haben, werden Sie es nicht bemerken, aber die Zeit scheint exponentiell zu steigen.

Sobald jedoch (in Chunks, Verzeichnis nach Verzeichnis vielleicht) begangen, dann werden die Dinge sehr viel schneller. Updates dauern nicht so lange und Sie können die Sparse-Checkout-Funktion (sehr empfohlen) verwenden, um an Abschnitten des Repositorys zu arbeiten. Angenommen, Sie müssen nicht Tausende von Dateien ändern, Sie werden feststellen, dass es ziemlich gut funktioniert.

Das Commit von 10.000 Dateien - wieder alles auf einmal wird nicht schnell, aber 1.000 Dateien zehn Mal am Tag wird viel leichter zu verwalten sein.

Also versuchen Sie es, sobald Sie alle Dateien drin haben, und sehen, wie es funktioniert. All dies wird in 1.7 behoben, da der Mechanismus der Arbeitskopie geändert wird, um diese .svn-Verzeichnisse zu entfernen (so dass Sperren einfacher und viel schneller sind).

Quelle

2010-03-31 20:08:46 gbjbaanb

Es ist nicht wirklich die große Anzahl von Dateien, es ist die große Anzahl von Verzeichnissen, die die Leistung am meisten beeinflusst. –

@gbjbaanb @Sander Zu viele Dateien in einem einzigen Ordner scheint das Problem zu sein. Bitte schauen Sie sich Update 1 an. – hashable

Ich bezog mich auf die von @gbjbaanb verursachten Verlangsamungen, die durch .svn-Verzeichnisse verursacht wurden. Diese Verlangsamung wird durch viele Verzeichnisse verursacht, nicht durch viele Dateien. Auch das Sperren der Arbeitskopie vor der Operation und das anschließende Entsperren kostet bei vielen Verzeichnissen viel Zeit. –

Ab Juli 2008 hatte der Linux-Kernel git Repo etwa 260.000 Dateien. (2.6.26)

http://linuxator.wordpress.com/2008/07/22/5-things-you-didnt-know-about-linux-kernel-code-metrics/

Zu dieser Anzahl von Dateien, sagt der Kernel-Entwickler noch git ist wirklich schnell. Ich sehe nicht, warum es bei 500.000 Dateien langsamer wäre. Git verfolgt Inhalte, keine Dateien.

Quelle

2010-03-31 18:07:57 jonescb

Um dies zu bestätigen: Ich habe gerade eine Commit getestet, die im Wesentlichen alle Inhalte eines riesigen Repository (26000 Dateien, 5 GB) neu geschrieben hat. Es dauerte ungefähr 6 Minuten, meistens I/O-begrenzt über eine nicht so schnelle Netzwerkhalterung. In Ihrem Anwendungsfall sind die Diffs eher 50 MB, also sollten Sie viel schnellere Commit-Zeiten sehen. (Ihr ursprüngliches Commit kann noch eine Weile dauern - ungefähr fünf Minuten bis zu einer Stunde, abhängig von Ihrem System.) – Cascabel

Seien Sie sich bewusst. Git hat eine steile Lernkurve für Programmierer und kann für Nicht-Programmierer verwirrend sein. Ich benutze jetzt ständig git und konnte nicht ohne es arbeiten, aber ich brauchte ein paar Monate um mich zu beruhigen. Stellen Sie sicher, dass Sie bereit sind, einige Stunden in das Training Ihrer Nicht-Programmierer Kollegen zu versenken, wenn Sie sich zu Git verpflichten - kein Wortspiel beabsichtigt :) – AndyL

@Andy Danke für diesen wertvollen Kommentar über Git's Lernkurve. – hashable

Git ist Ihre beste Wette. Sie können ein ganzes Betriebssystem einchecken (zwei Gigabyte Code in ein paar Hunderttausend Dateien) und es bleibt nutzbar, obwohl das erste Einchecken eine ganze Weile dauert, etwa 40 Minuten.

Quelle

2010-03-31 18:09:04

nur 40 Minuten? Beeindruckend! –

Vorausgesetzt, das System hat eine schnelle Festplatte, ja. Ich nehme an, SSD wäre der Weg für die ultimative Geschwindigkeit von Revisionskontrollsystemen. –

Danke für diesen Tipp. Ja. Mit einer SSD als SVN-Server HDD würde die Dinge beschleunigen. – hashable

für svn "Flat-File-Modus" FSFS was bedeutet, nehme ich an:
- sicher, dass Sie die neueste SVN laufen. FSFS hatte Sharding hinzugefügt in ~ 1,5 IIRC, die eine Nacht/Tag-Unterschied bei 500k Dateien sein wird.Das bestimmte Dateisystem, das Sie ausführen, wird auch einen großen Effekt haben. (Denken Sie nicht einmal darüber auf NTFS.)
- Sie werden IO-gebunden mit so vielen Dateitransaktionen. SVN ist nicht sehr effektiv damit, Dateien in .svn/sowie die echten Dateien zu speichern.
git hat viel bessere Leistung als svn, und Sie schulden es sich selbst zumindest
vergleichen

Quelle

2010-03-31 18:13:26

@Nathan Ja. Ich glaube wir verwenden Version 1.6.x von SVN. – hashable

und mit der Anzahl der Dateien, Svn 1.7 wird viel bessere Unterstützung durch Verschrotten der .svn Verzeichnisse, die eine erhebliche Auswirkung auf eine sehr große Anzahl von Dateien haben. Das ist natürlich noch nicht geschehen. – gbjbaanb

sharding wird Ihnen helfen, wenn Sie eine große Anzahl von Revisionen haben, verbessert es nichts für die Anzahl der Dateien. Es sind die Revisionen, die im Repository erstellt werden. –

Benötigen Sie wirklich ein Dateisystem mit billigen Schnappschüsse, wie ZFS? Sie können es so konfigurieren, dass der Status des Dateisystems alle 5 Minuten gespeichert wird, um eine gewisse Änderungshistorie zu verwenden.

Quelle

2010-03-31 18:21:32 joeforker

Ihre Antwort klingt wie eine Frage (Tippfehler?). Wie auch immer, guter Zeiger! – paprika

Es heißt sokratische Methode ;-) – joeforker

für solche kurzen Dateien würde ich über die Verwendung einer Datenbank anstelle eines Dateisystems überprüfen.

Quelle

2010-03-31 18:39:54 Javier

Gibt es einen Grund, warum Sie 10k modifizierte Dateien pro Commit festschreiben müssen? Subversion würde viel besser skalieren, wenn jeder Benutzer sofort seine eigene Datei eincheckt. Dann müssen Sie die Dateien einmal täglich veröffentlichen, Sie können sie sehr schnell taggen und die veröffentlichte Version aus dem Tag

Quelle

2010-04-01 18:09:34

@Sander 10k ist die obere Grenze. Ein Benutzer kann aufgrund von Abhängigkeiten zwischen Dateien nicht nur eine Datei gleichzeitig einchecken. – hashable

Meinen Sie, dass sie, wenn sie ihre Arbeit manuell erledigen, bis zu 10k Dateien produzieren, die nur einmal ausgeführt werden müssen? Das klingt ziemlich unmöglich, wenn die Dateien nicht generiert werden. In diesem Fall ist es im Allgemeinen besser, die Quelldateien in der Quellcodeverwaltung zu speichern. –

Die manuelle Arbeit wird nicht auf Dateiebene durchgeführt. Kleine Änderungen (an den Informationen, die in allen Dateien gemeinsam dargestellt werden) können dazu führen, dass mehrere Dateien geändert werden. Ja. Für die obere Grenze von 10000 Dateiänderungen sind die Änderungen wahrscheinlich auf programmatische Dateiänderungen zurückzuführen. (Es gibt sowohl menschliche als auch automatische Bearbeitung der Dateien.) – hashable

Ich empfehle Mercurial, da es immer noch Git in der Usability-Abteilung führt (git hat bekommen besser, aber, eh).

bzr hat Sprünge in der Benutzerfreundlichkeit auch gemacht.

Quelle

2010-04-01 22:18:54

Skalierbares (halbe Millionen Dateien) Versionskontrollsystem

Antwort

Verwandte Themen