从外部 Web 服务器使用 MongoHQ 时预计会有多长时间的延迟
有没有人可以提供有关使用托管数据库解决方案（特别是 MongoDB）和 Web 服务器的建议。具体来说：
延迟是否可以接受？ 如何将 Web 服务器与托管数据库服务器放在同一位置（通过 Azure 等在地理上）以减少延迟？ 有没有办法降低从 Web 服务器调用托管数据库服务器（通过私有 IP 或其他方式）的带宽成本？ 是否有任何网络托管解决方案提供该软件包（应用程序托管和托管数据库）
Does anyone have advice to offer regarding using a hosted DB solution, specifically MongoDB, with a web server. Specifically:
Is the latency acceptable?
How do I co-locate (geographically via Azure, etc) the web server with the hosted DB server to reduce latency?
Is there a way to mitigate the bandwidth cost from making call from the web server to a hosted DB server (via private IP or other?)
Are there any web hosting solutions that offer the package (App hosting & hosted DB)
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
我刚刚查看了 MongoHQ - 我发现无法指定特定的数据中心。即使您可以（也许我错过了这个细节），这些都是 AWS 区域，它们与 Windows Azure 并不位于同一数据中心。您必须对哪个 AWS 区域最接近（例如 Windows Azure 的中北部数据中心）进行最佳猜测。
如果您想减少带宽/延迟，您可以将 MongoDB 托管在辅助角色中，甚至托管在托管网站的 Web 角色中，这将降低每月的实例成本。请记住，如果您托管在 Windows Azure 中，则需要做好扩展的准备，因此独立的 MongoDB 数据库是不够的。那么，您可以将 MongoDB 置于其自己的辅助角色中，将数据库存储在云驱动器（在 blob 存储中）中以实现持久性，并确保实例计数不会超过 1。仅运行一个实例，当工作角色重新启动以安装安全补丁时，或者底层硬件崩溃时，您可能会出现周期性中断（您会在很短的时间内恢复，但会有周期性的数据库离线期）。
我在 MongoSV 会议上[演示了如何使用 MongoDB 副本集][1]。唯一的问题是您需要 3 个实例才能完成此任务。如果您通常运行 3 个 Web 角色实例，则可以搭载这些实例。否则，您需要在一组单独的辅助角色中管理此配置。与 MongoHQ 相比，您的每月成本将会上升（但您的 Web 角色和 MongoDB 之间不会收取带宽费用，您的延迟会极低，并且您可以轻松地将数据库扩展到 1TB，超出 MongoHQ 2GB 限制。
还有一件事：如果您有多个使用 MongoDB 的网站，您可以在 Windows Azure 中创建一个 MongoDB 托管服务（如上所述），然后从所有网站部署访问它，这将为您带来经济性。规模，降低迁移到多租户 MongoDB 数据库的成本
编辑 6/16/2013 这是一个非常古老、过时的答案：
编辑 7/15/2013 MongoLab 现在已在生产中提供 8GB 副本集。我在博客这里也有一个链接到 MongoLab 的 帖子。
I just looked at MongoHQ - I see no way to specify a specific data center. Even if you could (maybe I missed that detail), those are AWS regions, which don't live in the same datacenters as Windows Azure. You'd have to take a best guess about which AWS region is closest to, say, Windows Azure's North Central datacenter.
If you want to mitigate bandwidth/latency, you could host MongoDB in a worker role, or even in the Web Role hosting your website, which would reduce monthly instance cost. Just remember that, if you host in Windows Azure, you need to be prepared to scale, so standalone MongoDB databases won't be sufficient. Well, you could place MongoDB in its own worker role, store your database in a Cloud Drive (in blob storage) for durability, and ensure you never raised the instance count beyond 1. With only one instance running, you could have periodic outages when the worker role gets rebooted for security patch installation, or the underlying hardware crashes (you'd be back up in a very short time, but you would have periodic database offline periods).
I [demonstrated using MongoDB replicasets][1] at the MongoSV conference. The only issue is that you'd need 3 instances to accomplish this. If you typically run 3 instances of your web role, you could piggyback on those instances. Otherwise, you'd need to manage this configuration in a separate set of worker roles. Compared to MongoHQ, your monthly cost will go up (but your bandwidth won't be charged between your web role and MongoDB, you'd have extremely low latency, and you'd easily be able to scale your database up to 1TB, going beyond the MongoHQ 2GB limit.
One more thing: If you have several websites using MongoDB, you could create a single MongoDB hosted service in Windows Azure (as described above), then access it from all of your website deployments. This would give you economy of scale, reducing cost as you move to a multi-tenant MongoDB database.
EDIT 6/16/2013 This is a very old, outdated answer. A few updates:
EDIT 7/15/2013 MongoLab now has an 8GB Replica Set offering in production. I blogged about it here which also has a link to MongoLab's post.