用于非常频繁的 gps 数据收集的技术堆栈答案

【问题标题】：Technology stack for very frequent gps data collection用于非常频繁的 gps 数据收集的技术堆栈
【发布时间】：2011-02-26 04:35:09
【问题描述】：

我正在开展一个项目，该项目涉及每秒（当他们移动时）从许多用户（比如 1000 个）收集 gps 数据。我计划在 EC2 上使用带有 mysql 持久块存储的专用数据库实例，并使用 nginx 前端运行 ruby on rails 应用程序。我以前没有研究过这样的数据收集应用程序。我在这里遗漏了什么吗？

我将拥有另一个实例，它将充当应用程序服务器并使用来自同一 EBS 的数据。如果有人以前处理过这样的系统，任何建议将不胜感激？

【问题讨论】：

每秒？您是否考虑过这可能对用户产生的影响？（如大幅缩短电池寿命）
是的，电池寿命将是一个问题。但用户只会在开车时使用它，很多人可能会在车载移动充电器中使用它。
而不是每秒，你应该增加更新时间，比如 5 分钟
您打算将这些数据保留多长时间？ 1000 QPS 的持续 lat/lon 写入是每月至少 40 GB 的磁盘使用增长，不包括任何类型的索引。我上次检查时，EC2 实例有大约 150 GB 可用。您是否计划每 3 个月添加一个新的数据库实例？
好吧，它不会那么持久。粗略估计是每天

标签： mysql ruby-on-rails amazon-ec2

【解决方案1】：

我最担心 MySQL 和磁盘是你的瓶颈。我将假设您已经熟悉 Ruby/Rails 的权衡，即始终需要在应用程序层投入更多硬件以换取更高的程序员生产力。但是，您将需要为写入扩展 MySQL，如果您实际上谈论超过 1000 QPS（1000 个用户，每秒写入一次），这可能是一个棘手的提议。我建议您使用您计划使用的任何 MySQL 配置，并向其投入大量的写入流量。如果它以低于 3000 QPS 的速度下降（总是为峰值留出喘息的空间），您将需要修改您的计划（每秒数据？真的吗？）或先写入 memcache 之类的东西并使用定时任务一次性写入数据库（MySQL 3.22.5及以后版本支持单次查询多次插入，还有LOAD DATA INFILE方法，可以和/dev/shm配合使用）。如果您不使用 InnoDB，也可以查看延迟插入。

我当然有偏见（我为 Google 工作），但我会为此使用 App Engine。我们一直在 App Engine 上运行获得比这更多的写入流量的东西，而且效果很好。它开箱即用，无需启动新映像，而且您不必处理基于 SQL 的持久性的扩展问题。此外，在计费开始之前，您还可以获得大量免费配额。如果您真的想要一个 Ruby 环境，您可以运行 JRuby，或者您可以选择支持更好的 Python。即使您将 Vlad 或 Capistrano 与 EC2 一起使用，部署也更加容易。

编辑： Here's a very conservative estimate of your data growth. 16 字节只是存储纬度/经度坐标对（两个双精度）所需的最小值。在现实世界中，您有索引和其他数据库开销会增加这个数字。根据实际数据相应地调整公式，以计算达到 150GB 限制的速度。

【讨论】：

感谢 Bob 的回复。我们正在考虑的一件事是将数据本地保存在智能手机上并分批发送（每 2 或 5 分钟一次）。这会改变你描述的任何场景吗？我以前使用过谷歌应用引擎，如果我们在项目中不太远，肯定会使用它。此外，我们比 python django 更擅长 Rails。
好吧，事实上，我可能不会使用 Django 来处理这种吞吐量。我只需编写一个请求处理程序并处理所有裸机。如果你打算使用 Rails，你应该做同样的事情，并使用 Rails Metal Rack 中间件处理所有这些传入的请求。您的应用程序的其余部分应该能够使用正常的 Rails 请求逻辑来完成。
是的，分批发送数据会是更好的方法。即使每分钟一次也将是一个巨大的进步。

【解决方案2】：

您应该为此使用 PostgreSQL。 Postgres 对空间数据类型（点、线、平面等）有更好的支持。它还具有处理和计算不同空间数据类型以及索引此类数据的功能。您可能希望使用 GeoKit gem for ruby on rails 进行 ActiveRecord 级别的各种操作。

我同意 webdestroya - 每一秒？

【讨论】：

我实际上并没有在空间方面使用任何花哨的功能。我将使用这些数据使用谷歌地图进行一些计算显示路线。此外，我们过去一直在使用 mysql。所以遗产也在这里发挥作用。