近期网上流行一批新的搜索引擎，动不动就大言不惭，要跟龙头老大Elasticsearch比，想把Elasticsearch击败。
1. Typesense 太猖狂了，对Elasticsearch极为不敬
如近期炒作很猖狂的Typesense开源搜索引擎，一出来就急着挑战Elasticsearch，我们来看看它的嚣张之处到底在哪？
Typesense 50毫秒完成3200万条数据搜索，这款搜索引擎让ElasticSearch慌了
这算得上开源搜索界的一记重拳！
这回可把ElasticSearch打得措手不及了。
最近放出了一段视频，展示了一款名为Typesense的开源搜索引擎的恐怖威力：
我可以在不到50毫秒的时间内搜索3200万条记录。
这个速度简直疯了！
。。。。。。。
看到这里，不少开发者都惊呆了：
"这速度也太离谱了吧？我们的搜索怎么就这么慢呢？"
但是我想说的是：Typesense 就这？
2. Typesense 就这？？
Typesense 就这点性能就敢拿出来大言不惭，敢于挑战ES？也太嚣张了吧！！
3. 来看看Elasticsearch吧
ES要用好，确实是一门难能的技术。学习ES，从初学到深入，再到产品级的亿级数据量搜索调优实战，学习曲线是比较陡！！
3.1 什么是Lucene
很多ES爱好者们可能不太清楚这个玩意，其实ES的前身就是Lucene，ES就是基于Lucene（单机版）做出来的集群搜索！
Lucene 其实学习起来不难，只需要理解每个字段有三个配置属性，即index(是否创建索引，选择是后，还需要选择索引类型),tokenizer（是否分词，选择是后还需要选择分词器类型）,store（是否存储，若该值是否，index=true，表示不存在，但需要创建索引，用来搜索）即可。其它属性一般都是基于这三个的扩展，抓住主要的，再去做扩展学习就比较轻松！
其它不多说，本人也是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秒以内。
比如，你现在有一行数据：id，name，age … 30 个字段。但是你现在搜索，只需要根据 id，name，age 三个字段来搜索。如果你傻乎乎往 ES 里写入一行数据所有的字段，就会导致 90% 的数据无法用来搜索。
结果硬是占据了 ES 机器上的 Filesystem Cache 的空间，单条数据的数据量越大，就会导致 Filesystem Cahce 能缓存的数据就越少。
其实，仅仅写入 ES 中要用来检索的少数几个字段就可以了，比如写入 es id，name，age 三个字段。
然后你将其他的字段数据存在 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 专注于轻量级、资源高效、易于使用、基于模式并针对简单搜索用例进行量身定制。
