SQL Azure 可以在没有任何特定技术或管理（分区/复制...）的情况下进行扩展吗？
SQL Azure 是否可以在没有任何特定技术或管理（如 Google App Engine 的 BigTable）的情况下进行扩展？不需要手动分区或复制？
Can SQL Azure scale without any specific technique or administration like Google App Engine's BigTable? No manual partitioning or replication required?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
您的意思是扩展以满足不断增长的需求，还是增加大小以容纳更多数据？
关于大小：您选择数据库的“版本”（网络版或商业版） - 两者都有不同的大小限制。您只需根据尺寸付费。最大大小为 50GB。选择版本后，容量将增加到容纳您的数据所允许的最大容量。你没有做什么特别的事情。
关于满足性能需求的扩展...从 SQL Azure 的角度来看，您实际上无需管理与可扩展性有关的任何事情...您的数据库与 MS 数据中心中运行的各种 SQL 服务器上的其他数据库位于同一位置。理论上，如果数据库变得太热，您的数据库将被移动到不太繁忙的服务器...但是，SQL Azure 不被认为是高度可扩展的解决方案（即：facebook/twitter 质量）。
如果您需要超大规模的可扩展性，则需要使用 Azure 表存储
Do you mean scale to meet increasing demand, or do you mean increase in size to accommodate additional data?
With respect to size: you pick the "edition" of the database (web or business) - both have different size limitations. You are billed based on size only. max size is 50gb. Once edition is picked, the capacity will increase up to max allowed to accommodate your data. You do nothing special.
With respect to scale to meet performance demands... you are abstracted away from managing really anything that has to do with scalability from SQL Azure perspective... Your database is colocated with other databases on various SQL servers running in MS data center. theoretically your database will be moved to a less-busy server if it becomes too hot... however, SQL Azure is not considered to be highly scalable solution (ie: facebook/twitter quality).
If you need mega-scalability, you'll need to go with Azure Table Storage
对于大多数应用程序来说，SQL Azure 可以很好地扩展。
“它会扩大规模吗？”这是我们很多人对 SQL Azure 感到好奇的问题。特别是因为您无法告诉它要分配多少 RAM、CPU 核心或具有负载平衡功能的复制服务器。使用 Windows Azure，您可以告诉它您希望在每种资源上托管应用程序的数量，但 SQL Azure 的情况并非如此。对于某些人来说，这可能听起来很糟糕，但 SQL Azure 旨在“自动”扩展数据库服务器以满足您的需求。老实说，我不能说这意味着什么，因为我（到目前为止）还没有从微软找到关于该主题的太多官方信息。
对于 Facebook 和 Twitter 等流量极高的网站，有人建议非关系数据库（例如 Azure 表存储）可以更好地扩展，因为数据库在查询数据时的开销较小。如果您需要关系数据库功能（例如外键关系和 SQL 连接功能），那么您可能需要使用 SQL Azure。
它并不像“使用 SQL Azure，或不使用 SQL Azure”那么明确。可以使用一些数据库架构设计模式，例如非规范化数据库表（每个查询需要更少的联接）和 水平分区您的数据，使您的设计能够更好地扩展。
也可以使用 SQL Azure 和 Azure 表存储的混合或混合解决方案。如果您有一些需要关系查询的数据，则将其放入 SQL Azure 中。如果您有不需要关系数据库的数据，那么您可以将其放入 Azure 表存储中。
请记住，数据库设计是应用程序整体架构的一部分，您应该像计划是否使用 TDD、IOC 和依赖注入一样对其进行规划。毕竟，如果您的数据库无法扩展，那么应用程序代码再出色也没有用。
除此之外，思考这个主题让我想知道 Xbox Live 和 Bing Search 使用什么来满足他们的数据库需求。是关系型、非关系型还是混合型？
For the majority of applications, SQL Azure will scale just fine.
"Will it scale?" Now that is the question a lot of us wonder about SQL Azure. Especially since you can't tell it how much Ram, CPU Cores or replicated servers with load balancing to allocate. With Windows Azure you can tell it how many of each resource you want your application hosted on, but that isn't the case with SQL Azure. This may sound really bad to some, but SQL Azure is designed to "automagically" scale the database server to your needs. What that means I honestly can't say, as I haven't (as of yet) found much official information from Microsoft on that topic.
With extremely high traffic sites, such as Facebook and Twitter, it has been suggested that non-relational databases (such as Azure Table Storage) can scale better since the database has less overhead when querying data. If you need relational database features (such as foreign key relationships and sql join functionality) then you probably want to use SQL Azure.
It's not as clear cut as "to SQL Azure, or not to SQL Azure." There are database architecture design patterns that can be used such as denormalizing database tables (require less joins per query) and Horizontally Partitioning your data to allow your design to better scale.
A Hybrid or Mixed solution of both SQL Azure and Azure Table Storage can be used too. If you have some data that requires relational queries, then put it in SQL Azure. If you have data that does not require a relational database, then you could put it in Azure Table Storage.
Remember, the database design is part of the overall architecture of your application and you should plan it out just as much as you plan whether to use TDD, IOC and Dependency Injection. After all, if your database can't scale, it doesn't matter how awesome the application code is.
Aside, Thinking about this topic makes me wonder what XBox Live and Bing Search use for their database needs. Is it Relational, Non-Relational or Hybrid?