经常使用误区之将 Elasticsearch Elasticsearch 视为相关数据库！

Elasticsearch 是一个弱小的工具，尤其在全文检索、实时剖析、机器学习、天文数据运行、日志和事情数据剖析、安保消息和事情治理等场景有少量的运行。

但是，Elastic Stack 技术栈的选型及运行效劳取决于正确的经常使用方式。选型失误或许误用 Elasticsearch 或许会造成裁减性疑问、性能疑问（如为处置一个疑问经常使用十分复杂的脚本造成性能极差）等，从而使全体体验感变差。所以，本文区别于之前的正向解说的方式，更多的解说反例或许负面运行案例。“以史为鉴”，以便于大家更好地经常使用 Elasticsearch。

本系列文章会有 10 几篇左右，一篇一个常识点解说 Elasticsearch 经常使用误区解读，敬请等候！

误区1：将 Elasticsearch 视为相关数据库

Elasticsearch 常被曲解为 MySQL 或许 PostgreSQL 等相关数据库的间接代替品，用户除了间接代替经常使用外更看其全文搜查和极速聚合的才干。

但是，我们必定明晰的认知：Elasticsearch 设计初衷不是处置复杂事务和相关数据模型的。

我们从上方几个维度逐个倒退讨论：

1、该不该选型 Elasticsearch ？

团体倡导先了解 Elasticsearch 的实用场景以及不实用场景，这样能分明 Elastic Stack 技术栈更适宜哪些业务需求。

例如，我们文章之前图解的六大运行场景是十分适宜的。但是，关于须要处置复杂事务、多表联查操作和高分歧性要求的运行，如银行系统的买卖处置和ERP系统等，Elasticsearch 则不太适宜。

Elasticsearch 更实用场景：

经过对比这些场景，反观自己的业务需求，就能判别能否应该选型 Elasticsearch 甚至 Elastic Stack 作为技术栈。

2、了解 Elasticsearch 的设计

Elasticsearch 是一种面向文档的搜查引擎，专为极速搜查少量数据而设计。

Elasticsearch 基于Apache Lucene构建，提供了弱小的全文搜查、剖析和数据聚合配置。

以下是 Elasticsearch 的关键特点：

如前所述，Elasticsearch 并不是设计用来处置相关数据和事务的。它的关键长处在于剖析和搜查才干，而不是数据相关的严厉保养。

3、了解 Elasticsearch 与相关数据库的比拟

相关数据库（如 MySQL、Oracle 及 PostgreSQL 等）和 Elasticsearch 之间有几个关键区别：

3.1 数据模型比拟

3.2 查问才干比拟

在相关数据库中，我们可以经常使用复杂的 SQL 查问、事务和多表关联操作来保证数据的分歧性和完整性。例如：

BEGIN TRANSACTION;-- 降级订单形态UPDATE ordersSET status = 'shipped'WHERE order_id = 123;-- 缩小库存UPDATE productsSET stock = stock - 1WHERE product_id = 456;-- 记载客户优惠INSERT INTO customer_activity (customer_id, activity)VALUES (789, 'Order 123 shipped');COMMIT;

上述事务示例能确保一切相关操作（降级订单形态、缩小库存和记载客户优惠）要么所有成功，要么所有失败，从而保证数据的分歧性（事务的实质）。

在 Elasticsearch 中，我们关键并重于全文搜查和数据聚合剖析，而不允许复杂的事务和多表关联操作。

比如：用户需求如下：

“想求教下大佬们，假定 es 中 有两个表，一个会员表，一个订单表，假构想关联查问，例如查问24年注册的一切的会员的订单总数，经过什么方式能极速查问？”

我们文章做过火析，Elasticsearch 不是一丁点也不允许多表关联，只是允许的力度有限，允许的方式外围有如下几种：