英文字体设计网站,回收那个网站做推广好,wordpress插件问题,提高网站权重的作用近期网上流行一批新的搜索引擎#xff0c;动不动就大言不惭#xff0c;要跟龙头老大Elasticsearch比#xff0c;想把Elasticsearch击败。
1. Typesense 太猖狂了#xff0c;对Elasticsearch极为不敬
如近期炒作很猖狂的Typesense开源搜索引擎#xff0c;一出来就急着挑战…近期网上流行一批新的搜索引擎动不动就大言不惭要跟龙头老大Elasticsearch比想把Elasticsearch击败。
1. Typesense 太猖狂了对Elasticsearch极为不敬
如近期炒作很猖狂的Typesense开源搜索引擎一出来就急着挑战Elasticsearch我们来看看它的嚣张之处到底在哪
Typesense 50毫秒完成3200万条数据搜索这款搜索引擎让ElasticSearch慌了
这算得上开源搜索界的一记重拳这回可把ElasticSearch打得措手不及了。svpino最近放出了一段视频展示了一款名为Typesense的开源搜索引擎的恐怖威力我可以在不到50毫秒的时间内搜索3200万条记录。这个速度简直疯了。。。。。。。看到这里不少开发者都惊呆了
这速度也太离谱了吧我们的搜索怎么就这么慢呢但是我想说的是Typesense 就这
2. Typesense 就这
Typesense 就这点性能就敢拿出来大言不惭敢于挑战ES也太嚣张了吧
3. 来看看Elasticsearch吧
ES要用好确实是一门难能的技术。学习ES从初学到深入再到产品级的亿级数据量搜索调优实战学习曲线是比较陡
3.1 什么是Lucene
很多ES爱好者们可能不太清楚这个玩意其实ES的前身就是LuceneES就是基于Lucene单机版做出来的集群搜索
Lucene 其实学习起来不难只需要理解每个字段有三个配置属性即index(是否创建索引选择是后还需要选择索引类型),tokenizer是否分词选择是后还需要选择分词器类型,store是否存储若该值是否indextrue表示不存在但需要创建索引用来搜索即可。其它属性一般都是基于这三个的扩展抓住主要的再去做扩展学习就比较轻松
其它不多说本人也是ES的爱好者从2012年接触lucene开始通过一个具体项目实战就对lucene有了比较深的了解lucene当时用的4.0版本经过了数年的进化现在都已经9.0版本了当时就有上亿的IO跟踪记录用的lucene存放对某些字段创建了索引硬盘都是普通的机械盘内存只分配了2G搜索速度那叫一个快都是毫秒级返回几毫秒到几十毫秒很少超过100毫秒的
3.2 来看看ES吧
ES的数据量如果不是很大一般都没什么性能调整几百万千把万甚至几千万就无需做什么调优基本上保证内存适当大些查询都是毫秒级直接完败Typesense 。
只有上了亿级流量数据量了才有必要考虑对ES做一些性能调优
如下图是ES集群搜索单个节点的流程示意图从此图得知ES 的搜索引擎严重依赖于底层的 Filesystem Cache如果给 Filesystem Cache 更多的内存尽量让内存可以容纳所有的 IDX Segment File 索引数据文件那么你在搜索的时候基本都会走内存且性能会非常高。 **性能差距究竟可以有多大**我们之前很多的测试和压测如果走磁盘一般肯定上秒搜索性能绝对是秒级别的1 秒、5 秒、10 秒。但如果走 Filesystem Cache则是走纯内存的那么一般来说性能比走磁盘要高一个数量级基本上就是毫秒级的从几毫秒到几百毫秒不等。
3.3 ES亿级数据调优实战
真实场景
某个公司 ES 节点有 3 台机器每台机器看起来内存很多64G总内存就是 64 * 3 192G。
每台机器给 ES JVM Heap 是 32G那么剩下来留给 Filesystem Cache 的就是每台机器才 32G总共集群里给 Filesystem Cache 的就是 32 * 3 96G 内存。
而此时整个磁盘上索引数据文件在 3 台机器上一共占用了 1T 的磁盘容量ES 数据量是 1T那么每台机器的数据量是 300G。这样性能好吗
场景分析
Filesystem Cache 的内存才 100G十分之一的数据可以放内存其它的都在磁盘然后你执行搜索操作大部分操作都是走磁盘性能肯定差。
优化方案
根据我们自己的生产环境实践经验最佳的情况下是仅仅在 ES 中就存少量的数据就是你要用来搜索的那些索引如果内存留给 Filesystem Cache 的是 100G那么你就将索引数据控制在 100G 以内即可。这样你的数据几乎全部走内存来搜索性能非常之高一般可以在1秒以内。
比如你现在有一行数据idnameage … 30 个字段。但是你现在搜索只需要根据 idnameage 三个字段来搜索。如果你傻乎乎往 ES 里写入一行数据所有的字段就会导致 90% 的数据无法用来搜索。
结果硬是占据了 ES 机器上的 Filesystem Cache 的空间单条数据的数据量越大就会导致 Filesystem Cahce 能缓存的数据就越少。
其实仅仅写入 ES 中要用来检索的少数几个字段就可以了比如写入 es idnameage 三个字段。
然后你将其他的字段数据存在 MySQL/HBase 里我们一般是建议用 ES HBase 这个架构。
HBase 的特点是适用于海量数据的在线存储就是对 HBase 可以写入海量数据但是不要做复杂的搜索做很简单的一些根据 id 或者范围进行查询的操作就可以了。
从 ES 中根据 name 和 age 去搜索拿到的结果可能就 20 个 doc id然后根据 doc id 到 HBase 里去查询每个 doc id 对应的完整的数据查出来后再返回给前端。
**写入 ES 的数据最好小于等于或者是略微大于 ES 的 Filesystem Cache 的内存容量。**你从 ES 检索可能只花费 20ms然后再根据 ES 返回的 id 去 HBase 里查询查 20 条数据可能只耗费 30ms。
可能你原来那么玩儿1T 数据都放 ES会每次查询都是 5~10s现在可能性能就会很高每次查询就是 50ms。
4. Elasticsearch 的未来及其对搜索引擎行业的影响
Elasticsearch 是一个开源搜索引擎和分析平台近年来越来越受欢迎。凭借其近乎实时地索引和搜索大量数据的能力Elasticsearch 已成为许多企业和组织的首选解决方案。随着技术的不断发展Elasticsearch 的未来一片光明它对搜索引擎行业的影响预计将是巨大的。
推动 Elasticsearch 未来发展的关键趋势之一是大数据的持续增长。随着越来越多的数据生成组织正在寻找实时处理和分析数据的方法。Elasticsearch 提供了一种解决方案使组织能够快速搜索、分析和可视化大量数据。这将继续推动 Elasticsearch 的采用并可能导致开发新的用例。
塑造 Elasticsearch 未来的另一个趋势是云的增长。随着云计算的日益普及组织正在寻找将其数据和应用程序迁移到云的方法。Elasticsearch 提供了一种可以轻松部署在云中的云原生解决方案使其成为许多组织的有吸引力的选择。
人工智能 (AI) 和机器学习 (ML) 也有望在 Elasticsearch 的未来中发挥重要作用。凭借索引和搜索大量数据的能力Elasticsearch 为构建 AI 和 ML 应用程序提供了一个宝贵的平台。例如Elasticsearch 可用于构建推荐系统、预测模型等。
Elasticsearch 的未来也可能受到边缘计算增长的影响。随着设备和传感器数量的增加组织正在寻找在靠近源头的边缘处理数据的方法。Elasticsearch 为此提供了解决方案使组织能够在边缘索引和搜索数据从而减少延迟并提高性能。
Elasticsearch 现在在做什么
Elasticsearch 在数据库领域以多种有趣的方式颠覆了传统数据库。由于 Elasticsearch 并非旨在成为应用程序的主要数据库如 MySQL 或 MongoDB因此它具有更大的扩展灵活性这是典型数据库产品无法做到的。Elastic 似乎正在采用“广泛”增长模式来扩大其用户群并创新 Elastic 堆栈。他们创建了Elasticsearch 有价值的其他用例并开始蚕食其他数据库技术的市场份额。他们扫荡了 MongoDB、MySQL 和其他解决方案未能关注的所有边缘领域。
5. Elasticsearch 与 Typesense有什么区别
Elasticsearch 和 Typesense 都是非常流行的搜索和数据检索解决方案。让我们来探讨一下它们之间的主要区别。
5.1 可扩展性
Elasticsearch 的设计具有高度可扩展性可通过向集群添加更多节点来实现水平扩展。它可以处理大量数据并在需要时扩展到数千台服务器。另一方面Typesense 构建为轻量级并针对低资源消耗进行了优化。它是小型部署或资源效率优先考虑时的理想选择。
5.2 查询
Elasticsearch 提供强大而灵活的查询 DSL领域特定语言允许进行复杂的查询和聚合。它还高效地支持全文搜索、过滤和排序。另一方面Typesense 提供了简化的查询语法使其更易于使用和理解。它针对简单的搜索用例进行了优化可能无法提供与 Elasticsearch 相同级别的灵活性。
5.3 无模式与基于模式
Elasticsearch 无模式这意味着它可以处理同一索引内不同结构的文档。这种灵活性在处理非结构化数据时非常有用。相比之下Typesense 采用基于模式的方法其中文档必须遵循预定义的模式。这可确保数据一致性和更高效的索引但在处理动态或不断发展的数据结构时可能会受到限制。
5.4 索引速度
Elasticsearch 针对快速索引数据进行了优化。它可以处理高写入负载并且可以近乎实时地索引数据。这使得它适合需要频繁更新索引的用例。Typesense 虽然也具有良好的索引性能但在高写入场景中可能不如 Elasticsearch 快。
5.5 内置功能
Elasticsearch 具有各种内置功能如地理位置搜索、语言分析器和对父子关系的支持。它还拥有强大的插件和集成生态系统。另一方面Typesense 专注于提供轻量级且易于使用的搜索引擎内置功能较少。它可能需要额外的定制或与外部库集成才能实现某些功能。
5.6 社区和采用
Elasticsearch 存在时间较长拥有较大的社区和用户群。它已被企业广泛采用并且拥有更成熟的生态系统。Typesense 作为市场上的新玩家社区可能较小可用资源也较少。
5.7 学习曲线
ElasticSearch是比较著名的搜索引擎您可能知道它是一种非常强大的工具但它也很复杂学习难度很高曲线陡峭。例如在内部部署 ElasticSearch 时您将面临高昂的生产操作开销需要处理超过 3000 个配置参数。
Typesense用 C 编写是 ElasticSearch 的一个更易于使用的替代品。社区将其描述为一个开源、快速、容错且易于使用的搜索引擎。
6. 总结
综上所述Elasticsearch 的未来前景光明预计其对搜索引擎行业的影响将是巨大的。凭借实时索引和搜索大量数据的能力Elasticsearch 完全有能力在大数据、云计算、人工智能和边缘计算的持续增长中发挥关键作用。现在采用 Elasticsearch 的公司将能够充分利用这些趋势并可能在未来几年获得巨大的收益。
总而言之Elasticsearch 提供可扩展性、强大的查询功能、无模式结构、快速索引、更广泛的内置功能和更大的社区。
另一方面Typesense 专注于轻量级、资源高效、易于使用、基于模式并针对简单搜索用例进行量身定制。
