What is the best way to store stacktrace in database

I'm looking for the best way to store the stacktrace (obtained via Thread.dumpStack()) and exception trace in the database.

I'm developing an app that does application performance. It traces method calls(with duration), captures errors (that result in exception trace) & generates stack trace for slow executions.

The environment is Java + MySQL 5.0

Currently, the trace info of a web request & stack traces are stored in a file(as json) and meta data is stored in the database table.

For reporting & replication purpose, I'm thinking of storing them in the database. On an average, the size of complete trace info is 40 kb. Is it prudent to store them in the db or keep it in the file system and move to nosql.

Moving to nosql, i can solve the replication but still the reporting will开发者_Go百科 be a tough one.

Why not store the additional information needed for reporting as part of the 'metadata'? There may not be anything wrong with storing the complete stack trace in a file and storing a reference to that file in the DB depending on the needs of the application. I would consider what you need to report on and evaluate those elements for inclusion in the DB. For example, are you reporting on the root cause of the exception? Consider pre-processing the data down to what you need for reporting. If you are already saving the entire stack trace separately, you won't be losing any information should you need to report on something else in the future.

This question was asked a long time ago so I assume you have already made a decision but I would have been hesitant about moving to a nosql architecture without having a clear reason for doing so. Relational databases still have their place in certain scenarios and most of them have an efficient mechanism for storing large amounts of text (e.g. a stack trace).