Bigtable数据库设计理论

Question

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

我知道什么可行，什么不可行，什么是性能和可维护性（几乎 - 当你开始拥有真实的数据时，总会有地方调整）。

看来我无法找到关于分布式可伸缩数据库的大量知识，例如Google的Bigtable（用于为Google应用程序引擎编写应用程序）。什么可行，什么不可行，什么会缩放，为什么不行？

当然，有一些博客文章和文章，但有关于设计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）论文的启发
2. Hypertable也被Bigtable的纸
3. Cassandra的数据模型被Bigtable的纸启发灵感
4. Hadoop受谷歌的GFS和MapReduce论文启发

Answer 2

搜索项面向列的数据库 /数据存储

Wikipedia

在一开始，有关于如何建立数据库的讨论。以行为导向获胜。

但是，面向列的处于“复兴”阶段。最适合大型只读，分布式场景。

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

Answer 3

只是为了确定...您确实已经阅读了关于bigtable的谷歌搜索结果paper？

像hadoop这样的技术是基于这个初始文件。

Answer 4

关于非关系数据库设计，我没有多少关于这方面的文献，但我可以通过挖掘关系范式之前的旧论文获得一些有价值的见解。

Bigtable等数据库的基本洞察当然是，在网络应用程序和其他大型应用程序中，考虑到廉价磁盘存储的可用性，最好的方法是优化读取操作，并做更多的工作写道。规范化恰恰相反 - 最大限度地减少了磁盘上的数据复制，从而使写入变得更容易，更便宜，但读取更难。关系数据库设计的所有差异几乎都来自这一个事实。

另一个结果 - 可能会引起更多注意的是，当您为读取进行优化时，您必须知道您将提前读取什么类型的读取数据，而标准化结构或多或少与读取无关。