You may have noticed that the Wrapper Query is just another QueryBuilder, which means you get back a builder on which you can simply add more parameters to. A gut reaction could be to add a token somewhere in the JSON string to be replaced, but this is where the Elasticsearch API shines.
Elasticsearch json query how to#
The next question is how to start augmenting the query to search across organization IDs and time periods. Which you feed into the QueryBuilder like this: QueryBuilders. On the surface, this is simple functionality where you can feed the QueryBuilder object a JSON string. This is when we discovered Elasticsearch’s Wrapper Query. This worked at first, but we didn’t want to have to edit code every time we needed to calculate a new metric or slightly change an existing one. We eventually realized that we usually had to tack on an organization’s ID and some time range to the query so we abstracted that out and just required the metric-specific part of the query to be given. termQuery("organizationId", organizationId)). When we first started using Elasticsearch, we built queries in a pretty straightforward way: BoolQueryBuilder(). Although it is generally a facade for Elasticsearch’s REST API, a particularly clever feature has been helping us build our metrics microservice with great velocity and flexibility without compromising robustness.
However, one aspect that we grossly undervalued was its fantastic Java API.
We chose Elasticsearch for storage as we trusted its powerful search capabilities and scalability. The problem was that we weren’t quite sure which metrics would be used nor what sort of queries would be needed to support our accounting and billing needs. In Solace PubSub+ Cloud, we began storing metrics early on in anticipation for accounting and billing.