<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">With respect to alerting, I am bit less concerned since the read does not happen on each write. If I understand correctly, it is done async via JMS when the cache(s) need to be reloaded which could be due to a change in trait value. I do not think that partitioning by resource id really helps for the alerting query since we are filtering off of the agent id and not the resource id. I might instead do something like,<div><br></div><div>CREATE TABLE agent_traits (</div><div>&nbsp; &nbsp; agent_id int,</div><div>&nbsp; &nbsp; schedule_id,</div><div>&nbsp; &nbsp; value varchar,</div><div>&nbsp; &nbsp; time timestamp,</div><div>&nbsp; &nbsp; PRIMARY KEY (agent_id, schedule_id, time)</div><div>);</div><div><br></div><div>To reload an agent cache, we can easily and efficiently query across a single partition to obtain the latest trait values. I am not too concerned about repeated inserts. I rather treat the data as immutable and maintain a history versus updating in place. Nathan Marz makes good arguments for immutable data in his upcoming book[1]. And of course in RHQ, we already have lots of history tables that essentially mimic behavior we get for free with Cassandra.</div><div><br></div><div>To limit or cap the amount of trait data we store, we can periodically run a job that purges old data. If the rows become too wide, we might need to consider further partitioning the agents_traits table. We could partition by day.</div><div><br></div><div><div>CREATE TABLE agent_traits (</div><div>&nbsp; &nbsp; agent_id int,</div><div>&nbsp; &nbsp; day timestamp</div><div>&nbsp; &nbsp; schedule_id,</div><div>&nbsp; &nbsp; value varchar,</div><div>&nbsp; &nbsp; time timestamp,</div><div>&nbsp; &nbsp; PRIMARY KEY ((agent_id, day), schedule_id, time)</div><div>);</div></div><div><br></div><div>This approach would make purging old data more efficient.</div><div><br></div><div>I do think the measurement report code should be refactored so that the MeasurementData includes resource ids since we have user-facing trait queries that filter by resource id. I would further denormalize the data though to include in measurement_data_trait the additional columns we fetch.</div><div><br></div><div>[1]&nbsp;<a href="http://www.manning.com/marz/">http://www.manning.com/marz/</a><br><div><br><div><div>On Apr 23, 2014, at 3:26 PM, Elias Ross &lt;<a href="mailto:genman@noderunner.net">genman@noderunner.net</a>&gt; wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite">On Tue, Apr 22, 2014 at 11:33 AM, Elias Ross &lt;<a href="mailto:genman@noderunner.net">genman@noderunner.net</a>&gt; wrote:<br><br><blockquote type="cite">The schema:<br><br>CREATE TABLE IF NOT EXISTS measurement_data_trait (<br> &nbsp;&nbsp;&nbsp;schedule_id int,<br> &nbsp;&nbsp;&nbsp;value varchar,<br> &nbsp;&nbsp;&nbsp;timestamp int, -- when it was inserted<br> PRIMARY KEY (schedule_id)<br>);<br></blockquote><br>My inclination was to change this to<br><br>CREATE TABLE IF NOT EXISTS measurement_data_trait (<br> &nbsp;&nbsp;&nbsp;&nbsp;resource_id int,<br> &nbsp;&nbsp;&nbsp;&nbsp;schedule_id int,<br> &nbsp;&nbsp;&nbsp;&nbsp;value varchar,<br> &nbsp;&nbsp;&nbsp;&nbsp;timestamp int, -- when it was inserted<br> &nbsp;PRIMARY KEY (resource,id schedule_id)<br>);<br><br>The reason is that all the traits are selectable by resource_id<br>directly. They're also stored together for easier caching and<br>selecting.<br><br>The downside is you must know the resource_id before you can do any<br>insert. This is a problem as the measurement report does not contain<br>this piece of information. Which would require a lot of changes to<br>'MeasurementData', the agent, and so forth.<br><br><blockquote type="cite"><br>Approach is to:<br>1) Select the current value. (*)<br>2) If it is different then insert into the history table. Use TTL<br>columns to delete old records.<br>3) In any case, update the measurement_data_trait table with the most<br>current value<br><br></blockquote>...<br><br>I know this approach is slow (and can block). But for alerting we do<br>need a select at some point, at least for those alerted on traits.<br>Oracle tells us this, because the update count lets us know the trait<br>changed or not.<br><br>On IRC, the suggestion was to cache the existing trait values to<br>determine a trait changed. We can still do that effectively with a<br>Cassandra-side row cache. The alternative is to use a clustered cache,<br>but RHQ does not support that sort of clustering yet.<br><br>I think my initial implementation will use some sort of thread pool or<br>async EJB call though, for the select+update, and I'll have to<br>determine if that is effective or not. I do have a 200+ machine<br>cluster which will prove if the average cache (assuming my<br>installation is average) performs well enough.<br>_______________________________________________<br>rhq-devel mailing list<br><a href="mailto:rhq-devel@lists.fedorahosted.org">rhq-devel@lists.fedorahosted.org</a><br>https://lists.fedorahosted.org/mailman/listinfo/rhq-devel<br></blockquote></div><br></div></div></body></html>