GraphDB - hilft eine in diesem Fall?
-
Applikation: Analysiert .NET-Assemblies und findet Abhängigkeiten zwischen diesen (bspw. Methodenaufrufe). Abhängigketien werden in einer Datenbank gespeichert:
Dependency: Type, PartRef, PartDep
DependencyPart: AssemblyID, Type, Member, SourceFile, SourceLine
(grobe Darstellung)Von einer Klasse/Methode im Code können wir nun alle direkten und auch indirekten Abhängigkeiten herausfinden und sofort sehen ob und auf welche Teile sich eine Änderung an dieser Stelle auf abhängige Projekte auswirken würde.
===
Trotz gutem Einsatz von Indices (Import-Performance ging dabei in den Keller, aber läuft ohnehin über Nacht) haben wir immer noch Performance-Probleme. Da viele viele Versionen der selben Assembly eingefügt werden kommen wir schnell zu großen Datenmengen (derzeit in der Testversion 1,5 Millionen Dependency-Einträge und X,Y Millionen DependencyPart-Einträge.
Das Query welches direkte Abhängigkeiten findet dauert gar nicht so lange, uns schmerzt dann das rekursive Suchen nach indirekten Abhängigkeiten. Materialisieren wollen wir die indirekten Abhängigkeiten in der DB aber nicht da sonst der Import exponentiell in der Zeit anwächst und so bald nicht mher über Nacht durchlaufen könnte.
Zielzeit ist < 1,5s, derzeit sind es aber noch "ein paar Sekunden", je nachdem wie tief der Dependency-Baum ist versteht sich.
Da dieser Dependency-Baum eine graphenartige Struktur hat überlegen wir nun von einem MSSQL-Server evtl. auf eine Graph-Database umzusteigen. Hardware ist derzeit ein einzelner 4core-Intel-Core2-Prozessor, genügend RAM (12GB) und leider keine SSD sondern eine normale HDD, wobei wir natürlich hoffen den Großteil der Datenbank im RAM behalten zu können. 64bit-System und Windows Server 2008.
Könnte uns da eine Graph-Datenbank helfen? Ist das überhaupt der richtige Einsatzzweck? Wenn ja, welche Performance-Verbesserung könnten wir uns da erwarten?
MfG SideWinder