与 Amazon RDS 上的多个实例相比，拥有多个数据库更好吗？
我计划在 Amazon EC2 上部署我的 Web 应用程序（基于 ASP.Net），并将持久性部署在 Amazon RDS 上。我有一种“直觉”，至少我的会话存储（同样在 RDS 上）应该与应用程序数据库的其余部分分开。这是因为我预计会话存储中会有很高的活动。
RDS 支持在单个实例上创建多个数据库的能力。但是，我想知道采用单独的实例是否明智，或者单独的数据库是否足够好。我知道期望这样的可扩展性需求有点不成熟，但这更多的是从规划的角度来看，因为稍后为正在运行的应用程序切换会话状态服务器可能会造成破坏。
此外，还有一点需要注意的是，拥有 2 个小型实例看起来比将小型实例扩展到大型实例更便宜（准确地说是 4 倍）。最后，是否有任何可用于规划（针对云数据库）的推荐实践？
I am planning to deploy my web application (ASP.Net based) on the Amazon EC2 and the persistence on Amazon RDS. I have a 'gut feeling' that at least my session store (again on RDS) should be separate from the rest of the application database. This is because I am expecting high activity in the session store.
RDS supports the ability to create multiple databases on single instance. However, I would like to know if it would be wise to take a separate instance or whether a separate database is good enough. I know that it is somewhat pre-mature to expect such a scalability need, but this is more from planning perspective, because it may disruptive to switch the session state server for a running application later.
Further, 1 more point to note is that having 2 small instances looks to be cheaper that scaling up a small instance to a large (it is 4 times to be precise). And to finish, are there any recommended practices already available for planning (for cloud database)?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
我会研究会话存储的其他可能性，例如。 memcached 或类似类型的内存存储。但是，如果您绝对必须将会话存储在真实的数据库中，那么在同一实例上拥有两个数据库与在数据旁边拥有一个会话表没有什么不同。数据库存储的问题是每个页面视图（检索然后存储会话）的沉重网络请求成本，而不是表的放置。
对于较大的实例，它们不仅更好，因为它们有更多的内存来适应更大的数据集，而且重要的是，它们具有更好的网络和磁盘 I/O。因此，即使是 10 个小实例也无法让您摆脱其中之一的 I/O 瓶颈。
I would investigate other possibilities for session storing, eg. memcached or similar type of in-memory storage. However, if you absolutely must store sessions in a real database, then having two databases on the same instance is not at all different than having a sessions table right next to your data. The problem with database store is the heavy network request cost for each and every page view (retrieve and then store session back), not the placement of the table.
As for larger instances, they are not only better because they have more memory to fit larger datasets but, importantly, they have much better network and disk I/O. So, even ten small instances would not save you from a I/O bottleneck at one of them.