Ditto provides a search functionality as one of the services around its managed digital twins. The functionality is available for the following APIs.
|Ditto protocol||Websocket and connections||Reactive-streams compatible|
|Server-sent events||HTML5 server-sent events||Streaming with resumption|
Ditto’s microservice things-search automatically consumes all
events which are emitted for changes to
Policies and updates an for search
optimized representation of the
Thing data into its own database.
No custom indexes have to be defined as the structure in the database is “flattened” so that all data contained in Things can be searched for efficiently.
Ditto’s search index provides eventual consistency.
In order to reduce load to the database when processing updates in a high frequency, the search index is updated in
small batches with a default interval of 1 second (configurable via environment variable
That means that when a thing is updated and the API (e.g. the HTTP endpoint) returns a success response, the search index will not reflect that change in that instant. The change will most likely be reflected in the search index within 1-2 seconds. In rare cases the duration until consistency is reached again might be higher.
Example: Search for all things located in “living-room”, reorder the list to start with the lowest thing ID as the first element, and return the first 5 results:
Filter: eq(attributes/location,"living-room") Sorting: sort(+thingId) Paging: size(5),cursor(CURSOR_ID)
Search count queries
The Search supports specifying in which
namespaces it should be searched. This may significantly improve the search
performance when many Things of different namespaces are managed in Ditto’s search index.
Sorting and paging options
sort option governs the order of search results.
If not given, search results are listed in the ascending order of thing IDs, namely
limits the search results delivered in one HTTP response or one Ditto protocol message to
If the paging option is not explicitly specified a default value of 25 is used. The maximum allowed count is 200.
Starts the search at the position of the cursor with ID
<cursor-id>. The cursor ID is obtained from the field
cursor of a previous response and marks the position after the last entry of the previous search. A response
includes no cursor if there are no more results.
If a request has a
cursor option, then any included
sort option may not differ from the original request of the cursor. Otherwise, the request is rejected.
Example - return ten items with a cursor
RQL paging (deprecated)
The RQL limiting part specifies which part (or “page”) should be returned of a large search result set.
Limits the search results to
<count> items, starting with the item at index
- if the paging option is not explicitly specified, the default value
limit(0,25)is used, i.e. the first
25results are returned.
- the maximum allowed count is
Example - return the first ten items
Example - return the items 11 to 20
i.e. Return the next ten items (from index 11 to 20)