我们当前的软件解决方案使用本地ES安装(1个群集和1个节点)来存储文档,以便以后用户可以搜索它们。节点的摄取不是连续完成的,而是假设每月使用批量一次。文档集并不大,文档的大小也很小。由于该用例不需要很高的性能,因此该解决方案在普通的笔记本电脑(具有8Gb RAM的i5)中可以正常工作而没有问题。
现在,我们的软件解决方案面临两个新要求:
对于这2个新要求,无法使用当前解决方案,因为所有文档将使用相同索引在同一节点中建立索引。进一步的搜索将显示来自不同客户的文档。
解决此问题的第一种方法是根据客户对文档建立索引,即为每个客户创建索引,并在相应索引上创建索引/搜索文档。但是,我们正在考虑另一种允许我们进行以下操作的解决方案:
基于此,我认为解决方案将是在同一台PC上安装多个ES安装,每个安装都有其取决于客户的配置:
那么我的问题是,有人遇到过类似的用例吗?通过安装多个ES并同时使其服务连续运行会导致性能问题吗?使用此配置可能会出现哪些问题?
任何帮助将不胜感激。
更新
根据收到的答案以及未来可能的答案,我想进一步说明我们的解决方案+ ES的体系结构:
主题是...
...不是很关键
答案 0 :(得分:3)
您可以在生产中的同一台机器上运行ES的多个安装,但是它有很多缺点。
理想情况下,您应该至少有一个碎片副本,并且该碎片应该存在于另一台物理计算机(节点)中,以便在基础结构发生故障的情况下可以恢复,这是为了提高您的弹性系统。
在生产中,经常会遇到一个用例,在这种情况下,拥有单个分片是不够的,您需要将索引分为多个主分片以使其具有水平可扩展性,但是如果您只使用一台物理服务器,那么拥有多个分片将无济于事。
在一个安装中有大量流量的情况下,进行多个安装也无济于事,它会消耗所有物理资源(如RAM,CPU,磁盘),并使所有安装也停止生产。由于ES安装不是无状态的,而且您不能仅在另一台计算机上开始同一安装,而又不移动其所有数据和配置,因此很难找出根本原因并迅速解决问题。
基本上,您的应用程序是真正的基于租户的SAAS应用程序,考虑到您的需求,您应该在设计系统时考虑以下因素:
希望您的回答很清楚,如果我错过了您的要求,请告诉我。
基于我要添加的问题的最新信息:
正如OP提到的那样,它是一个非常小的桌面应用程序,而不是服务器端应用程序,因此,不要混合和存储每个客户的内容非常重要。任何人都可以安装https://github.com/lmenezes/cerebro之类的ES Web管理插件并读取其他客户的数据。
在您的情况下,最好的解决方案是根据客户指定的版本进行一次ES安装,并且只有一个与运行桌面应用程序的客户相关的索引。正如我前面提到的,您可以轻松使用delete API。
根本不需要进行多次安装,即使它们不会处于活动状态,但仍然会占用本地磁盘空间(对于台式机应用程序,这尤其重要),并且可能导致{ {3}}和this问题,并且根本没有更干净的设计来将不必要的信息存储在桌面应用程序上,并且还引起了一个安全问题,这通常是一个更大的问题。