RHQ relies on a centralized relational database as its sole data store for everything from inventory to plugin meta data to metrics and so on. RHQ can be used with either PostgreSQL or Oracle. Different types of data stored in the RHQ database can have vastly different data access patterns. Plugin meta data (i.e., resource types, metric definitions, operation definitions, etc.) for example is almost entirely read-only. For production use, that meta data changes very infrequently, typically only when added or upgraded which is often only done during server upgrade. Metrics, including call time data, and events on the other hand, are very write intensive. Agents continually send metrics and event reports to the server which can easily result in thousands or tens of thousands of writes every minute.
For time series data like metrics, call time data, and events, the RDMBs adds some unnecessary overhead. While ACID transactions are one of the greatest features of relational databases, they are often times counter productive for managing time series data. Losing a handful of data points from a metric report will be inconsequential whereas losing inventory data would be a serious problem. For things like inventory data and plugin meta data, consistency is priority. For the time series data that RHQ manages, the consistency requirements are less important. Availability however, is more important. Whether we are collecting metrics from one agent, one hundred agents, or one thousand agents, we want to ensure that the database remains available to persist all of that incoming data.
PostgreSQL and Oracle provide adequate performance for writes up to a certain point. The problem however is not rooted in performance. The challenge lies in providing the scalability necessary to maintain an acceptable level of performance whether we are storing metric data for 10, 100, or 1000 agents. This is something that RDBMs do not do very well (at least compared to other types of databases) in large part due to the strong guarantees they provide around consistency.
Databases — Provides an overview of possible solutions followed by a recommendation of which database should be used.
Acceptance Criteria — Provides a compilation of questions that needs to be addressed as we move forward with our next generation storage solution.