QUERIES AND AGGREGATIONS
Group records, sum values and filter related data.Group records, sum values and filter related data.
Return due tasks only for tenants with spare capacity. Compare running-container counts with each tenant's settings in one keyed query, or use nested groups and signed sums for usage reports.
Less data movement
Compute results inside Keldra so your application fetches the records it needs.
Authorisation built in
Each custom-realm input can use its own authorisation relation for the same end-user subject.
Answers for real operational work
Find ready tasks, compare tenant capacity and summarise usage across related records.
THREE INPUTS. ONE ELIGIBILITY QUERY.
Find ready tasks by tenant capacity
A scheduler stores tasks, running-container leases and tenant settings as separate object types. Their shared tenant key connects the question.
1. Read capacity settings
Read each tenant's capacity from its settings input. Use an explicit fallback when no override is present; duplicate values are an error, not an arbitrary choice.
2. Count running containers
Count authorised live lease records for the tenant, using the running input's own predicate and relation.
3. Return eligible tasks
Filter ready, due tasks where the running count is below that tenant's capacity. Request an ordered page rather than downloading the whole queue.
A useful result for the application
Receive eligible tasks, with optional named per-filter group values. Selecting work is not claiming it: use the existing atomic write or programme needed for concurrent schedulers.
Calculate over authorised records inside Keldra
Reduce application complexity
Grouping and keyed filtering combine related facts inside a bounded query instead of making the application join every record itself.
Respect access boundaries
Only authorised live records contribute to a custom-realm result, facet or aggregate. A group is not a bypass around object visibility.
Solve practical problems
Identify eligible work, check available capacity and produce useful summaries using your indexed data model.
Task scheduling, capacity checks and usage reports
Ready tasks
Find the next tasks that are due for tenants with room to run them. Multiple named keyed filters combine with AND.
Capacity checks
Compare running counts with a value from a separate settings input. Missing overrides can use an explicit configured fallback.
Operational summaries
Group counts and signed sums by tenant, object type or status. SUM(100, -100) is zero; negative deltas are not turned into positive usage.
One coherent set of query tools
Use the grouping and metric shape that fits the question. Declare the required field capabilities when creating the index.
Facets and nested groups
Count facet values, or build aggregation trees with terms and compound keys, ranges, numeric histograms, UTC date histograms, named filters and missing-value buckets. Child computations work on their parent group's records.
Metrics over matching values
Calculate COUNT, VALUE_COUNT, signed SUM, MINIMUM, MAXIMUM, AVERAGE, SINGLE_VALUE and bounded exact DISTINCT_COUNT. Select TOP_VALUES or explicitly ordered TOP_HITS where individual values or records are needed.
Operations on completed buckets
Filter, sort and limit merged buckets. Derive differences, cumulative sums, rates and moving averages from named metric outputs. These operations run after shard results merge, not independently on incomplete shard groups.
Keyed semi-joins
Filter outer records using grouped values from named inputs with a shared key. Keep each input's predicate and authorisation relation explicit. This is a bounded keyed query model, not an unrestricted SQL join engine.
Queries use declared index capabilities and configured work and memory bounds. Full-set facets and aggregates examine the matching set; a small hit-page limit does not make that work disappear. Provision an appropriate physical order for efficient deep hit paging. Root aggregation buckets have their own continuation tokens.
The native keyed-filter shape
This IndexKeyedFilter is placed in the outer task query's keyed_filters. Its outer predicate selects ready, due tasks; limit and order choose the page. The input index names and relations are application-defined, and can refer to the same multi-type index when their predicates distinguish the records.
name: "tenant_capacity"
outer_key_field: "tenant_id"
inputs {
name: "running"
index_name: "workspace_objects"
key_field: "tenant_id"
authorization_relation: "list_containers"
predicate { conjunction { expressions { predicate {
field: "document_type"
operator: INDEX_PREDICATE_OPERATOR_EQUAL
values_json: "\"container_lease\""
} } expressions { predicate {
field: "status"
operator: INDEX_PREDICATE_OPERATOR_EQUAL
values_json: "\"running\""
} } } }
}
inputs {
name: "settings"
index_name: "workspace_objects"
key_field: "tenant_id"
authorization_relation: "read_capacity"
predicate { predicate {
field: "document_type"
operator: INDEX_PREDICATE_OPERATOR_EQUAL
values_json: "\"tenant_settings\""
} }
}
condition {
left { input: "running" operation: INDEX_AGGREGATE_OPERATION_COUNT }
operator: INDEX_PREDICATE_OPERATOR_LESS_THAN
group_value {
input: "settings"
operation: INDEX_AGGREGATE_OPERATION_SINGLE_VALUE
field: "capacity"
missing_fallback_json: "8"
}
}
WORK SMARTER WITH YOUR DATA
Replace document-fetch loops with indexed calculations.
Keep the calculation close to the indexed records, with fewer application-side requests and clear authorisation for each input.
