How to create a PowerShell alias to connect MogDB

MogDB是云和恩墨发布的基于开源数据库openGauss的企业级发行版。在连接串方面兼容标准的PostgreSQL连接方式,而pgcli是连接PostgreSQL的一个优秀客户端程序。本文描述如何在Windows系统的Powershell中设置alias,来简便地连接到MogDB数据库。

pgcli的安装不再赘述,可以参考pgcli网站中描述的安装方法,比较简单。

使用pgcli连接数据库,并且同时把密码也放在连接串中完成一条命令就直接登录数据库,例子如下:

 pgcli postgres://amjith:passw0rd@example.com:5432/app_db

其中每个部分的含义如下:

  • postgres://是标准的数据库类型提示符,不需要变更;
  • amjith是连接数据库的用户名,passw0rd是用户密码;
  • example.com是数据库所在的服务器hostname,可以直接使用IP地址来替换;
  • 5432是数据库监听的端口;
  • app_db是需要连接的数据库名称。

需要注意的一点是,如果在密码中存在“@”这样的特殊字符,那么需要把@改写成“%40”,比如密码如果是passw0rd@123,则命令行需要写成:

pgcli postgres://amjith:passw0rd%40123@example.com:5432/app_db

接下来,我们需要设置一个更简单的alias,比如我习惯使用p1,设置完毕以后,在命令行窗口键入p1以后回车,就可以直接连接到目标数据库。

如果是macOS,我们可以直接设置.zshrc文件;如果是Linux,可以设置.bash_profile。那么在Windows操作系统中,如果使用Powershell,该如何设置?

首先,要找到Powershell的配置文件路径,当安装完Powershell之后,进入Powershell命令行。

PS C:\Users\kamus> echo $profile
D:\Documents\PowerShell\Microsoft.PowerShell_profile.ps1

如果没有该文件,则创建该文件,然后使用任何文本编辑器,在该文件中加入以下行。

Function pgcli_mogdb1 {pgcli --prompt "\u@\d> " postgres://amjith:passw0rd%40123@example.com:5432/app_db}
   Set-Alias -Name p1 -Value pgcli_mogdb1

因为Set-Alias命令的限制,一整条pgcli命令算是复杂命令,需要先写入到一个function中,然后再调用该function。

最后的效果如下:

PS C:\Users\kamus> p1
Server: PostgreSQL 9.2.4
Version: 3.1.0
Chat: https://gitter.im/dbcli/pgcli
Home: http://pgcli.com
mogdb@ocomp> select version();
+-------------------------------------------------------------------------------------------------------------------------------------------------------------------+
| version                                                                                                                                                           |
|-------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| PostgreSQL 9.2.4 (MogDB 2.0.0 build b75b585a) compiled at 2021-05-28 17:20:47 commit 0 last mr   on x86_64-unknown-linux-gnu, compiled by g++ (GCC) 7.3.0, 64-bit |
+-------------------------------------------------------------------------------------------------------------------------------------------------------------------+
SELECT 1
Time: 0.072s
mogdb@ocomp>

How to run PostgreSQL 11 in Linux on ARM

我们选择的系统是一个运行在AArch64芯片架构上的CentOS 7.5。

[root@ecs-arm-0005 ~]# uname -a
Linux ecs-arm-0005 4.14.0-49.el7a.aarch64 #1 SMP Tue Apr 10 17:22:26 UTC 2018 aarch64 aarch64 aarch64 GNU/Linux

[root@ecs-arm-0005 ~]# cat /etc/centos-release
CentOS Linux release 7.5.1804 (AltArch)

这台服务器拥有8颗ARMv8(Huawei Kunpeng 916 2.4GHz)的芯片,和29GB的内存,并不是很大的机器。

[root@ecs-arm-0005 ~]# cat /proc/cpuinfo | grep processor|wc -l
8

[root@ecs-arm-0005 ~]# cat /proc/meminfo | grep MemTotal
MemTotal:       29756224 kB

这台服务器有两块磁盘,一块是系统盘vda,一块是超高IO的数据盘vdb。vdb还没有创建文件系统,自然也没有挂载点。

[root@ecs-arm-0005 ~]# lsblk
NAME   MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
vdb    253:16   0  100G  0 disk
vda    253:0    0   40G  0 disk
├─vda2 253:2    0 39.8G  0 part /
└─vda1 253:1    0  244M  0 part /boot/efi

将vdb格式化为ext4格式的文件系统,挂载到/data目录中。作为后续Pg数据库的数据文件存储位置。

[root@ecs-arm-0005 ~]# mkfs -t ext4 /dev/vdb
mke2fs 1.42.9 (28-Dec-2013)
Filesystem label=
OS type: Linux
Block size=4096 (log=2)
Fragment size=4096 (log=2)
Stride=0 blocks, Stripe width=0 blocks
6553600 inodes, 26214400 blocks
1310720 blocks (5.00%) reserved for the super user
First data block=0
Maximum filesystem blocks=2174746624
800 block groups
32768 blocks per group, 32768 fragments per group
8192 inodes per group
Superblock backups stored on blocks:
    32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208,
    4096000, 7962624, 11239424, 20480000, 23887872

Allocating group tables: done
Writing inode tables: done

[root@ecs-arm-0005 ~]# mkdir /data
[root@ecs-arm-0005 ~]# mount /dev/vdb /data
[root@ecs-arm-0005 ~]# df -h
Filesystem      Size  Used Avail Use% Mounted on
devtmpfs         15G     0   15G   0% /dev
tmpfs            15G     0   15G   0% /dev/shm
tmpfs            15G   22M   15G   1% /run
tmpfs            15G     0   15G   0% /sys/fs/cgroup
/dev/vda2        40G  1.6G   36G   5% /
/dev/vda1       244M  8.6M  236M   4% /boot/efi
tmpfs           2.9G     0  2.9G   0% /run/user/0
/dev/vdb         99G   61M   94G   1% /data

如果要保证在操作系统重新启动的时候,vdb还会自动挂载到/data目录下,还需要修改/etc/fstab文件,此处不赘述。

因为Pg for ARM的版本并没有发布实现编译好的二进制安装包(实际上也有,但是是比较古老的9.2版本),因此首先我们下载PostgreSQL数据库最新版本11.3的源码。通过编译源码手动安装。

如果在下述过程中发现报错:configure: error: no acceptable C compiler found in $PATH,则表示没有安装gcc编译器,需要通过yum install gcc gcc-c++命令来事先安装。
如果在下述过程中发现报错:configure: error: readline library not found,则表示没有安装readline-devel包,需要通过yum install readline-devel命令来事先安装。
如果在下述过程中发现报错:configure: error: zlib library not found,则表示没有安装zlib-devel包,需要通过yum install zlib-devel命令来事先安装。

总结一下就是需要事先安装以下依赖包。

yum install gcc gcc-c++ readline-devel zlib-devel

从configure到make install都是标准的Linux下编译源码安装的步骤。如果一切正常,在第一步时不会显示任何error,在第二步最后会显示:All of PostgreSQL successfully made. Ready to install.字样。

$ ./configure
$ make
$ su
# make install

成功安装完毕以后,因为我们使用的是默认配置,因此PostgreSQL软件被安装到/usr/local/pgsql目录中。

[root@ecs-arm-0005 postgresql-11.3]# ls -l /usr/local/pgsql
total 16
drwxr-xr-x 2 root root 4096 Jun  4 16:01 bin
drwxr-xr-x 6 root root 4096 Jun  4 16:01 include
drwxr-xr-x 4 root root 4096 Jun  4 16:01 lib
drwxr-xr-x 6 root root 4096 Jun  4 16:01 share

接下来创建postgres用户,而不要使用root用户管理数据库。

# adduser postgres
# passwd postgres

之前我们在/data目录下挂载了100GB的高速IO数据盘,所以下面我们将PostgreSQL数据库的数据文件存储位置指定到/data目录下,并初始化数据库。

# mkdir /data/pgsql/data
# chown postgres /data/pgsql/data
# su - postgres
$ /usr/local/pgsql/bin/initdb -D /data/pgsql/data

初始化数据库的正常显示如下。

[postgres@ecs-arm-0005 ~]$ /usr/local/pgsql/bin/initdb -D /data/pgsql/data
The files belonging to this database system will be owned by user "postgres".
This user must also own the server process.

The database cluster will be initialized with locale "en_US.UTF-8".
The default database encoding has accordingly been set to "UTF8".
The default text search configuration will be set to "english".

Data page checksums are disabled.

fixing permissions on existing directory /data/pgsql/data ... ok
creating subdirectories ... ok
selecting default max_connections ... 100
selecting default shared_buffers ... 128MB
selecting dynamic shared memory implementation ... posix
creating configuration files ... ok
running bootstrap script ... ok
performing post-bootstrap initialization ... ok
syncing data to disk ... ok

WARNING: enabling "trust" authentication for local connections
You can change this by editing pg_hba.conf or using the option -A, or
--auth-local and --auth-host, the next time you run initdb.

Success. You can now start the database server using:

    /usr/local/pgsql/bin/pg_ctl -D /data/pgsql/data -l logfile start

数据库初始化结束以后显示的最后一条命令,告知了如果要启动数据库应该使用的命令。

[postgres@ecs-arm-0005 ~]$ /usr/local/pgsql/bin/pg_ctl -D /data/pgsql/data -l logfile start
waiting for server to start.... done
server started

至此,PostgreSQL 11.3在CentOS 7.5 on ARM上的安装和运行宣告完成。

[postgres@ecs-arm-0005 ~]$ psql
psql (11.3)
Type "help" for help.

postgres=# \db
       List of tablespaces
    Name    |  Owner   | Location
------------+----------+----------
 pg_default | postgres |
 pg_global  | postgres |
(2 rows)

PostgreSQL 9.5 new feature highlight: BRIN indexes

前几天PostgreSQL 9.5 Alpha 1版本刚刚发布,在新版本中吸引我注意的是BRIN index。为什么引人注意?因为这就是活脱脱的Oracle Exadata中的Storage Index和Oracle Database 12.1.0.2中的新功能Zone Maps。

Exadata的Storage Index不说了,因为那并非数据库范畴的解决方案,而Oracle数据库12.1.0.2中的新功能Zone Maps曾让我非常激动,但是最终发现该功能也只能在运行于Exadata上的Oracle中才能启用,略失望。

Zone Maps的解释如下:

Zone maps in an Oracle Database store minimum and maximum values of columns for a range of blocks (known as a zone). In addition to performing I/O pruning based on predicates of clustered fact tables, zone maps prune on predicates of dimension tables provided the fact tables are attribute-clustered by the dimension attributes though outer joins with the dimension tables.

BRIN index的解释如下:

BRIN stands for Block Range INdexes, and store metadata on a range of pages. At the moment this means the minimum and maximum values per block…So if a 10GB table of order contained rows that were generally in order of order date, a BRIN index on the order_date column would allow the majority of the table to be skipped rather than performing a full sequential scan.

同样的思路,在一个类索引结构中存储一定范围的数据块中某个列的最小和最大值,当查询语句中包含该列的过滤条件时,就会自动忽略那些肯定不包含符合条件的列值的数据块,从而减少IO读取量,提升查询速度。

以下借用Pg wiki中的例子解释BRIN indexes的强大。

 -- 创建测试表orders
 CREATE TABLE orders (
     id int,
     order_date timestamptz,
     item text);

 -- 在表中插入大量记录,Pg的函数generate_series非常好用。
 INSERT INTO orders (order_date, item)
 SELECT x, 'dfiojdso' 
 FROM generate_series('2000-01-01 00:00:00'::timestamptz, '2015-03-01 00:00:00'::timestamptz,'2 seconds'::interval) a(x);

 -- 该表目前有13GB大小,算是大表了。
 # \dt+ orders
                    List of relations
  Schema |  Name  | Type  | Owner | Size  | Description 
 --------+--------+-------+-------+-------+-------------
  public | orders | table | thom  | 13 GB | 
 (1 row)

 -- 以全表扫描的方式查询两天内的记录,注意这里预计需要30s,这是一个存储在SSD上Pg数据库,因此速度已经很理想了。
 # EXPLAIN ANALYSE SELECT count(*) FROM orders WHERE order_date BETWEEN '2012-01-04 09:00:00' and '2014-01-04 14:30:00';
                                                                          QUERY PLAN                                                                          
 -------------------------------------------------------------------------------------------------------------------------------------------------------------
  Aggregate  (cost=5425021.80..5425021.81 rows=1 width=0) (actual time=30172.428..30172.429 rows=1 loops=1)
    ->  Seq Scan on orders  (cost=0.00..5347754.00 rows=30907121 width=0) (actual time=6050.015..28552.976 rows=31589101 loops=1)
          Filter: ((order_date >= '2012-01-04 09:00:00+00'::timestamp with time zone) AND (order_date <= '2014-01-04 14:30:00+00'::timestamp with time zone))
          Rows Removed by Filter: 207652500
  Planning time: 0.140 ms
  Execution time: 30172.482 ms 
 (6 rows)

 -- 接下来在order_date列上创建一个BRIN index
 CREATE INDEX idx_order_date_brin
   ON orders
   USING BRIN (order_date);

 -- 查看这个BRIN index占多少物理空间,13GB的表,而BRIN index只有504KB大小,非常精简。
 # \di+ idx_order_date_brin
                               List of relations
  Schema |        Name         | Type  | Owner | Table  |  Size  | Description 
 --------+---------------------+-------+-------+--------+--------+-------------
  public | idx_order_date_brin | index | thom  | orders | 504 kB | 
 (1 row)

 -- 再次执行相同的SQL,看看性能提升多少。速度上升到只需要6秒钟,提升了5倍。如果这是存储在HDD上的Pg库,这个效果还能更明显。
 # EXPLAIN ANALYSE SELECT count(*) FROM orders WHERE order_date BETWEEN '2012-01-04 09:00:00' and '2014-01-04 14:30:00';
                                                                               QUERY PLAN                                                                               
 -----------------------------------------------------------------------------------------------------------------------------------------------------------------------
  Aggregate  (cost=2616868.60..2616868.61 rows=1 width=0) (actual time=6347.651..6347.651 rows=1 loops=1)
    ->  Bitmap Heap Scan on orders  (cost=316863.99..2539600.80 rows=30907121 width=0) (actual time=36.366..4686.634 rows=31589101 loops=1)
          Recheck Cond: ((order_date >= '2012-01-04 09:00:00+00'::timestamp with time zone) AND (order_date <= '2014-01-04 14:30:00+00'::timestamp with time zone))
          Rows Removed by Index Recheck: 6419
          Heap Blocks: lossy=232320
          ->  Bitmap Index Scan on idx_order_date_brin  (cost=0.00..309137.21 rows=30907121 width=0) (actual time=35.567..35.567 rows=2323200 loops=1)
                Index Cond: ((order_date >= '2012-01-04 09:00:00+00'::timestamp with time zone) AND (order_date <= '2014-01-04 14:30:00+00'::timestamp with time zone))
  Planning time: 0.108 ms
  Execution time: 6347.701 ms
 (9 rows)

 --能够让用户自行设定一个range中可以包含的数据块数,也是很体贴的设计。默认情况下一个range包含128个page,我们可以修改为更小或者更大,包含的page越少则精度越细,相应的BRIN index也就会越大;反之则精度粗,BRIN index小。
 -- 创建一个每个range包含32 pages的索引。
 CREATE INDEX idx_order_date_brin_32
 ON orders
 USING BRIN (order_date) WITH (pages_per_range = 32);
 
 -- 再创建一个每个range包含512 pages的索引。
 CREATE INDEX idx_order_date_brin_512
 ON orders
 USING BRIN (order_date) WITH (pages_per_range = 512);

--比较一下各个索引的大小。
 # \di+ idx_order_date_brin*
                                  List of relations
  Schema |          Name           | Type  | Owner | Table  |  Size   | Description 
 --------+-------------------------+-------+-------+--------+---------+-------------
  public | idx_order_date_brin     | index | thom  | orders | 504 kB  | 
  public | idx_order_date_brin_32  | index | thom  | orders | 1872 kB | 
  public | idx_order_date_brin_512 | index | thom  | orders | 152 kB  | 
 (3 rows)

延展阅读:
Postgres 9.5 feature highlight: BRIN indexes
WAITING FOR 9.5 – BRIN: BLOCK RANGE INDEXES