0

I'm drafting a proof-of-concept build server and what got me thinking is how to store all the data it produces. For example, I'd like to store

  • Unit test results: which tests were run, how much time each test took, results, stacktraces, number of assertions
  • Code coverage information, with line-level granularity
  • Various LoC metrics - per file, per file type
  • Code duplicates information

Additionally, these are the kinds of queries I'd like to run:

  • How has tests' execution time changed over time?
  • How has overall code coverage percentage changed over time? And what about this particular method? How has uncovered line count changed over time?
  • What was the dynamic of LoC for *.cs files? How total LoC count was changing?

Stuffing all this into a RDBMS doesn't sound like a particularly good idea. What storage technology fits my bill best here?

Anton Gogolev
  • 113,561
  • 39
  • 200
  • 288

1 Answers1

1

If you don't want to use an RDBMS you could definitely go with MongoDB for your requirements.

It allows you to group similar documents in a collection and each document in a collection does not have to have the same schema. One document can have 5 fields, another can have 10.

It can be fairly easily scaled to provide redundancy.

MongoDB also provides what they call the "aggregation framework" that allows you to generate stats/aggregations over your data. It's faster than their map/reduce solution - which can be a little slow of course.

Of all the document databases out there right now, I would say it is clearly the most mature and definitely has the richest query language.

ryan1234
  • 7,237
  • 6
  • 25
  • 36