Bigtable数据库设计理论

Question

我精通关系数据库设计的理论和实践。

我知道什么是有效的，什么是无效的，什么是性能好的，什么是可维护的(几乎-当你开始拥有真实的数据时，总是有地方可以调整)。

我似乎找不到大量关于分布式可伸缩数据库的知识，比如google的Bigtable (用于为google app engine编写应用程序)。什么管用，什么不管用，什么能扩展，为什么不能？

当然，也有一些博客文章和文章，但是有关于为bigtable和类似数据库范例设计数据库的书籍或学术研究论文吗？

Answer 1

...是否有关于为bigtable和类似的数据库范例设计数据库的书籍或学术研究论文？

Bigtable本质上是一个数据库本身，所以我认为你的问题更多的是关于如何在这些类似于Bigtable的数据库中建模和在某种程度上设计你的模式。更具体地说，您想知道如何在Google的App Engine上做到这一点。

对于GAE，您将使用Datastore API，它为Bigtable添加了一个重要的抽象层，因此在某种程度上，您不必像使用HBase那样担心低层细节。在SO上有一些帖子(here's a great answer by，一位谷歌工程师，我认为他是GAE团队的一员)，将指导您并提供有关如何使用这种新型数据库系统的提示。

帮助信息：

1. HBase的灵感来自谷歌的Bigtable (Alternate Link) paper
2. Hypertable的灵感也来自于Bigtable paper
3. Cassandra's数据模型的灵感来自于Bigtable paper
4. Hadoop的灵感来自于谷歌的GFS和MapReduce papers

Answer 2

据我所知，最近关于非关系数据库设计的文献不多--尽管你可能会通过挖掘关系范式“won”之前的旧论文来获得一些有价值的见解。

当然，像Bigtable这样的数据库的基本见解是，在web应用程序和其他读取繁重的应用程序中，考虑到廉价磁盘存储的可用性，最好的方法是优化读取，并在写入方面做更多的工作。标准化则相反-最小化磁盘上的数据复制，从而使写入更容易、成本更低，但读取更困难。几乎所有与关系数据库设计的差异都源于这一事实。

另一个可能需要更多注意的结果是，当您针对读取进行优化时，您必须提前知道您将参与的读取类型，而规范化结构或多或少是读取不可知的。

Answer 3

搜索词是column oriented databases/datastores

Wikipedia

在一开始，有一个关于如何建立数据库的讨论。面向行的won。

然而，面向列的技术正处于“复兴”阶段。它最适合大型只读、分布式场景。

当你搜索面向列的数据库/商店时，有很多理论可以找到。