es打怪升级之基础篇

ES-基础篇

前言

作为一名后端coder,mysql无疑是我们日常开发中最常用的数据库,作为一个款有着二十几年悠久历史的关系型数据库有着自己鲜明的特征,支持事务的ACID特性,支持表间join.这些特征使得mysql很适合事务类业务,例如订单业务.

然而如果我们换个场景，在复杂场景下的检索需求，mysql还适合这种业务吗？如果我们用mysql去实现复杂场景的搜索问题,那么就需要开发人员熟悉mysql的索引机制,
对于搜索字段建立二级索引,必要时候需要建立联合索引,了解最左匹配原则，但是即便是针对所有的检索字段建立了索引,同样也会面对各种性能问题,各种慢查询等等,还记得我们面试时候经常问的sql性能调优吗,需要了解各种索引建立的原则,更何况索引越多,也会影响到插入性能,如果稍微了解数据库原理的朋友都知道mysql的索引是基于B+树实现的,当数据量达到千万级别的时候,mysql的检索同样也会很慢,通常做法我们就要对数据库进行拆分,分库分表一些列操作,分库分表之后之前单库支持的join以及全局有序都不得不在业务中实现.真是应了那句话"查询容易，优化不易，且写且珍惜".

那么有没有一种新的数据存储模型，使得在这种复杂检索需求下同样也能保持稳定的搜索性能，同时支持横向扩展数据分片，实际上elasticsearch就是为了这种场景下应运而生的全文检索工具。

本文是es的基础篇,要向熟悉一个工具,最快的方式就是实践并使用它,所以本文主要立足于es的基础知识,使读者在阅读完本文之后能够直观的感受到es能做什么. 其中包括了es的核心概念,索引的设置,以及CURD操作，

基本概念

es是一个基于Lucene的全文搜索和分析系统,既然是一种数据搜索系统,那么肯定有自己的数据存储方式. 例如mysql将数据组织成一行行记录的形式.同样我们也需要了解es中数据逻辑上是如何存储的.
es中对数据存储有这几种概念: 索引(index),类型(type),文档(document),属性(field).

索引 index

es中数据在哪里存储呢?在mysql中如果我们要存储用户的注册信息,我们通常创建一个用户user表,这里的user表就是mysql的存储模结构,这里的user表就是mysql中数据容器,同样es中的数据存放在成为索引(index)的地方,在es中索引是具有相同业务特征的文档集合。使用索引名称唯一标识此索引,并且通过引用此名称完成对索引的增加、删除、更新以及查询操作。

类型 type

es中的type类型在es6.x之后已经不推荐使用了,在将来的版本中es会完全去掉type

文档 document

有了用户表信息，那么表中的每一行记录同样在es中也有相应的抽象，叫做document，至于为什么叫文档，我想这主要是由于es的每一个记录的数据模型决定的，在mysql中每一行记录是由每一列决定的,是有固定关系模式.而在es