Hi - We are designing a system for reporting and are planning to use
Elastic search as a backend. We want to expose reporting in such a way that
users can build custom reports on top of their data without us coming in
their way. One way to do this is to expose elastic search query APIs
through our public endpoints. The other option is to use an abstraction
language which get translated to elastic search queries in the middle tier.
The latter option allows us to control what runs on ES but can become
restrictive in terms of how much we expose the rich query mechanism of ES
using the abstraction layer. I would like to know if there is a known
design pattern to solve this. How have users of elastic search addressed
flexibility vs. control?
It depend on your requirements and your product strategy - both is possible
with pros and cons:
are your users proficient in a report language? Do they already write
report specs in a "standard" report language? Do you want to support this
report language standard? Do you like to share report standard language
mapping to ES with the ES community? Then, try to find out if you can
translate report language to ES domain language.
are your users fond of ES? If you open the access by proxy to the _search
backend, you are independent of any kind report language, but your users
must learn by an extra step how to formulate Elasticsearch queries (and
they could also formulate "bad queries" which are challenging ES cluster
resources)
Hi - We are designing a system for reporting and are planning to use
Elastic search as a backend. We want to expose reporting in such a way that
users can build custom reports on top of their data without us coming in
their way. One way to do this is to expose Elasticsearch query APIs
through our public endpoints. The other option is to use an abstraction
language which get translated to Elasticsearch queries in the middle tier.
The latter option allows us to control what runs on ES but can become
restrictive in terms of how much we expose the rich query mechanism of ES
using the abstraction layer. I would like to know if there is a known
design pattern to solve this. How have users of Elasticsearch addressed
flexibility vs. control?
We are in the middle of doing the same thing, designing a system for
reporting. And I want to create a middle API layer for the reasons you
suggest and other reasons. I would like to exchange notes with you in a
private message, if you want. You have to create some middle later, right?
You don't want to let users issue request for DELETE http://yourhost:9200/_all/.
Zennet
On Tuesday, June 10, 2014 12:03:08 AM UTC-7, Pradeep Narayan wrote:
Hi - We are designing a system for reporting and are planning to use
Elastic search as a backend. We want to expose reporting in such a way that
users can build custom reports on top of their data without us coming in
their way. One way to do this is to expose Elasticsearch query APIs
through our public endpoints. The other option is to use an abstraction
language which get translated to Elasticsearch queries in the middle tier.
The latter option allows us to control what runs on ES but can become
restrictive in terms of how much we expose the rich query mechanism of ES
using the abstraction layer. I would like to know if there is a known
design pattern to solve this. How have users of Elasticsearch addressed
flexibility vs. control?
Apache, Apache Lucene, Apache Hadoop, Hadoop, HDFS and the yellow elephant
logo are trademarks of the
Apache Software Foundation
in the United States and/or other countries.