本文目录导航：
如何经常使用ElasticSearch存储和查问数据
引入ES的要素在于相关型数据库如MySQL在数据量大、查问性能降落及裁减才干有限的状况下显得无余，尤其在日志记载和查问密集场景。
ES作为搜查引擎，具有高效搜查、剖析和计算海量数据的才干，特意适宜IOT畛域存储和剖析设施控制日志。
在经常使用ES存储数据时，借助SpringBoot框架可轻松成功。
引入ES相关依赖后，经过ElasticsearchRestTemplate模板类提供简便的接口，如save方法用于存储数据。
此方法接纳自定义业务字段的数据和指定的索引名作为参数，索引名相似于MySQL中的表名。
查问数据则经过构建查问条件成功。
首先应用BoolQueryBuilder构建过滤条件，如依据设施ID和期间启动挑选。
接着经常使用NativeSearchQueryBuilder构建完整的查问条件，包括分页和降序排序。
最后调用elasticsearchRestTemplate的search方法口头查问，并经常使用流形式从查问结果中提取所需数据。
经常使用ES时，关键在于SpringBoot与ES的集成与参数性能。
elasticsearchRestTemplate提供了弱小的性能，简化了数据操作环节。
同时，了解ES外部上班原理关于深化运行和优化系统性能大有裨益。
经过以上步骤，可以成功数据的高效存储与查问，为业务剖析提供有力支持。
elasticsearch 在大数据中能成功哪些性能
由于须要优化名目标搜查品质，最近钻研了一下Elasticsearch，一款十分低劣的散布式搜查程序。
最开局的一些笔记放到github，这里只是演绎总结一下。
首先，为什么要经常使用Elasticsearch？最开局的时刻，咱们的名目仅仅经常使用MySQL启动繁难的搜查，而后一个不能索引的like语句，间接拉低MySQL的性能。
起初，咱们曾思考过sphinx，并且sphinx也在之前的名目中成功实施过，但想想如今的数据量级，多台MySQL，以及搜查服务自身HA，还有后续扩容的疑问，咱们觉得sphinx并不是一个最优的选用。
于是人造将眼光放到了Elasticsearch上方。
依据官方自己的引见，Elasticsearch是一个散布式搜查服务，提供Restful API，底层基于Lucene，驳回多shard的形式保障数据安保，并且提供智能resharding的性能，加之github等大型的站点也驳回 Elasticsearch作为其搜查服务，咱们选择在名目中经常使用Elasticsearch。
关于Elasticsearch，假设要在名目中经常使用，须要处置如下疑问：索引，关于须要搜查的数据，如何建设适宜的索引，还须要依据特定的言语经常使用不同的analyzer等。
搜查，Elasticsearch提供了十分弱小的搜查性能，如何写出高效的搜查语句？数据源，咱们一切的数据是寄存到MySQL的，MySQL是惟一数据源，如何将MySQL的数据导入到Elasticsearch？关于1和2，由于咱们的数据都是从MySQL生成，index的field是固定的，关键做的上班就是依据业务场景设计好对应的mapping以及search语句就可以了，当然实践无法能这么繁难，须要咱们始终的调优。
而关于3，则是须要一个工具将MySQL的数据导入Elasticsearch，由于咱们对搜查实时性要求很高，所以须要将MySQL的增量数据实时导入，笔者惟一能想到的就是经过row based binlog来成功。
而近段期间的上班，也就是成功一个MySQL增量同步到Elasticsearch的服务。
LuceneElasticsearch底层是基于Lucene的，Lucene是一款低劣的搜查lib，当然，笔者以前依然没有接触经常使用过。
:-)Lucene关键概念：document：用来索引和搜查的关键数据源，蕴含一个或许多个Field，而这些Field则蕴含咱们跟Lucene交互的数据。
Field：document的一个组成局部，有两个局部组成，name和value。
Term：无法宰割的单词，搜查最小单元。
Token：一个Term出现形式，蕴含这个Term的内容，在文档中的起始位置，以及类型。
Lucene经常使用Inverted index来存储term在document中位置的映射相关。
譬如如下文档：Elasticsearch Server 1.0 （document 1）Mastring Elasticsearch （document 2）Apache Solr 4 Cookbook （document 3）经常使用inverted index存储，一个繁难地映射相关：TermCountDocuemnt1.01<1>41<3>Apache1<3>Cookbook1<3>Elasticsearch2<1>.<2>Mastering1<2>Server1<1>Solr1<3>关于上方例子，咱们首先经过火词算法将一个文档切分红一个一个的token，再失掉该token与document的映射相关，并记载token产生的总次数。
这样就失掉了一个繁难的inverted index。
Elasticsearch关键概念要经常使用Elasticsearch，笔者以为，只有要了解几个基本概念就可以了。
在数据层面，关键有：Index：Elasticsearch用来存储数据的逻辑区域，它相似于相关型数据库中的db概念。
一个index可以在一个或许多个shard上方，同时一个shard也或许会有多个replicas。
document：Elasticsearch外面存储的实体数据，相似于相关数据中一个table外面的一行数据。
document由多个field组成，不同的document外面同名的field必定具有相反的类型。
document外面field可以重复产生，也就是一个field会有多个值，即multivalued。
document type：为了查问须要，一个index或许会有多种document，也就是document type，但须要留意，不同document外面同名的field必定要是相反类型的。
Mapping：存储field的相关映射消息，不同document type会有不同的mapping。
关于相熟MySQL的童鞋，咱们只有要大略以为Index就是一个db，document就是一行数据，field就是table的column，mapping就是table的定义，而document type就是一个table就可以了。
document type这个概念其实最开局也把笔者给弄懵懂了，其实它就是为了更好的查问，举个繁难的例子，一个index，或许一局部数据咱们想经常使用一种查问形式，而另一局部数据咱们想经常使用另一种查问形式，于是就有了两种type了。
不过这种状况应该在咱们的名目中不会产生，所以理论一个index上方仅会有一个 type。
在服务层面，关键有：Node: 一个server实例。
Cluster：多个node组成cluster。
Shard：数据分片，一个index或许会存在于多个shards，不同shards或许在不同nodes。
Replica：shard的备份，有一个primary shard，其他的叫做replica shards。
Elasticsearch之所以能灵活resharding，关键在于它最开局就预先调配了多个shards（貌似是1024），而后以shard为单位启动数据迁徙。
这个做法其真实散布式畛域十分的广泛，codis就是经常使用了1024个slot来启动数据迁徙。
由于恣意一个index都可性能多个replica，经过冗余备份的形式保障了数据的安保性，同时replica也能分担读压力，相似于MySQL中的slave。
Restful APIElasticsearch提供了Restful API，经常使用json格局，这使得它十分利于与外部交互，只管Elasticsearch的客户端很多，但笔者依然很容易的就写出了一个繁难客户端用于名目中，再次印证了Elasticsearch的经常使用真心很容易。
Restful的接口很繁难，一个url示意一个特定的资源，譬如/blog/article/1，就示意一个index为blog，type为aritcle，id为1的document。
而咱们经常使用http规范method来操作这些资源，POST新增，PUT降级，GET失掉，DELETE删除，HEAD判别能否存在。
这里，友谊介绍httpie，一个十分弱小的http工具，团体觉得比curl还用，简直是命令行调试Elasticsearch的绝配。
一些经常使用httpie的例子:# createhttp POST :9200/blog/article/1 tags:=[elasticsearch]# gethttp GET :9200/blog/article/1# updatehttp PUT :9200/blog/article/1 tags:=[elasticsearch, hello]# deletehttp DELETE :9200/blog/article/1# existshttp HEAD :9200/blog/article/1索引和搜查只管Elasticsearch能智能判别field类型并建设适宜的索引，但笔者依然介绍自己设置相关索引规定，这样才干更好为后续的搜查服务。
咱们经过定制mapping的形式来设置不同field的索引规定。
而关于搜查，Elasticsearch提供了太多的搜查选项，就不逐一律述了。
索引和搜查是Elasticsearch十分关键的两个方面，间接相关到产品的搜查体验，但笔者现阶段也仅仅是大略了解了一点，后续在具体引见。
同步MySQL数据Elasticsearch是很弱小，但要建设在有足量数据状况上方。
咱们的数据都在MySQL上方，所以如何将MySQL的数据导入Elasticsearch就是笔者最近钻研的物品了。
只管如今有一些成功，譬如elasticsearch-river-jdbc，或许elasticsearch-river-mysql，但笔者并不计划经常使用。
elasticsearch-river-jdbc的性能是很弱小，但并没有很好的支持增量数据降级的疑问，它须要对应的表只增不减，而这个简直在名目中是无法能办到的。
elasticsearch-river-mysql倒是做的很不错，驳回了python-mysql-replication来经过binlog失掉变卦的数据，启动增量降级，但它貌似处置MySQL dump数据导入的疑问，不过这个笔者真的好好确认一下？话说，python-mysql-replication笔者还提交过pull处置了minimal row image的疑问，所以对elasticsearch-river-mysql这个名目很有好感。
只是笔者选择自己写一个进去。
为什么笔者选择自己写一个，不是由于笔者青睐造轮子，关键要素在于关于这种MySQL syncer服务（增量失掉MySQL数据降级到相相关统），咱们不光可以用到Elasticsearch上方，而且还能用到其他服务，譬如cache上方。
所以笔者其实想成功的是一个通用MySQL syncer组件，只是如今关键关注Elasticsearch罢了。
名目代码在这里go-mysql-elasticsearch，现已成功第一阶段开发，外部对接测试中。
go-mysql-elasticsearch的原理很繁难，首先经常使用mysqldump失掉以后MySQL的数据，而后在经过此时binlog的name和position失掉增量数据。
一些限度：binlog必定要变成row-based format格局，其实咱们并不须要担忧这种格局的binlog占用太多的硬盘空间，MySQL 5.6之后GTID形式都介绍经常使用row-based format了，而且理论咱们都会把控SQL语句品质，不准许一次性性更改正多行数据的。
须要同步的table最好是innodb引擎，这样mysqldump的时刻才不会阻碍写操作。
须要同步的table必定要有主键，好吧，假设一个table没有主键，笔者真心会疑心设计这个table的同窗编程水平了。
多列主键也是不介绍的，笔者现阶段不计划支持。
必定别灵活更改须要同步的table结构，Elasticsearch只能支持灵活参与field，并不支持灵活删除和更改field。
理论来说，假设触及到alter table，很多时刻曾经证实前期设计的不正当以及关于未来裁减的预估无余了。
更具体的说明，等到笔者成功了go-mysql-elasticsearch的开发，并经过消费环境中测试了，再启动补充。
总结最近一周，笔者花了不少期间在Elasticsearch上方，如今算是基本入门了。
其实笔者觉得，关于一门疑问的技术，找一份靠谱的资料（官方文档或许入门书籍），蛋疼的对着资料敲一遍代码，疑问的再问google，最后在将其用到实践名目，这门技术就算是初步把握了，当然知晓还得在下点功夫。
如今笔者只是觉得Elasticsearch很美妙，上线之后铁定会有坑的，那时刻只能缓缓填了。
话说，笔者是不是要学习下java了，省的到时刻看疑问代码就惨了。
:-)
elasticsearch-head插件有什么用
elasticsearch-head插件的关键作用在于提供对Elasticsearch集群的直观治理和监控。
它作为一个用户界面工具，使得用户能够繁难地对集群中的节点、索引、搜查性能以及数据启动治理和监控，无需深化了解复杂的API。
经过装置和集成这个插件，治理员和开发者可以实时检查集群的形态，包括节点衔接状况、索引的大小、搜查性能等关键消息。
集群作为Elasticsearch的外围组成局部，由多个节点组成，它们共享数据并协同提供索引和搜查服务。
每个集群都有一个举世无双的名字，称为elasticsearch，这个称号在节点间是经过指定集群名来识别和衔接的。
集群名至关关键，由于它选择了节点间的交互形式和数据散布。
elasticsearch-head插件的价值在于它简化了对集群的治理操作，使得用户能够轻松地监控和诊断潜在的疑问，优化系统的稳固性和效率。
无论是对新手还是阅历丰盛的治理员来说，这个插件都是一个必无法少的辅佐工具，协助他们更好地理解和治理Elasticsearch集群的运转。
