在数据库中存储大量数据

Question

我对大量数据的存储有疑问。情况如下：

1. 我要存储

   • GPS坐标（纬度和经度）（每分钟甚至更短的间隔，但我正在考虑每分钟）
   • 事件，可以针对多个坐标重复
   • 条目的日期时间或时间戳（不知道在我的情况下使用哪个更好）
   • （用户 ID）

2. 我希望能够查询：

   • 按区域划分的事件（定义纬度和经度的范围，例如从 (1,1) 到 (2,2)）
   • 从日期 X 到日期 Y 的用户跟踪（一名或多名用户）

到目前为止，我正在考虑解决方案：

解决方案 1

id_user (int)
id_experince (int)
id_event (int)
dt (datetime)
latitude (decimal)
longitude (decimal)

我开始做一些计算，类似于： - 每个用户每天大约 500 个条目 - 由于我正在准备一些负载的应用程序，因此可能有大约 100-150 个用户，这将是 75000 个条目/天 - 一个月后将有数百万个条目

也许，解决方案 1 不是一个好的解决方案，因为数据库的大小增长得非常快。

解决方案2

有2个表，其中一个将根据事件聚合坐标，例如我有一个事件“晚餐”，需要30分钟，因此30个条目将被分组在一个BLOB类型的字段中。该表将如下所示：

id_user (int)
id_experience (int)
id_event (int)
dt (datetime)
coordinates(blob)

另一个表已计算出具有某些“宽度”和“长度”的位置，并具有指向第一个表的指针

latitude (decimal)
longitude (decimal)
id_entry_in_first_table (int)

此解决方案仅部分解决了我的问题，想象一下，某些事件不会超过几分钟并且需要第二个数据库。

解决方案 3

这可能不是非常正确的解决方案，但似乎有一定道理。我有与某种体验相关的用户，该体验具有开始日期和结束日期。当经验添加时，我将为该经验创建数据转储并保存到文件中，删除与该经验相关的条目。当用户想要查阅“存档”体验时，我会将数据加载到某个临时表中并在一天内将其删除（例如），在这种情况下，我将根据解决方案1保存数据。

主要问题是：就数据库性能而言，所提出的解决方案是否可以接受？对于我的问题有更好的解决方案吗？

Answer 1

“数百万个条目”听起来很多，但这就是数据库设计的目的。无论您如何设计它，如果您根据稍后想要从中提取结果的方式对其进行优化（因为这将花费时间而不是插入），那么您就可以开始了。

当然，如果您有很多用户同时对您的数据库执行很多操作，那么我认为您的服务器/带宽会先于数据库执行！

Answer 2

我会选择主细节方法。

两个优点：

1. 没有冗余条目（1 个主行和 x 个带有坐标的子行）

2. 它仍然很容易查询（与 blob 方法相比）。

   SELECT m.id_user、m.id_experince、m.id_event、c.latitude、c.longitude
   FROM master_table m
   LEFT JOIN child_table c ON m.id = c.master_table_id
   

如果您在 master_table_id 上设置外键或索引，即使主表中有数百万条记录，这也应该相当快

Answer 3

您可能想阅读以下内容：http://dev.mysql。 com/doc/refman/5.0/en/spatial-extensions.html。

一般来说，只要您可以在查询中使用索引，巨大的表就不是问题 - 可以在消费级笔记本电脑上查询数十亿条记录。如果您打算扩展到大量历史记录，则应该制定归档策略，但这不是一个重要的优先事项。

更棘手的是支持您在特定地理边界内查找事件的愿望；这很容易以各种令人讨厌的方式破坏您的索引策略。如果您必须基于数学运算进行查询，则可能无法使用索引 - 因此查找 1 英里圆圈半径内的用户可能必须评估数据库表中每条记录的圆圈公式。

空间扩展为此提供了一个解决方案 - 但它们不是“免费的”，您必须专门为此优化您的设计。