mysql - 维基百科转储表页面链接的问题

我从 enwiki-latest-pagelinks.sql.gz 下载了 dumps.wikimedia.org/enwiki/latest/ 转储。

我对文件进行了压缩，其未压缩大小为 37G。

表结构是这样的:

SHOW CREATE TABLE wp_dump.pagelinks;

CREATE TABLE `pagelinks` (
  `pl_from` int(8) unsigned NOT NULL DEFAULT '0',
  `pl_namespace` int(11) NOT NULL DEFAULT '0',
  `pl_title` varbinary(255) NOT NULL DEFAULT '',
  `pl_from_namespace` int(11) NOT NULL DEFAULT '0',
  UNIQUE KEY `pl_from` (`pl_from`,`pl_namespace`,`pl_title`),
  KEY `pl_namespace` (`pl_namespace`,`pl_title`,`pl_from`),
  KEY `pl_backlinks_namespace` (`pl_from_namespace`,`pl_namespace`,`pl_title`,`pl_from`)
) ENGINE=InnoDB DEFAULT CHARSET=binary

我将该表导入到一个新的空数据库中:

mysql -D wp_dump -u root -p < enwiki-latest-pagelinks.sql

我正在运行任务的计算机有 16G 的 RAM，并且 mysql 数据库位于 SSD 上，所以我假设尽管表的大小，导入不会花费太长时间。

但是，该任务已经运行了一天，并且仍在运行。没有其他进程访问mysql，计算机上也没有工作负载。

数据库文件本身现在有 79G 大。

ls -lh

-rw-r----- 1 mysql mysql   65 May 11 17:40 db.opt
-rw-r----- 1 mysql mysql 8,6K May 12 07:06 pagelinks.frm
-rw-r----- 1 mysql mysql  79G May 13 16:59 pagelinks.ibd

该表现在有超过 5 亿行。

SELECT table_name, table_rows FROM INFORMATION_SCHEMA.TABLES WHERE TABLE_SCHEMA = 'wp_dump';

+------------+------------+
| table_name | table_rows |
+------------+------------+
| pagelinks  |  520919860 |
+------------+------------+

我想知道:
enwiki-latest-pagelinks.sql 真的超过 79G 大吗？
pagelinks 真的包含超过 5 亿行吗？

导入 pagelinks 表真的需要那么长时间吗？

您能否提供一些指标，即预期的表大小和行数？

更新 :2017 年 5 月 14 日:
insert 仍在运行； pagelinks.ibd 文件现在 130G；行数现在接近 7 亿

更新 :2017 年 5 月 16 日:
insert 仍在运行； pagelinks.ibd 文件现在 204G；行数现在超过 12 亿

我计算了过去两天每秒插入的行数:

行/sek = 3236

并且:sql 脚本中每个插入语句有数千次插入(head -41 enwiki-latest-pagelinks.sql | tail -1 | grep -o "(" | wc -l 是 30471)

所以，我的后续/修改的问题:

考虑到 37G 的 sql 文件大小和表结构(如上所列)，行数和 idb 文件大小是否符合预期？

rows/sek = 3236 是一个很好的值(意味着插入表需要几天时间)？

什么可能是限制速度因素/我如何加快导入速度？

禁用索引(并在插入后计算它们)？

优化交易(提交(在脚本中没有设置)/autocommit(现在开启))？

优化变量设置(例如 innodb_buffer_pool_size ，现在是 134217728)？

最佳答案

37GB 的数据 --> 79GB 的 InnoDB 表似乎合理......

标题:2 个引号和 1 个逗号 --> 1 个字节的长度

Ints:几个字节，加上逗号 --> INT 的 4 个字节(不管 (...) 之后的 INT 。参见 MEDIUMINT .

每行 20-30 字节开销

BTrees 的开销为 20-40%。

UNIQUE 索引变成 PRIMARY KEY 和数据簇 --> 很少的开销。

其他两个索引:每个索引的大小几乎与数据相同。这更多允许增加的尺寸。

将它们加在一起，我希望该表超过 120GB。因此，可能缺少一些细节。猜测:转储是每个 INSERT 一行，而不是不太冗长的 many-rows-per-INSERT 。

至于性能，这完全取决于 SELECTs 。将 innodb_buffer_pool_size 设置为 11G 左右。这对于缓存 79G 可能足够有效。

更多

将 UNIQUE 更改为 PRIMARY ，为了清楚起见，因为 InnoDB 确实需要一个 PK。

检查源数据。是 ( pl_from , pl_namespace , pl_title ) 顺序吗？如果没有，您可以在加载前对文件进行排序吗？如果可以，仅此一项就应该对速度有很大帮助。

buffer_pool 的 128MB 也严重阻碍了进度。

关于mysql - 维基百科转储表页面链接的问题，我们在Stack Overflow上找到一个类似的问题：https://stackoverflow.com/questions/43954631/

pageLinks

mysql - 维基百科转储表页面链接的问题