该应用程序将连续（大约每秒）收集用户的位置并将其存储。

该数据是结构化的。在关系数据库中，它将存储为： | user | timestamp | latitude | longitude |

但是，数据太多。每个用户每天将有60×60×24 = 86,400条记录。即使有1000个用户，这也意味着每天86,400,000条记录。

每天不仅有86,400,000条记录。因为这些记录将被处理，并且它们的处理后的版本也将被存储。因此，将该数字乘以大约2。

我打算如何使用数据

本质上，我计划对位置数据进行更粗粒度的处理，以便于使用。那是：

1. 对接收到的带有时间戳的数据进行排序。
2. 依次浏览此列表，确定位置是否发生了重大变化（通过查看经度和纬度发生了多少变化）
3. 将不重要的位置更改表示为输出中的单个条目（因此，输出是位置数据的粗粒度版本）。
4. 通过要求更大的纬度和经度更改以进行重大更改，对输出进行迭代处理。因此，从先前输出产生的输出将更加粗糙。
5. 根据需要重复整个过程。
6. 汇总一系列分辨率并将其发送给用户。另外，存储数据的所有分辨率以供以后使用。

我应该用什么来存储这些数据？我应该使用关系数据库还是NoSQL解决方案？设计此应用程序时，我还应考虑哪些其他事项？

一些用于存储此数据的替代方法：

1. 消息队列（可能是分布式的），例如Apache Kafka

这将针对写入和读取数据流进行优化。它是以易于处理的格式收集数据流的理想选择，但通常无法查询它，除非通过整体读取该流。因此，这可能是出于存档目的，或者是进入处理层的中间步骤。

2. 关系数据库

您可以将其写入数据库，并且当卷超过数据库的处理能力时，可以分片数据库（=有多个数据子集位于不同的数据库服务器上）。好处：您可以使用关系数据库，而不必学习任何新知识。缺点：所有与数据库有关的代码都必须知道哪个数据驻留在哪个分片上，聚合查询必须在应用程序软件中完成。

3. 分布式NoSQL数据库，例如Cassandra。

您将数据写入分布式NoSQL数据库，它将自动为您分片数据。Cassandra允许您在整个集群中进行查询，需要较少的应用程序代码来取回数据。好处：更自然地适合于大量数据，缺点：需要特定的专业知识，并对这些系统如何工作的机制有深入的了解，以实现良好的性能并根据您的需求查询数据。NoSQL并不是一个神奇的性能修复，它是一组折衷，必须理解这些折衷。

4. Hadoop /文件

数据被附加到文件，这些文件由Hadoop平台自动分布在服务器之间，使用M / R或Apache Spark等工具在这些服务器上进行处理，最后使用Hive或Impala等Hadoop SQL引擎进行查询（作为文件）。

选择哪一个？

这些选择之间的权衡比较复杂，它们在很大程度上取决于您的写入和读取模式，因此，唯一可以决定这些权衡的人就是您。如果您缺乏时间来深入了解这些替代方法，则只需使用关系数据库并逐步了解分片解决方案即可。很可能是YAGNI。

深入了解您的需求。有一种方法可以产生每秒跟踪位置的错觉。

如果您有一个知道当前GPS位置并将其写入数据库的应用，那么如果位置不变，为什么还要继续写入呢？ 即使您需要数据，如果用户已经睡了7个小时，您也可以通过编程的方式在丢失的时隙中填写重复的位置，以进行计算或映射或执行其他任何操作。

如果您确实每秒跟踪一次位置，那么是否需要永远存储这些数据？ 您可以将记录归档到另一个数据库，以防止当前表变得太大。或者，您甚至可以保留位置变化的记录。这在数据仓库中很常见。

您的数据是一组时间序列。您已经给出了随时间变化的数字集（每个用户两个）。通常，您不是在寻找任何类型的关系存储，而是在寻找RRD存储。这些存储主要集中在通过缓冲来减少大量小写操作的I / O工作。

关系存储对于这个时间序列量是一个混乱。但是，请注意，就可编程利用而言，RRD的开发并没有像SQL那样得到很好的支持。您可能正在寻找认真的集成工作，但是鉴于您的要求，这几乎是不可避免的。