包含postgresql维度的词条
postgresql 和postgis区别是什么?
了存储、查询和修改空间关系的能力。本文中 ‘PostgreSQL’ 指代基本的关系数据库功能,而 ‘PostGIS’ 指代扩展的空间操作特性。
商河ssl适用于网站、小程序/APP、API接口等需要进行数据传输应用场景,ssl证书未来市场广阔!成为成都创新互联公司的ssl证书销售渠道,可以享受市场价格4-6折优惠!如果有意向欢迎电话联系或者加微信:18980820575(备注:SSL证书合作)期待与您的合作!
客户端-服务器构架
PostgreSQL 同众多数据库产品一样,采用客户端-服务器构架。客户端向服务器发出请求并得到响应。这种机制同浏览器从网络服务器获取网页类似。在 PostgreSQL 中,请求以 SQL 语言发出,而响应多为从数据库提取的表单。
客户端与服务器可以部署在同一台设备上,即 PostgreSQL 可以在单一的计算机上使用。借由系统内部的 ‘loopback’ 通信机制,数据库系统可以进行私密通讯。除非专门配置,外界是不能访问这些信息的。
本位介绍三种客户端:命令行, Quantum GIS , pgAdmin 图形化数据库客户端。
创造具有空间信息处理能力的数据库
命令行客户端在终端模拟器(Terminal Emulator)中运行。在 Applications 菜单的 Accessories 中打开一个终端模拟器,将显示一个 Unix 风格的命令行界面。输入:
psql -V
回车确认,将显示 PostgreSQL 版本号。
一个 PostgreSQL 服务器中,可以将不同的任务组织到不同的数据库。每个数据库独立运作,拥有专门的表单、显示、用户等。访问 PostgreSQL 数据库时将指定一个数据库。
服务器上数据库列表通过以下命令查询:
psql -l
输出将罗列 Live 上配置的几个数据库。这里演示新建一个。
PostgreSQL 使用 createdb 工具创建数据库。这里建立的数据库应带有 PostGIS 的扩展功能,因此需要指定相应的模板。这里将新建数据库称为 demo 。命令为:
createdb-Ttemplate_postgisdemo
现在执行 psql-l 应当可以看到 demo 数据库。
也可以使用 SQL 语言创建 PostGIS 数据库。首先使用 dropdb 命令删除之前创建的数据库,然后使用 psql 命令开启 SQL 命令解析器:
dropdbdemopsql-dpostgres
这样就连接到了一个通用的系统数据库 postgres 。输入 SQL 命令建立新数据库:
postgres=# CREATE DATABASE demo TEMPLATE=template_postgis;
现在可以转换连接到新建的数据库。若重新连接时可以使用 psql-ddemo 命令。但在 psql 系统内部也可以使用以下命令:
postgres=# \c demo
一个信息页面将显示当前已连接 demo 数据库。输入 \dt 列出当前数据库内的表单,输出如下:
demo=# \dtListofrelationsSchema|Name|Type|Owner--------+------------------+-------+-------public|geometry_columns|table|userpublic|spatial_ref_sys|table|user(2rows)
这两个表格是 PostGIS 默认的。其中 spatial_ref_sys 存储着合法的空间坐标系统。利用 SQL 查询查看:
demo=# SELECT srid,auth_name,proj4text FROM spatial_ref_sys LIMIT 10;srid|auth_name|proj4text------+-----------+--------------------------------------3819|EPSG|+proj=longlat+ellps=bessel+towgs...3821|EPSG|+proj=longlat+ellps=aust_SA+no_d...3824|EPSG|+proj=longlat+ellps=GRS80+towgs8...3889|EPSG|+proj=longlat+ellps=GRS80+towgs8...3906|EPSG|+proj=longlat+ellps=bessel+no_de...4001|EPSG|+proj=longlat+ellps=airy+no_defs...4002|EPSG|+proj=longlat+a=6377340.189+b=63...4003|EPSG|+proj=longlat+ellps=aust_SA+no_d...4004|EPSG|+proj=longlat+ellps=bessel+no_de...4005|EPSG|+proj=longlat+a=6377492.018+b=63...(10rows)
以上显示确认了该数据库已经建立空间操作功能。数据库中的 geometry_columns 用于记录那些表格是有空间信息的。
手工建立空间数据表格
空间数据库已经建立,现在可以建立具有空间信息的表格。
首先建立一个常规的表格存储有关城市(cities)的信息。这个表格有两栏,一个是 ID 编号,一个是城市名:
demo=# CREATE TABLE cities ( id int4, name varchar(50) );
现在添加一个空间栏用于存储城市的位置。习惯上这个栏目叫做 the_geom 。它记录了数据为什么类型(点、线、面)、有几维(这里是二维)以及空间坐标系统。此处使用 EPSG:4326 坐标系统:
demo=# SELECT AddGeometryColumn ('cities', 'the_geom', 4326, 'POINT', 2);
完成后,查询 cities 表单应当显示这个新栏目。同时页面将显示当前表达没有记录(0 rows)。
demo=# SELECT * from cities;id|name|the_geom----+------+----------(0rows)
为添加记录,需要使用 SQL 命令。对于空间栏,使用 PostGIS 的 ST_GeomFromText 可以将文本转化为坐标与参考系号的记录:
demo=# INSERT INTO cities (id, the_geom, name) VALUES (1,ST_GeomFromText('POINT(-0.1257 51.508)',4326),'London, England');demo=# INSERT INTO cities (id, the_geom, name) VALUES (2,ST_GeomFromText('POINT(-81.233 42.983)',4326),'London, Ontario');demo=# INSERT INTO cities (id, the_geom, name) VALUES (3,ST_GeomFromText('POINT(27.91162491 -33.01529)',4326),'East London,SA');
当然,这样的输入方式难以操作。其它方式可以更快的输入数据。就目前来说,表格内已经有了一些城市数据,可以先进行查询等操作。
简单查询
标准的 SQL 操作都可以用于 PostGIS 表单:
demo=# SELECT * FROM cities;id|name|the_geom----+-----------------+----------------------------------------------------1|London,England|0101000020E6100000BBB88D06F016C0BF1B2FDD2406C149402|London,Ontario|0101000020E6100000F4FDD478E94E54C0E7FBA9F1D27D45403|EastLondon,SA|0101000020E610000040AB064060E93B4059FAD005F58140C0(3rows)
这里的坐标是无法阅读的 16 进制格式。要以 WKT 文本显示,使用 ST_AsText(the_geom) 或 ST_AsEwkt(the_geom) 函数。也可以使用 ST_X(the_geom) 和 ST_Y(the_geom) 显示一个维度的坐标:
demo=# SELECT id, ST_AsText(the_geom), ST_AsEwkt(the_geom), ST_X(the_geom), ST_Y(the_geom) FROM cities;id|st_astext|st_asewkt|st_x|st_y----+------------------------------+----------------------------------------+-------------+-----------1|POINT(-0.125751.508)|SRID=4326;POINT(-0.125751.508)|-0.1257|51.5082|POINT(-81.23342.983)|SRID=4326;POINT(-81.23342.983)|-81.233|42.9833|POINT(27.91162491-33.01529)|SRID=4326;POINT(27.91162491-33.01529)|27.91162491|-33.01529(3rows)
空间查询:
PostGIS 为 PostgreSQL 扩展了许多空间操作功能。以上已经涉及了转换空间坐标格式的 ST_GeomFromText 。多数空间操作以 ST(spatial type)开头,在 PostGIS 文档相应章节有罗列。这里回答一个具体的问题:以米为单位并假设地球是完美椭球,上面三个城市相互的距离是多少?
demo=# SELECT p1.name,p2.name,ST_Distance_Sphere(p1.the_geom,p2.the_geom) FROM cities AS p1, cities AS p2 WHERE p1.id p2.id;name|name|st_distance_sphere-----------------+-----------------+--------------------London,Ontario|London,England|5875766.85191657EastLondon,SA|London,England|9789646.96784908EastLondon,SA|London,Ontario|13892160.9525778(3rows)
输出显示了距离数据。注意 ‘WHERE’ 部分防止了输出城市到自身的距离(0)或者两个城市不同排列的距离数据(London, England 到 London, Ontario 和 London, Ontario 到 London, England 的距离是一样的)。尝试取消 ‘WHERE’ 并查看结果。
这里采取不同的椭球参数(椭球体名、半主轴长、扁率)计算:
demo=# SELECT p1.name,p2.name,ST_Distance_Spheroid(p1.the_geom,p2.the_geom,'SPHEROID["GRS_1980",6378137,298.257222]')FROMcitiesASp1,citiesASp2WHEREp1.idp2.id;name|name|st_distance_spheroid-----------------+-----------------+----------------------London,Ontario|London,England|5892413.63776489EastLondon,SA|London,England|9756842.65711931EastLondon,SA|London,Ontario|13884149.4140698(3rows)
制图
以 PostGIS 数据制图需要相应的客户端支持。包括 Quantum GIS、gvSIG、uDig 在内的多种客户端均可以。以下使用 Quantum GIS:
从 Desktop GIS 菜单启动 Quantum GIS 并在其 layer 菜单选择 AddPostGISlayers 。连接到 Natural Earth PostGIS 数据库的参数在 Connections 下拉菜单中有。这里可以定义和储存其它的配置。点击 Edit 可以查看具体参数。点击 Connect 连接:

系统将显示所有空间信息表供选择:

选择 lakes 湖泊表单并点击底部的 Add 添加。顶部的 Load 可以载入新的数据库连接配置。数据将被导入:

界面上显示出湖泊的分布。QGIS 并不理解湖泊一词的含义,也许不会自动使用蓝色。请查看其手册了解如何设置。这里缩放到加拿大一处著名的湖泊群。
自动创建空间数据表单
OSGeo Live 的多数桌面 GIS 系统都可以将 shp 等文件导入数据库。这里依然使用 QGIS 演示。
QGIS 中导入 shp 可以使用 PostGIS Manager 插件。在 Plugins 菜单选择 FetchPlugins 导入最新的官方插件列表(需要网络连接)。找到 PostGISManager 点击 Installplugin 安装。

完成后,在 Plugin 菜单点击 PostGIS Manager 启动。也可以点击工具栏上大象与地球的图标。
该插件将连接 Natural Earth 数据库。若提示输入密码,留空即可。在开启的界面中,选择表单可以显示相应的信息。预览(Preview)选项卡可以显示地图预览。这里选择了 populated places 图层并缩放到一个小岛:

接下来使用 PostGIS Manager 将 shp 导入数据库。这里使用 R 统计扩展包含的 North Carolina sudden infant death syndrome (SIDS) 数据:
在 Data 菜单选择 Loaddatafromshapefile 选项。点击 ... 选中 R maptools 中的 sids.shp 。
分库分表 VS newsql数据库
最近与同行 科技 交流,经常被问到分库分表与分布式数据库如何选择,网上也有很多关于中间件+传统关系数据库(分库分表)与NewSQL分布式数据库的文章,但有些观点与判断是我觉得是偏激的,脱离环境去评价方案好坏其实有失公允。
本文通过对两种模式关键特性实现原理对比,希望可以尽可能客观、中立的阐明各自真实的优缺点以及适用场景。
首先关于“中间件+关系数据库分库分表”算不算NewSQL分布式数据库问题,国外有篇论文pavlo-newsql-sigmodrec,如果根据该文中的分类,Spanner、TiDB、OB算是第一种新架构型,Sharding-Sphere、Mycat、DRDS等中间件方案算是第二种(文中还有第三种云数据库,本文暂不详细介绍)。
基于中间件(包括SDK和Proxy两种形式)+传统关系数据库(分库分表)模式是不是分布式架构?我觉得是的,因为存储确实也分布式了,也能实现横向扩展。但是不是"伪"分布式数据库?从架构先进性来看,这么说也有一定道理。"伪"主要体现在中间件层与底层DB重复的SQL解析与执行计划生成、存储引擎基于B+Tree等,这在分布式数据库架构中实际上冗余低效的。为了避免引起真伪分布式数据库的口水战,本文中NewSQL数据库特指这种新架构NewSQL数据库。
NewSQL数据库相比中间件+分库分表的先进在哪儿?画一个简单的架构对比图:
这些大多也是NewSQL数据库产品主要宣传的点,不过这些看起来很美好的功能是否真的如此?接下来针对以上几点分别阐述下的我的理解。
这是把双刃剑。
CAP限制
想想更早些出现的NoSQL数据库为何不支持分布式事务(最新版的mongoDB等也开始支持了),是缺乏理论与实践支撑吗?并不是,原因是CAP定理依然是分布式数据库头上的颈箍咒,在保证强一致的同时必然会牺牲可用性A或分区容忍性P。为什么大部分NoSQL不提供分布式事务?
那么NewSQL数据库突破CAP定理限制了吗?并没有。NewSQL数据库的鼻主Google Spanner(目前绝大部分分布式数据库都是按照Spanner架构设计的)提供了一致性和大于5个9的可用性,宣称是一个“实际上是CA”的,其真正的含义是 系统处于 CA 状态的概率非常高,由于网络分区导致的服务停用的概率非常小 ,究其真正原因是其打造私有全球网保证了不会出现网络中断引发的网络分区,另外就是其高效的运维队伍,这也是cloud spanner的卖点。详细可见CAP提出者Eric Brewer写的《Spanner, TrueTime 和CAP理论》。
完备性 :
两阶段提交协议是否严格支持ACID,各种异常场景是不是都可以覆盖?
2PC在commit阶段发送异常,其实跟最大努力一阶段提交类似也会有部分可见问题,严格讲一段时间内并不能保证A原子性和C一致性(待故障恢复后recovery机制可以保证最终的A和C)。完备的分布式事务支持并不是一件简单的事情,需要可以应对网络以及各种硬件包括网卡、磁盘、CPU、内存、电源等各类异常,通过严格的测试。之前跟某友商交流,他们甚至说目前已知的NewSQL在分布式事务支持上都是不完整的,他们都有案例跑不过,圈内人士这么笃定,也说明了 分布式事务的支持完整程度其实是层次不齐的。
但分布式事务又是这些NewSQL数据库的一个非常重要的底层机制,跨资源的DML、DDL等都依赖其实现,如果这块的性能、完备性打折扣,上层跨分片SQL执行的正确性会受到很大影响。
性能
传统关系数据库也支持分布式事务XA,但为何很少有高并发场景下用呢? 因为XA的基础两阶段提交协议存在网络开销大,阻塞时间长、死锁等问题,这也导致了其实际上很少大规模用在基于传统关系数据库的OLTP系统中。
NewSQL数据库的分布式事务实现也仍然多基于两阶段提交协议,例如google percolator分布式事务模型,
采用原子钟+MVCC+ Snapshot Isolation(SI),这种方式通过TSO(Timestamp Oracle)保证了全局一致性,通过MVCC避免了锁,另外通过primary lock和secondary lock将提交的一部分转为异步,相比XA确实提高了分布式事务的性能。
但不管如何优化,相比于1PC,2PC多出来的GID获取、网络开销、prepare日志持久化还是会带来很大的性能损失,尤其是跨节点的数量比较多时会更加显著,例如在银行场景做个批量扣款,一个文件可能上W个账户,这样的场景无论怎么做还是吞吐都不会很高。
虽然NewSQL分布式数据库产品都宣传完备支持分布式事务,但这并不是说应用可以完全不用关心数据拆分,这些数据库的最佳实践中仍然会写到,应用的大部分场景尽可能避免分布式事务。
既然强一致事务付出的性能代价太大,我们可以反思下是否真的需要这种强一致的分布式事务?尤其是在做微服务拆分后,很多系统也不太可能放在一个统一的数据库中。尝试将一致性要求弱化,便是柔性事务,放弃ACID(Atomicity,Consistency, Isolation, Durability),转投BASE(Basically Available,Soft state,Eventually consistent),例如Saga、TCC、可靠消息保证最终一致等模型,对于大规模高并发OLTP场景,我个人更建议使用柔性事务而非强一致的分布式事务。关于柔性事务,笔者之前也写过一个技术组件,最近几年也涌现出了一些新的模型与框架(例如阿里刚开源的Fescar),限于篇幅不再赘述,有空再单独写篇文章。
HA与异地多活
主从模式并不是最优的方式,就算是半同步复制,在极端情况下(半同步转异步)也存在丢数问题,目前业界公认更好的方案是基于paxos分布式一致性协议或者其它类paxos如raft方式,Google Spanner、TiDB、cockcoachDB、OB都采用了这种方式,基于Paxos协议的多副本存储,遵循过半写原则,支持自动选主,解决了数据的高可靠,缩短了failover时间,提高了可用性,特别是减少了运维的工作量,这种方案技术上已经很成熟,也是NewSQL数据库底层的标配。
当然这种方式其实也可以用在传统关系数据库,阿里、微信团队等也有将MySQL存储改造支持paxos多副本的,MySQL也推出了官方版MySQL Group Cluster,预计不远的未来主从模式可能就成为 历史 了。
需要注意的是很多NewSQL数据库厂商宣传基于paxos或raft协议可以实现【异地多活】,这个实际上是有前提的,那就是异地之间网络延迟不能太高 。以银行“两地三中心”为例,异地之间多相隔数千里,延时达到数十毫秒,如果要多活,那便需异地副本也参与数据库日志过半确认,这样高的延时几乎没有OLTP系统可以接受的。
数据库层面做异地多活是个美好的愿景,但距离导致的延时目前并没有好的方案。 之前跟蚂蚁团队交流,蚂蚁异地多活的方案是在应用层通过MQ同步双写交易信息,异地DC将交易信息保存在分布式缓存中,一旦发生异地切换,数据库同步中间件会告之数据延迟时间,应用从缓存中读取交易信息,将这段时间内涉及到的业务对象例如用户、账户进行黑名单管理,等数据同步追上之后再将这些业务对象从黑名单中剔除。由于双写的不是所有数据库操作日志而只是交易信息,数据延迟只影响一段时间内数据,这是目前我觉得比较靠谱的异地度多活方案。
另外有些系统进行了单元化改造,这在paxos选主时也要结合考虑进去,这也是目前很多NewSQL数据库欠缺的功能。
Scale横向扩展与分片机制
paxos算法解决了高可用、高可靠问题,并没有解决Scale横向扩展的问题,所以分片是必须支持的。NewSQL数据库都是天生内置分片机制的,而且会根据每个分片的数据负载(磁盘使用率、写入速度等)自动识别热点,然后进行分片的分裂、数据迁移、合并,这些过程应用是无感知的,这省去了DBA的很多运维工作量。以TiDB为例,它将数据切成region,如果region到64M时,数据自动进行迁移。
分库分表模式下需要应用设计之初就要明确各表的拆分键、拆分方式(range、取模、一致性哈希或者自定义路由表)、路由规则、拆分库表数量、扩容方式等。相比NewSQL数据库,这种模式给应用带来了很大侵入和复杂度,这对大多数系统来说也是一大挑战。
这里有个问题是NewSQL数据库统一的内置分片策略(例如tidb基于range)可能并不是最高效的,因为与领域模型中的划分要素并不一致,这导致的后果是很多交易会产生分布式事务。 举个例子,银行核心业务系统是以客户为维度,也就是说客户表、该客户的账户表、流水表在绝大部分场景下是一起写的,但如果按照各表主键range进行分片,这个交易并不能在一个分片上完成,这在高频OLTP系统中会带来性能问题。
分布式SQL支持
常见的单分片SQL,这两者都能很好支持。NewSQL数据库由于定位与目标是一个通用的数据库,所以支持的SQL会更完整,包括跨分片的join、聚合等复杂SQL。中间件模式多面向应用需求设计,不过大部分也支持带拆分键SQL、库表遍历、单库join、聚合、排序、分页等。但对跨库的join以及聚合支持就不够了。
NewSQL数据库一般并不支持存储过程、视图、外键等功能,而中间件模式底层就是传统关系数据库,这些功能如果只是涉及单库是比较容易支持的。
NewSQL数据库往往选择兼容MySQL或者PostgreSQL协议,所以SQL支持仅局限于这两种,中间件例如驱动模式往往只需做简单的SQL解析、计算路由、SQL重写,所以可以支持更多种类的数据库SQL。
SQL支持的差异主要在于分布式SQL执行计划生成器,由于NewSQL数据库具有底层数据的分布、统计信息,因此可以做CBO,生成的执行计划效率更高,而中间件模式下没有这些信息,往往只能基于规则RBO(Rule-Based-Opimization),这也是为什么中间件模式一般并不支持跨库join,因为实现了效率也往往并不高,还不如交给应用去做。
存储引擎
传统关系数据库的存储引擎设计都是面向磁盘的,大多都基于B+树。B+树通过降低树的高度减少随机读、进而减少磁盘寻道次数,提高读的性能,但大量的随机写会导致树的分裂,从而带来随机写,导致写性能下降。NewSQL的底层存储引擎则多采用LSM,相比B+树LSM将对磁盘的随机写变成顺序写,大大提高了写的性能。不过LSM的的读由于需要合并数据性能比B+树差,一般来说LSM更适合应在写大于读的场景。当然这只是单纯数据结构角度的对比,在数据库实际实现时还会通过SSD、缓冲、bloom filter等方式优化读写性能,所以读性能基本不会下降太多。NewSQL数据由于多副本、分布式事务等开销,相比单机关系数据库SQL的响应时间并不占优,但由于集群的弹性扩展,整体QPS提升还是很明显的,这也是NewSQL数据库厂商说分布式数据库更看重的是吞吐,而不是单笔SQL响应时间的原因。
成熟度与生态
分布式数据库是个新型通用底层软件,准确的衡量与评价需要一个多维度的测试模型,需包括发展现状、使用情况、社区生态、监控运维、周边配套工具、功能满足度、DBA人才、SQL兼容性、性能测试、高可用测试、在线扩容、分布式事务、隔离级别、在线DDL等等,虽然NewSQL数据库发展经过了一定时间检验,但多集中在互联网以及传统企业非核心交易系统中,目前还处于快速迭代、规模使用不断优化完善的阶段。
相比而言,传统关系数据库则经过了多年的发展,通过完整的评测,在成熟度、功能、性能、周边生态、风险把控、相关人才积累等多方面都具有明显优势,同时对已建系统的兼容性也更好。
对于互联网公司,数据量的增长压力以及追求新技术的基因会更倾向于尝试NewSQL数据库,不用再考虑库表拆分、应用改造、扩容、事务一致性等问题怎么看都是非常吸引人的方案。
对于传统企业例如银行这种风险意识较高的行业来说,NewSQL数据库则可能在未来一段时间内仍处于 探索 、审慎试点的阶段。基于中间件+分库分表模式架构简单,技术门槛更低,虽然没有NewSQL数据库功能全面,但大部分场景最核心的诉求也就是拆分后SQL的正确路由,而此功能中间件模式应对还是绰绰有余的,可以说在大多数OLTP场景是够用的。
限于篇幅,其它特性例如在线DDL、数据迁移、运维工具等特性就不在本文展开对比。
总结
如果看完以上内容,您还不知道选哪种模式,那么结合以下几个问题,先思考下NewSQL数据库解决的点对于自身是不是真正的痛点:
如果以上有2到3个是肯定的,那么你可以考虑用NewSQL数据库了,虽然前期可能需要一定的学习成本,但它是数据库的发展方向,未来收益也会更高,尤其是互联网行业,随着数据量的突飞猛进,分库分表带来的痛苦会与日俱增。当然选择NewSQL数据库你也要做好承担一定风险的准备。
如果你还未做出抉择,不妨再想想下面几个问题:
如果这些问题有多数是肯定的,那还是分库分表吧。在软件领域很少有完美的解决方案,NewSQL数据库也不是数据分布式架构的银弹。相比而言分库分表是一个代价更低、风险更小的方案,它最大程度复用传统关系数据库生态,通过中间件也可以满足分库分表后的绝大多数功能,定制化能力更强。 在当前NewSQL数据库还未完全成熟的阶段,分库分表可以说是一个上限低但下限高的方案,尤其传统行业的核心系统,如果你仍然打算把数据库当做一个黑盒产品来用,踏踏实实用好分库分表会被认为是个稳妥的选择。
很多时候软件选型取决于领域特征以及架构师风格,限于笔者知识与所属行业特点所限,以上仅为个人粗浅的一些观点,欢迎讨论。
数据库为什么要分库分表
1 基本思想之什么是分库分表?
从字面上简单理解,就是把原本存储于一个库的数据分块存储到多个库上,把原本存储于一个表的数据分块存储到多个表上。
2 基本思想之为什么要分库分表?
数
据库中的数据量不一定是可控的,在未进行分库分表的情况下,随着时间和业务的发展,库中的表会越来越多,表中的数据量也会越来越大,相应地,数据操作,增
删改查的开销也会越来越大;另外,由于无法进行分布式式部署,而一台服务器的资源(CPU、磁盘、内存、IO等)是有限的,最终数据库所能承载的数据量、
数据处理能力都将遭遇瓶颈。
3 分库分表的实施策略。
分库分表有垂直切分和水平切分两种。
3.1
何谓垂直切分,即将表按照功能模块、关系密切程度划分出来,部署到不同的库上。例如,我们会建立定义数据库workDB、商品数据库payDB、用户数据
库userDB、日志数据库logDB等,分别用于存储项目数据定义表、商品定义表、用户数据表、日志数据表等。
3.2
何谓水平切分,当一个表中的数据量过大时,我们可以把该表的数据按照某种规则,例如userID散列,进行划分,然后存储到多个结构相同的表,和不同的库
上。例如,我们的userDB中的用户数据表中,每一个表的数据量都很大,就可以把userDB切分为结构相同的多个userDB:part0DB、
part1DB等,再将userDB上的用户数据表userTable,切分为很多userTable:userTable0、userTable1等,
然后将这些表按照一定的规则存储到多个userDB上。
3.3 应该使用哪一种方式来实施数据库分库分表,这要看数据库中数据量的瓶颈所在,并综合项目的业务类型进行考虑。
如果数据库是因为表太多而造成海量数据,并且项目的各项业务逻辑划分清晰、低耦合,那么规则简单明了、容易实施的垂直切分必是首选。
而
如果数据库中的表并不多,但单表的数据量很大、或数据热度很高,这种情况之下就应该选择水平切分,水平切分比垂直切分要复杂一些,它将原本逻辑上属于一体
的数据进行了物理分割,除了在分割时要对分割的粒度做好评估,考虑数据平均和负载平均,后期也将对项目人员及应用程序产生额外的数据管理负担。
在现实项目中,往往是这两种情况兼而有之,这就需要做出权衡,甚至既需要垂直切分,又需要水平切分。我们的游戏项目便综合使用了垂直与水平切分,我们首先对数据库进行垂直切分,然后,再针对一部分表,通常是用户数据表,进行水平切分。
4 分库分表存在的问题。
4.1 事务问题。
在执行分库分表之后,由于数据存储到了不同的库上,数据库事务管理出现了困难。如果依赖数据库本身的分布式事务管理功能去执行事务,将付出高昂的性能代价;如果由应用程序去协助控制,形成程序逻辑上的事务,又会造成编程方面的负担。
4.2 跨库跨表的join问题。
在执行了分库分表之后,难以避免会将原本逻辑关联性很强的数据划分到不同的表、不同的库上,这时,表的关联操作将受到限制,我们无法join位于不同分库的表,也无法join分表粒度不同的表,结果原本一次查询能够完成的业务,可能需要多次查询才能完成。
4.3 额外的数据管理负担和数据运算压力。
额
外的数据管理负担,最显而易见的就是数据的定位问题和数据的增删改查的重复执行问题,这些都可以通过应用程序解决,但必然引起额外的逻辑运算,例如,对于
一个记录用户成绩的用户数据表userTable,业务要求查出成绩最好的100位,在进行分表之前,只需一个order
by语句就可以搞定,但是在进行分表之后,将需要n个order
by语句,分别查出每一个分表的前100名用户数据,然后再对这些数据进行合并计算,才能得出结果。
如何使用Navicat for PostgreSQL域
Navicat for PostgreSQL 11.1.13 最新版域常规属性:
基础类型类别:可选择的基础数据类型有:Base Type、Composite Type、Enum Type 和 Domain。需要注意的是,仅支持 PostgreSQL 8.2 或以上版本。
基础类型模式:选择基础数据类型的模式。
基础类型:从下拉列表选择域的基础数据类型。
维度:数组符的维度。
长度和比例:使用“长度”编辑框定义栏位的长度,使用“比例”编辑框定义小数点之后的位数。
默认:DEFAULT 子句为域数据类型列指定默认值,该值是任何没有变量的表达式(但是子查询是不允许),默认表达式的数据类型必须符合域的数据类型。如果没有指定默认值,那么默认值是 null 值。
默认表达式将用于任何没有为列指定值的插入操作,如果一个特定的列已定义默认值,它会无视任何关于域的默认。反过来,域默认会无视任何关于基础数据类型的默认值。
不是 null:域的值不允许是 null。
拥有者:域函数的拥有者,定义域的用户成为其拥有者。需要注意的是,支持 PostgreSQL 7.4 或以上版本。
检查
检查选项卡为管理域检查提供。方便用户创建新的、编辑或删除选定的检查。CHECK 子句指定完整性限制或测试,域的值必须符合。每个限制必须是一个生成 Boolean(布尔)结果的表达式,它应使用 VALUE 关键字来参照被测试的值。
postgresql 怎么自动创建分区
在数据库日渐庞大的今天,为了方便对数据库数据的管理,比如按时间,按地区去统计一些数据时,基数过于庞大,多有不便。很多商业数据库都提供分区的概念,按不同的维度去存放数据,便于后期的管理,PostgreSQL也不例外。
PostgresSQL分区的意思是把逻辑上的一个大表分割成物理上的几块儿。分区不仅能带来访问速度的提升,关键的是,它能带来管理和维护上的方便。
分区的具体好处是:
某些类型的查询性能可以得到极大提升。
更新的性能也可以得到提升,因为表的每块的索引要比在整个数据集上的索引要小。如果索引不能全部放在内存里,那么在索引上的读和写都会产生更多的磁盘访问。
批量删除可以用简单的删除某个分区来实现。
可以将很少用的数据移动到便宜的、转速慢的存储介质上。
在PG里表分区是通过表继承来实现的,一般都是建立一个主表,里面是空,然后每个分区都去继承它。无论何时,都应保证主表里面是空的。
小表分区不实际,表在多大情况下才考虑分区呢?PostgresSQL官方给出的建议是:当表本身大小超过了机器物理内存的实际大小时(the size of the table should exceed the physical memory of the database server),可以考虑分区。
PG目前(9.2.2)仅支持范围分区和列表分区,尚未支持散列分区。
二、环境
系统环境:CentOS release 6.3 (Final)
PostgreSQL版本:PostgreSQL 9.2.2 on x86_64-unknown-linux-gnu, compiled by gcc (GCC) 4.4.6 20120305 (Red Hat 4.4.6-4), 64-bit
三、实现分区
3.1 创建主表
david=# create table tbl_partition (
david(# id integer,
david(# name varchar(20),
david(# gender boolean,
david(# join_date date,
david(# dept char(4));
CREATE TABLE
david=#
3.2 创建分区表
david=# create table tbl_partition_201211 (
check ( join_date = DATE '2012-11-01' AND join_date DATE '2012-12-01' )
) INHERITS (tbl_partition);
CREATE TABLE
david=# create table tbl_partition_201212 (
check ( join_date = DATE '2012-12-01' AND join_date DATE '2013-01-01' )
) INHERITS (tbl_partition);
CREATE TABLE
david=# create table tbl_partition_201301 (
check ( join_date = DATE '2013-01-01' AND join_date DATE '2013-02-01' )
) INHERITS (tbl_partition);
CREATE TABLE
david=# create table tbl_partition_201302 (
check ( join_date = DATE '2013-02-01' AND join_date DATE '2013-03-01' )
) INHERITS (tbl_partition);
CREATE TABLE
david=# create table tbl_partition_201303 (
check ( join_date = DATE '2013-03-01' AND join_date DATE '2013-04-01' )
) INHERITS (tbl_partition);
CREATE TABLE
david=# create table tbl_partition_201304 (
check ( join_date = DATE '2013-04-01' AND join_date DATE '2013-05-01' )
) INHERITS (tbl_partition);
CREATE TABLE
david=# create table tbl_partition_201305 (
check ( join_date = DATE '2013-05-01' AND join_date DATE '2013-06-01' )
) INHERITS (tbl_partition);
CREATE TABLE
david=#
3.3 分区键上建索引
david=# create index tbl_partition_201211_joindate on tbl_partition_201211 (join_date);
CREATE INDEX
david=# create index tbl_partition_201212_joindate on tbl_partition_201212 (join_date);
CREATE INDEX
david=# create index tbl_partition_201301_joindate on tbl_partition_201301 (join_date);
CREATE INDEX
david=# create index tbl_partition_201302_joindate on tbl_partition_201302 (join_date);
CREATE INDEX
david=# create index tbl_partition_201303_joindate on tbl_partition_201303 (join_date);
CREATE INDEX
david=# create index tbl_partition_201304_joindate on tbl_partition_201304 (join_date);
CREATE INDEX
david=# create index tbl_partition_201305_joindate on tbl_partition_201305 (join_date);
CREATE INDEX
david=#
对于开发人员来说,希望数据库是透明的,只管 insert into tbl_partition。对于数据插向哪个分区,则希望由DB决定。这点,ORACLE实现了,但是PG不行,需要前期人工处理下。
3.4 创建触发器函数
david=# CREATE OR REPLACE FUNCTION tbl_partition_insert_trigger()
RETURNS TRIGGER AS $$
BEGIN
IF ( NEW.join_date = DATE '2012-11-01' AND
NEW.join_date DATE '2012-12-01' ) THEN
INSERT INTO tbl_partition_201211 VALUES (NEW.*);
ELSIF ( NEW.join_date = DATE '2012-12-01' AND
NEW.join_date DATE '2013-01-01' ) THEN
INSERT INTO tbl_partition_201212 VALUES (NEW.*);
ELSIF ( NEW.join_date = DATE '2013-01-01' AND
NEW.join_date DATE '2013-02-01' ) THEN
INSERT INTO tbl_partition_201301 VALUES (NEW.*);
ELSIF ( NEW.join_date = DATE '2013-02-01' AND
NEW.join_date DATE '2013-03-01' ) THEN
INSERT INTO tbl_partition_201302 VALUES (NEW.*);
ELSIF ( NEW.join_date = DATE '2013-03-01' AND
NEW.join_date DATE '2013-04-01' ) THEN
INSERT INTO tbl_partition_201303 VALUES (NEW.*);
ELSIF ( NEW.join_date = DATE '2013-04-01' AND
NEW.join_date DATE '2013-05-01' ) THEN
INSERT INTO tbl_partition_201304 VALUES (NEW.*);
ELSIF ( NEW.join_date = DATE '2013-05-01' AND
NEW.join_date DATE '2013-06-01' ) THEN
INSERT INTO tbl_partition_201305 VALUES (NEW.*);
ELSE
RAISE EXCEPTION 'Date out of range. Fix the tbl_partition_insert_trigger() function!';
END IF;
RETURN NULL;
END;
$$
LANGUAGE plpgsql;
CREATE FUNCTION
david=#
说明:如果不想丢失数据,上面的ELSE 条件可以改成 INSERT INTO tbl_partition_error_join_date VALUES (NEW.*); 同时需要创建一张结构和tbl_partition 一样的表tbl_partition_error_join_date,这样,错误的join_date 数据就可以插入到这张表中而不是报错了。
附上出处链接:
postgresql----数组类型和函数
postgresql支持数组类型,可以是基本类型,也可以是用户自定义的类型。日常中使用数组类型的机会不多,但还是可以了解一下。不像C或JAVA高级语言的数组下标从0开始,postgresql数组下标从1开始,既可以指定长度,也可以不指定长度。且postgresql既支持一维数组,也支持多维数组,但是平时二维数组也就够用了。
示例1.使用ARRAY构建数组类型
---1*4的一维数组test=#selectarray[1,2,3,4];
array -----------{1,2,3,4}
(1 row)--2*2的二维数组test=#selectarray[[1,2],[3,4]];
array ---------------{{1,2},{3,4}}
(1 row)--1*2的二维数组,基本类型为box矩形类型,且和上面相比box类型元素之间是以分号分隔的,其他所有类型的数据都是以逗号分隔的test=#selectarray[box'(1,1),(0,0)',box'(0,0),(-1,-1)'];
array -----------------------------{(1,1),(0,0);(0,0),(-1,-1)}
(1row)
示例2.创建一张表,字段包含数组类型
其中int[]表示数组长度无限制,int[4]表示数组长度为4.
test=#createtabletbl_array(aint[],bvarchar(32)[][],cint);CREATETABLEtest=#insertintotbl_array (a,b,c)values(array[1,2],array[[1,2,3],[4,5,6]],1);INSERT01test=#insertintotbl_array (a,b,c)values(array[1,2,3],array[[1,2],[4,5]],2);INSERT01test=#select*from tbl_array ;
a |b| c ---------+-------------------+---{1,2}|{{1,2,3},{4,5,6}}|1 {1,2,3}|{{1,2},{4,5}}|2(2 rows)
test=#selecta[1],b[2]fromtbl_arraywherec=1;
a | b ---+---1|
(1 row)
test=#selecta[1],b[2][1]fromtbl_arraywherec=1;
a | b ---+---1|4(1 row)
test=#selecta[1],b[2][4]fromtbl_arraywherec=1;
a | b ---+---1|
(1row)
test=#updatetbl_arrayseta[1]=200wherea[1]=1;UPDATE1test=#selecta[1],b[2][4]from tbl_array ;
a | b -----+---100|200|
(2rows)
也可以使用[下标:上标]方式来查询数组连续的某些元素。
test=#selecta[2:3]from tbl_array ;
a -------{2}
{2,3}
(2 rows)
test=#selecta[1:3]from tbl_array ;
a -----------{100,2}
{200,2,3}
(2rows)
数组操作符与函数
操作符
操作符描述示例结果
=相等 SELECT ARRAY[1.1,2.1,3.1]::int[] = ARRAY[1,2,3]; t
不等于 select ARRAY[1,2,3] ARRAY[1,2,4]; t
小于 select ARRAY[1,2,3] ARRAY[1,2,4]; t
大于 select ARRAY[1,4,3] ARRAY[1,2,4]; t
=小于或等于 select ARRAY[1,2,3] = ARRAY[1,2,3]; t
=大于或等于 select ARRAY[1,4,3] = ARRAY[1,4,3]; t
@包含 select ARRAY[1,4,3] @ ARRAY[3,1]; t
@包含于 select ARRAY[2,7] @ ARRAY[1,7,4,2,6]; t
重叠(是否有相同元素) select ARRAY[1,4,3] ARRAY[2,1]; t
||数组与数组连接 select ARRAY[1,2,3] || ARRAY[4,5,6]; {1,2,3,4,5,6}
||数组与数组连接 select ARRAY[1,2,3] || ARRAY[[4,5,6],[7,8,9]]; {{1,2,3},{4,5,6},{7,8,9}}
||元素与数组连接 select 3 || ARRAY[4,5,6]; {3,4,5,6}
||数组与元素连接 select ARRAY[4,5,6] || 7; {4,5,6,7}
函数
函数返回类型描述示例结果
array_append(anyarray,anyelement)anyarray 在数组末尾追加元素
SELECT array_append(ARRAY[1,2], 3);
{1,2,3}
array_cat(anyarray,anyarray)anyarray 连接两个数组 SELECT array_cat(ARRAY[1,2,3], ARRAY[4,5]); {1,2,3,4,5}
array_ndims(anyarray)int 返回数组维数 SELECT array_ndims(ARRAY[[1,2,3], [4,5,6]]); 2
array_dims(anyarray)text 返回数组维数的文本表示 SELECT array_dims(ARRAY[[1,2,3], [4,5,6]]); [1:2][1:3]
array_fill(anyelement,int[], [,int[]])anyarray使用提供的值和维度初始化一个数组,其中anyelement是值,第一个int[]是数组的长度,第二个int[]是数组下界,下界默认是1 SELECT array_fill(7, ARRAY[3], ARRAY[2]); [2:4]={7,7,7}
array_length(anyarray,int)int 返回数组指定维度的长度 SELECT array_length(array[1,2,3], 1); 3
array_lower(anyarray,int)int 返回数组指定维度的下界 SELECT array_lower('[0:2]={1,2,3}'::int[], 1); 0
array_position(anyarray,anyelement[,int])int 返回数组元素anyelement从数组的[,int]位置(默认为1)开始第一次出现在数组中的位置,数组必须是一维的 SELECT array_position(ARRAY['sun','mon','tue','wed','thu','fri','sat'], 'mon'); 2
array_positions(anyarray,anyelement)int[] 返回元素在数组中的所有位置 SELECT array_positions(ARRAY['A','A','B','A'], 'A'); {1,2,4}
array_prepend(anyelement,anyarray)anyarray 在数组开头添加新的元素 SELECT array_prepend(1, ARRAY[2,3]); {1,2,3}
array_remove(anyarray,anyelement)anyarray 从数组中删除所有的指定元素,必须是一维数组 SELECT array_remove(ARRAY[1,2,3,2], 2); {1,3}
array_replace(anyarray,anyelement,anyelement)anyarray 替换指定数组元素为新的元素 SELECT array_replace(ARRAY[1,2,5,4], 5, 3); {1,2,3,4}
array_to_string(anyarray,text[,text])text 将数组元素使用分隔符连接为文本,NULL可以使用指定元素替换 SELECT array_to_string(ARRAY[1, 2, 3, NULL, 5], ',', '*'); 1,2,3,*,5
array_upper(anyarray,int)int 数组指定维度的上届 SELECT array_upper(ARRAY[1,8,3,7], 1); 4
cardinality(anyarray)int 返回数组所有维度的长度总和,如果是空数组则返回0 SELECT cardinality(ARRAY[[1,2],[3,4]]); 4
string_to_array(text,text[,text])text[] 将文本使用分隔符分隔后转换为数组,如果指定第三个参数,则第三个参数在数组中被转换为NULL SELECT string_to_array('xx~^~yy~^~zz', '~^~', 'yy'); {xx,NULL,zz}
unnest(anyarray)setof anyelement 将数组元素转换为行 SELECT unnest(ARRAY[1,2]);
1
2
unnest(anyarray,anyarray[, ...])setof anyelement, anyelement [, ...] 将多维数组转换为行集合,其中第一个数组显示为第一列,第二个数组显示为第二列,以此类推。但是这个函数只在from子句中使用 SELECT * from unnest(ARRAY[1,2],ARRAY['foo','bar','baz']);
unnest | unnest
--------+----
1 | foo
2 | bar
| baz
网站标题:包含postgresql维度的词条
URL地址:http://azwzsj.com/article/dsdgojo.html