点击上方 蓝字 关注我们
在大数据应用中，完成数据实时处理与搜索的搜索数据库或者搜索引擎必不可少。在日益增加的需求面前，市面上开源搜索引擎直面两大挑战：
一是开源社区版软件在性能等方面无法满足商业应用的需求;
二是在信息安全和自主可控方面，无法满足政务、金融等有特殊需求的用户的需求。
国产自研搜索引擎如分布式搜索引擎Transwarp Scope在设计上考虑了自主可控、高性能、高并发、低延时等特性，以满足在大数据环境下对搜索引擎的需求。
目前，中国用户采用Transwarp Scope替代Elasticsearch，可实现平滑迁移，同时比Elasticsearch具有更强的查询性能、扩展性、数据一致性和可靠性，以及更低的硬件和运维成本等优势。
同时Transwarp Scope已完成与龙芯、海光、飞腾等国产芯片以及中标麒麟、统信UOS等国产操作系统的适配工作，满足信创要求和国产化替换需求。
1.开源系统Elasticsearch or Opensearch?
自2021年1月1日，开源大数据实时搜索引擎Elasticsearch的许可协议从Apache许可证，变更为Server Side Public License(SSPL)。
SSPL协议并不是Elasticsearch背后的商业公司Elastic开发的，而是借鉴了数据库企业MongoDB开发的新型许可协议，以应对Elasticsearch在商业化道路上开源版本与商业版本的竞争。
SSPL相比于Apache许可证有一些重要的变化。其中最主要的变化是，SSPL要求将使用SSPL许可的软件作为一种服务提供给其他人时，必须公开源代码并以相同的许可证授权，以便其他人也可以自由使用、修改和重新分发软件。
换句话说，这就意味着如果将Elasticsearch作为服务提供给他人，必须公开源代码，这与之前Elasticsearch的Apache许可证是不同的。
这一变更引起了一些争议和讨论。一些人认为这是对开源社区的背叛，因为它限制了以商业方式使用Elasticsearch。另一方面，Elasticsearch的开发者表示，这一变更是为了保护自己的商业利益，防止云服务提供商将Elasticsearch作为自己的产品，而不提供价值回馈给Elasticsearch社区。
无论如何，这一变更对于那些使用Elasticsearch的开发者和用户来说，需要了解并评估其对其影响。对于已经在使用Elasticsearch的项目和产品，可以继续使用之前的Apache许可证版本，但不再获得新的功能和更新。对于新的项目和产品，需要评估是否适合使用SSPL许可的Elasticsearch，并了解其对商业使用的影响。
随后几年，Elastic陷入了与亚马逊月科技AWS开源Opensearch的长久纷争。目前，Elasticsearch和Kibana使用了三种开源许可协议：Apache License 2.0、Apache License 2.0 compatible license和Elastic License。其中，Apache License 2.0是最广泛使用的开源许可协议之一，而Elastic License则是Elastic公司自己制定的许可协议。
现在，Opensearch和Elasticsearch是两个不同的开源搜索引擎，Elasticsearch最初由Elastic公司开发和维护，并在Elastic License下进行开源发布。
而Opensearch是由亚马逊云科技AWS公司在Elasticsearch基础上创建的分支项目，由一个全球化的社区团队进行管理，并使用Apache 2.0许可证。
另外，Opensearch通过添加一些新功能、扩展和插件来增强与Elasticsearch的兼容性。Opensearch还专注于提供更好的监视和故障排除功能，以及更好的安全性和隐私保护。
未来，Opensearch围绕开源社区反馈和需求来制定路线图，而Elasticsearch则由Elastic公司根据其商业目标来制定路线图。
用户可以根据自己的需求和背景，选择适合自己的搜索引擎。
2.选择开源Elasticsearch，中国用户还要面临这些问题
除了许可协议变更，Elasticsearch还存在这些挑战：
第一，开源Elasticsearch硬件成本高，存储限制问题。分析发现Elasticsearch常驻在Java堆内存空间中的内部数据大小会随着单节点数据量的增大而线性增大。而Java堆内存空间总大小又受到Java虚拟机本身的限制，最终导致了不必要的限制：单服务器上部署单个Elasticsearch实例，能服务的数据量最多到10TB左右。
在项目实践中，客户为了追求高性价比，一台服务器部署30TB、40TB磁盘并不罕见。而为了提高磁盘利用率，此类客户不得不在每台服务器上部署多个Elasticsearch实例。这样，几十个节点的集群就可能部署超过100个实例。
而如此多的实例，就会面临集群扩展后的不稳定问题，触发节点失联，运维成本高，特别是用户并发查询;运维人员进行建表、删表操作;又发生单点故障，状态信息要同步;这样多种任务并发的情景下，集群压力大，简单的操作也要几分钟才响应。
而响应变慢，使后续操作积压，加剧集群压力，导致个别节点不稳定，甚至超时报错。有节点报错进一步加剧集群压力，这样形成恶性循环，触发多个节点连环失联的问题。
第二，开源ES数据恢复慢问题。Elasticsearch如果有节点出现磁盘损坏需要更新的情况，该节点必须重新启动。
同时，为了满足数据入库性能要求，Elasticsearch没有对写入数据做细粒度的标记控制，缺乏“增量数据”的概念。当单个节点重启时，或是单点发生故障进行数据恢复时，它采用全量数据拷贝方式恢复数据，工作量大，往往需要小时级的时间才能恢复服务，十分影响服务的正常进行。
此外，Elasticsearch使用的分配shard算法也不合理。算法的时间复杂度与shard总数N的平方成正比，与集群节点数M成反比。随着数据规模的上升，shard总数N的增长远快于集群节点数M的增长，时间复杂度近似和数据规模的平方成正比。
集群规模上百节点时，由于建表操作和数据恢复操作都使用了shard分配算法，响应时间很慢，往往要数分钟响应。这也影响了单点故障恢复时间。
第三，开源ES 部分数据有丢失风险。为了满足数据入库性能要求，它在数据层采用了简单的主从最终一致性模型。当主副本出现故障时，从副本和主副本不能保证数据的强一致性，从副本的数据有可能不是最新的。以此为基础恢复数据，可能导致部分数据丢失。
Elasticsearch数据安全方面也有考虑不足。Elasticsearch没有回收站功能。用户误做了删除数据操作后无法便捷的找回，恢复数据十分麻烦。
3.自研搜索引擎Scope替代Elasticsearch效果突出
某政府单位采用开源ES（Elasticsearch），面临众多挑战，如无法扩容，节点个数达开源ES上限；集群恢复慢，开源ES一旦重启需要小时级别恢复；读写资源无法隔离，拖累查询性能，系统设计为读写两套集群；数据总量大，总数据量超几十PB,单张表达百亿条级别；数据日增量大，每天加工增量数据60TB；返回延时低，指定条件查询1s内返回并支持上千并发；场景复杂，需要支持小语种，多语言、数字混合场景等。
某政府单位采用星环搜索引擎Scope平滑替换ES。基于星环大数据基础平台TDH构建大规模数据综合搜索平台，使用星环时间存储库Eventstore作为数据总线，星环实时流计算引擎Slipstream做实时数据引擎，清洗分析并入库到星环宽表数据库Hyperbase与Scope的综合搜索库中，提供基于几十PB数据量的快速查询和搜索能力，集群规模达200个节点。
该项目融合人、地、物、事、组织与视频/图片等因素，通过星环TDH构建一站式智慧云搜索平台，实现了PB级数据统一存储、检索满足海量数据毫秒级响应，高并发、快速统计、字段精确与模糊查询等复杂组合场景，并通过单节点存储容量比开源高6倍的优势，降低了客户硬件投资成本。
2023年最新发布的Transwarp Scope 2.5提供了更友好的兼容度支持。在满足高性能多样化检索的同时，在集群拓展性、安全管控能力、运维管控、数据一致性等方面进一步加强，充分覆盖顾客在搜索引擎类产品的国产化替换痛点并提供平滑迁移的解决方案，助力企业构建稳定可靠、安全易用的日志分析、海量数据检索等检索业务场景。
在性能上，星环Scope 2.5依靠多进程架构，充分利用集群资源，支持与实时流引擎Slipstream无缝衔接，支持flink/kafka to Scope，全文检索毫秒级响应。
在可展性上，星环Scope 2.5支持在线水平扩展，支持百节点+大规模集群的部署，利用容器技术实现资源调度和资源隔离，支持弹性扩缩容。
星环Scope 2.5基于Raft一致性协议的存储引擎，具备自动故障迁移、自动数据修复的能力。同时提供用户认证、传输加密等功能，保障集群数据安全。
星环Scope 2.5满足各类软硬件环境需求以及信创需求，支持单集群混合架构部署，最大化利用硬件资源，实现了多类操作系统适配，支持多种架构的CPU，实现灵活部署。
参考资料：
·https://mp.weixin.qq.com/s/D_mHx2LEjr8UJSm8nUDcJg
·https://coralogix.com/guides/elasticsearch/elasticsearch-vs-opensearch-key-differences/
·https://mp.weixin.qq.com/s/TpB-XbgNjqInFnIsuSO2Hw
·https://mp.weixin.qq.com/s/71c5TwZM56AoCC0jThKwzQ
·https://bigdataboutique.com/blog/opensearch-vs-elasticsearch-an-up-to-date-comparison-5c1c71
相关文章
·创新引领应用案例与国产化替代系列：革命性转变：MariaDB替代MySQL理想破灭，MySQL 5.7退役引发轰动，替代开源数据库还需看国产数据库崛起
·创新引领应用案例与国产化替代系列：设备时序数据、消费者行为图数据、交易关系型数据···建设高效稳健大数据平台，某烟草企业实现多模式数据的深度价值变现
·创新引领应用案例与国产化替代系列：许可变更、服务改变、安全威胁和成本增加、性能难以提升···一家航空公司用国产化替代一招解决开源大数据CDH所有烦恼!
·创新引领应用案例与国产化替代系列：打破数据架构边界，实现数据集中管理和分析!这家头部农商行湖仓一体做到了!
春
天
END
