ElasticSearch - basic concepts and comparison with mysql

Table of contents

1. Basic concepts of ElasticSearch

1.1. Document

1.2. Index

1.3. Mapping

2. Compare mysql

2.1. Concept comparison

2.2. Comparison of applicable scenarios

2.2.1. Does that mean that with es, it can completely replace our mysql?

2.2.2. What is the relationship between them?


1. Basic concepts of ElasticSearch


1.1. Document

Elasticsearch is oriented to document storage, which can be a piece of product data in the database or order data... These things will be serialized into json format and stored in es.

For example, the product table mentioned earlier contains data such as id, title, and price, which will eventually be serialized into json format and stored.

1.2. Index

An index is a collection of documents of the same type. This is equivalent to a table in MySQL, and the document is each row of data in the table.

1.3. Mapping

The mapping here is the constraints on the document fields, such as what is your field name and whether the data type is a string or a number. This is similar to the constraints in mysql.

Ps: So it is not difficult for us to see that there are some similarities between the concept of es and mysql. Let’s compare them below.

2. Compare mysql


2.1. Concept comparison

Let’s look at the data. The first column is mysql and the second column is es.

  • Table => Index: An index is a collection of documents, similar to a table in a database.
  • Row => Document: A document is a piece of data, similar to each row of data in a database, but the format of the document is json format.
  • Column => Field: Field is the field in the json document, similar to the column in the database.
  • Constraints => Mapping: Mapping is a constraint on the documents in the index, such as a field type constraint (data type). Similar to the table structure in a database.
  • SQL => DSL: DSL is a json-style request statement provided in es, which is used to operate es and implement CRUD.

2.2. Comparison of applicable scenarios

2.2.1. Does that mean that with es, it can completely replace our mysql?

It's not possible, because the two of them are good at different things~~

  • mysql: It is better at transaction operations. Transactions include atomicity, durability, consistency, and isolation, so it can ensure data security, persistent storage, and data consistency. 
  • es: There is no concept of transactions in es. It is better at data search, analysis and operations.

For example, if you want to do a business such as placing orders and paying, the requirements for transactions are very high, so you should use mysql for storage; if you first do a product search or page search, this kind of search is more complicated ( For example, if the user searches for all relevant information through keywords), then he needs to use es to do it.

2.2.2. What is the relationship between them?

They have a complementary relationship in the system architecture. For example, if our user searches for a product order, because es has a stronger search capability, we use es to search here. This also means that there must be data on es. , then how to ensure that there is data on both sides? Generally, writing data is written in mysql (for data security and persistence, mysql is used to store all data), and mysql will also synchronize the data to es, thereby realizing double writing of data . In the future, that is A complementary effect.

 

Guess you like

Origin blog.csdn.net/CYK_byte/article/details/133214045