elasticsearch学习笔记之一（为什么要使用elasticsearch）

来源：互联网发布：华硕淘宝官方旗舰店编辑：程序博客网时间：2024/06/05 05:57

下面就根据我个人的工作经验以及日常中用到的功能和大家一起交流和互相学习，有什么不足之处欢迎大家批评指正。

最近两年elasticsearch已经开始在国内流行起来，其中也不乏有大公司在使用，比如百度、新浪。可以预见这个产品会越来越火，和它一起做搜索的solr是各有千秋，Elasticsearch是一个基于ApacheLucene(TM)的开源搜索引擎。无论在开源还是专有领域，Lucene可以被认为是迄今为止最先进、性能最好的、功能最全的搜索引擎库。

•分布式的实时文件存储，每个字段都被索引并可被搜索

•分布式的实时分析搜索引擎

•可以扩展到上百台服务器，处理PB级结构化或非结构化数据

分布式

elasticsearch（以下简称ES）为分布式而生，而且它的设计隐藏了分布式本身的复杂性。Elasticsearch在分布式概念上做了很大程度上的透明化，Elasticsearch致力于隐藏分布式系统的复杂性。以下这些操作都是在底层自动完成的：

•将你的文档分区到不同的容器或者分片(shards)中，它们可以存在于一个或多个节点中。

•将分片均匀的分配到各个节点，对索引和搜索做负载均衡。

•冗余每一个分片，防止硬件故障造成的数据丢失。

•将集群中任意一个节点上的请求路由到相应数据所在的节点。

•无论是增加节点，还是移除节点，分片都可以做到无缝的扩展和迁移。

横向扩展和纵向扩展

Elasticsearch用于构建高可用和可扩展的系统。扩展的方式可以是购买更好的服务器( 纵向扩展(vertical scale or scaling up))或者购买更多的服务器（横向扩展(horizontal scaleor scaling out)）。

Elasticsearch虽然能从更强大的硬件中获得更好的性能，但是纵向扩展有它的局限性。真正的扩展应该是横向的，它通过增加节点来均摊负载和增加可靠性。

对于大多数数据库而言，横向扩展意味着你的程序将做非常大的改动才能利用这些新添加的设备。对比来说，Elasticsearch天生就是分布式的：它知道如何管理节点来提供高扩展和高可用。这意味着你的程序不需要关心这些。在这章我们将探索如何创建你的集群(cluster)、节点(node)和分片(shards)，使其按照你的需求进行扩展，并保证在硬件故障时数据依旧安全。

基于http协议

基于HTTP协议，以JSON为数据交互格式的RESTful API，其他所有程序语言都可以使用RESTful API，通过9200端口的与Elasticsearch进行通信，你可以使用你喜欢的WEB客户端，事实上，如你所见，你甚至可以通过 curl 命令与Elasticsearch通信。

Elasticsearch官方提供了多种程序语言的客户端——Groovy，Javascript， .NET，PHP，Perl，Python，以及 Ruby——还有很多由社区提供的客户端和插件，所有这些可以在文档中找到。

向Elasticsearch发出的请求的组成部分与其它普通的HTTP请求是一样的：

curl -X<VERB>'<PROTOCOL>://<HOST>/<PATH>?<QUERY_STRING>' -d'<BODY>'

• VERB HTTP方法：GET , POST , PUT , HEAD , DELETE

• PROTOCOL http或者https协议（只有在Elasticsearch前面有https代理的时候可用）

• HOST Elasticsearch集群中的任何一个节点的主机名，如果是在本地的节点，那么就叫localhost

• PORT Elasticsearch HTTP服务所在的端口，默认为9200

• QUERY_STRING 一些可选的查询请求参数，例如 ?pretty 参数将使请求返回更加美观易读的JSON数据

• BODY 一个JSON格式的请求主体（如果请求需要的话）

负载均衡

节点(node)是一个运行着的Elasticsearch实例。一个集群是由多个ES的实例组成的，集群通常会有一个主节点，主节点根据负载均衡算法将请求均匀的分发到各个节点上。保证集群的高性能，主节点上也存储了其他各个节点的信息，这样才能知道将这些请求具体分发给谁。

同时，万一有机器宕机了另外的机器还可以继续使用，保证正常的业务不受影响。起到多台机器热备份的效果。

CAP

C（强一致性）：所有的节点上的数据时刻保持同步

A（高可用性）：每个请求都能接受到一个响应，无论响应成功或失败

P（分区容忍性）：系统应该能持续提供服务，即使系统内部有消息丢失（分区）

CA without P：如果不要求P（不允许分区），则C（强一致性）和A（可用性）是可以保证的。但其实分区不是你想不想的问题，而是始终会存在，因此CA的系统更多的是允许分区后各子系统依然保持CA。(关系型数据库)

CP without A：如果不要求A（可用），相当于每个请求都需要在Server之间强一致，而P（分区）会导致同步时间无限延长，如此CP也是可以保证的。很多传统的数据库分布式事务都属于这种模式。(Hbase)

AP wihtout C：要高可用并允许分区，则需放弃一致性。一旦分区发生，节点之间可能会失去联系，为了高可用，每个节点只能用本地数据提供服务，而这样会导致全局数据的不一致性。现在众多的NoSQL都属于此类。(redis、ES)

以上说了这么多只不过是它的一部分优势而已，但是这些优势已经让你有足够的理由考虑使用它了，相信你也大概了解了为什么现在很多公司会青睐它了。

阅读全文

0 0