关系数据库的哪些方面使其难以在 Google App Engine 等服务上充分扩展？
显然，BigTable 架构的原因与当你处理 Google 必须处理的大量服务器时扩展关系数据库的困难有关。
但从技术上讲，到底是什么导致关系数据库难以扩展呢？
在大公司的企业数据中心中，他们似乎能够成功地做到这一点，所以我想知道为什么不能简单地以更大的数量级做到这一点，以便使其在谷歌的服务器上扩展。
Apparently the reason for the BigTable architecture has to do with the difficulty scaling relational databases when you're dealing with the massive number of servers that Google has to deal with.
But technically speaking what exactly makes it difficult for relational databases to scale?
In the enterprise data centers of large corporations they seem to be able to do this successfully so I'm wondering why it's not possible to simply do this at a greater order of magnitude in order for it to scale on Google's servers.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
当您执行涉及物理分布式关系的查询时，您必须将每个关系的数据提取到一个中心位置。对于大量数据来说，这显然无法很好地扩展。
设置良好的 RDBMS 服务器将在 RAM 中的热页上执行大部分查询，而几乎不需要物理磁盘或网络 I/O。
如果受到网络 I/O 的限制，那么关系数据的优势就会减弱。
When you perform a query that involves relationships which are physically distributed, you have to pull that data for each relationship into a central place. That obviously won't scale well for large volumes of data.
A well set-up RDBMS server will perform the majority of it's queries on hot-pages in RAM, with little physical disk or network I/O.
If you are constrained by network I/O, then the benefits of relational data become lessened.
除了 Mitch 的回答之外，还有另一个方面：Web 应用程序通常不太适合关系数据库。关系数据库强调规范化 - 本质上，使写入更容易，但读取更困难（就完成的工作而言，对您来说不一定如此）。这对于 OLAP、即席查询类型的情况非常有效，但对于 Web 应用程序则不太有效，因为 Web 应用程序通常更倾向于读取而不是写入。
Bigtable 等非关系数据库采取的策略恰恰相反：非规范化，使读取变得更容易，但代价是写入成本更高。
In addition to Mitch's answer, there's another facet: Webapps are generally poorly suited to relational databases. Relational databases put emphasis on normalization - essentially, making writes easier, but reads harder (in terms of work done, not necessarially for you). This works very well for OLAP, ad-hoc query type situations, but not so well for webapps, which are generally massively weighted in favor of reads over writes.
The strategy taken by non-relational databases such as Bigtable is the reverse: denormalize, to make reads much easier, at the cost of making writes more expensive.
上述主要原因是物理位置和网络 IO。此外，即使是大公司也只处理搜索引擎处理的一小部分数据。
考虑一下标准数据库上的索引，也许有几个字段......搜索引擎需要在大型文本字段上进行快速文本搜索。
The main reason as stated is physical location and network IO. Additionally, even large corporations deal with a fraction of the data that search engines deal with.
Think about the index on a standard database, maybe a few feilds... search engines need fast text search, on large text fields.