Elasticsearch多租户SaaS或单实例和代理的Docker?

我正在尝试构build一个Elasticsearch即服务的原型。 我已经想到了两种不同的方法,我希望得到一个或另一个实现的意见

  1. Elasticsearch的单一安装和顶层的一个代理层添加用户validation(http基本authentication+用户帐户来validation使用情况)。 这种方法是比较直接的,主要的挑战是正确configuration集群来处理负载以及权限,这样用户就不会有数据泄漏,从而无法访问集群pipe理API。

  2. 使用Docker作为容器,并为每个用户提供一个elasticsearch实例。 在这种情况下,我将通过使用Linux容器(Docker)提供隔离。 我仍然需要pipe理身份validation。

实现这两者可能会很好,玩耍,看看事情的行为。 任何有关每种方法的利弊的意见?

谢谢!

免责声明:我是Elasticsearch服务提供商Facetflow的创始人,它目前提供共享群集。

我认为这两种方法都有优点,但可能适合不同types的客户。 看看其他SaaS提供商,如MongoDB提供商MongoLab,他们基本上都提供了两个设置(尽pipe不使用Docker)。

所以,我看到他们的利弊:

共享群集

大多数Elasticsearch即服务提供商都是这样操作的。

优点:

  1. 对于大多数用户来说,只要寻找好的search和分析工具,价格就更实惠了。
  2. 更简单的维护,更less的集群供您监控
  3. Elasticsearch的潜在版本可以集成在一起。 如果您需要与其他系统(您所做的)进行交stream,请编写您自己的插件(我们为此进行身份validation,孤岛,授权,统计等),更less的版本将更容易维护。

缺点:

  1. 嘈杂的邻居必须受到监视,你必须调整和重新安置指数来处理这个问题。
  2. 用户必须从Elasticsearch版本的有限列表中进行select,通常是单个版本。
  3. 用户没有得到完整的集群pipe理控制。

使用Docker的私有集群

一个这样工作的供应商是Found 。

优点:

  1. 用户可能可以部署Elasticsearch的各种版本
  2. 用户可以有完整的群集pipe理访问权限
  3. 嘈杂的邻居不会影响他们的集群,减less你的人工干预

缺点:

  1. 复杂的监控和支持。 如果人们可以做任何他们想做的事情(closuresapi上的集群),你必须清楚你作为一个提供者的职责何时终止,什么东西在晚上唤醒你。
  2. 与多个版本的复杂集成,请参阅共享集群专业人员
  3. 因为您必须分配可能不总是使用的资源,所以成本更高。