• 关于

    访问透明性如何搭建

    的搜索结果

问题

用户指南-读写分离-读写分离简介

功能介绍 当您开通读写分离功能后,实例中会存在如下三类地址: 主实例的连接地址:可以只有内网或者外网地址,也可以内外网地址共存。只读实例的连接地址:可以只有内网或者外...
李沃晟 2019-12-01 21:38:38 697 浏览量 回答数 0

问题

读写分离简介

功能介绍 目前,只有MySQL 5.6版本的实例支持读写分离功能,因为该功能必须和 只读实例一起使用。当您开通读写分离功能后,实例中会存在如下三类地址: 主实例的连接地址ÿ...
云栖大讲堂 2019-12-01 21:39:36 1046 浏览量 回答数 0

问题

SSH面试题

1.什么是struts2?struts的工作原理? struts2:1)经典的  mvc (Model  View  Controller) 框架                          ...
琴瑟 2019-12-01 21:46:22 3489 浏览量 回答数 0

阿里云试用中心,为您提供0门槛上云实践机会!

100+款试用云产品,最长免费试用12个月!拨打95187-1,咨询专业上云建议!

问题

词汇表是什么样的?(S-V)

S A | B | C | D | E | F | G | H | I | J | K | L | M | N | O | P | Q | R | S | T | U | V | W | X | Y | Z SASL ...
轩墨 2019-12-01 22:06:08 2530 浏览量 回答数 1

回答

OceanBase 1.4分区表用法 业务数据做水平拆分,有如下几种方案 分库分表:通过分布式数据库中间件做分库分表拆分和路由等。如DRDS,MyCat,TDSQL等。分区:Oracle 12c的sharding, OceanBase 1.0及以后的版本存储级别切片,对应用透明。如Google的Spanner,PingCap的TiDB 这里只演示OceanBase的分区用法。 OceanBase的分区策略支持hash/list/range,以及支持二级分区(hash+hash,hash+range,key+key,range+range等)。详细用法请参见 OceanBase官网 文档里 的 OB分区表用法 。 无论是分库分表,还是分区的方案,都会面临一个问题,就是当一个Query 要取不同机器(节点)上的数据的时候,如果保证取出来的数据是一致的(指来自于同一个时间点或版本)。 分库分表方案解决不了这个问题, OB1.4也不能解决这个问题。OB2.0 新增全局时间服务,能提供全局一致性快照读功能,所以解决了这个问题。 这里演示一下 OB1.4 里规避这个跨节点读的方案(弱一致读) SQL: SELECT @@version;drop table if exists t_parttable;create table t_parttable(    id bigint not null primary key,     name varchar(50) not NULL,      KEY name_ind(NAME) LOCAL ) DEFAULT CHARSET=utf8mb4 partition by hash(mod(id,1000)) partitions 8;insert into t_parttable(id, name) values(1,'a'),(2,'A'),(3,'b'),(4,'B'),(5,'c'),(6,'C'),(7,'d'),(8,'D');set session ob_query_timeout=1000000; select * from t_parttable where name='a';explain select * from t_parttable where name='a';select /*+read_consistency(weak)*/ * from t_parttable where name='a';select * from t_parttable partition(p1);select * from t_parttable partition(p2); 该问题,在OceanBase 2.0后版本已经解了 ------------------------- OB租户负载均衡历史查看 接楼上建的表,这里演示一下如何在租户里查看负载均衡的历史。 OB作为一个分布式数据库,至少包含3个节点。其负载均衡的原理跟传统负载均衡的原理大不一样。 传统负载均衡设备(F5)或软件(LVS,SLB等)都是通过在某一协议层作为流量入口然后分配流量给后端不同的节点,从而去改变后端节点的压力。 OceanBase的负载均衡是自己通过调整每个节点(ObServer)里的数据(Partition)分布,从而间接改变打到各个节点(ObServer)上的流量,从而改变各个节点的压力。 有关OceanBase负载均衡的原理详细,请查看 《 OceanBase负载均衡的魅力 》 示例演示:租户视角查看负载均衡历史。 这里是新建了一个分区表(8个分区),在插入数据后,触发了负载均衡机制,把8个分区分散到多个节点上。 SQL: # 查看分区表的数据SHOW CREATE TABLE db_bin.t_parttable;SELECT /*+read_consistency(weak)*/ * FROM db_bin.t_parttable ORDER BY id ;# 查看租户的资源单元(Unit)分布SELECT tenant_name, unit_id,zone,svr_ip,max_cpu,round(max_memory/1024/1024/1024) max_mem_gb FROM gv$unit;# 查看租户的负载均衡历史SELECT str_to_date(h.gmt_create,'%Y-%m-%d %h:%i:%s') gmt_create, h.zone, t.database_name, t.tablegroup_name, t.table_name, t.part_num,h.partition_id,h.data_size, h.data_src_ip,  h.dest_unit_id, h.dest_ip, h.result_code, h.COMMENT , h.rs_svr_ip FROM gv$unit_load_balance_event_history h JOIN gv$TABLE t ON (h.table_id=t.table_id)WHERE t.table_name NOT LIKE '%recycle%' AND t.database_name='db_bin'ORDER BY gmt_create DESC LIMIT 100; ------------------------- OB sys租户查看集群使用信息     OceanBase作为一款通用的分布式关系型数据库,跟其他同行产品相比,有一个独特的地方,就是支持多租户,即支持集群资源(CPU/MEM/DISK等)的做租户管理。 OceanBase集群,至少是三节点。OceanBase把三个节点的机器资源能力聚合成一个大的资源池,然后做二次资源管理和分配。为每个租户分配一个特定规格的小的资源池,并且随时可以动态调整。 租户对于业务开发来说就是一个体的实例,只是开发不需要关注这个实例在哪个节点上。租户的使用体验类似于 MySQL (默认,以后还支持Oracle兼容模式的租户)。     假设OceanBase集群已经搭建好了,在创建租户之前,先清点一下现有集群的资源使用状况。下面是示例     SQL: # 查看集群节点资源使用情况SELECT svr_ip, s.zone, s.cpu_total, s.cpu_assigned, s.cpu_assigned_percent, round(s.mem_total/1024/1024/1024) mem_total_gb, round(s.mem_assigned/1024/1024/1024) mem_ass_gb, s.mem_assigned_percentFROM __all_virtual_server_stat sORDER BY zone,svr_ip;# 查看资源单元规格定义SELECT NAME, max_cpu, min_cpu, round(max_memory/1024/1024/1024) max_mem_gb , round(min_memory/1024/1024/1024) min_mem_gb FROM __all_unit_config ORDER BY unit_config_id LIMIT 10;# 查看已有租户及其资源池信息SELECT t.tenant_name, p.name pool_name, c.name config_name, p.unit_count, p.zone_list, t.`locality`FROM __all_resource_pool p JOIN __all_unit_config c ON (p.unit_config_id=c.unit_config_Id)  LEFT JOIN __all_tenant t ON (p.tenant_id=t.tenant_id)WHERE p.NAME IN ('yq_Pool','app_pool')  ORDER BY p.resource_pool_id; ------------------------- OceanBase租户创建(很简单)     接楼上。     清点了OceanBase集群资源使用情况后,选定一个规格,就可以快速创建出一个租户(demo_t) 示例:OB1.4下创建租户(2步) SQL: # 清理已经创建的同名租户DROP tenant IF EXISTS demo_t;DROP resource pool demo_pool;# 创建新的资源池(Resource Pool)CREATE resource pool demo_pool unit='S0_unit_config', unit_num=2;# 创建租户 CREATE tenant IF NOT EXISTS demo_t resource_pool_list=('demo_pool') SET VARIABLES ob_tcp_invited_nodes='%';# 查看已有租户及其资源池信息SELECT now() cur_time, str_to_date(t.gmt_create,'%Y-%m-%d %h:%i:%s') gmt_create,  t.tenant_name, p.name pool_name, c.name config_name, p.unit_count, p.zone_list, t.`locality`FROM __all_resource_pool p JOIN __all_unit_config c ON (p.unit_config_id=c.unit_config_Id)  LEFT JOIN __all_tenant t ON (p.tenant_id=t.tenant_id)WHERE p.NAME IN ('demo_pool')  ORDER BY p.resource_pool_id;     退出当前sys租户,重新登录新建租户 ,用户名是:root@demo_t#集群名,密码默认是空。 登录后新建Database,并创建账户访问DB。 ------------------------- OceanBase里索引创建特征 OceanBase里创建索引稍微有点特殊,开发和运维需要留意一下。 如果是在create table里带上了索引(包括唯一索引,也就是唯一性约束),是立即生效的。OB 1.x 版本里在表存在的情况下新建的索引(包括唯一索引),命令立即返回,但是索引不是立即生效。需要等到OB集群发起大合并之后才会生效。其中唯一索引需要等待两次大合并。所以运维建索引后需要安排1-2次大合并操作。OB 2.x 版本里在表存在的情况下新建的索引(包括唯一索引),命令立即返回,索引也不是立即生效,但是索引开始后台异步创建,创建时间取决于数据量。 示例如下: 1. OB 1.x 版本的索引 2. OB 2.x版本的索引 ------------------------- 回 9楼(xcb296) 的帖子 有什么想了解的 可以先说一下。 这个主要是根据用户问题来做的。
mq4096 2019-12-02 00:56:01 0 浏览量 回答数 0

回答

OceanBase 1.4分区表用法 业务数据做水平拆分,有如下几种方案 分库分表:通过分布式数据库中间件做分库分表拆分和路由等。如DRDS,MyCat,TDSQL等。分区:Oracle 12c的sharding, OceanBase 1.0及以后的版本存储级别切片,对应用透明。如Google的Spanner,PingCap的TiDB 这里只演示OceanBase的分区用法。 OceanBase的分区策略支持hash/list/range,以及支持二级分区(hash+hash,hash+range,key+key,range+range等)。详细用法请参见 OceanBase官网 文档里 的 OB分区表用法 。 无论是分库分表,还是分区的方案,都会面临一个问题,就是当一个Query 要取不同机器(节点)上的数据的时候,如果保证取出来的数据是一致的(指来自于同一个时间点或版本)。 分库分表方案解决不了这个问题, OB1.4也不能解决这个问题。OB2.0 新增全局时间服务,能提供全局一致性快照读功能,所以解决了这个问题。 这里演示一下 OB1.4 里规避这个跨节点读的方案(弱一致读) SQL: SELECT @@version;drop table if exists t_parttable;create table t_parttable(    id bigint not null primary key,     name varchar(50) not NULL,      KEY name_ind(NAME) LOCAL ) DEFAULT CHARSET=utf8mb4 partition by hash(mod(id,1000)) partitions 8;insert into t_parttable(id, name) values(1,'a'),(2,'A'),(3,'b'),(4,'B'),(5,'c'),(6,'C'),(7,'d'),(8,'D');set session ob_query_timeout=1000000; select * from t_parttable where name='a';explain select * from t_parttable where name='a';select /*+read_consistency(weak)*/ * from t_parttable where name='a';select * from t_parttable partition(p1);select * from t_parttable partition(p2); 该问题,在OceanBase 2.0后版本已经解了 ------------------------- OB租户负载均衡历史查看 接楼上建的表,这里演示一下如何在租户里查看负载均衡的历史。 OB作为一个分布式数据库,至少包含3个节点。其负载均衡的原理跟传统负载均衡的原理大不一样。 传统负载均衡设备(F5)或软件(LVS,SLB等)都是通过在某一协议层作为流量入口然后分配流量给后端不同的节点,从而去改变后端节点的压力。 OceanBase的负载均衡是自己通过调整每个节点(ObServer)里的数据(Partition)分布,从而间接改变打到各个节点(ObServer)上的流量,从而改变各个节点的压力。 有关OceanBase负载均衡的原理详细,请查看 《 OceanBase负载均衡的魅力 》 示例演示:租户视角查看负载均衡历史。 这里是新建了一个分区表(8个分区),在插入数据后,触发了负载均衡机制,把8个分区分散到多个节点上。 SQL: # 查看分区表的数据SHOW CREATE TABLE db_bin.t_parttable;SELECT /*+read_consistency(weak)*/ * FROM db_bin.t_parttable ORDER BY id ;# 查看租户的资源单元(Unit)分布SELECT tenant_name, unit_id,zone,svr_ip,max_cpu,round(max_memory/1024/1024/1024) max_mem_gb FROM gv$unit;# 查看租户的负载均衡历史SELECT str_to_date(h.gmt_create,'%Y-%m-%d %h:%i:%s') gmt_create, h.zone, t.database_name, t.tablegroup_name, t.table_name, t.part_num,h.partition_id,h.data_size, h.data_src_ip,  h.dest_unit_id, h.dest_ip, h.result_code, h.COMMENT , h.rs_svr_ip FROM gv$unit_load_balance_event_history h JOIN gv$TABLE t ON (h.table_id=t.table_id)WHERE t.table_name NOT LIKE '%recycle%' AND t.database_name='db_bin'ORDER BY gmt_create DESC LIMIT 100; ------------------------- OB sys租户查看集群使用信息     OceanBase作为一款通用的分布式关系型数据库,跟其他同行产品相比,有一个独特的地方,就是支持多租户,即支持集群资源(CPU/MEM/DISK等)的做租户管理。 OceanBase集群,至少是三节点。OceanBase把三个节点的机器资源能力聚合成一个大的资源池,然后做二次资源管理和分配。为每个租户分配一个特定规格的小的资源池,并且随时可以动态调整。 租户对于业务开发来说就是一个体的实例,只是开发不需要关注这个实例在哪个节点上。租户的使用体验类似于 MySQL (默认,以后还支持Oracle兼容模式的租户)。     假设OceanBase集群已经搭建好了,在创建租户之前,先清点一下现有集群的资源使用状况。下面是示例     SQL: # 查看集群节点资源使用情况SELECT svr_ip, s.zone, s.cpu_total, s.cpu_assigned, s.cpu_assigned_percent, round(s.mem_total/1024/1024/1024) mem_total_gb, round(s.mem_assigned/1024/1024/1024) mem_ass_gb, s.mem_assigned_percentFROM __all_virtual_server_stat sORDER BY zone,svr_ip;# 查看资源单元规格定义SELECT NAME, max_cpu, min_cpu, round(max_memory/1024/1024/1024) max_mem_gb , round(min_memory/1024/1024/1024) min_mem_gb FROM __all_unit_config ORDER BY unit_config_id LIMIT 10;# 查看已有租户及其资源池信息SELECT t.tenant_name, p.name pool_name, c.name config_name, p.unit_count, p.zone_list, t.`locality`FROM __all_resource_pool p JOIN __all_unit_config c ON (p.unit_config_id=c.unit_config_Id)  LEFT JOIN __all_tenant t ON (p.tenant_id=t.tenant_id)WHERE p.NAME IN ('yq_Pool','app_pool')  ORDER BY p.resource_pool_id; ------------------------- OceanBase租户创建(很简单)     接楼上。     清点了OceanBase集群资源使用情况后,选定一个规格,就可以快速创建出一个租户(demo_t) 示例:OB1.4下创建租户(2步) SQL: # 清理已经创建的同名租户DROP tenant IF EXISTS demo_t;DROP resource pool demo_pool;# 创建新的资源池(Resource Pool)CREATE resource pool demo_pool unit='S0_unit_config', unit_num=2;# 创建租户 CREATE tenant IF NOT EXISTS demo_t resource_pool_list=('demo_pool') SET VARIABLES ob_tcp_invited_nodes='%';# 查看已有租户及其资源池信息SELECT now() cur_time, str_to_date(t.gmt_create,'%Y-%m-%d %h:%i:%s') gmt_create,  t.tenant_name, p.name pool_name, c.name config_name, p.unit_count, p.zone_list, t.`locality`FROM __all_resource_pool p JOIN __all_unit_config c ON (p.unit_config_id=c.unit_config_Id)  LEFT JOIN __all_tenant t ON (p.tenant_id=t.tenant_id)WHERE p.NAME IN ('demo_pool')  ORDER BY p.resource_pool_id;     退出当前sys租户,重新登录新建租户 ,用户名是:root@demo_t#集群名,密码默认是空。 登录后新建Database,并创建账户访问DB。 ------------------------- OceanBase里索引创建特征 OceanBase里创建索引稍微有点特殊,开发和运维需要留意一下。 如果是在create table里带上了索引(包括唯一索引,也就是唯一性约束),是立即生效的。OB 1.x 版本里在表存在的情况下新建的索引(包括唯一索引),命令立即返回,但是索引不是立即生效。需要等到OB集群发起大合并之后才会生效。其中唯一索引需要等待两次大合并。所以运维建索引后需要安排1-2次大合并操作。OB 2.x 版本里在表存在的情况下新建的索引(包括唯一索引),命令立即返回,索引也不是立即生效,但是索引开始后台异步创建,创建时间取决于数据量。 示例如下: 1. OB 1.x 版本的索引 2. OB 2.x版本的索引 ------------------------- 回 9楼(xcb296) 的帖子 有什么想了解的 可以先说一下。 这个主要是根据用户问题来做的。
mq4096 2019-12-02 00:56:00 0 浏览量 回答数 0

回答

简介 ES是一个基于RESTful web接口并且构建在Apache Lucene之上的开源分布式搜索引擎。 同时ES还是一个分布式文档数据库,其中每个字段均可被索引,而且每个字段的数据均可被搜索,能够横向扩展至数以百计的服务器存储以及处理PB级的数据。 可以在极短的时间内存储、搜索和分析大量的数据。通常作为具有复杂搜索场景情况下的核心发动机。 ES就是为高可用和可扩展而生的。一方面可以通过升级硬件来完成系统扩展,称为垂直或向上扩展(Vertical Scale/Scaling Up)。 另一方面,增加更多的服务器来完成系统扩展,称为水平扩展或者向外扩展(Horizontal Scale/Scaling Out)。尽管ES能够利用更强劲的硬件,但是垂直扩展毕竟还是有它的极限。真正的可扩展性来自于水平扩展,通过向集群中添加更多的节点来分担负载,增加可靠性。ES天生就是分布式的,它知道如何管理多个节点来完成扩展和实现高可用性。意味应用不需要做任何的改动。 Gateway,代表ES索引的持久化存储方式。在Gateway中,ES默认先把索引存储在内存中,然后当内存满的时候,再持久化到Gateway里。当ES集群关闭或重启的时候,它就会从Gateway里去读取索引数据。比如LocalFileSystem和HDFS、AS3等。 DistributedLucene Directory,它是Lucene里的一些列索引文件组成的目录。它负责管理这些索引文件。包括数据的读取、写入,以及索引的添加和合并等。 River,代表是数据源。是以插件的形式存在于ES中。  Mapping,映射的意思,非常类似于静态语言中的数据类型。比如我们声明一个int类型的变量,那以后这个变量只能存储int类型的数据。比如我们声明一个double类型的mapping字段,则只能存储double类型的数据。 Mapping不仅是告诉ES,哪个字段是哪种类型。还能告诉ES如何来索引数据,以及数据是否被索引到等。 Search Moudle,搜索模块,支持搜索的一些常用操作 Index Moudle,索引模块,支持索引的一些常用操作 Disvcovery,主要是负责集群的master节点发现。比如某个节点突然离开或进来的情况,进行一个分片重新分片等。这里有个发现机制。 发现机制默认的实现方式是单播和多播的形式,即Zen,同时也支持点对点的实现。另外一种是以插件的形式,即EC2。 Scripting,即脚本语言。包括很多,这里不多赘述。如mvel、js、python等。    Transport,代表ES内部节点,代表跟集群的客户端交互。包括 Thrift、Memcached、Http等协议 RESTful Style API,通过RESTful方式来实现API编程。 3rd plugins,代表第三方插件。 Java(Netty),是开发框架。 JMX,是监控。 使用案例 1、将ES作为网站的主要后端系统 比如现在搭建一个博客系统,对于博客帖子的数据可以直接在ES上存储,并且使用ES来进行检索,统计。ES提供了持久化的存储、统计和很多其他数据存储的特性。 注意:但是像其他的NOSQL数据存储一样,ES是不支持事务的,如果要事务机制,还是考虑使用其他的数据库做真实库。 2、将ES添加到现有系统 有些时候不需要ES提供所有数据的存储功能,只是想在一个数据存储的基础之上使用ES。比如已经有一个复杂的系统在运行,但是现在想加一个搜索的功能,就可以使用该方案。 3、将ES作为现有解决方案的后端部分 因为ES是开源的系统,提供了直接的HTTP接口,并且现在有一个大型的生态系统在支持他。比如现在我们想部署大规模的日志框架、用于存储、搜索和分析海量的事件,考虑到现有的工具可以写入和读取ES,可以不需要进行任何开发,配置这些工具就可以去运作。 设计结构 1、逻辑设计 文档 文档是可以被索引的信息的基本单位,它包含几个重要的属性: 是自我包含的。一篇文档同时包含字段和他们的取值。 是层次型的。文档中还可以包含新的文档,一个字段的取值可以是简单的,例如location字段的取值可以是字符串,还可以包含其他字段和取值,比如可以同时包含城市和街道地址。 拥有灵活的结构。文档不依赖于预先定义的模式。也就是说并非所有的文档都需要拥有相同的字段,并不受限于同一个模式 {   "name":"meeting",   "location":"office",   "organizer":"yanping" } {   "name":"meeting",   "location":{     "name":"sheshouzuo",        "date":"2019-6-28"   },   "memebers":["leio","shiyi"] } 类型 类型是文档的逻辑容器,类似于表格是行的容器。在不同的类型中,最好放入不同的结构的文档。 字段 ES中,每个文档,其实是以json形式存储的。而一个文档可以被视为多个字段的集合。 映射 每个类型中字段的定义称为映射。例如,name字段映射为String。 索引 索引是映射类型的容器一个ES的索引非常像关系型世界中的数据库,是独立的大量文档集合。   关系型数据库与ES的结构上的对比 2、物理设计 节点 一个节点是一个ES的实例,在服务器上启动ES之后,就拥有了一个节点,如果在另一个服务器上启动ES,这就是另一个节点。甚至可以在一台服务器上启动多个ES进程,在一台服务器上拥有多个节点。多个节点可以加入同一个集群。 当ElasticSearch的节点启动后,它会利用多播(multicast)(或者单播,如果用户更改了配置)寻找集群中的其它节点,并与之建立连接。这个过程如下图所示: 节点主要有3种类型,第一种类型是client_node,主要是起到请求分发的作用,类似路由。第二种类型是master_node,是主的节点,所有的新增,删除,数据分片都是由主节点操作(elasticsearch底层是没有更新数据操作的,上层对外提供的更新实际上是删除了再新增),当然也能承担搜索操作。第三种类型是date_node,该类型的节点只能做搜索操作,具体会分配到哪个date_node,就是由client_node决定,而data_node的数据都是从master_node同步过来的 分片 一个索引可以存储超出单个结点硬件限制的大量数据。比如,一个具有10亿文档的索引占据1TB的磁盘空间,而任一节点都没有这样大的磁盘空间;或者单个节点处理搜索请求,响应太慢。   为了解决这个问题,ES提供了将索引划分成多份的能力,这些份就叫做分片。当你创建一个索引的时候,你可以指定你想要的分片的数量。每个分片本身也是一个功能完善并且独立的“索引”,这个“索引”可以被放置到集群中的任何节点上。 分片之所以重要,主要有两方面的原因:   1、允许你水平分割/扩展你的内容容量 允许你在分片(潜在地,位于多个节点上)之上进行分布式的、并行的操作,进而提高性能/吞吐量 至于一个分片怎样分布,它的文档怎样聚合回搜索请求,是完全由ES管理的,对于作为用户的你来说,这些都是透明的。   2、在一个网络/云的环境里,失败随时都可能发生,在某个分片/节点不知怎么的就处于离线状态,或者由于任何原因消失了。这种情况下,有一个故障转移机制是非常有用并且是强烈推荐的。为此目的,ES允许你创建分片的一份或多份拷贝,这些拷贝叫做复制分片,或者直接叫复制。 复制之所以重要,主要有两方面的原因: (1)在分片/节点失败的情况下,提供了高可用性。因为这个原因,注意到复制分片从不与原/主要(original/primary)分片置于同一节点上是非常重要的。 (2)扩展你的搜索量/吞吐量,因为搜索可以在所有的复制上并行运行 总之,每个索引可以被分成多个分片。一个索引也可以被复制0次(意思是没有复制)或多次。一旦复制了,每个索引就有了主分片(作为复制源的原来的分片)和复制分片(主分片的拷贝)之别。分片和复制的数量可以在索引创建的时候指定。在索引创建之后,你可以在任何时候动态地改变复制数量,但是不能改变分片的数量。   默认情况下,ES中的每个索引被分片5个主分片和1个复制,这意味着,如果你的集群中至少有两个节点,你的索引将会有5个主分片和另外5个复制分片(1个完全拷贝),这样的话每个索引总共就有10个分片。一个索引的多个分片可以存放在集群中的一台主机上,也可以存放在多台主机上,这取决于你的集群机器数量。主分片和复制分片的具体位置是由ES内在的策略所决定的。 3、插件HEAD elasticsearch-head是一个界面化的集群操作和管理工具 ● node:即一个 Elasticsearch 的运行实例,使用多播或单播方式发现 cluster 并加入。 ● cluster:包含一个或多个拥有相同集群名称的 node,其中包含一个master node。 ● index:类比关系型数据库里的DB,是一个逻辑命名空间。 ● alias:可以给 index 添加零个或多个alias,通过 alias 使用index 和根据index name 访问index一样,但是,alias给我们提供了一种切换index的能力,比如重建了index,取名● customer_online_v2,这时,有了alias,我要访问新 index,只需要把 alias 添加到新 index 即可,并把alias从旧的 index 删除。不用修改代码。 ● type:类比关系数据库里的Table。其中,一个index可以定义多个type,但一般使用习惯仅配一个type。 ● mapping:类比关系型数据库中的 schema 概念,mapping 定义了 index 中的 type。mapping 可以显示的定义,也可以在 document 被索引时自动生成,如果有新的 field,Elasticsearch 会自动推测出 field 的type并加到mapping中。 ● document:类比关系数据库里的一行记录(record),document 是 Elasticsearch 里的一个 JSON 对象,包括零个或多个field。 ● field:类比关系数据库里的field,每个field 都有自己的字段类型。 ● shard:是一个Lucene 实例。Elasticsearch 基于 Lucene,shard 是一个 Lucene 实例,被 Elasticsearch 自动管理。之前提到,index 是一个逻辑命名空间,shard 是具体的物理概念,建索引、查询等都是具体的shard在工作。shard 包括primary shard 和 replica shard,写数据时,先写到primary shard,然后,同步到replica shard,查询时,primary 和 replica 充当相同的作用。replica shard 可以有多份,也可以没有,replica shard的存在有两个作用,一是容灾,如果primary shard 挂了,数据也不会丢失,集群仍然能正常工作;二是提高性能,因为replica 和 primary shard 都能处理查询。另外,如上图右侧红框所示,shard数和replica数都可以设置,但是,shard 数只能在建立index 时设置,后期不能更改,但是,replica 数可以随时更改。但是,由于 Elasticsearch 很友好的封装了这部分,在使用Elasticsearch 的过程中,我们一般仅需要关注 index 即可,不需关注shard。   shard、node、cluster 在物理上构成了 Elasticsearch 集群,field、type、index 在逻辑上构成一个index的基本概念,在使用 Elasticsearch 过程中,我们一般关注到逻辑概念就好,就像我们在使用MySQL 时,我们一般就关注DB Name、Table和schema即可,而不会关注DBA维护了几个MySQL实例、master 和 slave 等怎么部署的一样。 ES中的索引原理 (1)传统的关系型数据库 二叉树查找效率是logN,同时插入新的节点不必移动全部节点,所以用树型结构存储索引,能同时兼顾插入和查询的性能。因此在这个基础上,再结合磁盘的读取特性(顺序读/随机读),传统关系型数据库采用了B-Tree/B+Tree这样的数据结构做索引 (2)ES 采用倒排索引 那么,倒排索引是个什么样子呢? 首先,来搞清楚几个概念,为此,举个例子: 假设有个user索引,它有四个字段:分别是name,gender,age,address。画出来的话,大概是下面这个样子,跟关系型数据库一样 Term(单词):一段文本经过分析器分析以后就会输出一串单词,这一个一个的就叫做Term Term Dictionary(单词字典):顾名思义,它里面维护的是Term,可以理解为Term的集合 Term Index(单词索引):为了更快的找到某个单词,我们为单词建立索引 Posting List(倒排列表):倒排列表记录了出现过某个单词的所有文档的文档列表及单词在该文档中出现的位置信息,每条记录称为一个倒排项(Posting)。根据倒排列表,即可获知哪些文档包含某个单词。(PS:实际的倒排列表中并不只是存了文档ID这么简单,还有一些其它的信息,比如:词频(Term出现的次数)、偏移量(offset)等,可以想象成是Python中的元组,或者Java中的对象) (PS:如果类比现代汉语词典的话,那么Term就相当于词语,Term Dictionary相当于汉语词典本身,Term Index相当于词典的目录索引) 我们知道,每个文档都有一个ID,如果插入的时候没有指定的话,Elasticsearch会自动生成一个,因此ID字段就不多说了 上面的例子,Elasticsearch建立的索引大致如下: name字段: age字段: gender字段: address字段: Elasticsearch分别为每个字段都建立了一个倒排索引。比如,在上面“张三”、“北京市”、22 这些都是Term,而[1,3]就是Posting List。Posting list就是一个数组,存储了所有符合某个Term的文档ID。 只要知道文档ID,就能快速找到文档。可是,要怎样通过我们给定的关键词快速找到这个Term呢? 当然是建索引了,为Terms建立索引,最好的就是B-Tree索引(MySQL就是B树索引最好的例子)。 我们查找Term的过程跟在MyISAM中记录ID的过程大致是一样的 MyISAM中,索引和数据是分开,通过索引可以找到记录的地址,进而可以找到这条记录 在倒排索引中,通过Term索引可以找到Term在Term Dictionary中的位置,进而找到Posting List,有了倒排列表就可以根据ID找到文档了 (PS:可以这样理解,类比MyISAM的话,Term Index相当于索引文件,Term Dictionary相当于数据文件) (PS:其实,前面我们分了三步,我们可以把Term Index和Term Dictionary看成一步,就是找Term。因此,可以这样理解倒排索引:通过单词找到对应的倒排列表,根据倒排列表中的倒排项进而可以找到文档记录) 为了更进一步理解,用两张图来具现化这一过程: (至于里面涉及的更加高深的数据压缩技巧,以及多个field联合查询利用跳表的数据结构快速做运算来查询,这些大家有兴趣可以自己去了解)
问问小秘 2020-04-29 15:40:48 0 浏览量 回答数 0

云产品推荐

上海奇点人才服务相关的云产品 小程序定制 上海微企信息技术相关的云产品 国内短信套餐包 ECS云服务器安全配置相关的云产品 开发者问答 阿里云建站 自然场景识别相关的云产品 万网 小程序开发制作 视频内容分析 视频集锦 代理记账服务 阿里云AIoT