我有一个关于存储大量数据的问题。情况如下:
1. 我想要存储: - GPS坐标(纬度和经度)(每分钟或更短时间间隔,但我考虑每分钟) - 可以在多个坐标上重复的事件 - 条目的日期时间或时间戳(不知道在我的情况下哪个更好) - (用户ID)
2. 我希望能够查询: - 通过区域定义(例如从(1,1)到(2,2))查询事件 - 从日期X到日期Y跟踪一个或多个用户
到目前为止,我考虑的解决方案是: 解决方案1
我开始进行一些计算,大约每个用户每天会有500个条目;因为我正在为某种负载准备应用程序,可能会有100-150个用户,这将是75000个条目/天;一个月后就会有数百万个条目。解决方案1可能不是好的解决方案,因为数据库的大小将会快速增长。 解决方案2 有两张表,其中之一将根据事件汇总坐标,例如我有一个事件“晚餐”,需要30分钟,那么30个条目将归为一个具有BLOB类型的字段。此表将如下所示:
这个解决方案只是部分地解决了我的问题。想象一下,有些事件不会超过几分钟,需要第二个数据库... 解决方案 3 这可能不是非常正确的解决方案,但它似乎有一定意义。我有一个用户关联到某种经历,它有开始日期和结束日期。当添加经历时,我将创建该经历的数据转储并保存到文件中,并删除与该经历相关的条目。当用户想要查看“存档”的经历时,我将把数据加载到某个临时表中,并在一天内删除它(例如),在这种情况下,我将按照解决方案1保存数据。
主要问题是:在数据库性能方面,这些解决方案中是否有可接受的方案?对于我的问题,是否有更好的解决方案?
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 有两张表,其中之一将根据事件汇总坐标,例如我有一个事件“晚餐”,需要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保存数据。
主要问题是:在数据库性能方面,这些解决方案中是否有可接受的方案?对于我的问题,是否有更好的解决方案?