存储 html 文件（或一般文件）的最佳数据库

Question

将 html 文件（小尺寸，~最大 700kb）存储到数据库中的最佳数据库类型（面向文档、关系、键值等）是什么？

目前我正在使用 sqlite3 和 python，但如果条目/文件的数量超过 3000（那么 .db 文件大约为 260mb），它似乎会变得相当慢。除此之外，sqlite 不适合多处理用例。

sqlite 模式是这样的：

CREATE TABLE articles (url TEXT NOT NULL,published DATETIME,title TEXT, fetched TEXT NOT
    NULL,section TEXT,PRIMARY KEY (url), FOREIGN KEY(url) references
    contents(url));
CREATE TABLE contents(url TEXT NOT NULL,date DATETIME,content TEXT,PRIMARY KEY (url));

CREATE TABLE shares (url TEXT NOT NULL, date DATETIME,likes INTEGER NOT NULL,
                    totals INTEGER NOT NULL,clicks INTEGER, comments INTEGER NOT                
                    NULL,share INTEGER NOT NULL, 
                    tweets INTEGER NOT NULL,PRIMARY KEY(date,url),FOREIGN KEY (url)       
                     REFERENCES articles(url));

html 文件转到内容

Answer 1

对于使用 URL 作为主键的以文档为中心的数据库，并且还必须支持多个并发编写器，您可能希望考虑使用 SQLite 上的 noSQL 数据库之一。目前此处列出了其中的 122 个。

“相当慢”对你来说意味着什么？您确定感知到的缓慢是@数据库吗？

Answer 2

所以你认为，sqlite 一般来说应该具有足够的可扩展性？

现实世界中不存在“一般”场景。不，我认为它对于以文档为中心的应用程序（记录可以达到 500K）来说不能很好地扩展。 SQLite 没有经过优化，无法在繁忙的多个并发写入场景中很好地扩展，其中“繁忙”是一个多变量函数，涉及每秒写入次数、正在写入的记录大小以及表上有多少个索引。简而言之，写入操作的磁盘密集度越高（ergo），其扩展性就越差。换句话说，记录越大和/或表的索引越多，每秒可以容纳的写入次数就越少。 500K 的记录确实是一个非常大的记录。使用 MVCC 会更好。