我正在尝试构建Elasticsearch即服务的原型(prototype)。我考虑了两种不同的方法,我想就一种或另一种实现方式征求意见

  • 单个安装Elasticsearch,并在其顶部添加一个代理层以添加用户验证(http基本认证+用户帐户以验证使用情况)。
    这种方法相对简单,主要的挑战是正确配置集群以处理负载以及权限,因此不会有用户无法访问集群管理API的数据泄漏。
  • 使用Docker作为容器,并为每个用户拥有一个elasticsearch实例。在这种情况下,我将使用Linux容器(Docker)提供隔离。我仍然需要管理身份验证。

  • 既实现又玩转,看看事情如何表现,可能会很好。对每种方法的利弊有何看法?

    谢谢!

    最佳答案

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

    我认为这两种方法都有优点,但可能适合不同类型的客户。
    查看其他SaaS提供商,例如MongoDB提供商MongoLab,他们实际上最终提供了两种设置(尽管未使用Docker)。

    因此,我所看到的利弊:

    共享集群

    大多数Elasticsearch即服务提供商都以这种方式运行。

    优点:

  • 对于只是寻求良好搜索和分析功能的大多数用户而言,价格实惠得多。
  • 维护更简单,集群更少,让您可以监控
  • 可能要集成的Elasticsearch版本较少。如果您需要与其他系统进行通信(您需要这样做),请编写自己的插件(我们已经完成了身份验证,筒仓,授权,统计信息等工作),而版本越少,维护起来就越容易。

  • 缺点:
  • 必须监视嘈杂的邻居,并且您必须缩放并重新定位索引才能处理此问题。
  • 用户必须从有限的Elasticsearch版本列表中进行选择,通常是单个版本。
  • 用户无法获得完整的集群管理员控制。

  • 使用Docker的私有(private)集群

    一个以这种方式工作的提供程序是Found

    优点:
  • 用户可能能够部署各种版本的Elasticsearch
  • 用户可以具有完整的集群管理员访问权限
  • 嘈杂的邻居不会影响他们的集群,减少您的手动干预

  • 缺点:
  • 复杂的监视和支持。如果人们可以做他们想做的任何事情(通过api关闭集群),则必须弄清楚作为提供者的责任在哪里结束,以及什么会在晚上唤醒您。
  • 与多个版本的复杂集成,请参阅共享集群专家。
  • 更加昂贵,因为您必须分配可能不总是使用的资源。
  • 10-05 20:32
    查看更多