Storage Hints
Last updated
Last updated
Intelie Live supports that hints are used to tell the storage providers how to behave in some situations. Hints change the behavior of queries on the storage, but have generally little effect on the real time queries.
As the name of the feature describes, these are only hints, and there is no guarantee that the storage providers will strictly respect them. Intelie Live might decide, for example, that a hint will not be applied in order to execute the query together with other queries as an optimization. They are very useful, but do not rely purely on them for any feature.
It is important to notice that Intelie Live supports multiple storage providers simultaneously. Besides that, a Pipes query on the storage may execute up to 3 actual queries on the database in order to fit the data that were received during the execution. Then, even if all the hints were respected, the final result of a query would not follow the hints strictly because it is a concatenation of all of those queries.
.flags:nocache
: disables cache (both for reading and writing);
.flags:noautoselect
: disables automatic generation of .select
hint based on static analysis of the query;
.flags:nometrics
: disables metric collection (may speed up the query in some cases);
.flags:nocount
: disables cursor counting, which takes some time before the query starts iterating through events (disabling this exact count enables count estimation);
.flags:noasync
: disables async query evaluation;
.flags:forceasync
: forces async query evaluation, even when it’s disabled globally;
.flags:noindex
: disables index check/automatic creation;
.flags:forcecount
: forces exact counting, even when it’s disabled globally;
.flags:reversed
: asks the StorageProvider to provide events in reverse order (from newest to oldest), dangerous as hell (!);
.flags:forceindex
: forces index check and creation, even when it’s disabled globally (note that this also forces creation of .where indexes).
Queries containing .flags:reversed
do not support time-based aggregations, do not take advantage of the cache mechanism, and need specific indexes (reversed) on the database to be fast.
Hint
Type
Support
Since
.timestamp
string
mongodb, postgresql
When this hint is used, Live will use the values of this field as the index of the query. For example, .timestamp:my_timestamp
will make the field my_timestamp
be used as the index for this query. The .timestamp
hint has one implication on the real time queries: it replaces the value of the timestamp
field with the value of the designated field.
.limit
integer
mongodb, postgresql
Limits the number of the entries returned by the storage query, that is, the number of events input to the Pipes query. It is important to notice that the limit is applied to each of the performed queries, and, to fit data that arrived during the query execution, Live executes up to 3 actual consecutive queries on the storage.
Example: .limit:10
.where
filter
mongodb, postgresql
Applies a filter on the storage query. This is useful to limit the results and to take advantage of database indexes. The semantics of this field might be different from Pipes, and varies depending on the storage provider. Filters on mongodb, for example, are case sensitive, which does not occur on Intelie Pipes. This hint can be used alternatively with a !
after the property name on the Pipes filter.
Example: .where:'some_field$:some_value'
or some_field!:some_value
(on the Pipes filter).
.select
set<string>
mongodb, postgresql
Limits the fields of the result entries. Live automatically analyses all storage queries and infer the fields that might be returned, ignoring the others. But this can be manually overriden.
Obs: The field defined as the.timestamp
(timestamp
by default) is always included.
Example: .select:'a_field,another_field'
.flags
set<string>
mongodb, postgresql
nocache
, noautoselect
, nometrics
, nocount
, noasync
, forceasync
, noindex
, forcecount
, reversed
, forceindex
.
Example: .flags:'noasync,nocount'
.batchSize
integer
mongodb
Deprecated on 2.25.0 in favor of dynamically calculated sizes.