您当前的位置:首页 > 生活常识

phoenix如何用(vultr怎么用)

时间:2023-05-08 12:30:43

phoenix如何用(vultr怎么用)?如果你对这个不了解,来看看!

phoenix全局索引和本地索引测试,下面是爱音乐的程序员小新人给大家的分享,一起来看看。

phoenix如何用

1.测试表说明

原hbase表是只有1个列族,算上rowkey一共6个字段的hbase表。

一共37个regions,数据量一共3亿6千4百万

hbase中表描述

数据样例

数据量

2.建立索引

hbase的二级索引在phoenix中建立。

建索引的语句如下,建好索引之后,有数据的变更索引数据和原始数据会实时的同步更新

create index car_index_index1 on car(hphm)

1

因为这张表是已经存在的大表,而且数据量也不少,直接用上面的语句建立索引时间会很长,所以这里用批量建立索引的方式

#首先在phoenix中建立索引表信息

create index car_index_datehphm on "car"("f1"."date","f1"."hphm") include ("f1"."coorid","f1"."cx","f1"."ys") async;

#这里的建立索引语句加了async,异步建立索引。另外f1是hbase中原始的列族名,这张表是原始hbase表转过来的,为什么这么写就不解释了,"f1"."date"就代表一个字段。include是什么后面再解释

#下面启动批量建立索引的mr任务

${HBASE_HOME}/bin/hbase org.apache.phoenix.mapreduce.index.IndexTool \

--data-table "car" --index-table CAR_INDEX_DATEHPHM \

--output-path ASYNC_IDX_HFILES

12345678

3亿6千万的数据,批量建立索引时间为1小时10分钟

3.索引测试

上面的建立的索引是两个字段的复合索引。可以分别对两个字段进行单独或者一起的条件过滤查询

##车牌查询

0: jdbc:phoenix:localhost:2181:/hbase> select * from "car" where "f1"."hphm" like '苏E3G%' limit 10;

+-------------------------+---------+------+-----------------+----------+-----+

| ID | coorid | cx | date | hphm | ys |

+-------------------------+---------+------+-----------------+----------+-----+

| 20170101005027_苏E3G2SA | t | 奔驰 | 20170101005027 | 苏E3G2SA | 黄 |

| 20170101011949_苏E3GS62 | � | 奥迪 | 20170101011949 | 苏E3GS62 | 银 |

| 20170101014325_苏E3G7S8 | � | 丰田 | 20170101014325 | 苏E3G7S8 | 银 |

| 20170101022906_苏E3GPQB | D | 保时捷 | 20170101022906 | 苏E3GPQB | 黄 |

| 20170101030015_苏E3G2SA | | 奔驰 | 20170101030015 | 苏E3G2SA | 黄 |

| 20170101030157_苏E3G2SA | � | 奔驰 | 20170101030157 | 苏E3G2SA | 黄 |

| 20170101033901_苏E3G117 | � | 奥迪 | 20170101033901 | 苏E3G117 | 蓝 |

| 20170101040047_苏E3G7S8 | | 丰田 | 20170101040047 | 苏E3G7S8 | 银 |

| 20170101040114_苏E3G8CW | * | 宝马 | 20170101040114 | 苏E3G8CW | 黄 |

| 20170101041608_苏E3G6GH | $ | 奔驰 | 20170101041608 | 苏E3G6GH | 红 |

+-------------------------+---------+------+-----------------+----------+-----+

10 rows selected (1.767 seconds)

用时1.767秒,分析原因为车牌种类比较少,筛选出的速度会稍微慢点,如果建立二级索引第一个字段用车牌,速度应该会快很多。

## 日期查询

0: jdbc:phoenix:localhost:2181:/hbase> select * from "car" where "f1"."date">='20170110' and "f1"."date"<='20170210' limit 10;

+-------------------------+---------+------+-----------------+----------+-----+

| ID | coorid | cx | date | hphm | ys |

+-------------------------+---------+------+-----------------+----------+-----+

| 20170110000000_京AM7BPF | t | 丰田 | 20170110000000 | 京AM7BPF | 白 |

| 20170110000000_京C4SS4G | � | 大众 | 20170110000000 | 京C4SS4G | 红 |

| 20170110000000_新D5AGEG | � | 宝马 | 20170110000000 | 新D5AGEG | 黄 |

| 20170110000000_新DFMM96 |

| 奔驰 | 20170110000000 | 新DFMM96 | 黄 |

| 20170110000000_沪HB1R23 | � | 保时捷 | 20170110000000 | 沪HB1R23 | 银 |

| 20170110000000_沪IMARPP | � | 丰田 | 20170110000000 | 沪IMARPP | 白 |

| 20170110000000_沪KR5QA2 | � | 日产 | 20170110000000 | 沪KR5QA2 | 黑 |

| 20170110000000_浙KQDWM9 | � | 日产 | 20170110000000 | 浙KQDWM9 | 黑 |

| 20170110000000_湘BMPWCM | � | 奔驰 | 20170110000000 | 湘BMPWCM | 银 |

| 20170110000000_湘HHS4E9 | � | 日产 | 20170110000000 | 湘HHS4E9 | 红 |

+-------------------------+---------+------+-----------------+----------+-----+

10 rows selected (0.049 seconds)

用时为49毫秒。

##日期车牌查询

0: jdbc:phoenix:localhost:2181:/hbase> select * from "car" where "f1"."date">='20170110' and "f1"."date"<='20170210' and "f1"."hphm" like '.E3G%' limit 10;

+-------------------------+---------+------+-----------------+----------+-----+

| ID | coorid | cx | date | hphm | ys |

+-------------------------+---------+------+-----------------+----------+-----+

| 20170110005537_苏E3GS62 | � | 奥迪 | 20170110005537 | 苏E3GS62 | 银 |

| 20170110010344_苏E3G21Q | K | 讴歌 | 20170110010344 | 苏E3G21Q | 黄 |

| 20170110013131_苏E3G21Q | � | 讴歌 | 20170110013131 | 苏E3G21Q | 黄 |

| 20170110013318_苏E3G21Q | � | 讴歌 | 20170110013318 | 苏E3G21Q | 黄 |

| 20170110013452_苏E3GQCF | C | 沃尔沃 | 20170110013452 | 苏E3GQCF | 白 |

| 20170110034239_苏E3G7S8 | � | 丰田 | 20170110034239 | 苏E3G7S8 | 银 |

| 20170110041044_苏E3G2SA | 6 | 奔驰 | 20170110041044 | 苏E3G2SA | 黄 |

| 20170110041829_苏E3GEM2 | m | 讴歌 | 20170110041829 | 苏E3GEM2 | 蓝 |

| 20170110045503_苏E3G2SA | | 奔驰 | 20170110045503 | 苏E3G2SA | 黄 |

| 20170110050616_苏E3GS62 | O | 奥迪 | 20170110050616 | 苏E3GS62 | 银 |

+-------------------------+---------+------+-----------------+----------+-----+

10 rows selected (0.706 seconds)

用时700多毫秒

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657

4.索引类型

phoenix的索引大致分为两类global index和local index,好像和星环有点类似,其实这是hbase二级索引解决方案里面广为人知的两种方案,侧重点不同,使用场景也不一样。

global index,global是默认的索引格式。官方文档翻译过来的:Global indexing适用于多读少写的业务场景。使用Global indexing的话在写数据的时候会消耗大量开销,因为所有对数据表的更新操作(DELETE, UPSERT VALUES and UPSERT SELECT),会引起索引表的更新,而索引表是分布在不同的数据节点上的,跨节点的数据传输带来了较大的性能消耗。在读数据的时候Phoenix会选择索引表来降低查询消耗的时间。在默认情况下如果想查询的字段不是索引字段的话索引表不会被使用,也就是说不会带来查询速度的提升。Local index,适用于写操作频繁的场景。与Global index一样,Phoenix会自动判定在进行查询的时候是否使用索引。使用Local indexing时,索引数据和数据表的数据是存放在相同的服务器中的避免了在写操作的时候往不同服务器的索引表中写索引带来的额外开销。使用Local indexing的时候即使查询的字段不是索引字段索引表也会被使用,这会带来查询速度的提升,这点跟Global indexing不同。一个数据表的所有索引数据都存储在一个单一的独立的可共享的表中。

官方文档上写的太书面了,下面用几个例子就能明白这两种索引格式是怎么设计以及怎样运行原理了。

4.1 global index 测试

上面的测试例子用的是global index,后面的例子为了快,就建立一些测试表。

##建立表

create table test_global(id varchar primary key,f1 varchar,f2 varchar);

##建立global index

create index test_global_index on test_global(f1) include(f2);

##插入两条数据

upsert into test_global values('1','2','3');

upsert into test_global values('4','5','6');

##查看索引表数据

select * from test_global_index;

+-------+------+-------+

| 0:F1 | :ID | 0:F2 |

+-------+------+-------+

| 2 | 1 | 3 |

| 5 | 4 | 6 |

+-------+------+-------+

2 rows selected (0.037 seconds)

##查看hbase表上面的数据

scan 'TEST_GLOBAL_INDEX'

hbase(main):002:0> scan 'TEST_GLOBAL_INDEX'

ROW COLUMN+CELL

2\x001 column=0:\x00\x00\x00\x00, timestamp=1501489856443, value=\x00\x00\x00\x00

2\x001 column=0:\x80\x0B, timestamp=1501489856443, value=3

5\x004 column=0:\x00\x00\x00\x00, timestamp=1501489860185, value=\x00\x00\x00\x00

5\x004 column=0:\x80\x0B, timestamp=1501489860185, value=6

2 row(s) in 0.0620 seconds

12345678910111213141516171819202122232425

global index

1.以上可以看出global index的设计方式,会单独写一张索引表,列族为include字段,rowkey的设计方位是:

二级索引字段1+”\x00”+二级索引字段2(复合索引)…+”\x00”+原表rowkey

2.查询的时候,会直接定位到索引表,通过rowkey查到位置,然后从索引表中带出数据

3.因为建立索引的时候还要多写一份include字段,读的时候直接从索引表定位并读出信息。所以这种表的应用场景定位是写的慢,读得快

4.2 local index 测试

##建立表

create table test_local(id varchar primary key,f1 varchar,f2 varchar);

##建立local index

create local index test_local_index on test_local(f1);

##插入两条数据

upsert into test_local values('1','2','3');

upsert into test_local values('4','5','6');

##local index 并不会创建新的表,而是在原来的表里面写入索引数据

##查看hbase表中数据

hbase(main):014:0> scan 'TEST_LOCAL'

ROW COLUMN+CELL

\x00\x002\x001 column=L#0:\x00\x00\x00\x00, timestamp=1501491310774, value=\x00\x00\x00\x00

\x00\x005\x004 column=L#0:\x00\x00\x00\x00, timestamp=1501491315118, value=\x00\x00\x00\x00

1 column=0:\x00\x00\x00\x00, timestamp=1501491310774, value=x

1 column=0:\x80\x0B, timestamp=1501491310774, value=2

1 column=0:\x80\x0C, timestamp=1501491310774, value=3

4 column=0:\x00\x00\x00\x00, timestamp=1501491315118, value=x

4 column=0:\x80\x0B, timestamp=1501491315118, value=5

4 column=0:\x80\x0C, timestamp=1501491315118, value=6

4 row(s) in 0.0250 seconds

1234567891011121314151617181920

local index

1.以上可以看出local index的设计方式,索引数据直接写在原表rowkey中,列族不写任何实际信息,local index的rowkey的设计方位是:

原数据region的start key+”\x00”+二级索引字段1+”\x00”+二级索引字段2(复合索引)…+”\x00”+原rowkey

第一条信息”原数据region的start key”,这样做的目的是保证索引数据和原数据在一个region上,定位到二级索引后根据原rowkey就可以很快在本region上获取到其它信息,减少网络开销和检索成本。

2.查询的时候,会在不同的region里面分别对二级索引字段定位,查到原rowkey后在本region上获取到其它信息

3.因为这种索引设计方式只写索引数据,省了不少空间的占用,根据索引信息拿到原rowkey后再根据rowkey到原数据里面获取其它信息。所以这种表的应用场景定位是写的快,读得慢

4.3 local index和global index比较

1.索引数据

global index单独把索引数据存到一张表里,保证了原始数据的安全,侵入性小local index把数据写到原始数据里面,侵入性强,原表的数据量=原始数据+索引数据,使原始数据更大

2.性能方面

global index要多写出来一份数据,写的压力就大一点,但读的速度就非常快local index只用写一份索引数据,节省不少空间,但多了一步通过rowkey查找数据,写的速度非常快,读的速度就没有直接取自己的列族数据快。

4.4其它

phoenix大的方面分为这两种索引,细的方面可以分为4种。phoenix还另外加了一种配置,根据索引是否可变,意思就是为了减少写入的压力,索引表只建立一次不会更改。

5.总结

用phoenix只是用hbase自身实现了hbase自己的二级索引,用hbase自己rowkey查询的特点来设计索引数据的rowkey,性能方面完全要靠一次检索索引数据的数据量大小了,所以具体业务具体分析。

vultr怎么用

前言

尽管在 2010 左右 IPV6 就开始刷存在感了,但是直到美帝把 IPV4 的资源都分配完了,IPV6 依旧没有获得很好的支持。

但是最近在开发者的圈子里,IPV6 开始怒刷存在感,因为苹果现在开始需要每一个 APP 都支持 IPV6-Only 环境下的使用。我觉得这是一件好事,如果不好好推动一把, IPV6 的体验始终不会跟上去。所以,如果苹果不推,那么迟早谷歌也会强推 IPV6。

就像谷歌

IPv6-Only

IPv6-Only 意味着网络下只能连接上 IPv6 地址,没有 IPV4 的存在,这也就意味着 DNS 缓存服务器也必须是 IPv6 地址,只能连接上支持 IPv6 的服务器。如果要解析一个域名,域名本身及其所属的根域名的 DNS 服务器也必须统统支持 IPv6。

域名所属的根域名的 DNS 服务器 支持 IPv6

域名使用的 DNS 解析和 DNS 服务器 支持 IPv6

服务器 支持 IPV6,并拥有 IPV6 ip 资源

服务器系统和 Web 软件 支持 IPV6

域名和 DNS 服务

在 顶级域名的 IPV6 支持报告 中,我们可以看到截止本文发布,仅 98.1% 的顶级域名都已经支持 IPV6 的解析了。像:com、net、biz、cloud、top 都是支持的。

然后是 DNS 服务器了,国外的例如 CloudFlare、NS1、Rage53、DNSimple、Rage4 等,国内的 DnsPod、百度云加速、sDNS 都已经支持了。 不过截止本文发布,阿里云 DNS、Cloudxns 还不支持 IPV6-Only。

DNS 解析 IPV6,对应的是 AAAA 记录。 IPV4 对应的是 A 记录。

服务器支持 IPV6

目前,国外的 DigitalOcean、Vultr、Linode 都是默认分配 IPV6 IP 的,很多一些 VPS 品牌甚至会赠送一个段的 IPV6 资源。而在国内目前看来,无论是 阿里云、青云、腾讯云 还是其他,都并没有很好的 IPV6 支持。

如果我们的网站或应用托管在阿里云或者其他云上,那么要让其支持 IPV6-Only,那么目前有两种可行的方案就是:

服务器在第三层(网络层)使用隧道传输来曲线支持 IPV6

HTTP Proxy ,让支持 IPV6 的服务器做反向代理,将 AAAA 记录解析到代理服务器上

使用 CDN 缓存,像 CloudFlare 这样的 CDN 只要使用就可以支持 IPV6

不过,上述的三种,都有一定缺陷,其中第一种缺陷最少,几乎原生;而反代受限于反代服务器的延时,而且建设成本也挺高的;CDN 缓存么,像 Cloudflare 在国内速度并不理想

隧道传输支持 IPV6

这里介绍使用 Hurricane Electric Free IPv6 Tunnel Broker 来拓展服务器支持 IPV6.Tunnel Broker 相当于建立在网络层(第三层)上的代理,需要你的服务器的操作系统支持,而且服务器必须要有一个固定的 IPv4 地址。

一、注册,https://www.tunnelbroker.net/ 记得,别忘了验证邮箱

二、创建隧道,https://www.tunnelbroker.net/new_tunnel.php

三、IPv4 Endpoint (Your side): 输入服务器的 IP ; Available Tunnel Servers: 这里选择一个延时最低的地域。经过测试亚洲的 香港、新加坡、日本 国内访问还都挺糟糕的。 推荐 Fremont。

四、点击 Create Tunnel 就创建好了,

五、修改网络参数,使系统支持 IPV6。编辑 /etc/sysctl.conf 将

net.ipv6.conf.all.disable_ipv6 = 1net.ipv6.conf.default.disable_ipv6 = 1net.ipv6.conf.lo.disable_ipv6 = 1

修改为

net.ipv6.conf.all.disable_ipv6 = 0net.ipv6.conf.default.disable_ipv6 = 0net.ipv6.conf.lo.disable_ipv6 = 0

再运行 sysctl -p 的命令,启用IPv6

root@MF8.BIZ:~# sysctl -pnet.ipv6.conf.all.disable_ipv6 = 0net.ipv6.conf.default.disable_ipv6 = 0net.ipv6.conf.lo.disable_ipv6 = 0vm.swappiness = 0net.ipv4.neigh.default.gc_stale_time = 120net.ipv4.conf.all.rp_filter = 0net.ipv4.conf.default.rp_filter = 0net.ipv4.conf.default.arp_announce = 2net.ipv4.conf.all.arp_announce = 2net.ipv4.tcp_max_tw_buckets = 5000net.ipv4.tcp_syncookies = 1net.ipv4.tcp_max_syn_backlog = 1024net.ipv4.tcp_synack_retries = 2net.ipv4.conf.lo.arp_announce = 2net.ipv4.conf.lo.arp_announce = 2

六、在 HE 哪里,点击 Example Configurations,然后选择自己的系统,这里以 Debian 8.5 为例。

修改 /etc/network/interfaces 文件,在下面加上,如图片中列出的代码

保存,然后重启系统。

七、确认开启。

执行 ifup he-ipv6 确认 IPv6 已启用。

root@MF8.BIZ:~# ifup he-ipv6ifup: interface he-ipv6 already configuredifup: interface he-ipv6 already configured

八、DNS 添加 AAAA 记录到分配的 IP 上。

Web 服务器软件确认开启

并不是服务器开启 IPV6,就一切 OK 了。在 Apache 、Nginx 这样的 WEb 服务器软件上依旧要进行相关设置。

Nginx

server { listen 80; // 监听 IPv4 的 80 端口 listen [::]:80; // 监听 IPv6 的 80 端口}server { listen 443 ssl http2; // 监听 IPv4 的 443 端口 listen [::]:443 ssl http2; // 监听 IPv6 的 443 端口}

Apache HTTPD

Listen 服务器 IPV4 IP:8080Listen [分配的 IPV6 IP]:8080

都别忘记重启!

检测

dig

支持 dig 的系统,可以使用 dig aaaa 来检测域名是否正确解析 IPV6

WWW.MF8.BIZ'S-NOTEBOOK:~ MF8$ dig mirrors6.tuna.tsinghua.edu.cn aaaa; <<>> DiG 9.8.3-P1 <<>> mirrors6.tuna.tsinghua.edu.cn aaaa;; global options: +cmd;; Got answer:;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 64171;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0;; QUESTION SECTION:;mirrors6.tuna.tsinghua.edu.cn. IN AAAA;; ANSWER SECTION:mirrors6.tuna.tsinghua.edu.cn. 300 IN CNAME mirrors6.a.s.tuna.tsinghua.edu.cn.mirrors6.a.s.tuna.tsinghua.edu.cn. 300 IN AAAA 2402:f000:1:416:166:111:206:63;; Query time: 623 msec;; SERVER: 223.6.6.6#53(223.6.6.6);; WHEN: Tue Sep 6 11:55:31 2016;; MSG SIZE rcvd: 102

IPV6 test

http://ipv6-test.com/validate.php 可以很方便详细的检测 IPV6 的支持情况。

索引

最新文章