网站title如何修改,网站建设用什么软件有哪些,高端玩家,一个网站可以做多个描述吗hbase和es的选取 hbase与es结合
背景介绍
HBase与ElasticSearch是现代应用在处理海量数据的技术架构会经常被使用的两款产品#xff0c;其中HBase是一个分布式KV系统#xff0c;具有灵活Schema、水平扩展、低成本、高并发的优势#xff0c;但在复杂查询、分析能力方面相对…hbase和es的选取 hbase与es结合
背景介绍
HBase与ElasticSearch是现代应用在处理海量数据的技术架构会经常被使用的两款产品其中HBase是一个分布式KV系统具有灵活Schema、水平扩展、低成本、高并发的优势但在复杂查询、分析能力方面相对比较弱特别适合海量半结构化、结构化数据的低成本存储和在线高并发查询。而ElasticSearch是一个分布式搜索引擎具有灵活Schema、水平扩展、检索快的优势但在成本、查询并发、一致性方面相对不足特别适合海量半结构化、结构化数据的复杂查询和全文检索。HBase与ElasticSearch两者有类似的灵活数据结构和分布式扩展性又有各自鲜明的特点一个擅长存一个擅长取为了取长补短所以业界会经常将两者结合使用把Elasticsearch作为HBase中部分字段的索引存储从而同时实现低成本存储高并发吞吐高效检索的效果典型场景如日志、监控、账单、用户画像等。
HBase与ES的组合使用
当应用决定组合使用HBaseES的时候核心要解决数据写入、数据查询这两个问题即数据如何准确写入到两个系统数据又如何从两个系统查询合并目前常见的方案有三种 应用双写双读应用需要同时与HBase、ElasticSearch独立交互其优点是不需要引入额外依赖应用可以根据自身需求定制或简化写入分发和查询合并的逻辑但缺点也比较多包括开发成本高、维护复杂、写入Latency增大、可用性下降、一致性解决困难等。数据自动复制应用双读应用在写入链路只与HBase交互在查询链路仍与两个系统交互其优点是写入过程对应用保持透明较容易保证最终一致性ES系统异常后也不会影响写入但缺点是需要额外开发维护一套数据同步服务应用查询数据的复杂性仍然较高利用触发器应用只读写HBase应用在读写链路只与HBase交互利用HBase Coprocessor功能在HBase表上挂载读写触发器其中写触发器负责数据写入HBase的同时自动往ElasticSearch写入读触发器负责解析Scan语句中的查询表达自动根据存储在ElasticSearch的索引字段进行加速并与HBase中查询到的整行数据进行合并后返回给客户端。所以总的来说这套方案的优点是应用的读写逻辑比较简单只需要和HBase交互但其缺点是其开发非常复杂需要对HBase及其Coprocessor功能有深入理解开发足够健壮的读写触发器并将复杂多条件查询和数据检索的需求嵌入到HBase的查询框架中。同时一致性、可用性、写入Latency这几个问题也依然存在。 通过上述三个方案的介绍我们可以发现HBaseElasticsearch的组合使用过程中会碰到以下几个痛点 开发维护成本巨大需要开发和维护数据实时同步、数据查询合并、索引字段增删管理、历史数据索引构建等多个能力这依赖于开发者对HBase和ES系统的深入掌握否则很容易造成数据错误。数据一致性弱由于数据写入ES后无法立即可见并且HBase到ES之间的异步数据复制所以会造成应用侧的数据不一致性导致出现数据从HBase可以查到但从ES查不到的现象。部署成本高昂HBase与Elasticsearch都是分布式架构但前者使用存储计算分离架构后者使用存储计算耦合架构使得两个系统间的资源无法共享复用碎片化浪费加大。可用性和吞吐下降由于HBase的并发吞吐能力远大于Elasticsearch对于数据串行写HBase、Elasticsearch两个系统的方案会导致写入延迟上升吞吐下降到ES水平并且可用性也随之下降。部分功能失效或衰退数据生命管理周期TTL是一个HBase与ES都具备的常用功能但两者对其执行有一定的差异化会导致部分数据在一个系统中已经过期淘汰但在另一个系统还保留着的间歇性现象。多版本是HBase中的常用功能可以还原乱序写入数据的顺序性但Elasticsearch并不支持所以两者组合后就无法继续使用该功能否则会出现不可预测的奇怪现象。非Java开发者使用困难两个系统的服务端都是使用Java开发上述方案二和方案三中的数据同步组件和触发器都需要Java开发对非Java开发者并不友好。
Lindorm Searchindex介绍 除了HBaseElasticsearch的组合Elasticsearch与MySQL、MongoDB、Cassandra等系统的组合也经常被用在各个业务场景中这种数据库搜索引擎的多套系统组合方案普遍具有类似的开发维护复杂、成本高昂、一致性弱等痛点。基于此情况阿里云数据库Lindorm着力打造了企业级特性Searchindex帮助用户更加简单、高效、低成本地应对海量数据的存储检索需求。 云原生多模数据库 Lindorm 是一个适用于任何规模、多种模型的数据库服务平台支持海量多样化数据的低成本、实时在线的存储检索分析提供宽表、时序、搜索、文件等多种数据模型兼容HBase/Cassandra、OpenTSDB、Solr、SQL、HDFS等多种开源接口是互联网、IoT、车联网、广告、社交、监控、游戏、风控等场景首选数据库也是为阿里巴巴核心业务提供支撑的数据库之一。 Searchindex是Lindorm宽表提供的一种新型索引用户只需简单的SQL语句即可管理索引的增删和构建数据读写也可以使用统一的SQL访问在使用体验上与传统数据库的二级索引一致但其具备强大的全文索引和复杂条件查询能力这背后是因为相关索引数据由基于Lucene的分布式搜索引擎LindormSearch管理通过倒排索引、BKD-Tree、Bitmap等数据结构大幅提升海量数据的筛选速度。 让我们看一个具体的使用例子 原始表 CREATE TABLE myTable (id bigint,name text,age int,sex text,city textaddress text,PRIMARY KEY (id)) ;需求对 姓名(name)、年龄(age)、性别(sex)、城市(city)、地址(address) 建立全文索引 CREATE SEARCH INDEX myIndex ON myTable WITH COLUMNS (name, age, sex, city, address); 注意索引列的先后顺序不影响即索引列(c3, c2, c1)与索引列(c1, c2, c3)最终的效果是一致的。 查询 标准查询语句模糊查询SELECT * FROM myTable WHERE name LIKE ‘小%’ 多维查询排序SELECT * FROM myTable WHERE city‘杭州’ AND age18 ORDER BY age ASC 多维查询翻页SELECT * FROM myTable WHERE name‘小刘’ AND sexfalse OFFSET 100 LIMIT 10 ORDER BY age DESC高级查询语句多维查询排序SELECT * FROM myTable WHERE search_query’city:杭州 age:[18 TO *] ORDER BY age ASC’文本检索SELECT * FROM myTable WHERE search_query‘address:西湖区’从上面的例子可以看到用户只要了解基本SQL无需开发即可使用Lindorm Searchindex。通过该特性可以完全解决HBaseElasticsearch组合使用遇到的难题具体来说有如下优势简单易用作为一个数据库特性开箱即用索引增删、索引构建、存储优化等全部通过SQL命令控制无需额外的开发和维护。统一SQL访问数据的读写都通过SQL进行并且服务端会自动选择最合适的索引加速查询。数据多一致相比于Elasticsearch的数据写入后无法实时可见的缺点LindormSearch支持数据写入后立即可见所以Lindorm Searchindex提供强一致和最终一致两种模式低成本表的原始数据和索引数据共享存储大幅减少资源碎片 功能完整TTL、多版本等核心功能可以在Searchindex中继续正常使用支持多种开发语言应用可以通过Java、C、Python、Go等主流开发语言使用该特性
总结
面对海量数据的低成本存储高效检索的需求业界通常使用HBaseElasticSearch的组合方案但该方案存在开发维护复杂、数据一致性弱、部署成本高、原功能失效等难题其他常见的MySQL/MongoDB/Cassandra的组合使用也有类似的痛点。基于此情况阿里云数据库Lindorm着力打造了企业级特性Searchindex可以完美解决HBaseElasticSearch组合使用遇到的难题帮助用户更加简单、高效、低成本地应对海量数据的存储检索需求。
