更新时间：2022-07-27 17:52
产品详情
相关技术圈
我的收藏
IMPORT FOREIGN SCHEMA语句用于批量创建外部表。本文为您介绍IMPORT FOREIGN SCHEMA语句的用法和使用限制。
使用限制
使用IMPORT FOREIGN SCHEMA语句时，建议您添加LIMIT TO限制，并使用括号将需要添加限制的表名称括起来。如果不添加该限制，系统则将目标MaxCompute工作空间中的所有表批量创建至Hologres中。
仅Hologres V1.1.26及以上版本支持对使用IMPORT FOREIGN SCHEMA创建的外部表名称增加前缀和后缀，如果您的实例是V1.1.26以下版本，请您提交工单或加入在线支持钉钉群申请升级实例。
仅Hologres V1.3及以上版本支持MaxCompute的三层模型模式（即在原先的Project和Table之间增加了一层Schema的概念），更多描述请参见MaxCompute Schema。如果您想在Hologres中使用MaxCompute的三层模型的项目创建外部表，且您的Hologres版本较低，请您提交工单升级实例。
命令格式
在Hologres中批量创建外部表的命令格式如下。
IMPORT FOREIGN SCHEMA remote_schema
[ { LIMIT TO | EXCEPT } ( table_name [, ...] ) ]
FROM SERVER odps_server
INTO local_schema
[ OPTIONS ( option 'value' [, ... ] ) ]
参数说明
参数说明如下表所示。
参数 描述
remote_schema
MaxCompute两层模型：需要导入的MaxCompute表所在的项目名称。
MaxCompute三层模型：需要导入的MaxCompute的项目名称和Schema名称，格式为odps_project_name#odps_schema_name。如果您MaxCompute的Project是三层模型模式，您仍使用两层模型的写法调用，则会报错，报错样例如下。
failed to import foreign schema:Table not found - table_xxx
table_name 需要导入的MaxCompute表名称。
server_name MaxCompute表所在的外部服务器名称，默认为odps_server。
您可以直接调用Hologres底层已创建的名为odps_server的外部表服务器。详细原理请参见Postgres FDW。
local_schema Hologres外部表所在的schema名（如public）。
options Hologres支持如下四个option：
if_table_exist：表示导入时已经存在该表。取值如下：
error：默认值，表示已有同名外部表，不再重复创建。
ignore：忽略该同名表，跳过该表的导入，使导入的表不重复。
update：更新并重新导入该表。
if_unsupported_type：表示导入的外部表中存在Hologres不支持的数据类型。取值如下：
error：报错，导入失败， 并提示哪些表存在不支持的类型。
skip：默认值，表示跳过导入的存在不支持类型的表，并提示哪些表被跳过。
prefix：表示导入时生成的Hologres外部表的前缀，自Hologres V1.1.26版本新增。
suffix：表示导入时生成的Hologres外部表的后缀，自Hologres V1.1.26版本新增。
说明 Hologres仅支持创建MaxCompute外部表。新建的外部表名称需要同MaxCompute表的名称一致。
使用示例
MaxCompute两层模型。
示例选取MaxCompute公共数据集public_data中的表，在Hologres中批量创建外部表。您可以参照使用公开数据集描述，登录并查询数据集 。
示例1：为public schema新建一张外部表，若表存在则更新表。
IMPORT FOREIGN SCHEMA public_data LIMIT to
(customer)
FROM server odps_server INTO PUBLIC options(if_table_exist 'update')
示例2：为public schema批量新建外部表。
IMPORT FOREIGN SCHEMA public_data LIMIT to(
customer,
customer_address,
customer_demographics,
inventory,item,
date_dim,
warehouse)
FROM server odps_server INTO PUBLIC options(if_table_exist 'update')
示例3：新建一个testdemo schema并批量新建外部表。
create schema testdemo
IMPORT FOREIGN SCHEMA public_data LIMIT to(
customer,
customer_address,
customer_demographics,
inventory,item,
date_dim,
warehouse)
FROM server odps_server INTO testdemo options(if_table_exist 'update')
set search_path to testdemo
示例4：在public schema批创建外部表，已有外表则报错。
IMPORT FOREIGN SCHEMA public_data LIMIT to
(customer,
customer_address)
FROM server odps_server INTO PUBLIC options(if_table_exist 'error')
示例5：在public schema批量创建外部表，已有外表则跳过该外部表。
IMPORT FOREIGN SCHEMA public_data LIMIT to
(customer,
customer_address)
FROM server odps_server INTO PUBLIC options(if_table_exist 'ignore')
MaxCompute三层模型。
基于MaxComputeodps_hologres项目的tpch_10g这个Schema中的odps_region_10g表创建Hologres中的外部表。
IMPORT FOREIGN SCHEMA "odps_hologres#tpch_10g" LIMIT to
(
odps_region_10g
)
FROM SERVER odps_server INTO public OPTIONS(if_table_exist 'error',if_unsupported_type 'error')
HoloWeb可视化批量创建外部表
HoloWeb提供可视化批量创建外部表功能，无需写SQL命令就能创建外部表，步骤如下。
进入HoloWeb页面，详情请参见连接HoloWeb。
在HoloWeb开发页面的顶部菜单栏，选择元数据管理 >MaxCompute加速，单击批量创建外部表。
您也可以在元数据管理界面的已登录实例列表。单击目标数据库，鼠标右击数据库下已创建的目标模式，选择批量创建外部表。
在批量创建外部表页面，配置各项参数。
类别 参数 描述
基本属性 实例名 已登录的实例名称。
数据库 存放新创建外部表的Hologres数据库名称。
目标位置 模式 模式名称。
您可以选择默认创建的public模式，也可以选择新建的模式名称。
来源 类型 目前仅支持MaxCompute外部表。
服务器列表 您可以直接调用Hologres底层已创建的名为odps_server的外部表服务器。详细原理请参见Postgres FDW。
远程库 MaxCompute的项目名称。
选择要直接加速的表
整库加速：批量创建所选项目下的所有表。
部分加速：您可以通过搜索表名称或关键字，选择需要创建的表。
说明 部分加速最多支持显示200张表，超出部分将不显示，但是也会创建成功。
例如，目标项目中共有203个名称中包含test的表，搜索test时，此处最多只会显示200个相关的表，但实际上203个表都会创建成功。
高级选项 表名冲突
忽略，继续创建其他表：创建表时，如果数据库中已存在当前创建的表名称，则忽略当前创建的表，继续创建其他表。
更新，修改同名表：创建表时，如果数据库中已存在当前创建的表名称，则更新已有表的数据。
报错，不再重复创建：创建表时，如果数据库中已存在当前创建的表名称，则发送报错，不再重复创建。
数据类型不支持
报错，导入失败：如果创建表时存在不支持的数据类型，则产生报错，导入数据失败。
忽略，跳过不支持字段：如果创建表时存在不支持的数据类型，则忽略不支持的字段，继续导入数据。
单击运行，批量创建外部表。
数据类型映射
批量创建的MaxCompute外部表与Hologres的数据类型映射，详情请参见批量创建MaxCompute外部表与Hologres的数据类型映射。
1. 概述cstore_fdw实现了 PostgreSQL 数据库的列式存储。列存储非常适合用于数据分析的场景，数据分析的场景下数据是批量加载的。
这个扩展使用了Optimized Row Columnar (ORC)数据存储格式，ORC改进了Facebook的RCFile格式，带来如下好处:
压缩:将内存和磁盘中数据大小削减到2到4倍。可以扩展以支持不同压缩算法。
列投影:只提取和查询相关的列数据。提升IO敏感查询的性能。
跳过索引:为行组存储最大最小统计值，并利用它们跳过无关的行。
2. 使用
cstore_fdw的安装和使用都非常简单，可以参考官方资料。
thub.com/citusdata/cstore_fdw
注)注意cstore_fdw只支持PostgreSQL9.3和9.4 。
下面做几个简单的性能对比，看看cstore_fdw究竟能带来多大的性能提升。
2.1 数据加载
2.1.1 普通表
CREATE TABLE tb1
(
id int,
c1 TEXT,
c2 TEXT,
c3 TEXT,
c4 TEXT,
c5 TEXT,
c6 TEXT,
c7 TEXT,
c8 TEXT,
c9 TEXT,
c10 TEXT
)
注:要和普通表的全表扫描作对比，所以不建主键和索引。
[postgres@node2 chenhj]$ time psql -p 40382 -At -F, -c "select id,id::text,id::text,id::text,id::text,id::text,id::text,id::text,id::text,id::text,id::text from generate_series(1,10000000) id"|time psql -p 40382 -c "copy tb1 from STDIN with CSV"
COPY 10000000
1.56user 1.00system 6:42.39elapsed 0%CPU (0avgtext+0avgdata 7632maxresident)k
776inputs+0outputs (17major+918minor)pagefaults 0swaps
real6m42.402s
user0m15.174s
sys 0m14.904s
postgres=# select pg_total_relation_size('tb1'::regclass)
pg_total_relation_size
------------------------
1161093120
(1 row)
postgres=# \timing
Timing is on.
postgres=# analyze tb1
ANALYZE
Time: 11985.070 ms
插入1千万条记录，数据占用存储大小1.16G，插入耗时6分42秒，分析耗时12秒。
2.1.2 cstore表
$ mkdir -p /home/chenhj/data94/cstore
CREATE EXTENSION cstore_fdw
CREATE SERVER cstore_server FOREIGN DATA WRAPPER cstore_fdw
CREATE FOREIGN TABLE cstb1
(
id int,
c1 TEXT,
c2 TEXT,
c3 TEXT,
c4 TEXT,
c5 TEXT,
c6 TEXT,
c7 TEXT,
c8 TEXT,
c9 TEXT,
c10 TEXT
)
SERVER cstore_server
OPTIONS(filename '/home/chenhj/data94/cstore/cstb1.cstore',
compression 'pglz')
[postgres@node2 chenhj]$ time psql -p 40382 -At -F, -c "select id,id::text,id::text,id::text,id::text, www.hnnedu.com id::text,id::text,id::text,id::text,id::text,id::text from generate_series(1,10000000) id"|time psql -p 40382 -c "copy cstb1 from STDIN with CSV"
COPY 10000000
1.53user 0.78system 7:35.15elapsed 0%CPU (0avgtext+0avgdata 7632maxresident)k
968inputs+0outputs (20major+920minor)pagefaults 0swaps
real7m35.520s
user0m14.809s
sys 0m14.170s
[postgres@node2 chenhj]$ ls -l /home/chenhj/data94/cstore/cstb1.cstore
-rw------- 1 postgres postgres 389583021 Jun 23 17:32 /home/chenhj/data94/cstore/cstb1.cstore
postgres=# \timing
Timing is on.
postgres=# analyze cstb1
ANALYZE
Time: 5946.476 ms
插入1千万条记录，数据占用存储大小390M，插入耗时7分35秒，分析耗时6秒。
使用cstore列存储后，数据占用存储大小降到普通表的3分之1。需要说明的是，由于所有TEXT列填充了随机数据，压缩率不算高，某些实际的应用场景下压缩效果会比这更好。
2.2 Text列的like查询性能对比
2.2.1 普通表
清除文件系统缓存，并重启PostgreSQL
[postgres@node2 chenhj]$ pg_ctl -D /home/chenhj/data94 -l logfile94 restart
[root@node2 ~]# free
total used free sharedbuffers cached
Mem: 2055508 7713561284152 0 9900 452256
-/+ buffers/cache: 3092001746308
Swap: 4128760 3876243741136
[root@node2 ~]# echo 1 >/proc/sys/vm/drop_caches
[root@node2 ~]# free
total used free sharedbuffers cached
Mem: 2055508 3267881728720 0228 17636
-/+ buffers/cache: 3089241746584
Swap: 4128760 3819123746848
对Text列执行like查询
[postgres@node2 chenhj]$ iostat -k dm-2
Linux 2.6.32-71.el6.x86_64 (node2) 06/23/14_x86_64_(2 CPU)
avg-cpu: %user %nice %system %iowait %steal %idle
0.800.000.383.420.00 95.40
Device:tpskB_read/skB_wrtn/skB_readkB_wrtn
dm-2 58.55 330.68 212.0873514414714848
[postgres@node2 chenhj]$ time psql -p 40382 -c "select count(*) from tb1 where c1 like '%66'"
count
--------
100000
(1 row)
real0m7.051s
user0m0.001s
sys 0m0.004s
[postgres@node2 chenhj]$ iostat -k dm-2
Linux 2.6.32-71.el6.x86_64 (node2) 06/23/14_x86_64_(2 CPU)
avg-cpu: %user %nice %system %iowait %steal %idle
0.800.000.383.430.00 95.39
Device:tpskB_read/skB_wrtn/skB_readkB_wrtn
dm-2 58.90 381.53 211.9084895974714956
耗时7.1秒，产生IO读1.14G,IO写108K。
不清文件系统缓存，不重启PostgreSQL，再执行一次。消耗时间降到1.6秒，几乎不产生IO。
[postgres@node2 chenhj]$ iostat -k dm-2
Linux 2.6.32-71.el6.x86_64 (node2) 06/23/14_x86_64_(2 CPU)
avg-cpu: %user %nice %system %iowait %steal %idle
0.800.000.383.430.00 95.39
Device:tpskB_read/skB_wrtn/skB_readkB_wrtn
dm-2 58.81 332.20 213.0673503014714364
[postgres@node2 chenhj]$ time psql -p 40382 -c "select count(*) from tb1 where c1 like '%66'"
count
--------
100000
(1 row)
real0m1.601s
user0m0.002s
sys 0m0.001s
[postgres@node2 chenhj]$ iostat -k dm-2
Linux 2.6.32-71.el6.x86_64 (node2) 06/23/14_x86_64_(2 CPU)
avg-cpu: %user %nice %system %iowait %steal %idle
0.800.000.383.430.00 95.38
Device:tpskB_read/skB_wrtn/skB_readkB_wrtn
dm-2 58.80 332.12 213.0173503374714364
2.2.2 cstore表
清除文件系统缓存，并重启PostgreSQL
[postgres@node2 chenhj]$ pg_ctl -D /home/chenhj/data94 -l logfile94 restart
[root@node2 ~]# echo 1 >/proc/sys/vm/drop_caches
对Text列执行like查询
[postgres@node2 chenhj]$ iostat -k dm-2
Linux 2.6.32-71.el6.x86_64 (node2) 06/23/14_x86_64_(2 CPU)
avg-cpu: %user %nice %system %iowait %steal %idle
0.800.000.383.380.00 95.45
Device:tpskB_read/skB_wrtn/skB_readkB_wrtn
dm-2 58.12 376.42 209.0484920174716048
[postgres@node2 chenhj]$ time psql -p 40382 -c "select count(*) from cstb1 where c1 like '%66'"
count
--------
100000
(1 row)
real0m2.786s
user0m0.002s
sys 0m0.003s
[postgres@node2 chenhj]$ iostat -k dm-2
Linux 2.6.32-71.el6.x86_64 (node2) 06/23/14_x86_64_(2 CPU)
avg-cpu: %user %nice %system %iowait %steal %idle
0.800.000.383.380.00 95.44
Device:tpskB_read/skB_wrtn/skB_readkB_wrtn
dm-2 58.12 378.75 208.8985507614716048
耗时2.8秒，产生IO读59M,IO写0K。执行时间优化的虽然不是太多，但IO大大减少，可见列投影起到了作用。
不清文件系统缓存，不重启PostgreSQL，再执行一次。消耗时间降到1.4秒，几乎不产生IO。
[postgres@node2 chenhj]$ iostat -k dm-2
Linux 2.6.32-71.el6.x86_64 (node2) 06/23/14_x86_64_(2 CPU)
avg-cpu: %user %nice %system %iowait %steal %idle
0.800.000.383.360.00 95.47
Device:tpskB_read/skB_wrtn/skB_readkB_wrtn
dm-2 57.75 376.33 207.5885508094716524
[postgres@node2 chenhj]$ time psql -p 40382 -c "select count(*) from cstb1 where c1 like '%66'"
count
--------
100000
(1 row)
real0m1.424s
user0m0.002s
sys 0m0.001s
[postgres@node2 chenhj]$ iostat -k dm-2
Linux 2.6.32-71.el6.x86_64 (node2) 06/23/14_x86_64_(2 CPU)
avg-cpu: %user %nice %system %iowait %steal %idle
0.800.000.383.360.00 95.47
Device:tpskB_read/skB_wrtn/skB_readkB_wrtn
dm-2 57.70 375.96 207.3885508094716588
2.3 对Int列执行=查询
2.3.1 普通表
清除文件系统缓存，并重启PostgreSQL后
[postgres@node2 chenhj]$ pg_ctl -D /home/chenhj/data94 -l logfile94 restart
[root@node2 ~]# echo 1 >/proc/sys/vm/drop_caches
对Int列执行=查询
[postgres@node2 chenhj]$ iostat -k dm-2
Linux 2.6.32-71.el6.x86_64 (node2) 06/23/14_x86_64_(2 CPU)
avg-cpu: %user %nice %system %iowait %steal %idle
0.790.000.373.330.00 95.50
Device:tpskB_read/skB_wrtn/skB_readkB_wrtn
dm-2 57.25 373.21 205.6785608974717624
[postgres@node2 chenhj]$ time psql -p 40382 -c "select count(*) from tb1 where id =666666"
count
-------
1
(1 row)
real0m6.844s
user0m0.002s
sys 0m0.006s
[postgres@node2 chenhj]$ iostat -k dm-2
Linux 2.6.32-71.el6.x86_64 (node2) 06/23/14_x86_64_(2 CPU)
avg-cpu: %user %nice %system %iowait %steal %idle
0.790.000.373.340.00 95.49
Device:tpskB_read/skB_wrtn/skB_readkB_wrtn
dm-2 57.60 422.57 205.5496991614717708
耗时6.8秒，产生IO读1.14G,IO写84K
不清缓存，再执行一次。消耗时间降到1.1秒，几乎不产生IO。
[postgres@node2 chenhj]$ iostat -k dm-2
Linux 2.6.32-71.el6.x86_64 (node2) 06/23/14_x86_64_(2 CPU)
avg-cpu: %user %nice %system %iowait %steal %idle
0.790.000.373.330.00 95.50
Device:tpskB_read/skB_wrtn/skB_readkB_wrtn
dm-2 57.44 421.37 204.9796991774718032
[postgres@node2 chenhj]$ time psql -p 40382 -c "select count(*) from tb1 where id =666666"
count
-------
大约10年前，我加入了Amazon Web Services，在那里我第一次看到了在分布式系统中进行权衡的重要性。在大学里，我已经了解了一致性和可用性之间的权衡（CAP定理），但实际上，频谱要比这深得多。任何设计决策都可能涉及延迟，并发性，可伸缩性，耐用性，可维护性，功能性， *** 作简便性以及系统其他方面之间的权衡，而这些权衡会对应用程序的功能和用户体验产生有意义的影响，并且即使是业务本身的有效性。
也许在权衡需求最明显的分布式系统中最具挑战性的问题是构建分布式数据库。当应用程序开始需要可以在许多服务器上扩展的数据库时，数据库开发人员开始做出极端的权衡。为了在许多节点上实现可伸缩性，分布式键值存储（NoSQL）抛弃了传统关系数据库管理系统（RDBMS）提供的丰富功能集，包括SQL，联接，外键和ACID保证。由于每个人都想要可伸缩性，因此RDBMS消失只是时间问题，对吗？实际上，关系数据库继续主导着数据库领域。这就是为什么：
在分布式系统（或任何系统）中进行权衡时，要考虑的最重要方面是开发成本。
数据库软件所做出的权衡将对应用程序的开发成本产生重大影响。在高级应用程序中处理需要可用性，可靠性和性能的数据是一个固有地需要解决的问题。成功解决每个小问题所需的工时数量可能很大。幸运的是，数据库可以解决许多这些子问题，但是数据库开发人员也面临成本问题。实际上，要使数据库足以满足大多数应用程序的功能，保证和性能，就需要数十年的时间。那就是建立关系数据库如PostgreSQL和MySQL的地方。
在Citus Data，我们从不同角度解决了数据库可伸缩性的需求。我和我的团队在过去的几年中花费了很多时间将已建立的RDBMS转换为分布式数据库，而又不会失去其强大功能或从基础项目中分叉。通过这样做，我们发现RDBMS是构建分布式数据库的理想基础。
使RDBMS对开发应用程序（尤其是开源RDBMS，尤其是云RDBMS）如此吸引人的原因在于，您可以有效地利用数十年来对RDBMS进行的工程投资，并利用这些RDBMS功能。您的应用，降低了开发成本。
RDBMS为您提供：
这些功能几乎对任何非平凡的应用都很重要，但是要花很长时间才能开发。另一方面，某些应用程序的工作量对于单台计算机来说太过苛刻，因此需要水平可伸缩性。
许多新的分布式数据库正在开发中，并且正在分布式键值存储（“ NewSQL”）之上实现RDBMS功能，例如SQL。尽管这些较新的数据库可以使用多台计算机的资源，但是在SQL支持，查询性能，并发性，索引，外键，事务，存储过程等方面，它们仍远未建立在关系数据库系统上。您遇到许多要在应用程序中解决的复杂问题。
许多大型互联网公司采用的替代方法是RDBMS的手动，应用程序层分片（通常是PostgreSQL或MySQL）。手动分片意味着有许多RDBMS节点，并且应用程序会根据某种条件（例如，用户ID）决定连接到哪个节点。应用程序本身负责如何处理数据放置，架构更改，查询多个节点，复制表等，因此，如果执行手动分片，最终将在应用程序中实现自己的分布式数据库，这可能甚至更多。昂贵。
幸运的是，有一种方法可以解决开发成本难题。
PostgreSQL已有数十年的发展 历史 ，其令人难以置信的重点是代码质量，模块化和可扩展性。这种可扩展性提供了一个独特的机会：无需分叉就可以将PostgreSQL转换为分布式数据库。这就是我们构建Citus的方式。
大约5年前，当我加入一家名为Citus Data的初创公司时，我为在竞争激烈的市场中建立高级分布式数据库而无任何现有基础架构，品牌知名度，进入市场，资本或大量工程师的挑战感到沮丧 。 仅开发成本就似乎是无法克服的。 但是，就像应用程序开发人员利用PostgreSQL来构建复杂的应用程序一样，我们利用PostgreSQL来构建……分布式PostgreSQL。
我们创建了Citus，这是开源的PostgreSQL扩展，而不是从头开始创建分布式数据库，它以提供水平扩展的方式透明地分发表和查询，但是应用程序开发人员需要具备所有PostgreSQL功能才能成功。
通过使用在计划查询时Postgres调用的内部挂钩，我们能够将分布式表的概念添加到Postgres。
分布式表的分片存储在具有所有现有功能的常规PostgreSQL节点中，Citus发送常规SQL命令以查询分片，然后合并结果。 我们还添加了参考表的概念，该参考表可在所有节点上复制，因此可以通过任何列与分布式表连接。 通过进一步增加对分布式事务，查询路由，分布式子查询和CTE，序列，更新等的支持，我们达到了最先进的PostgreSQL功能可以使用的规模，但现在已经可以大规模使用。
Citus相对来说还很年轻，但是已经建立在PostgreSQL之上，已经成为世界上最先进的分布式数据库之一。与PostgreSQL的完整功能集相比，这令人毛骨悚然，还有许多工作要做，Citus现在提供的功能及其扩展方式使其在分布式数据库环境中具有很大的独特性。许多当前的Citus用户最初使用Postgres中的许多高级功能在单节点PostgreSQL服务器上建立业务，然后仅用几周的开发工作就迁移到Citus，以将其数据库模式转换为分布式表和引用表。对于任何其他数据库，从单节点数据库到分布式数据库的这种迁移可能要花费数月甚至数年的时间。
像PostgreSQL这样的RDBMS具有几乎无限的功能和成熟的SQL引擎，可让您以多种方式查询数据。当然，这些功能只有在速度很快时才对应用程序有用。幸运的是，PostgreSQL很快，并且通过诸如实时查询编译之类的新功能不断提高，但是当您拥有大量数据或流量以至于一台机器速度太慢时，那些强大的功能就不再那么有用了……除非您可以结合许多计算机的计算能力。这就是功能成为超级大国的地方。
通过采用PostgreSQL功能并进行扩展，Citus具有许多超级功能，这些功能使用户可以将数据库扩展到任意大小，同时保持高性能及其所有功能。
尽管大多数这些功能对于开发需要扩展的复杂应用程序来说似乎都是必不可少的，但并不是所有分布式数据库都支持它们。下面我们根据公开提供的文档对一些流行的分布式数据库进行比较。
与在分布式数据库中拥有超级功能相比，更重要的是能够组合数据库超级功能来解决复杂的用例。
由于支持查询路由，参考表，索引，分布式事务和存储过程，因此即使最先进的多租户OLTP应用程序（例如Copper）也可以使用Citus扩展到单个PostgreSQL节点之外，而不会在应用程序中做出任何牺牲。
如果将子查询下推与并行的分布式DML结合使用，则可以在数据库内部转换大量数据。一个常见的示例是使用INSERT…SELECT构建汇总表，该表可以并行化以适应任何类型的数据量。结合通过COPY，索引，联接和分区进行的批量加载，您将拥有一个非常适合时间序列数据和实时分析应用程序（如Algolia仪表板）的数据库。
正如Microsoft的Min Wei在谈到Microsoft如何使用Citus和PostgreSQL分析Windows数据时指出的那样：Citus使您能够使用分布式OLTP解决大规模OLAP问题。
Citus与其他分布式数据库有些不同，后者通常是从头开始开发的。 Citus没有引入PostgreSQL中尚未提供的任何功能。 Citus数据库以满足需要扩展的用例的方式扩展了现有功能。重要的是，大多数PostgreSQL功能已经针对各种用例进行了数十年的开发和测试，而当今用例的功能要求最终并没有太大不同；主要是数据的规模和大小不同。因此，在构建现代应用程序时，基于世界上最先进的开源RDBMS（PostgreSQL！）构建的分布式数据库（如Citus）可以成为您的武器库中最强大的工具。
原文：https://www.citusdata.com/blog/2018/11/30/why-rdbms-is-the-future-of-distributed-databases/
本文：http://jiagoushi.pro/node/929
讨论：请加入知识星球或者微信圈子【首席架构师圈】
欢迎分享，转载请注明来源：内存溢出
微信扫一扫
支付宝扫一扫
评论列表（0条）