友情链接
搜索引擎数据库是一类专门用于数据内容搜索的NoSQL数据库,是非结构化大数据处理分析领域中重要的基础支撑软件。
伴随互联网、移动互联网、物联网、5G等信息通信技术及产业的发展,全球数据量呈现爆发式增长的趋势。根据IDC数据显示,到2028 年,全球数据圈(global datasphere)预计将增长到 400 ZB,非结构化数据成为全球数据量的主要来源。
非结构化数据指的是无法以预定义格式存储或适合现有数据模型的数据,比如图像、视频、音频、用户行为等等。数据结构复杂,不方便用传统的数据库二维逻辑来表现,但其中却蕴含着丰富的数据价值,因此如何高效地处理分析非结构化数据是数据库领域面临的机遇和挑战。
在这样的时代背景下,搜索引擎数据库逐渐被人们所熟知,它可以使用索引对数据中的相似特征进行归类,提供快速准确的数据检索服务。通过对索引和检索过程的优化,可以处理大量文本、半结构化或非结构化的数据。
搜索引擎数据库的应用十分广泛。
诞生的初期,搜索引擎数据库主要是为了解决关系型数据库中长文本检索效率低下的问题,所以又称为全文数据库、非结构化数据库等等。随着技术的发展,目前衍生出了多种处理不同类型来源数据的检索引擎并集成在不同的数据库中。例如除了长文本数据、常见的数值、日期之外,还可以处理各种各样的非结构化数据,例如 IP、地理位置信息、图片、音视频等等。
凭借在数据查询效率方面的优势,搜索引擎数据库在数据处理方面的地位越来越高,并在应用程序搜索、网站搜索、企业搜索、智能问答、图像与语音搜索、语义搜索、业务分析和安全分析等方面有着广泛的应用。
更多搜索引擎数据库的背景介绍以及所涉及的技术点剖析可点击下方对应链接进行查看:
Scope是星环自研的搜索软件,除了保留底层的lucene框架和工具层外,上层进行了全自主研发改造,扬弃了开源产品中的那些带来瓶颈和限制的模型,用更贴合海量数据大集群场景的模型来代替,打造出了自主可控的搜索引擎产品。
文档数据库
日志分析与监控
舆情分析
搜索引擎
一直以来,我国的上游核心技术频繁的遭遇“卡脖子”,严重影响了我国关键科技和产业的发展。在过去几年内, Elasticsearch 数据泄露事件频发,安全风险加剧。数据泄露事件频发给国内各行业用户敲响了数据安全的警钟。同时,ES在2021年更改了其开源协议,对其产品的许可协议增加了限制,也带来了更多的商业风险。
因此,自主可控和国产化替代迫在眉睫。
在这个体系和背景下,全链路的打通,软硬件的结合都是重要的环节。搜索产品作为一款软件,也要在国产化适配以及兼容性上都要做到更好。
Scope可以满足各类硬件环境需求以及信创需求,对国内主流服务器架构以及操作系统深度适配,并且支持混合架构部署,允许不同配置、不同架构、不同操作系统的机器在同⼀集群中部署和使用,充分利用集群资源。
除此之外,Scope还为用户提供了企业级安全保障,从以下3个维度全方位保护用户数据的安全:
Scope提供PB级海量数据的交互式多维检索分析服务,单实例可突破至百TB的数据存储,是Elasticsearch 的 5 倍以上,大大降低用户硬件成本。数据批量写入速度相对 Elasticsearch 提升 40%。相对于Elasticsearch, Scope 具有很强的容灾和数据恢复能力,重启恢复时间在 TB 级数据量下控制在分钟级,不到Elasticsearch 的 1/10。
除此之外,在满足了用户各类检索需求(日志检索、全文检索等)的同时也提供了更好的产品服务。
为实现更好的集群稳定性,Scope在分布式层对原有架构进行重构,将共识算法传统的流言传播模式goosip转变为Raft的架构。通过架构的优化,数据的同步逻辑也从过去的最终一致性转变为强一致性。从下图可以看出两类算法的差异。
原有goosip架构更偏向于主节点数据写入完成后,返回请求成功的响应,然后在内部做数据同步,最终达到所有节点数据一致的情况,即最终一致性。在该模型下,对于常规的日志等低价值信息比较友好,若存储高价值或不允许丢失的信息,将存在一定风险。例如,当集群中node1节点与集群网络连接断开,其他节点会重新组成集群,选举主节点。但是若node1节点数据并未及时同步,客户层面感知将会是数据丢失,因为其新写入数据在未同步的节点中不存在。同时,当node1恢复连接后加入集群,会因其不是主节点而反向同步其他节点,最终数据彻底丢失。
Scope选择升级Raft架构作为一致性协议,其对于数据同步、写入成功等请求,是在多数节点写入后返回。即使集群中某一节点出现上述失联问题,数据依旧可以被检索到,杜绝数据完全丢失。对于Scope的管理节点,同样采用Raft模式,可以有效地规避集群脑裂,也降低了大规模集群稳定性问题的出现。
Scope采用类bulkload的写入模式,有效降低读写混合场景对产品带来的压力。在bulkload的写入模式下,写入操作被拆分成两个步骤:首先是数据加工,生成数据库所需的数据格式;其次为数据加载,将生成的文件置于存储目录,使得检索引擎可以读取加载到该数据。一般来说,前者在cpu、内存中开销占比更大,它涉及索引的生成、数据的加工等一系列逻辑;而后者,则以数据传输过程的网络/磁盘开销为主并夹带少量的cpu开销,这部分网络/磁盘的开销对比当前主流的集群配置是可控和低占比的。
根据上述逻辑,将两步骤别放于不同集群或不同的服务器中执行,可以有效降低Scope集群的写入压力,提供更多的资源用于检索,实现一套读写分离的架构。同时,bulkload的写入模式同样适配实时流处理引擎slipstream中。在实时的写入时,实现降低Scope集群开销的效果。
Scope在存储方面做了大量的优化工作,在此着重描述3个典型优化点,分别为冷热数据分层、降低数据膨胀与堆外内存技术。
首先,Scope提供数据标签机制,并以此实现冷热数据分层。支持对节点/磁盘/以及索引数据进行标签化处理。对于分区表或者使用频率不同的表,可以通过标签机制加以区分和存储,实现热数据热存储,冷数据冷存储的效果。同时支持标签的随时更改,实现数据冷热的高效切换。
其次,Scope通过AutoMerge与索引机构优化实现降低数据膨胀。多数搜索引擎为提升检索的性能,选择牺牲存储能力或生成大量索引数据的方式。对比传统数据库或hdfs类大数据存储产品,存储开销会变得很大。Scope提供索引的AutoMerge机制,对于琐碎的索引文件进行自动合并,也进一步对原始的数据文件进行存储结构上的压缩和优化,可以有效降低数据的膨胀系数。
同时,Scope使用Search的off-heap机制,并对该机制进行持续性的优化,将原本堆内存储的部分索引的持久化内容放于堆外。一方面降低堆的使用开销,留出更多资源满足读写需求,另一方面,单机数据量---生成的索引数据数据量---内存可加载的索引数据,三者为正相关的关系,任何一者达到上限意味着节点容量达到上限,而内存往往是最先掣肘的一个因素。对此,Scope将持久化部分放到堆外,意味着可以有更多的数据被加载进来,从而有效地提升了产品的单机容量。
通过上述三个及其他种种技术优化,使得Scope在实际的生产环境中,索引数据的磁盘开销同比降低13%,单机存储规模从ES的5-20TB到达现有的50TB,在部分场景中甚至可以到达100+TB。
Scope借助星环SQL处理引擎Quark,以及自身的生态适配器Adapter,可以实现完备的数据流转方案。一方面,Scope通过Adapter实现了ES接口的对齐,确保用户可以像使用ES⼀样操作Scope产品。在ES的替换和迁移时,降低用户学习新的数据库接口和重新开发的工作压力。Scope通过Adapter可以很好规避这⼀问题,同时对于分词器之类的插件,以及logstash/beats类组件,Scope同样支持和兼容。
另一方面,Scope基于统一的Quark引擎提供了完整的SQL语法支持并实现了Scope SQL(搜索语法的SQL扩展),基于标准SQL、检索语义,可以覆盖大部分检索和入库的请求,实现跨存储的数据流通。
也就是说,用户可以将TDH跑批加工的数据,入库到Scope中提供检索业务。通过和quark SQL优化器的深度整合,优化数据搜索的执行过程,进一步提供了更好的性能。
Scope基于Quark还支持外表映射的操作,实现一份数据可以通过SQL或API的方式进行处理,开发者无需了解底层架构就可以开发出高效的搜索引擎,实现在PB数据量级上的秒级全文搜索。
Transwarp Scope聚焦于Elasticsearch检索场景平替,高度兼容Elasticsearch接口,可实现Elasticsearch业务的平滑迁移,如日志检索、全文检索以及数据智能等场景,并在产品稳定性、扩展性、高性能、高可用、成本等方面具有明显的优势。
某运营商有基于Hbase的主键精确查询和基于Elasticsearch的全景查询2套业务。在全景查询场景中,客户采用实时和离线2套集群,数据流转复杂,并且随着数据量的高速增长,系统稳定性经常出现问题。当集群出现问题时,Elasticsearch重启需要小时级别,集群恢复速度慢。在性能问题方面,读写资源无法隔离,拖累查询性能。
因此,该用户利用星环科技分布式搜索引擎Transwarp Scope替换掉了Elasticsearch,实现了实时和离线业务的统一,通过bulkload和实时流计算引擎Slipstream实现了数据的统一存储和查询。
入库方面,过去15+TB的日增离线数据可以快速加载到Scope当中,省去了两套Elasticsearch集群的快照同步环节,入库性能提升4倍。过去T+1模式入库逻辑直接通过微批的方式实现了分钟级延迟,集群的重启时间从6-10小时压缩到了分钟级,大幅度降低了业务中断时间。集群规模上,将过去两套Elasticsearch集群整合成统一的大集群,并且保障100+节点稳定运行,系统架构更加简单,运维成本更低。
下一章节将为您介绍如何安装与部署,以及使用示例。
友情链接
搜索引擎数据库是一类专门用于数据内容搜索的NoSQL数据库,是非结构化大数据处理分析领域中重要的基础支撑软件。
伴随互联网、移动互联网、物联网、5G等信息通信技术及产业的发展,全球数据量呈现爆发式增长的趋势。根据IDC数据显示,到2028 年,全球数据圈(global datasphere)预计将增长到 400 ZB,非结构化数据成为全球数据量的主要来源。
非结构化数据指的是无法以预定义格式存储或适合现有数据模型的数据,比如图像、视频、音频、用户行为等等。数据结构复杂,不方便用传统的数据库二维逻辑来表现,但其中却蕴含着丰富的数据价值,因此如何高效地处理分析非结构化数据是数据库领域面临的机遇和挑战。
在这样的时代背景下,搜索引擎数据库逐渐被人们所熟知,它可以使用索引对数据中的相似特征进行归类,提供快速准确的数据检索服务。通过对索引和检索过程的优化,可以处理大量文本、半结构化或非结构化的数据。
搜索引擎数据库的应用十分广泛。
诞生的初期,搜索引擎数据库主要是为了解决关系型数据库中长文本检索效率低下的问题,所以又称为全文数据库、非结构化数据库等等。随着技术的发展,目前衍生出了多种处理不同类型来源数据的检索引擎并集成在不同的数据库中。例如除了长文本数据、常见的数值、日期之外,还可以处理各种各样的非结构化数据,例如 IP、地理位置信息、图片、音视频等等。
凭借在数据查询效率方面的优势,搜索引擎数据库在数据处理方面的地位越来越高,并在应用程序搜索、网站搜索、企业搜索、智能问答、图像与语音搜索、语义搜索、业务分析和安全分析等方面有着广泛的应用。
更多搜索引擎数据库的背景介绍以及所涉及的技术点剖析可点击下方对应链接进行查看:
Scope是星环自研的搜索软件,除了保留底层的lucene框架和工具层外,上层进行了全自主研发改造,扬弃了开源产品中的那些带来瓶颈和限制的模型,用更贴合海量数据大集群场景的模型来代替,打造出了自主可控的搜索引擎产品。
文档数据库
日志分析与监控
舆情分析
搜索引擎
一直以来,我国的上游核心技术频繁的遭遇“卡脖子”,严重影响了我国关键科技和产业的发展。在过去几年内, Elasticsearch 数据泄露事件频发,安全风险加剧。数据泄露事件频发给国内各行业用户敲响了数据安全的警钟。同时,ES在2021年更改了其开源协议,对其产品的许可协议增加了限制,也带来了更多的商业风险。
因此,自主可控和国产化替代迫在眉睫。
在这个体系和背景下,全链路的打通,软硬件的结合都是重要的环节。搜索产品作为一款软件,也要在国产化适配以及兼容性上都要做到更好。
Scope可以满足各类硬件环境需求以及信创需求,对国内主流服务器架构以及操作系统深度适配,并且支持混合架构部署,允许不同配置、不同架构、不同操作系统的机器在同⼀集群中部署和使用,充分利用集群资源。
除此之外,Scope还为用户提供了企业级安全保障,从以下3个维度全方位保护用户数据的安全:
Scope提供PB级海量数据的交互式多维检索分析服务,单实例可突破至百TB的数据存储,是Elasticsearch 的 5 倍以上,大大降低用户硬件成本。数据批量写入速度相对 Elasticsearch 提升 40%。相对于Elasticsearch, Scope 具有很强的容灾和数据恢复能力,重启恢复时间在 TB 级数据量下控制在分钟级,不到Elasticsearch 的 1/10。
除此之外,在满足了用户各类检索需求(日志检索、全文检索等)的同时也提供了更好的产品服务。
为实现更好的集群稳定性,Scope在分布式层对原有架构进行重构,将共识算法传统的流言传播模式goosip转变为Raft的架构。通过架构的优化,数据的同步逻辑也从过去的最终一致性转变为强一致性。从下图可以看出两类算法的差异。
原有goosip架构更偏向于主节点数据写入完成后,返回请求成功的响应,然后在内部做数据同步,最终达到所有节点数据一致的情况,即最终一致性。在该模型下,对于常规的日志等低价值信息比较友好,若存储高价值或不允许丢失的信息,将存在一定风险。例如,当集群中node1节点与集群网络连接断开,其他节点会重新组成集群,选举主节点。但是若node1节点数据并未及时同步,客户层面感知将会是数据丢失,因为其新写入数据在未同步的节点中不存在。同时,当node1恢复连接后加入集群,会因其不是主节点而反向同步其他节点,最终数据彻底丢失。
Scope选择升级Raft架构作为一致性协议,其对于数据同步、写入成功等请求,是在多数节点写入后返回。即使集群中某一节点出现上述失联问题,数据依旧可以被检索到,杜绝数据完全丢失。对于Scope的管理节点,同样采用Raft模式,可以有效地规避集群脑裂,也降低了大规模集群稳定性问题的出现。
Scope采用类bulkload的写入模式,有效降低读写混合场景对产品带来的压力。在bulkload的写入模式下,写入操作被拆分成两个步骤:首先是数据加工,生成数据库所需的数据格式;其次为数据加载,将生成的文件置于存储目录,使得检索引擎可以读取加载到该数据。一般来说,前者在cpu、内存中开销占比更大,它涉及索引的生成、数据的加工等一系列逻辑;而后者,则以数据传输过程的网络/磁盘开销为主并夹带少量的cpu开销,这部分网络/磁盘的开销对比当前主流的集群配置是可控和低占比的。
根据上述逻辑,将两步骤别放于不同集群或不同的服务器中执行,可以有效降低Scope集群的写入压力,提供更多的资源用于检索,实现一套读写分离的架构。同时,bulkload的写入模式同样适配实时流处理引擎slipstream中。在实时的写入时,实现降低Scope集群开销的效果。
Scope在存储方面做了大量的优化工作,在此着重描述3个典型优化点,分别为冷热数据分层、降低数据膨胀与堆外内存技术。
首先,Scope提供数据标签机制,并以此实现冷热数据分层。支持对节点/磁盘/以及索引数据进行标签化处理。对于分区表或者使用频率不同的表,可以通过标签机制加以区分和存储,实现热数据热存储,冷数据冷存储的效果。同时支持标签的随时更改,实现数据冷热的高效切换。
其次,Scope通过AutoMerge与索引机构优化实现降低数据膨胀。多数搜索引擎为提升检索的性能,选择牺牲存储能力或生成大量索引数据的方式。对比传统数据库或hdfs类大数据存储产品,存储开销会变得很大。Scope提供索引的AutoMerge机制,对于琐碎的索引文件进行自动合并,也进一步对原始的数据文件进行存储结构上的压缩和优化,可以有效降低数据的膨胀系数。
同时,Scope使用Search的off-heap机制,并对该机制进行持续性的优化,将原本堆内存储的部分索引的持久化内容放于堆外。一方面降低堆的使用开销,留出更多资源满足读写需求,另一方面,单机数据量---生成的索引数据数据量---内存可加载的索引数据,三者为正相关的关系,任何一者达到上限意味着节点容量达到上限,而内存往往是最先掣肘的一个因素。对此,Scope将持久化部分放到堆外,意味着可以有更多的数据被加载进来,从而有效地提升了产品的单机容量。
通过上述三个及其他种种技术优化,使得Scope在实际的生产环境中,索引数据的磁盘开销同比降低13%,单机存储规模从ES的5-20TB到达现有的50TB,在部分场景中甚至可以到达100+TB。
Scope借助星环SQL处理引擎Quark,以及自身的生态适配器Adapter,可以实现完备的数据流转方案。一方面,Scope通过Adapter实现了ES接口的对齐,确保用户可以像使用ES⼀样操作Scope产品。在ES的替换和迁移时,降低用户学习新的数据库接口和重新开发的工作压力。Scope通过Adapter可以很好规避这⼀问题,同时对于分词器之类的插件,以及logstash/beats类组件,Scope同样支持和兼容。
另一方面,Scope基于统一的Quark引擎提供了完整的SQL语法支持并实现了Scope SQL(搜索语法的SQL扩展),基于标准SQL、检索语义,可以覆盖大部分检索和入库的请求,实现跨存储的数据流通。
也就是说,用户可以将TDH跑批加工的数据,入库到Scope中提供检索业务。通过和quark SQL优化器的深度整合,优化数据搜索的执行过程,进一步提供了更好的性能。
Scope基于Quark还支持外表映射的操作,实现一份数据可以通过SQL或API的方式进行处理,开发者无需了解底层架构就可以开发出高效的搜索引擎,实现在PB数据量级上的秒级全文搜索。
Transwarp Scope聚焦于Elasticsearch检索场景平替,高度兼容Elasticsearch接口,可实现Elasticsearch业务的平滑迁移,如日志检索、全文检索以及数据智能等场景,并在产品稳定性、扩展性、高性能、高可用、成本等方面具有明显的优势。
某运营商有基于Hbase的主键精确查询和基于Elasticsearch的全景查询2套业务。在全景查询场景中,客户采用实时和离线2套集群,数据流转复杂,并且随着数据量的高速增长,系统稳定性经常出现问题。当集群出现问题时,Elasticsearch重启需要小时级别,集群恢复速度慢。在性能问题方面,读写资源无法隔离,拖累查询性能。
因此,该用户利用星环科技分布式搜索引擎Transwarp Scope替换掉了Elasticsearch,实现了实时和离线业务的统一,通过bulkload和实时流计算引擎Slipstream实现了数据的统一存储和查询。
入库方面,过去15+TB的日增离线数据可以快速加载到Scope当中,省去了两套Elasticsearch集群的快照同步环节,入库性能提升4倍。过去T+1模式入库逻辑直接通过微批的方式实现了分钟级延迟,集群的重启时间从6-10小时压缩到了分钟级,大幅度降低了业务中断时间。集群规模上,将过去两套Elasticsearch集群整合成统一的大集群,并且保障100+节点稳定运行,系统架构更加简单,运维成本更低。
下一章节将为您介绍如何安装与部署,以及使用示例。