Question

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

我想存储
- GPS坐标（纬度和经度）（每分钟甚至更短的间隔，但我正在考虑每分钟）
- 可以为多个坐标重复的事件
- 日期时间或条目的时间戳（在我的情况下最好使用dunno）
- （用户ID）
我希望能够查询：
- 按地区划分的事件（定义纬度和经度范围，例如从（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

我会选择一个主要的细节方法。

两个优点：

查询仍然很容易（与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

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

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

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