ltcp/bericht/ori/ori-ver.tex

65 lines
3.9 KiB
TeX

\subsection{Vergleiche}
Da Ori Merkmale von Speicherdiensten, Versionskontrollsystemen und verteilten Dateisystemen in sich vereint, wurden aus diesen die Vertreter Dropbox, Git und GlusterFS zu einem Vergleich herangezogen.
\subsubsection{Cloud-Speicherdienst Dropbox}
Dropbox speichert seine Daten in der Cloud auf einem oder mehreren Servern, Ori hingegen seine Repositorien dezentral auf den einzelnen Nodes. Dies erhöht die Sicherheit der Daten, da nur Nutzer mit ssh-Zugang einfachen Zugriff auf diese erhalten. Desweiteren sind die Daten besser vor Verlust geschützt, da mit einer einzigen Kopie eines Repos die Daten auf allen Nodes wiederhergestellt werden können. Das Grafting würde in etwa dem Freigeben bei Dropbox entsprechen, jedoch bräuchte man dort keinen direkten Zugang zu einem Node und die Synchronisation des freigegeben Verzeichnis erfolgt automatisch. Bei Dropbox ist es außerdem möglich Verzeichnisse und Dateien für alle öffentlich im Internet zugänglich zu machen. Mit einem funktionierenden \emph{orisync} könnte auch bei Ori die Synchronisation der Daten zwischen den Nodes realisiert werden.
\subsubsection{Versionskontrollsystem Git}
Die Versionsverwaltung von Ori ähnelt sehr der von Git. So entsprechen sich die Befehle \emph{ori snapshot} und \emph{git commit}. \emph{ori pull} und \emph{ori checkout [commitid]} bilden zusammen die Funktion von \emph{git pull} ab. Darüber hinaus ist der Funktionsumfang von Git größer als der von Ori. Um Ori und Git zu vergleichen, haben die Entwickler den FUSE-Treiber deaktiviert und Ori als einfaches Checkin/Checkout-Programm vermessen. Laut ihren Angaben waren die adds und commits, sowie Klon-Operationen von Ori um 64 bzw. 70\% schneller als die von Git. Bei den Repositorien-Größen wurden von den Entwicklern folgende Werte gemessen:
\begin{center}
\begin{tabular}{|l|r|r|r|}
\hline
Data Set & Raw Size & Ori & Git \\ \hline
Linux Snapshot & 537.6MB & 450.0MB & 253.0MB \\ \hline
Zlib & 3.044MB & 2.480MB & 2.284MB \\ \hline
Wget & 13.82MB & 12.46MB & 6.992MB \\ \hline
User Documents & 4.5GB & 4.6GB & 3.4GB \\ \hline
Tarfiles & 2.8GB & 2.3GB & 2.3GB \\ \hline
\end{tabular}
\end{center}
Es ist ersichtlich, dass Git gegenüber Ori bei der Speichernutzung im Vorteil ist. Die Unterschiede in Geschwindigkeit und Speichernutzung liegen an den unterschiedlichen Kompressionsarten. Während Git eine Kombination aus Ganz-File-Dedublizierung, differentieller Kompression und einfacher Kompression verwendet, nutzt Ori nur Unter-File-Dedublizierung und einfache Kompression. Aufgrund der fehlenden differentiellen Kompression ist Ori im Gegensatz zu Git in der Lage, Snapshots zu löschen, da keine extra Dekompressions- und Kompressionsschritte benötigt werden.
\pagebreak
\subsubsection{Verteiltes Dateisystem GlusterFS}
Um Ori mit mit dem Dateisystem GlusterFS zu vergleichen, wurde auch Ori mit dem IOzone-Benchmark vermessen und die dabei aufgezeichneten Werte mit denen aus der Benchmark-Aufgabe verglichen. \\
Testaufruf GlusterFS:
\shellcmd{./iozone -azcR -+q 1 -U /fastfs -f /fastfs/testfile -b excel-fastfs.xls}
Testaufruf OriFS:
\shellcmd{./iozone -azcR -I -f /ori-home/rep/testfile -b excel.xls} \\
Beim Vermessen von \emph{orifs} wurde die Option \emph{-U /ori-home/rep} weggelassen, weil \emph{orifs} vom System nicht automatisch un- und gemounted werden kann. Dadurch können während des Testens Caching-Effekte aufgetreten sein und die gemessenen Werte nach oben hin abweichen. \\
Lesend: \\
\hfill \includegraphics[scale=1.1]{benchmarks/ori/iozone-fastfs-read-tmpl.pdf} \hspace*{\fill}
\vspace{1cm}
\hfill \includegraphics[scale=1.1]{benchmarks/ori/iozone-orifs-read-tmpl.pdf} \hspace*{\fill}
Schreibend: \\
\hfill \includegraphics[scale=1.1]{benchmarks/ori/iozone-fastfs-write-tmpl.pdf} \hspace*{\fill}
\vspace{1cm}
\hfill \includegraphics[scale=1.1]{benchmarks/ori/iozone-orifs-write-tmpl.pdf} \hspace*{\fill}
Auswertung: \\
\pagebreak