Investigate DB aggregation
Reported by Ben Hood | September 8th, 2011 @ 07:06 PM | in 0.9-series (closed)
The streaming based approach to aggregating unmatched events may be expensive in terms of network bandwidth and the parsing and aggregation operations that need to occur in the application. Initial profiling shows that this operation might be quite costly. An alternative approach would be to perform the same operation in the DB. This brings along a number of considerations:
- The DB code would not be very portable, hence we would need to limit the databases that we support, or fall back to the stream based approach for non-supported databases;
- DB Procedures code is quite different across DBs;
- Should we keep maintaining the current stream version to act as test framework?
Comments and changes to this ticket
-
Ben Hood September 8th, 2011 @ 07:12 PM
(from [190c7cc0dcfe0425ae9083db1f9f5b0de460840a]) [#362] Looked into a small PL/SQL proc to handle the diff aggregation https://github.com/lshift/diffa/commit/190c7cc0dcfe0425ae9083db1f9f...
-
Ben Hood September 8th, 2011 @ 07:20 PM
(from [9deabbdf3c913c7903a838c1d07846c2511d5061]) [#362] Aggregates should not contain ignored or matched events https://github.com/lshift/diffa/commit/9deabbdf3c913c7903a838c1d078...
-
Ben Hood September 8th, 2011 @ 07:22 PM
- State changed from “new” to “open”
-
Ben Hood October 3rd, 2011 @ 02:21 AM
- State changed from “open” to “invalid”
This ticket has been superseded by #371
-
Ben Hood November 14th, 2011 @ 05:35 PM
- Milestone set to “0.9-series”
- Milestone order changed from “110” to “0”
Please Sign in or create a free account to add a new ticket.
With your very own profile, you can contribute to projects, track your activity, watch tickets, receive and update tickets through your email and much more.
Create new ticket
Create your profile
Help contribute to this project by taking a few moments to create your personal profile. Create your profile ยป
A Real Time Differencing Tool.
Ben Hood