I've found the stored procedures to be insufficiently flexible to handle complex requirements compared to modern programming languages (requirements come in for new reports on a regular basis). I'd like to generate these reports in application code (C#) but can't see a way around the performance issue. Has anyone dealt with similar challenges and how did you work around them?
Ask HN: Generating reports on time series data without killing performance?
1–10 of 15 posts
Re: Ask HN: Generating reports on time series data without killing performance?
#2Re: Ask HN: Generating reports on time series data without killing performance?
#3That volume of data should be handled pretty easily by the right indexes and joins. At one place with that order of magnitude of data we kept an offline synced clone of the data with indexes designed for the queries we needed to run (this is basically OLAP). Have you already looked into that?
Edit: If you're saying mirror the time series data onto the application server to avoid the network roundtrip, I guess that is possible but we still face the SQL overhead with each query.
Re: Ask HN: Generating reports on time series data without killing performance?
#4That volume of data should be handled pretty easily by the right indexes and joins. At one place with that order of magnitude of data we kept an offline synced clone of the data with indexes designed for the queries we needed to run (this is basically OLAP). Have you already looked into that?
Yes currently all the reports operate quite efficiently on a set of indexes. The performance of the database is currently very good with the reports in PL/SQL. The problem arises when the reports are generated using application logic on another server. Let's say we have a report for the last 10,000 records. For each of those records, I have to query the database again for some other time series information. If the la…
Re: Ask HN: Generating reports on time series data without killing performance?
#5Earlier quoted context omitted.
Yes currently all the reports operate quite efficiently on a set of indexes. The performance of the database is currently very good with the reports in PL/SQL. The problem arises when the reports are generated using application logic on another server. Let's say we have a report for the last 10,000 records. For each of those records, I have to query the database again for some other time series information. If the la…
Yeah, you definitely don't want to be making those roundtrips. Why doesn't a join work?
To give a very broad example of one report: take 10,000 latest time series records from geographic location X. Now for each of those records load the latest 100 time series records from location Y and Z. Multiply all records from Y and Z together then divide by the value at location X. Throw in lots of business rules at every one of these steps so we have no chance of representing this as a tidy join operation and so that we can make no assumptions about the data we'll need to load to generate the report :)
Re: Ask HN: Generating reports on time series data without killing performance?
#6Earlier quoted context omitted.
Yeah, you definitely don't want to be making those roundtrips. Why doesn't a join work?
Complex domain-specific requirements preclude simple joins unfortunately. This is why I'd like to redevelop these queries in C#. There are many imperative steps performed on each time series record to decide how these reports are generated. To give a very broad example of one report: take 10,000 latest time series records from geographic location X. Now for each of those records load the latest 100 time series record…
Edit - returning multiple result sets from the server is always an option too.
Re: Ask HN: Generating reports on time series data without killing performance?
#7Earlier quoted context omitted.
Yeah, you definitely don't want to be making those roundtrips. Why doesn't a join work?
Complex domain-specific requirements preclude simple joins unfortunately. This is why I'd like to redevelop these queries in C#. There are many imperative steps performed on each time series record to decide how these reports are generated. To give a very broad example of one report: take 10,000 latest time series records from geographic location X. Now for each of those records load the latest 100 time series record…
Sorry, I probably edited my post while you were typing. The amount of data to load is theoretically unbounded (could load the entire data set for a big report) and it's very difficult to estimate ahead of time which data needs to be loaded. This is because the data in the time series dictates which secondary sets of data will be loaded on a record-by-record basis.
Re: Ask HN: Generating reports on time series data without killing performance?
#8Earlier quoted context omitted.
Yeah, you definitely don't want to be making those roundtrips. Why doesn't a join work?
Complex domain-specific requirements preclude simple joins unfortunately. This is why I'd like to redevelop these queries in C#. There are many imperative steps performed on each time series record to decide how these reports are generated. To give a very broad example of one report: take 10,000 latest time series records from geographic location X. Now for each of those records load the latest 100 time series record…
Re: Ask HN: Generating reports on time series data without killing performance?
#9Earlier quoted context omitted.
Yeah, you definitely don't want to be making those roundtrips. Why doesn't a join work?
Complex domain-specific requirements preclude simple joins unfortunately. This is why I'd like to redevelop these queries in C#. There are many imperative steps performed on each time series record to decide how these reports are generated. To give a very broad example of one report: take 10,000 latest time series records from geographic location X. Now for each of those records load the latest 100 time series record…
Yeah, this is the unfortunate conclusion that I arrived at too. I'm looking at making these reports go through a job queue which e-mails the result to the user when it's done. This would allow me to develop much more complex, but much slower queries in C#.