3

我们有

所有这些都朝着一个共同的目标——使数据管理尽可能可扩展。

通过可扩展性，我理解的是，当数据大小增加时，使用成本不应该急剧上升。

当数据量很大时，RDBMS 会很慢，因为间接数不变的增加会导致更多的 IO。

替代文字

这些自定义可扩展的友好数据管理系统如何解决问题？

这是本文档中解释 Google BigTable 的图：

替代文字

在我看来是一样的。超可扩展性是如何实现的？

4

4 回答 4

2

具体到您关于 Bigtable 的问题，不同之处在于上图中的层次结构就是全部。每个 Bigtable tabletserver 负责一组 tablet（来自表的连续行范围）；从 row range 到 tablet 的映射保存在 metadata 表中，而从 tablet 到 tabletserver 的映射在 Bigtable master 的内存中维护。查找一行或一系列行需要查找元数据条目（几乎肯定会在托管它的服务器上的内存中），然后使用它来查找负责它的服务器上的实际行 - 导致只有一次或几次磁盘寻道。

简而言之，它可以很好地扩展的原因是因为它可以投入更多的硬件：给定足够的资源，元数据总是在内存中，因此不需要为它去磁盘，只为数据（而不是总是为此，要么！）。

于 2010-08-16T10:43:05.477 回答
2

“传统”SQL DBMS 市场实际上意味着极少数产品，这些产品传统上针对的是企业环境中的业务应用程序。大规模的无共享可扩展性历来不是这些产品或其客户的优先事项。因此很自然地出现了替代产品来支持互联网规模的数据库应用程序。

这与这些新产品不是“关系”DBMS 的事实无关。关系模型可以像任何其他模型一样进行扩展。可以说，关系模型比网络（基于图）模型更适合这些类型的大规模可扩展应用程序。只是 SQL 语言有很多缺点，目前还没有人提出合适的关系型 NOSQL（非 SQL）替代方案。

于 2010-08-16T05:47:00.177 回答
0

它是关于使用廉价的商品硬件来构建网络/网格/云并传播数据和负载（例如使用 map/reduce）。

在我看来，RDBMS 数据库就像（最初）设计为在一台超级计算机上运行的软件。您可以使用各种硬盘阵列、数据库集群，但仍然......

数据量增加了，因此在设计新的数据存储时考虑到这一点还有另一个理由——可扩展性、高可用性、TB 级数据。

另一件事——如果你从便宜的服务器构建网格/云，它是容错的，因为你将所有数据存储在三个（？）不同的位置，同时它很便宜。

回到您的图片 - 第一个来自一台计算机（通常），第二个来自计算机网络。

于 2010-08-15T20:27:33.900 回答
0

One theoretical answer on scalability is at http://queue.acm.org/detail.cfm?id=1394128 - the ACID guarantees are expensive. See http://database.cs.brown.edu/papers/stonebraker-cacm2010.pdf for a counter-argument.

事实上，仅仅在电力故障中幸存下来是昂贵的。多年前，我将 MySQL 与 Oracle 进行了比较。MySQL 比 Oracle 快得令人难以置信，但我们无法使用它。那个时代的 MySQL 是建立在 Berkeley DB 之上的，这比 Oracle 成熟的基于日志的数据库要快几英里，但是如果在基于 Berkely DB 的 MySQL 运行时断电，那么要使数据库再次保持一致是一个手动过程当电源重新打开时，您可能会永远丢失最近的更新。

于 2010-08-16T05:12:05.720 回答