用大量数据填充 PostgreSQL 数据库

发布于 2024-10-14 08:08:45 字数 238 浏览 1 评论 0原文

我有一个具有一定结构的 PostgreSQL 数据库，并且有几百万个 xml 文件。我必须解析每个文件，获取某些数据并填充数据库中的表。我想知道的是执行此例程的最佳语言/框架/算法。
我使用 DbLinq ORM 用 C# (Mono) 编写了一个程序。它不使用线程，只是逐个解析文件，填充表对象并将特定组的对象（例如 200）提交到数据库。它看起来相当慢：每分钟处理大约 400 个文件，大约需要一个月才能完成这项工作。
我询问你的想法和建议。

原文

分享到QQ

分享到微博

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

发布评论

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

无边思念无边月 2024-10-21 08:08:45

我认为当您在管道中使用小程序时，速度会更快：

将您的文件加入到一个大流中；
解析输入流并生成 PostgreSQL COPY 格式的输出流 - pg_dump 在创建备份时使用相同的格式，类似于制表符分隔值，如下所示：

COPY table_name (table_id, table_value) FROM stdin;
1   value1
2   value2
3   value3
\.

将 COPY 流加载到 Postgresq 中，使用“-F”选项临时启动以禁用 fsync 调用。

例如在 Linux 上：

find -name \*.xml -print0 | xargs -0 cat \
  | parse_program_generating_copy \
  | psql dbname

使用 COPY 比使用 ORM 插入快得多。连接文件将并行读取和写入数据库。禁用“fsync”将允许大幅加速，但如果服务器在加载过程中崩溃，则需要从备份恢复数据库。

I think it would be faster when you'll use small programs in a pipe that will:

join your files into one big stream;
parse input stream and generate an output stream in PostgreSQL COPY format - the same format pg_dump uses when creating backups, similar to tab-separated-values, looks like this:

COPY table_name (table_id, table_value) FROM stdin;
1   value1
2   value2
3   value3
\.

load COPY stream into Postgresq started temporarily with "-F" option to disable fsync calls.

For example on Linux:

find -name \*.xml -print0 | xargs -0 cat \
  | parse_program_generating_copy \
  | psql dbname

Using COPY is much faster than inserting with ORM. Joining files will parallelise reading and writing to database. Disabling "fsync" will allow for big speedup, but will require restoring a database from backup if a server crashes during loading.

回复收藏 0 原文

别忘他 2024-10-21 08:08:45

一般来说，我认为 Perl 是解析任务的一个不错的选择。我自己也不了解 Perl。在我看来，您的性能要求如此之高，以至于您可能需要创建一个 XML 解析器，因为标准解析器的性能可能会成为瓶颈（您应该在开始实施之前对其进行测试）。我自己使用 Python 和 psycopg2 与 Postgres 进行通信。

无论您选择哪种语言，您肯定希望使用 COPY FROM 以及可能使用 Perl/Python/其他语言的 stdin 将数据输入 Postgres。

您还可以使用次优解决方案并在 100 个 EC2 实例上极端并行地运行它，而不是花费大量时间来优化所有内容。这比花费大量时间寻找最佳解决方案要便宜得多。

在不知道文件大小的情况下，每分钟 400 个文件听起来还不错。问问自己是否值得花一周的开发时间来将时间减少到三分之一，还是现在就运行并等待一个月。

回复收藏 0 原文

~没有更多了~