Branch: refs/heads/master Home: https://github.com/hawkular/hawkular-alerts Commit: 4da35fab98941f1ca9f2ac7efd38a18d3bc1f47e https://github.com/hawkular/hawkular-alerts/commit/4da35fab98941f1ca9f2ac... Author: Jay Shaughnessy <jshaughn(a)users.noreply.github.com&gt; Date: 2016-11-16 (Wed, 16 Nov 2016) Changed paths: M hawkular-alerts-api/src/main/java/org/hawkular/alerts/api/services/EventsCriteria.java M hawkular-alerts-engine/src/main/java/org/hawkular/alerts/engine/impl/CassAlertsServiceImpl.java M hawkular-alerts-engine/src/main/java/org/hawkular/alerts/engine/impl/CassStatement.java M hawkular-alerts-engine/src/main/resources/org/hawkular/alerts/schema/cassalog.groovy M hawkular-alerts-engine/src/main/resources/org/hawkular/alerts/schema/checker.cql A hawkular-alerts-engine/src/main/resources/org/hawkular/alerts/schema/updates/schema-1.4.0.groovy M hawkular-alerts-engine/src/test/java/org/hawkular/alerts/engine/CassPersistenceTest.java M hawkular-alerts-engine/src/test/java/org/hawkular/alerts/engine/PersistenceTest.java Log Message: ----------- HWKALERTS-201 Improve scale for getAlerts/getEvents (#261) * HWKALERTS-201 Improve scale for getAlerts/getEvents For getAlerts: - remove indexing on status and severity - the low cardinality for these fields make them bad for indexing as the number alerts grows. And for filtering the number of returned alertIds will be very large. - prior to filtering on these fields, fetch the alerts (typically already filtered significantly by time) and then filter them directly. For getEvents - although category may have low cardinality it is unknown because categories are set by the client. So, maintain the index. - filter on category either via query+intersection, or manually, based on the size of the event set already filtered. - make the CriteriaNoQuerySize configurable and also optiponally overridden in the criteria. - Fix issue when initial filter returns 0 entities - Add some tests * PR Feedback