SQL backend to handle 'big data'
the collector and notification worker only works on a single thread... enabling collector to use multiple workers causes massive amount of deadlocks because of updating done to source/
Blueprint information
- Status:
- Complete
- Approver:
- gordon chung
- Priority:
- High
- Drafter:
- gordon chung
- Direction:
- Approved
- Assignee:
- gordon chung
- Definition:
- Approved
- Series goal:
- Accepted for juno
- Implementation:
-
Implemented
- Milestone target:
-
2014.2
- Started by
- gordon chung
- Completed by
- gordon chung
Related branches
Sprints
Whiteboard
Gerrit topic: https:/
Addressed by: https:/
improve performance of resource-list in sql
- merged
Addressed by: https:/
DBDeadlock exception in sql backend
Using SQL and big-data in same sentence seems funny to me :). I guess we should discuss this topic during summit and create a detailed plan of how to proceed with big-data.
alexei-kornienko 14.03.14
i should put big-data in quotes. -- gordc
Agreed that a summit discussion around this would be good...tweaks to the queries will certainly help, but the poor performance may need to be addressed by re-working the schema.
nealph 18.03.14
random thought - the queries seem to be ripe with opportunity to do concurrent queries (get a list of meter_id/
-- gordc 18.03.14
Addressed by: https:/
spawn multiple workers in services
Addressed by: https:/
Remove unused db code due to api v1 drop
Addressed by: https:/
refactor sql backend to improve write speed
NOTE:
write speed has been brought up to par as of https:/
Work Items
Dependency tree
* Blueprints in grey have been implemented.
