在Postgis中上传大量空间数据有哪些好方法?

发布于 2024-11-14 19:31:26 字数 338 浏览 2 评论 0原文

我有大量空间数据需要分析并在应用程序中使用。原始数据以 WKT 格式表示,我将其包装到 INSERT SQL 语句中以上传数据。

INSERT INTO sp_table ( ID_Info, "shape") VALUES ('California', , ST_GeomFromText('POLYGON((49153 4168, 49154 4168, 49155 4168, 49155 4167, 49153 4168))'));

然而,这种方法花费太多时间并且数据很大(1000 万行)。 那么,有没有其他方法可以上传大量的空间数据呢?

任何加速黑客和欢迎赞赏技巧。

I have a large amount of spatial data I need analyze and put into use in an application. Original data is represented in WKT format and I'm wrapping it into a INSERT SQL statements to upload the data.

INSERT INTO sp_table ( ID_Info, "shape") VALUES ('California', , ST_GeomFromText('POLYGON((49153 4168, 49154 4168, 49155 4168, 49155 4167, 49153 4168))'));

However this approach is taking too much time and data is large (10 million rows).
So, is there any other way to upload large amount of spatial data ?

Any speedup hacks & tricks are welcome appreciated.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(2

叫思念不要吵 2024-11-21 19:31:26

使用 COPY 将文本文件插入表(具有适当的列)

如果没有

VACUUM

则向此表添加一个串行主键每个 CPU 生成一个进程,执行以下操作:

INSERT INTO sp_table ( ID_Info, "shape")
SELECT state_name, ST_GeomFromText( geom_as_text )
FROM temp_table
WHERE id % numbre_of_cpus = x

为每个进程使用不同的“x”值,所以整个表都被处理了。这将允许每个核心在慢速 ST_GeomFromText 函数上运行。

插入后创建GIST索引。

Insert your text file into a table (with proper columns) using COPY

Add a SERIAL PRIMARY KEY to this table if it doesn't have one

VACUUM

Spawn one process per CPU which does this :

INSERT INTO sp_table ( ID_Info, "shape")
SELECT state_name, ST_GeomFromText( geom_as_text )
FROM temp_table
WHERE id % numbre_of_cpus = x

Use a different value of "x" for each process, so the entire table is processed. This will allow each core to run on the slow ST_GeomFromText function.

Create GIST index after insertion.

—━☆沉默づ 2024-11-21 19:31:26

在这里您可以找到一些常规性能提示。可能您启用了 fsync 属性并且每个 INSERT 命令都被强制物理写入硬盘,这就是为什么它需要如此多的时间。

不建议关闭 fsync(尤其是在生产环境中),因为它可以让您在操作系统意外崩溃后安全地恢复数据。根据文档:

因此仅建议关闭
fsync 如果您可以轻松地重新创建您的
来自外部数据的整个数据库。

Here you can find some general performance tips. Probably you have fsync property enabled and every INSERT command is forced to be physically written to hard disk, that's why it takes so much time.

It's not recommended to turn off fsync (especially in production environments), because it allows you to safely recover data after unexpected OS crash. According to doc:

Thus it is only advisable to turn off
fsync if you can easily recreate your
entire database from external data.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文