大型iPhone用户数据库的在线存储/同步：在服务器上还是在设备上执行？

我正在为流行的基于SQLite的iPhone flashcard应用开发一个在线用户数据库备份/同步系统；这是一个相当大的规模——我们可以很快获得1亿个或更多的个人flashcard记录（10000个用户，每个卡10000张）——我们需要在设计系统时考虑到这种可扩展性。但我们并不是真正从事基于网络的软件业务，至少在最初，我们并不打算实际提供这么多的web界面，除了帐户管理之外——所有用户数据的实际操作都将在脱机状态下进行

因此，我们似乎有两个基本选项来实现这一点：

• 在服务器上执行同步；将所有用户的数据存储在MySQL数据库中（或者在我们扩展时存储一堆数据），并仅下载/上传更改列表

• 在本地执行同步；从服务器下载数据库的最新版本，检查/应用设备上的更改，然后上载合并的数据库

本地同步选项似乎意味着编程工作量大大减少，托管成本大大降低，但同时也意味着用户的带宽使用量大大增加——可能每个同步操作的带宽使用量为2-4 MB，而基于web的同步操作的带宽使用量为几十K

有人觉得其中一个选项明显比另一个好吗？有没有其他我们没有考虑过的方法

---

谢谢。

我可能不太了解这种工作方式，但由于这是同步，为什么数据库的本地副本无法记录更改列表，然后可以在服务器端复制这些更改？这只适用于单个设备，当然不能将多个设备同步到同一数据集

---

这些变化可以用多种方式记录：例如，你可以对iPhone上的记录进行校验和，并在同步时再次校验和，然后上传已更改的记录，删除的记录需要单独记录。

事实上，这部分并不是我担心的，我最关心的是如何高效地管理服务器端的许多记录；这将不是一个小的MySQL项目，如果事情发展起来，我们可以很容易地进入集群/碎片领域。然而，如果我们只是检索/编写整个数据库文件，我们可能只需要一个小的EC2实例，按照S3标准，文件存储量很小。