Storage Hints

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.

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.

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.

More on flags

  • .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.

Last updated