哪种 DBMS 适合超快速读取和简单数据结构？

Question

我正在开发一种产品，作为其操作的一部分，必须跟踪大量文件/目录。这个想法是将统计信息存储在数据库中，然后在启动时为每个文件创建监视。更改的文件将排队（在数据库中）以组同步到远程数据库。它们将按优先级顺序同步，数字介于 1-10 之间。

数据库的相关资料：

• < 100,000 个统计信息条目
• 启动时读取整个数据库，只需要文件路径
• 排队的文件将有一个优先级字段（不需要搜索其他任何内容）
• 插入可能很慢

我发现了几个我认为可以工作的数据库，但我不确定哪个是最好的：

• Redis - 将文件路径存储为键，将统计数据存储为值；队列将是一个列表
• MongoDB - 比 Redis 更多的查询选项，但仍然很快

我认为 NoSQL 数据库将是这里的最佳解决方案，因为没有太多的关系逻辑在进行，并且总数据大小不会太大（例如 < 100 mb，接近 < 30 mb）。我确实看过 SQLite，因为它似乎很简单，可以嵌入到可安装的应用程序中。

由于这是面向最终用户的分布式应用程序而不是高负载服务器，因此数据库不必支持许多并发用户。这里的主要优先事项是找到一个模型最有意义的数据库。

那么问题来了，哪个数据库最适合这种情况？

另外，是否还有其他数据库对这样的应用程序更有意义？

Answer 1

如果你不是那么关心关系逻辑，想要真正快的读取速度，并且你愿意使用 RDBMS，我敢说 MySQL 是有偏见的。为什么 ？？？

MyISAM 存储引擎有一个选项，可以允许增加表的物理结构以获得更好的性能。那个选项是什么？ALTER TABLE 选项 ROW_FORMAT。

例如，MySQL Database Design and Tuning一书建议在第 72,73 页上使用 ROW_FORMAT=FIXED。这将在内部将所有 VARCHAR 字段转换为 CHAR。它会使 MyISAM 表变大，但对它执行 SELECT 会快得多。我可以亲自证明这一点。我曾经有一个 1.9GB 的表。我使用 ALTER TABLE tblname ROW_FORMAT=FIXED 更改了格式。该表最终为 3.7GB。SELECTs 的速度比它快了 20-25%，而没有改进或改变任何其他东西。

如果您已经有一个用数据填充的 MyISAM 表怎么办？您可以根据 MyISAM 表中的数据获取推荐列定义的指标。什么查询显示这些指标？

SELECT * FROM tblname PROCEDURE ANALYSE();

PROCEDURE ANALYZE () 这不会显示数据。它将读取每一列的值并推荐列定义。例如，如果您有一个值为 1-4 的类型列，则建议使用这 4 个值的 ENUM。然后您可以选择使用 TINYINT 或 CHAR(1)，因为它们占用相同的空间量（1 个字节）。

还有一点需要考虑：既然您正在考虑使用 NoSQL DB，那么您有没有想过以 NoSQL 的方式使用 MyISAM？这是很有可能的。我提到的同一本书的第 175 页建议使用HANDLER 结构来读取没有关系包袱的表。事实上，第175页给出了这个例子：

CREATE TABLE customer_mileage_details
(
    customer_id INT NOT NULL,
    ff_number CHAR(10) NOT NULL,
    transaction_date DATE NOT NULL,
    mileage SMALLINT NOT NULL,
    INSERT(customer_id),
    INSERT (ff_number,transaction_date)
) ENGINE = MYISAM;

该表包含数百万行。假设您需要创建一个具有以下要求的数据分析应用程序：

• 它需要尽快检索信息块。
• 根据用户输入或其他因素，它可能会在表格中“跳来跳去”。
• 它不关心并发性或其他数据完整性问题。
• 不需要跨应用程序表锁定。

这些命令允许从表中快速读取：

HANDLER customer_mileage_details OPEN;
HANDLER customer_mileage_details READ ff_number FIRST WHERE ff_number=('aaetm-4441');
HANDLER customer_mileage_details READ NEXT LIMT 10;
HANDLER customer_mileage_details CLOSE;

我希望这能让人深思。请调查一下。

警告

关于我写这篇特别文章的讽刺之处在于，我之前写了一篇关于在 Percona Server 二进制文件中使用 HANDLER 的文章，并认为使用它已经过时了。自从那篇较旧的帖子以来，我从没想过我会写一些东西来支持 HANDLER 结构。我现在站得更正了。

Answer 2

我首先想到的是我熟悉的特定 RDBMS。但是，我承认它可能不是此应用程序的最佳选择。

因此，我的建议是使用您熟悉的数据库。如果您熟悉 Redis 或 MongoDB，请选择其中之一。如果您更熟悉 SQLite，请选择它。

在这种规模的数据库上，一切都会很快。即使是磁盘较多的数据库也会使用某种缓存，这样磁盘速度就不会成为太大的问题。