A case for DAG databases
Correlating revision history with CI results
- Track: Graph Systems and Algorithms devroom
- Room: K.4.601
- Day: Saturday
- Start: 12:00
- End: 12:25
- Video only: k4601
- Chat: Join the conversation!
Graph database servers have grown immensely powerful, but they still can't query DAGs (Directed Acyclic Graphs) better than a command-line tool can: git. One CI system needs just that to correlate results and bugs with the revision history of the Linux kernel.
The KCIDB system at Linux Foundation's KernelCI project has been collecting build and test results for the Linux kernel for a while. We receive about 10K build and 200K test results per day from seven CI systems.
However, due to the specifics of the Linux development process, and the nature of testing an OS kernel, this raw data alone is not very useful to developers. In order to filter out already-known issues, spot new ones, and track performance trends, we need to correlate our results to the Linux revision history, which forms a DAG (Directed Acyclic Graph).
Our attempts to find a solution were unsuccessful: Neo4j couldn't do it, and we couldn't find another system which would be sufficiently different to offer hope. So, we're here to either find one, or inspire you to create one, specifically targeting large DAGs.
Speakers
 |
Nikolai Kondrashov |