Revision as of 08:26, 30 March 2007

Breakpad Database

Define schema that works well with current query/reporting needs
- Need to define metadata that we absolutely have to have
- Other information and common reports that any crash reporting system would have
- [need to dig up all common queries - jay]
The schema now accounts for the following kinds of information
- individual minidump records
- product/OS/buildid information
- control information used to "register" an incoming minidump and monitor/track/control its progress though all the stages from being transfered from the client until it is fully collected and processed on the server and available for reporting and analysis.
using the same database and schema for the minidump data and also for control over the processing of the minidumps has created problems in the past. when coruption is introduced, database performance problems crop up, or maintenance is required to manage the collection of minidumps, the processing of incoming minidumps is hindered and we start into a downward spiral of compounding problems. We should do some thinking to see if there are ways to improve on the existing design.

@@ Line 3: / Line 3: @@
 = Breakpad Database =
-* Use MySQL, like everything else (we should revisit this, as it may NOT be the right choice --morgamic)
+* PostgreSQL 8.1 or higher will be used because it offers things that MySQL does not have
-** Would we need to make use of stored procedures or views?
+** Arguably better performance for larger data sets
-** Would we need to do any sort of partitioning?
+** More precise datatypes
-** Does MySQL scale as well as PgSQL for arbitrarily large data sets?
+** Potential for partitioning if we need to scale the database in the future, which will likely happen if we plan on keeping more than 3 months worth of data
-** Any other reason why MySQL would hang us up (table type/storage engine problems)?
+** Long-standing support for stored procedures (which can be in Python :D)
+** Views for databases that are heavily normalized
 * Define schema that works well with current query/reporting needs
+** Need to define metadata that we absolutely have to have
+** Other information and common reports that any crash reporting system would have
 ** [need to dig up all common queries - jay]
 * The schema now accounts for the following kinds of information