在关系数据库中存储大量点（x，y，z）

Posted 2023-04-18

【中文标题】在关系数据库中存储大量点（x，y，z）

【英文标题】：Storing a huge amount of points(x,y,z) in a relational database

【发布时间】：2013-11-14 15:30:46

【问题描述】：

我需要在磁盘上存储一个非常简单的数据结构——Point。它的字段只是：

Moment - 64位整数，表示高精度的时间

EventType - 32 位整数，引用另一个对象

Value - 64 位浮点数

要求：

1) (Moment + EventType) 这对是Point 的唯一标识符，所以我怀疑它是一个表的复合主键

2) 有大量的Points。高达 50 亿（1-2 TB 的磁盘空间）。所以格式必须尽可能小。

3) 表的典型且几乎单一的用法是通过精确的EventType 和Moments 的范围检索（或创建视图）数百万个Points。

问题：

选择哪个 RDBMS 以及为什么选择？

Points 的表的最佳 sql 定义是什么？

下面关于我的想法的cmets也很感激

我的研究：

我是 RDBMS 领域的新手，但我听说过很多关于 SQLite 的信息。我不需要一个包含所有工具、功能和扩展（如 PostgreSQL 或 MSSQL）的庞大专业系统。此外，我觉得我不需要服务器而不是简单的“嵌入式”数据库文件，因此 SQLite 的选择看起来是最佳选择。另一个具有嵌入式数据库功能的优秀 RDBMS 是 Firebird，但我被 SQLite 的动态类型范式所吸引。看起来它可以为我节省磁盘空间，因为整数字段可以以“较小”的形式存储（1、2、3、4、6 字节）。

但很快问题就出现了。

首先，当主键为复合时，SQLite 会创建特殊的ROWID 列（64 位长度）：

CREATE TABLE points (
    moment integer not null,
    event_id integer not null,
    value numeric not null,
    PRIMARY KEY (moment, event_id)
);

这意味着表白白浪费了将近 40% 的空间。

我发现了关于 "The WITHOUT ROWID Optimization" 的好文章。但它仅在 SQLite 的 3.8.2 版本（2013 年 12 月）中可用。等待我需要的 ADO.NET 提供程序是不合适的。

另一个问题是 SQLite 对表使用B-tree。我不确定，但看起来选择数据范围效率低下。我的主要任务是根据主键的范围选择一大块 Points，所以看起来 SQLite 将是一个不好的选择。

未来的研究对我来说似乎太难了（至少在今天）。期待有经验的人的帮助。

【问题讨论】：

为什么你认为 B 树不好？你认为还有什么其他的表格组织会更有效率？

@CL 我认为这对我的目的不利。简单排序的数据将更容易按范围选择。

“简单排序的数据”不允许随机访问，不能保证数据保持排序状态。

【参考方案1】：

B 树是选择数据范围最有效的组织。

如果您搜索常量event_id 值和moment 值范围，则仅当event_id 是索引中的第一列时，双列索引才能用于这两个查找：

CREATE TABLE points (
    event_id INTEGER NOT NULL,
    moment INTEGER NOT NULL,
    value NUMERIC NOT NULL,
    PRIMARY KEY (event_id, moment)
);

您应该尝试使用 3.8.2 版本，以便可以使用 WITHOUT ROWID 优化。developers 可能会很高兴有人会测试这个功能，并给你一个编译的预发布版本。

【讨论】：

我认为这是最佳决定。成为 sqlite 早期测试人员的可能性激励了我，谢谢

【参考方案2】：

我认为如果您的表将使用多个用户，则不应使用嵌入式数据库 Oracle 怎么样 - 按索引（可能按事件）组织表 + 按范围分区 或mysql按范围分区

如果您的应用程序中真的只有一个用户，也许您可​​以使用文件系统？ 类似分区表的东西 您可以创建名称与范围相关的文件夹 并创建名称与 event_id 相关的文件，因此您只需要在文件中存储时刻 + 数据 甚至更多，例如你的时刻看起来像 201311141820001234567890123456 您可以创建名称为 2013111418 的文件夹，并仅将部分时刻和数据存储在文件中 20001234567890123456,数据 20001234567890123457,数据

【讨论】：

只有一个用户。 FS 将使用更多空间，查询效率低且难以实施和支持