Short description of our application: We analyze .NET assemblies and detect dependencies between them (e.g. method calls). We save those dependencies in a MSSQL server database. From a class/method in code we can now find all direct and indirect dependencies and are able to find out which code may break if we change the interface or implementation.
Although we make good use of indices (dropped our import performance, but that runs overnight anyways) we still have performance issues. As we import many many versions of the same assembly we have quite a heavy amount of data and queries take a few seconds, which is just not fast enough (< 1.5s is the target).
As dependencies are a graph-like structure we’re wondering if switching from MSSQL to a NoSQL graph database may help. This would take some time so we’re hoping for some external input first.
If yes, you can of course also post a recommended .NET graph database 🙂
Call me an old fogey, but I would be quite careful making such a technology switch – as this SO question shows, the technology choice is fairly limited, and I think you run the risk of turning your project into a “Neo4J” project, rather than a “dependency management” project. If you’ve really hit the buffers, that’s worth considering, but it doesn’t sound like you should be there with the data volumes you’re discussing.
The first thing I’d consider is looking at the “nested set” model – this specifically solves the performance problem when retrieving all children for a given node.