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

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

有关数据库的信息：

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

我找到了一些我认为可以使用的数据库，但是我不确定哪一个是最好的：

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

我认为NoSQL数据库将是最好的解决方案，因为没有太多的关系逻辑，总数据量也不会太大（例如<100 mb，更接近<30 mb）。我确实看过SQLite，因为它看起来很简单，可以嵌入可安装的应用程序中。

由于这是面向最终用户而不是高负载服务器的分布式应用程序，因此数据库不必支持许多同时用户。这里的首要任务是找到一个最有意义的数据库。

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

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

首先想到的是我熟悉的特定RDBMS。但是，我知道这可能不是最佳的应用程序。

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

在这种规模的数据库上，一切都将很快。即使是磁盘占用量更大的数据库，也将使用某种类型的缓存，因此磁盘速度并不是太大的问题。

如果您不关心关系逻辑，想要真正的快速读取速度，并且您愿意使用RDBMS，我会冒昧地说MySQL。为什么???

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

例如，《MySQL数据库设计和调整》一书建议在第72,73页上使用ROW_FORMAT = FIXED。这将在内部将所有VARCHAR字段转换为CHAR。它将使MyISAM表更大，但是针对它执行的SELECT将更快。我可以亲自证明这一点。我曾经有一张1.9GB的桌子。我使用ALTER TABLE tblname ROW_FORMAT = FIXED更改了格式。该表最终为3.7GB。SELECT的速度提高了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;

我希望这能引起大家的思考。请调查一下。

警告

具有讽刺意味的是，我写这篇特别的文章是我写了一篇有关Permana Server二进制文件中使用的HANDLER的早期文章，并认为使用它已过时。从那篇较早的文章开始，我从未想过我会写任何东西来支持HANDLER结构。我现在纠正了。