Storing large amount of data in database
我对存储大量数据有疑问。情况如下：
我想存放
- GPS坐标(经度和纬度)(每分钟甚至更短的间隔，但我正在考虑每分钟)
- 事件，可以重复几个坐标
- 入口的日期时间或时间戳(在我的情况下最好使用的dunno)
- (用户身份)
我希望能够查询：
- 按区域划分事件(定义纬度和经度范围，例如从(1,1)到(2,2))
- 用户从日期X跟踪到Y(一个或多个用户)
到目前为止，我一直在考虑解决方案：
解决方案1
1 2 3 4 5 6 |
我开始做一些计算，这将是这样的：
- 每天约500个条目/用户
- 因为我正准备申请一些负载，所以可以有大约100-150个用户，每天75000个条目
- 一个月后将有数百万条款
可能解决方案1并不是一个好的解决方案，因为数据库的大小增长非常快。
解决方案2
有2个表，其中一个是根据事件的聚合坐标，例如我有事件"晚餐"，它需要30分钟，所以30个条目将被分组在一个BLOB类型的字段中。该表格如下：
另一个表已经计算了具有一些"宽度"和"长度"的位置，具有指向第一个表的指针
这个解决方案只能部分地解决我的问题，想象一下，有些事件不会超过几分钟，而且需要第二个数据库。
解决方案3
这可能不是非常正确的解决方案，但似乎有道理。我有一些与某种体验相关的用户，它有开始日期和结束日期。当经验添加时，我将为该体验创建数据转储并保存到文件中，删除与体验相关的条目。当用户想要查阅"存档"体验时，我会将数据加载到某个临时表中并在一天内删除(例如)，在这种情况下，我将根据解决方案1保存数据。
主要问题是：在数据库性能方面是否可以接受任何提出的解决方案？我的问题有更好的解决方案吗？
我会选择一个主要的细节方法。
两个优点：
哟没有多余的条目(1个主行和x个子行与坐标)
它仍然很容易查询(与blob方法相反)。
如果在master_table_id上??设置外键或索引，即使主表中有数百万条记录，这应该非常快
"数以百万计的条目"听起来很多，但这就是数据库的设计目标。无论你如何设计它，如果你根据你以后想要从中提取结果的方式对它进行优化(那就是花费时间而不是插入的那些)那么你很高兴。
当然要说...如果你有很多用户同时在你的数据库中做很多事情，那么我认为你的服务器/带宽在你的数据库之前去了！
您可能希望阅读此内容：http：//dev.mysql.com/doc/refman/5.0/en/spatial-extensions.html。
从广义上讲，只要您可以在查询中使用索引，巨大的表就不是问题 - 可以在消费级笔记本电脑上查询数十亿条记录。如果您打算扩展到大量的历史记录，您应该有一个归档策略，但这不是一个重要的优先事项。
更棘手的是支持你在某个地理边界内寻找事件的愿望;这很容易以各种令人讨厌的方式打破你的索引策略。如果必须基于数学运算进行查询，则可能无法使用索引 - 因此查找半径为1英里的圆圈内的用户可能必须为数据库表中的每条记录评估圆形公式。
空间扩展为此提供了解决方案 - 但它们不是"免费"的，您必须专门为此优化您的设计。