具有数百万个“url”字符串的 sqlite 数据库设计 - 从 csv 批量导入缓慢答案

【问题标题】：sqlite database design with millions of 'url' strings - slow bulk import from csv具有数百万个“url”字符串的 sqlite 数据库设计 - 从 csv 批量导入缓慢
【发布时间】：2011-06-04 21:01:24
【问题描述】：

我正在尝试通过导入带有 url 的 csv 文件来创建一个 sqlite 数据库。该文件有大约 600 万个字符串。这是我用过的命令

create table urltable (url text primary key);
.import csvfile urldatabase

大约 300 万个 url 之后，速度变慢了很多，我的硬盘一直在旋转。我尝试将 csv 文件拆分为 1/4 块，但遇到了同样的问题。

我在 stackoverflow 上阅读了类似的帖子，并尝试使用 BEGIN...COMMIT 块和 PRAGMA synchronous=OFF，但它们都没有帮助。我能够创建数据库的唯一方法是从 url 中删除 primary key 约束。但是，当我运行选择命令来查找特定 url 时，需要 2-3 秒，这对我的应用程序不起作用。在 url 上设置主键后，选择是即时的。请告诉我我做错了什么。

[编辑] 有帮助的建议摘要：

减少交易次数
增加页面大小和缓存大小
稍后添加索引
从 url 中删除冗余

尽管如此，使用主索引，数据库大小还是我尝试导入的原始 csv 文件的两倍多。有什么办法可以减少吗？

【问题讨论】：

尝试使用 url 的哈希创建另一列并使其唯一。
如果数据不必是唯一的，为什么不给url列添加一个常规索引呢？
@JohnRoss ：关于您的第一条评论，如果我将哈希列设为唯一，我将如何处理哈希冲突？关于第二条评论，url数据是唯一的。
如果你知道输入数据是唯一的，为什么要让数据库在插入时验证呢？如果您选择具有良好熵的散列算法，例如 SHA1，您可能不会遇到冲突。我正在考虑插入时必须检查的内容，当您的所有输入都以 http://www. 开头时，这是 11 个字符，否则在检查每个插入的有效性时可能会被忽略。
@JoshRoss 不错的建议，就我而言，我可以拆分网址并忽略公共部分。

标签： search sqlite

【解决方案1】：

将缓存大小增加到足够大以包含内存中的所有数据。页面大小和缓存大小的默认值相对较小，如果这是一个桌面应用程序，那么您可以轻松地多次增加缓存大小。

PRAGMA page_size = 4096;
PRAGMA cache_size = 72500;

将为您提供略低于 300mb 的缓存大小。请记住，必须在创建数据库之前设置页面大小。默认页面大小为 1024，默认缓存大小为 2000。

或者（或几乎等效地）您可以完全在内存数据库中创建数据库，然后使用备份 API 将其移动到磁盘数据库。

【讨论】：

【解决方案2】：

PRIMARY KEY 或 UNIQUE 约束将自动生成索引。索引将显着加快SELECTs，但会以减慢INSERTs 为代价。

尝试将您的数据导入非索引表，然后然后明确地CREATE UNIQUE INDEX _index_name ON urltable(url)。一次建立所有索引可能比一次建立一个行更快。

【讨论】：

这不是我使用 BEGIN...COMMIT 块时发生的事情.. 即最后索引
@buffer，不完全一样，dan04是对的，插入完成后创建索引可以显着加快整体进程。但是，由于数据量如此之大且缓存大小很小，您仍然会遇到大量磁盘抖动，因此更好的解决方案是增加缓存大小（或者更好——两者都做）。
谢谢@dan04 和@Samuel Neff。您的方法确实有助于创建数据库。将 url 作为主键会使 db 的大小增加一倍以上。我怎样才能减少它？一个 600MB 的 url 文本文件转换为 1.5GB 的数据库，其中 url 上有主索引。
@buffer，你不能在缩小尺寸的同时仍然使用 sqlite。 SQLite 总是在内部将数据存储在由数字序列索引的页面中，并且附加索引存储在单独的页面中。如果您只想存储该数据一次，而您所拥有的只是 URL 列表，那么您可以使用更有效和更具体的数据结构和备用存储机制。我什至听说有些人使用 SQLite 中的树代码与 SQLite 分开。