在没有前后端分离概念之前，一个网站的完成总是“all in one”，在这个阶段，页面、数据、渲染全部在服务端完成，这样做的最大的弊端是后期维护， 扩展极其痛苦，开发人员必须同时具备前后端知识。于是后来慢慢的兴起了前后端分离的思想：即后端负责数据编造，而前端则负责数据渲染，前端静态页面调用指定api获取到有固定格式的数据，再将数据展示出来，这样呈现给用户的就是一个”动态“的过程。而关于api这部分的设计则成了一个问题。如何设计出一个便于理解，容易使用的api则成了一个问题，而所谓的RESTful就是用来规范我们的API的一种约束。
作为REST，其实是Representational State Transfer（表象层状态转变）三个单词的缩写，它由Roy Fielding(Fielding是HTTP协议1.0版和1.1版）的主要设计者、Apache服务器软件的作者之一、Apache基金会的第一任主席) 于2000年论文中提出，他在论文中提到："我这篇文章的写作目的，就是想在符合架构原理的前提下，理解和评估以网络为基础的应用软件的架构设计，得到一个功能强、性能好、适宜通信的架构。REST指的是一组架构约束条件和原则。"
如果一个架构符合REST的约束条件和原则，我们就称它为RESTful架构。要理解RESTful架构，最好的方法就是去理解Representational State Transfer这个词组到底是什么意思，它的每一个词代表了什么涵义。如果你把这个名称搞懂了，也就不难体会REST是一种什么样的设计。
REST的名称"表现层状态转化"中，省略了主语。"表现层"其实指的是"资源"（Resources）的"表现层"。 所谓"资源"，就是网络上的一个实体，或者说是网络上的一个具体信息。它可以是一段文本、一张图片、一首歌曲、一种服务，总之就是一个具体的实在。要让一个资源可以被识别，需要有个唯一标识，在Web中这个唯一标识就是URI(Uniform Resource Identifier)。URI既可以看成是资源的地址，也可以看成是资源的名称。如果某些信息没有使用URI来表示，那它就不能算是一个资源，只能算是资源的一些信息而已。
你可以用一个URI（统一资源定位符）指向它，每种资源对应一个特定的URI。要获取这个资源，访问它的URI就可以，因此URI就成了每一个资源的地址或独一无二的识别符。所谓"上网"，就是与互联网上一系列的"资源"互动，调用它的URI。
曾经Web上的URI都是冰冷的数字或者无意义的字符串，但现在越来越多的网站使用_或-来分隔一些单词，让URI看上去更为人性化。例如国内比较出名的开源中国社区，它上面的新闻地址就采用这种风格， 如http://www.oschina.net/news/38119/oschina-translate-reward-plan。
例如上述/git/git/commit/e3af72cdafab5993d18fae056f87e1d675913d08就表示了一个多级的资源，指的是git用户的git项目的某次提交记录，又例如/orders/2012/10可以用来表示2012年10月的订单记录。
很多人只是把‘?’简单的当做是参数的传递，很容易造成URI过于复杂、难以理解。可以把‘?’用于对资源的过滤，例如/git/git/pulls用来表示git项目的所有推入请求，而/pulls?state=closed用来表示git项目中已经关闭的推入请求，这种URL通常对应的是一些特定条件的查询结果或算法运算结果。
有时候我们需要表示同级资源的关系时，可以使用,或;来进行分割。例如哪天github可以比较某个文件在随意两次提交记录之间的差异，或许可以使用：
/git/git/block-sha1/sha1.h/compare/e3af72cdafab5993d18fae056f87e1d675913d08;bd63e61bdf38e872d5215c07b264dcc16e4febca作为URI。不过，现在github是使用…来做这个事情的，例如/git/git/compare/master…next。
因为"资源"表示一种实体，所以应该是名词，URI不应该有动词，动词应该放在HTTP协议中。
举例来说，某个URI是/posts/show/1，其中show是动词，这个URI就设计错了，正确的写法应该是/posts/1，然后用GET方法表示show。
如果某些动作是HTTP动词表示不了的，你就应该把动作做成一种资源。比如网上汇款，从账户1向账户2汇款500元，错误的URI是：POST /accounts/1/transfer/500/to/2，正确的写法是把动词transfer改成名词transaction，资源不能是动词，但是可以是一种服务。
例如：
http://www.example.com/app/1.0/foo
http://www.example.com/app/1.1/foo
因为不同的版本，可以理解成同一种资源的不同表现形式，所以应该采用同一个URI。版本号可以在HTTP请求头信息的Accept 段中进行区分。
"资源"是一种信息实体，它可以有多种外在表现形式。我们把"资源"具体呈现出来的形式，叫做它的"表现层"Representation。比如，文本可以用txt格式表现，也可以用HTML格式、XML格式、JSON格式表现，甚至可以采用二进制格式；图片可以用JPG格式表现，也可以用PNG格式表现。
URI只代表资源的实体，不代表它的形式。严格地说，有些网址最后的".html"后缀名是不必要的，因为这个后缀名表示格式，属于"表现层"范畴，而URI应该只代表"资源"的位置。它的具体表现形式，应该在HTTP请求的头信息中用Accept和Content-Type字段指定，这两个字段才是对"表现层"的描述。
访问一个网站，就代表了客户端和服务器的一个互动过程。在这个过程中，势必涉及到数据和状态的变化。互联网通信协议HTTP协议，是一个无状态协议。这意味着，所有的状态都保存在服务器端。因此，如果客户端想要操作服务器，必须通过某种手段，让服务器端发生"状态转化"（State Transfer）。而这种转化是建立在表现层之上的，所以就是"表现层状态转化"。
客户端用到的手段，目前来说只能是HTTP协议。具体来说，就是HTTP协议里面，四个表示操作方式的动词：GET、POST、PUT、DELETE。它们分别对应四种基本操作：GET 用来获取资源，POST 用来新建资源（也可以用于更新资源），PUT用来更新资源，DELETE 用来删除资源。GET、PUT和DELETE 请求都是幂等的，无论对资源操作多少次，结果总是一样的，POST不是幂等的。
综合上面的解释，我们总结一下什么是RESTful架构：
注意：REST架构风格并不是绑定在HTTP上，只不过目前HTTP是唯一与REST相关的实例。所以我们这里描述的REST也是通过HTTP实现的REST。
RFC 3986中是这样说的：A Uniform Resource Identifier (URI) 是一个紧凑的字符串用来标示抽象或物理资源。 一个URI可以进一步被分为定位符、名字或两者都是，术语“Uniform Resource Locator” (URL)是URI的子集，除了确定一个资源,还提供一种定位该资源的主要访问机制。
所以，URI = Universal Resource Identifier 统一资源标志符，包含URL和URN，支持的协议有http、https、ftp、mailto、magnet、telnet、data、file、nfs、gopher、ldap等，java还大量使用了一些非标准的定制模式，如 rmi，jar、jndi和doc，来实现各种不同用途。
URL = Universal Resource Locator统一资源定位符，URL唯一地标识一个资源在Internet上的位置。不管用什么方法表示，只要能定位一个资源，就叫URL。
URN = Universal Resource Name统一资源名称，URN它命名资源但不指定如何定位资源，比如：只告诉你一个人的姓名，不告诉你这个人在哪。对于一个资源来说，URN好比他的名字，而RL好比是资源的街道住址。换句话说，URN 标识了一个资源项目，而 URL 则提供了一种找到他的方法。
比如同时指定基本的获取机制和网络位置。举个例子，http://example.org/wiki/Main_Page，指向了一个被识别为/wike/Main_Page的资源，这个资源的表现形式是HTML和相关的代码。而获取这个资源的方法是在网络中从一个名为example.org 的主机上，通过 HTTP( Hypertext Transfer Protocol)获得。
而URN则是一种在特定的名称空间中通过通过名字来标识资源的 URI。当讨论一种资源而不需要知道它的位置或者如何去获得它的时候，就可以使用 URN。例如，在 International Standard Book Number (ISBN)系统中，* ISBN 0-486-27557-4 用来指定莎士比亚的作品《罗密欧与朱丽叶》的一个特定版本。
指示这一版本的URN是urn:isbn:0-486-27557-4*，但是如果想要获得这个版本的书，就需要知道它的位置，这样就必须知道它的 URL。
官网的说法：Elasticsearch是一个开源的分布式RESTful搜索和分析引擎，能够解决越来越多不同的应用场景。看一个应用场景，常见的WEB应用日志分析。一般我们会怎么做？
登录到每台服务器上，直接在日志文件中grep、awk就可以获得自己想要的信息。但在规模较大的场景中，此方法效率低下，面临问题包括日志量太大如何归档、文本搜索太慢怎么办、如何多维度查询。这个时候我们希望集中化的日志管理，所有服务器上的日志收集汇总。常见解决思路是建立集中式日志收集系统，将所有节点上的日志统一收集，管理，访问。
这样对于大型系统来说，都是一个分布式部署的架构，不同的服务模块部署在不同的服务器上，问题出现时，大部分情况需要根据问题暴露的关键信息，定位到具体的服务器和服务模块，构建一套集中式日志系统，可以提高定位问题的效率。
一个完整的集中式日志系统，需要包含以下几个主要特点：
ELK就是这样一整套解决方案，并且都是开源软件，之间互相配合使用，完美衔接，高效的满足了很多场合的应用，而不仅仅是日志分析。
ELK是三个开源软件的缩写，分别表示：Elasticsearch、Logstash、Kibana，它们都是开源软件。
Elasticsearch是个开源分布式搜索引擎，提供搜集、分析、存储数据三大功能。
它的特点有：分布式，零配置，自动发现，索引自动分片，索引副本机制，restful风格接口，多数据源，自动搜索负载等。
Logstash主要是用来做日志的搜集、分析、过滤日志的工具，支持大量的数据获取方式。一般工作方式为c/s架构，client端安装在需要收集日志的主机上，server端负责将收到的各节点日志进行过滤、修改等操作在一并发往elasticsearch上去。
Kibana也是一个开源和免费的工具，Kibana可以为Logstash 和ElasticSearch 提供的日志分析友好的Web界面，可以帮助汇总、分析和搜索重要数据日志。
新增了一个Beats系列组件，它是一个轻量级的日志收集处理工具(Agent)，Beats占用资源少，适合于在各个服务器上搜集日志或信息后传输给Logstash。加入Beats系列组件后，官方名称就变为了Elastic Stack。
我们的运行环境为Linux，演示服务器操作系统版本情况如下：
elasticsearch-7.7.0-linux-x86_64.tar.gz
kibana-7.7.0-linux-x86_64.tar.gz
filebeat-7.7.0-linux-x86_64.tar.gz
logstash-7.7.0.tar.gz
因为Elastic Stack中主要组件都是用Java写的，所以操作系统上还应该安装好Java，因为本次我们将以 Elasticsearch 7版本为主，所以，需要安装JDK1.8以上。而Elastic Stack系列产品我们可以到Elastic的官网上去下载：https://www.elastic.co/cn/downloads
我们选择7.7.0 版本，从具体的下载页面可以看到Elastic Stack支持各种形式的安装。我们选择以免安装的压缩包的形式，下载后上传到服务器解压缩即可运行。
Linux JDK安装：
环境变量： vim /etc/profile.d/java.sh
# jdk存放的位置
JAVA_HOME=/opt/jdk1.8.0_211
PATH=$JAVA_HOME/bin:$PATH
export JAVA_HOME PATH
使环境变量生效
source /etc/profile
检查：java -version
Elasticsearch 默认不允许用roo用户运行，会报错，而且从服务器安全的角度来说，也不应该以root用户来做日常工作，因此我们新建一个用户es并以es用户登录。
1）创建es用户组及es用户
adduser es //添加一个名为es的用户
passwd es //修改密码
Changing password for user es
New UNIX password: //在这里输入新密码
Retype new UNIX password: //再次输入新密码
passwd: all authentication tokens updated successfully.
2）更改elasticsearch文件夹及内部文件的所属用户及组为es:es
cd /usr/local // es安装包存放目录，我这里是放到了/usr/local/elasticsearch/elasticsearch-7.7.0下面
chown -R es:es elasticsearch
3）显示用户信息
id user
cat /etc/passwd
补充：查看用户和用户组的方法
用户列表文件：/etc/passwd
用户组列表文件：/etc/group
查看系统中有哪些用户：cut -d : -f 1 /etc/passwd
查看可以登录系统的用户：cat /etc/passwd | grep -v /sbin/nologin | cut -d : -f 1
查看用户操作：w命令(需要root权限)
查看某一用户：w 用户名
查看登录用户：who
whoami #要查看当前登录用户的用户名
who am i #表示打开当前伪终端的用户的用户名
who mom likes
查看用户登录历史记录：last
详情参考博客：
转自：https://blog.csdn.net/tropicofcancer9/article/details/53926920
4）ES入门的坑...及解决办法：
切记不能使用root用户解压es安装包，否则启动会报错
如果是用root用户解压，然后用创建的用户启动可能会遇到下面的错误：
Could not rename log file 'logs/gc.log' to 'logs/gc.log.23' (Permission denied).
所以一定要用创建好新的用户后加压ES，然后启动。
1）elasticsearch 7.7.0 目录结构如下：
具体看看关键的 jvm.options JVM 配置文件，默认配置如下：
-Xms1g
-Xmx1g
ES默认安装后设置的堆内存是1 GB，对于任何业务来说这个设置肯定是少了。那设置多少？
推荐：如果足够的内存，也尽量不要超过32 GB。即每个节点内存分配不超过32 GB。因为它浪费了内存，降低了CPU的性能，还要让GC应对大内存。如果你想保证其安全可靠，设置堆内存为31 GB是一个安全的选择。
参考地址：https://www.elastic.co/guide/cn/elasticsearch/guide/current/heap-sizing.html
2）解压启动
用tar -xvf命令解压压缩包elasticsearch-7.7.0-linux-x86_64.tar.gzip后进入elasticsearch-7.7.0 文件夹中的 bin 文件夹，并执行命令./elasticsearch。待启动完成
注意一定给新用户es的文件执行权限：chown -R es:elsearch elasticsearch
输入：curl http://192.168.30.101:9200，显示
[root@localhost local]# curl http://192.168.30.101:9200
{
"name" : "node-1",
"cluster_name" : "elasticsearch",
"cluster_uuid" : "xgo5nwnmTju3vBALoOHXqw",
"version" : {
"number" : "7.7.0",
"build_flavor" : "default",
"build_type" : "tar",
"build_hash" : "81a1e9eda8e6183f5237786246f6dced26a10eaf",
"build_date" : "2020-05-12T02:01:37.602180Z",
"build_snapshot" : false,
"lucene_version" : "8.5.1",
"minimum_wire_compatibility_version" : "6.8.0",
"minimum_index_compatibility_version" : "6.0.0-beta1"
},
"tagline" : "You Know, for Search"
}
表示我们的Elasticsearch运行成功了，我们试着在本地浏览器进行访问，却显示“拒绝了我们的连接请求”，因此我们还需要配置一下Elasticsearch，以允许我们进行外网访问，进入elasticsearch-7.7.0下的config目录，编辑elasticsearch.yml文件进行配置。
打开config目录 elasticsearch.yml配置
1）配置集群名称（默认是被注释的，并且默认有一个集群名）
cluster.name: my-application
2）配置当前es节点名称（默认是被注释的，并且默认有一个节点名）
node.name: node-1
3）配置存储数据的目录路径（用逗号分隔多个位置）和日志文件路径
path.data: /home/esuser/elasticsearch-7.7.0/data
# Path to log files:
path.logs: /home/esuser/elasticsearch-7.7.0/logs
4）绑定地址为特定IP地址（设置其它节点和该节点交互的ip地址，如果不设置它会自动判断）默认为0.0.0.0，绑定这台机器的任何一个ip
network.host: 192.168.30.101
5）集群启动时，设置master节点列表用逗号分隔，单机则保留一个节点
cluster.initial_master_nodes: ["node-1", "node-2"]
6）保存配置
ERROR: [2] bootstrap checks failed
[1]: max file descriptors [4096] for elasticsearch process is too low, increase to at least [65535]
[2]: max virtual memory areas vm.max_map_count [65530] is too low, increase to at least [262144]
1）每个进程最大同时打开文件数太小，可通过下面2个命令查看当前数量
ulimit -Hn
ulimit -Sn
解决方案：切换到root账户，修改/etc/security/limits.conf文件 增加配置，用户退出后重新登录生效su root 输入密码vi /etc/security/limits.conf 在文件最后，增加如下配置：用户退出后重新登录生效
* soft nofile 65536
* hard nofile 65536
重新登录后查看：
2）问题：max virtual memory areas vm.max_map_count [65530] is too low, increase to at least [262144]
原因：elasticsearch用户拥有的内存权限太小，至少需要262144解决：切换到root用户，在/etc/sysctl.conf文件最后添加一行vm.max_map_count=655360添加完毕之后，执行命令：sysctl -p //生效
修改/etc/sysctl.conf文件，增加配置：vm.max_map_count=262144
[root@localhost ~]# vi /etc/sysctl.conf
[root@localhost ~]# sysctl -p //
vm.max_map_count = 262144
然后重新启动：
访问地址：192.168.30.166:9200
显示Elasticsearch运行并访问成功！
我们知道，Elasticsearch提供的是restful风格接口，我们用浏览器访问不是很方便，除非我们自行编程访问restful接口。这个时候，就可以用上Kibana了，它已经为我们提供了友好的Web界面，方便我们后面对Elasticsearch的学习，接下来我们安装运行Kibana。
systemctl enable elasticsearch.service
systemctl start elasticsearch.service
验证elasticsearch服务是否正常运行在工作：
访问地址：192.168.30.166:9200
同样用tar -xvf命令解压压缩包，进入解压后的目录。为了方便我们的访问和连接Elasticsearch，也需要进入Kibana的config目录对Kibana进行配置。
然后进入Kibana的bin目录运行./kibana，kibana 因为是用node.js 编写的，所以启动和运行较慢，需要等待一段时间：
elasticsearch.hosts: ["http://192.168.30.166:9200"]
xpack.reporting.encryptionKey: "a_random_string"
xpack.security.encryptionKey: "something_at_least_32_characters"
访问页面：http://192.168.30.166:5601/
提示：server is not ready yet
报错信息:
"warning","migrations","pid":6181,"message":"Another Kibana instance appears to be migrating the index. Waiting for that migration to complete. If no other Kibana instance is attempting migrations, you can get past this message by deleting index .kibana_index_1 and restarting Kibana.
另一个Kibana实例似乎正在迁移索引。”等待迁移完成。如果没有其他Kibana实例尝试迁移，则可以通过删除索引.kibana_index_1并重新启动Kibana来跳过此消息
1）停止kibana
service kibana stop
2）在Elasticsearch中删除kibana索引
curl -XDELETE http://192.168.0.101:9200/.kibana*
3）重新启动
service kibana start
从提示我们可以看出，kibana的访问端口是5601，我们依然在本地浏览器中访问：
等候几分钟以后，就会进入kibana的主界面。
我们一般会用ps -ef 来查询某个应用是否在Linux 系统中启动，比如Elasticsearch，我们用：
ps -ef|grep java或者ps -ef|grep elasticsearch 均可：
但是当我们尝试ps -ef|grep kibana，却是不行的，因为kibana是node写的，所以kibana运行的时候是运行在node里面，我们要查询的话，只能ps -ef|grep node或者使用netstat -tunlp|grep 5601
因为我们的kibana开放的端口是5601，所以看到5601端口被Listen (监听)，说明 kibana 启动成功。
附：netstat参数说明：
-t (tcp)仅显示 tcp 相关选项
-u (udp)仅显示 udp 相关选项
-n 拒绝显示别名，能显示数字的全部转化成数字。
-l 仅列出有在 Listen (监听) 的服務状态
-p 显示建立相关链接的程序名
更多netstat的相关说明，自行查阅Linux手册。
点击面板中的“Dev Tools”按钮，进入Dev工具，开始我们的Elasticsearch初次访问之旅。
systemctl stop firewalld
systemctl disable firewalld
或者设置防火墙规则：
firewall-cmd --add-port=9200/tcp --permanent
firewall-cmd --add-port=9300/tcp --permanent
firewall-cmd --add-port=5601/tcp --permanent
firewall-cmd --reload
Add the following in your `/etc/yum.repos.d/` directory in a file with a `.repo` suffix, for example `logstash.repo`
cat <<EOF | tee /etc/yum.repos.d/elasticsearch.repo
[elasticsearch-7.x]
name=Elasticsearch repository for 7.x packages
baseurl=https://artifacts.elastic.co/packages/7.x/yum
gpgcheck=1
gpgkey=https://artifacts.elastic.co/GPG-KEY-elasticsearch
enabled=1
autorefresh=1
type=rpm-md
本文参考博文：https://www.voidking.com/dev-centos7-install-elk/
wget https://artifacts.elastic.co/downloads/elasticsearch/elasticsearch-7.7.0-x86_64.rpm
wget https://artifacts.elastic.co/downloads/kibana/kibana-7.7.0-x86_64.rpm
下载完成后使用rpm -ivh进行安装，注意这里会自动创建elasticsearch用户。由于es是只能运行在非root用户下，如果使用压缩包的方法进行安装的话，则需要手工创建用户useradd -M -s /sbin/nologin elasticsearch。
1）安装命令：
首先安装公共签名密钥：
rpm --import https://artifacts.elastic.co/GPG-KEY-elasticsearch
安装elasticsearch：
rpm -ivh elasticsearch-7.7.0-x86_64.rpm
2）设置开机启动：
sudo systemctl daemon-reload
sudo systemctl enable elasticsearch.service
3）安装完成之后，修改配置文件如下：
cat /etc/elasticsearch/elasticsearch.yml |grep -v '^#'
path.data: /var/lib/elasticsearch
path.logs: /var/log/elasticsearch
修改配置文件：
vim /etc/elasticsearch/elasticsearch.yml
cluster.name: myelk #集群名字
node.name: node-1 #node名字
path.data: /var/lib/elasticsearch #日志数据路径
path.logs: /var/log/elasticsearch #日志存放路径
network.host: 192.168.0.209
http.port: 9200
discovery.seed_hosts: ["192.168.0.209"]
cluster.initial_master_nodes: ["192.168.0.209"]
# 增加参数，使head插件可以访问es
http.cors.enabled: true
http.cors.allow-origin: "*"
4）重启Elasticsearch
systemctl stop elasticsearch
systemctl start elasticsearch
# 启动后稍等一会
ps -ef | grep elasticsearch
netstat -nlpt
访问地址：http://192.168.0.101:9200/
安装与配置的过程如下，注意，配置项kibana.index需要修改一下，不然会报Kibana server is not ready yet这个错。
1）安装命令：
rpm -ivh kibana-7.7.0-x86_64.rpm （rpm --install kibana-7.7.0-x86_64.rpm）
确认Kibana的安装信息：
rpm -qi kibana
2）设置开机自动启动：
systemctl enable kibana.service
3）修改配置允许其他机器访问：
vim /etc/kibana/kibana.yml
如下修改：
# line 2, uncomment and change
server.port: 5601
# line 7, uncomment and change
server.host: "0.0.0.0"
# line 28, uncomment
elasticsearch.hosts: ["http://192.168.0.209:9200"]
kibana.index: ".newkibana"
i18n.locale: "zh-CN" #设置中文展示
修改完配置后重启服务：
systemctl stop kibana
systemctl start kibana
4）查看启动状态：
netstat -tunpl |grep 5601
netstat -nlpt|grep 5601
tcp 0 0 0.0.0.1:5601 0.0.0.0:* LISTEN 12991/node
查看Kibana运行状态：
systemctl status kibana
ps -ef | grep kibana
netstat -nlpt
5）访问测试：
在左边命令窗口中输入put enjoy_test，并点击相关按钮，于是看到右边的结果窗口中es给我们返回了处理结果，表示我们在es中创建索引成功。
要查看我们刚刚创建的索引，执行“get enjoy_test”
往这个索引中添加文档，执行：
PUT /hankin_test/_doc/1
{
"msg":"Hello World!"
}
查询我们刚刚加入的文档，执行：get /hankin_test/_doc/1
从上面的例子中，我们看到了很多熟悉又陌生的概念，比如索引、文档等等。这些概念和我们平时看到的数据库里的比如索引有什么区别呢？
举个例子，现在我们要保存唐宋诗词，数据库中我们们会怎么设计？诗词表我们可能的设计如下：
要根据朝代或者作者寻找诗，都很简单，比如“select诗词全文from诗词表where作者=‘李白’”，如果数据很多，查询速度很慢，怎么办？我们可以在对应的查询字段上建立索引加速查询。
但是如果我们现在有个需求：要求找到包含“望”字的诗词怎么办？用“select诗词全文from诗词表where诗词全文like‘%望%’”，这个意味着要扫描库中的诗词全文字段，逐条比对，找出所有包含关键词“望”字的记录。基本上，数据库中一般的SQL优化手段都是用不上的。数量少，大概性能还能接受，如果数据量稍微大点，就完全无法接受了，更何况在互联网这种海量数据的情况下呢？怎么解决这个问题呢，用倒排索引。
比如现在有：
蜀道难（唐）李白 蜀道之难难于上青天，侧身西望长咨嗟。
静夜思（唐）李白 举头望明月，低头思故乡。
春台望（唐）李隆基 暇景属三春，高台聊四望。
鹤冲天(宋)柳永 黄金榜上，偶失龙头望。明代暂遗贤，如何向？未遂风云便，争不恣狂荡。何须论得丧？才子词人，自是白衣卿相。烟花巷陌，依约丹青屏障。 幸有意中人，堪寻访。且恁偎红翠，风流事，平生畅。青春都一饷。忍把浮名，换了浅斟低唱！
都有望字，于是我们可以这么保存：
如果查哪个诗词中包含上，怎么办，上述的表格可以继续填入新的记录
其实，上述诗词的中每个字都可以作为关键字，然后建立关键字和文档之间的对应关系，也就是标识关键字被哪些文档包含。 所以，倒排索引就是将文档中包含的关键字全部提取处理，然后再将关键字和文档之间的对应关系保存起来，最后再对关键字本身做索引排序。用户在检索某一个关键字是，先对关键字的索引进行查找，再通过关键字与文档的对应关系找到所在文档。
在存储在关系型数据库中的数据，需要我们事先分析将数据拆分为不同的字段，而在es这类的存储中，需要应用程序根据规则自动提取关键字，并形成对应关系。这些预先提取的关键字，在全文检索领域一般被称为term（词项），文档的词项提取在es中被称为文档分析，这是全文检索很核心的过程，必须要区分哪些是词项，哪些不是，比如很多场景下，apple和apples是同一个东西，望和看其实是同一个动作。
Elasticsearch中比较关键的基本概念有索引、文档、映射、映射类型、文档字段概念，为了方便理解，可以和关系数据库中的相关概念进行个比对：
Elasticsearch索引是映射类型的容器。一个Elasticsearch索引非常像关系型世界的数据库，是独立的大量文档集合。当然在底层，肯定用到了倒排索引，最基本的结构就是“keyword”和“Posting List”，Posting list就是一个int的数组，存储了所有符合某个term的文档id。
另外，这个倒排索引相比特定词项出现过的文档列表，会包含更多其它信息。它会保存每一个词项出现过的文档总数， 在对应的文档中一个具体词项出现的总次数，词项在文档中的顺序，每个文档的长度，所有文档的平均长度等等相关信息。
文档是ES中所有可搜索数据的最小单位，比如日志文件中的日志项、一部电影的具体信息等等。文档会被序列化JSON格式保存到ElasticSearch中，JSON对象由字段组成，每个字段都有对象的字段类型（字符串、数值、布尔、日期、二进制、范围类型）。同时每个文档都有一个Unique ID，可以自己指定ID，或者通过ElasticSearch自动生成。所以严格来说，es中存储的文档是一种半结构化的数据。
映射mapping定义了每个字段的类型、字段所使用的分词器等。
查看映射命令：GET /hankin_test/_mapping
{
"hankin_test" : {
"mappings" : {
"properties" : {
"msg" : {
"type" : "text",
"fields" : {
"keyword" : {
"type" : "keyword",
"ignore_above" : 256
}
}
}
}
}
}
}
可以显式映射，由我们在索引映射中进行预先定义；也可以动态映射，在添加文档的时候，由es自动添加到索引，这个过程不需要事先在索引进行字段数据类型匹配等等，es会自己推断数据类型。既然说到了字段类型，当然就离不开字段的数据类型了。
文档中的一个字段field就相当于关系型数据库中的一列column，那么它肯定有数据类型，es提供的数据类型包括至少有：核心数据类型、复杂数据类型 、地理数据类型、地理数据类型、专门数据类型等，详见第二章。
