我非常精通关系数据库设计的理论和实践。
我知道什么可行，什么不可行，什么是高性能的，什么是可维护的（几乎 - 当您开始拥有真实数据时，总有调整的地方）。
我似乎找不到关于分布式可扩展数据库的大量知识，例如 Google 的 Bigtable（用于为 google 应用引擎编写应用程序）。什么有效，什么无效，什么可以扩展，为什么不可以？
当然，有一些博客文章和文章，但是是否有关于为 bigtable 和类似数据库范例设计数据库的书籍或学术研究论文？
【问题讨论】：
标签： database-design google-app-engine bigtable
...有书籍或学术研究吗 关于设计数据库的论文 bigtable 和类似的数据库 范式？
Bigtable 本质上是一个数据库本身，所以我认为您的问题更多是关于如何在这些 Bigtable 类数据库中建模并在某种程度上设计您的架构。更具体地说，您想知道如何在 Google 的 App Engine 上执行此操作。
使用 GAE，您将使用 Datastore API，它为 Bigtable 添加了重要的抽象层，因此在某种程度上，您不必担心底层细节，就像使用 HBase 之类的东西一样。在 SO（here's a great answer by 一位 Google 工程师，我认为他是 GAE 团队的一员）上有一些帖子将指导您并提供有关如何处理这种新型数据库系统的提示。
有用的信息：
【讨论】：
搜索词是面向列的数据库/datastores
一开始有关于如何建立数据库的讨论。面向行赢了。
但是，面向列的内容正处于“复兴”阶段。它最适合大型只读分布式场景。
当您搜索面向列的数据库/存储时，可以找到很多理论。
【讨论】：
据我所知，关于非关系型数据库设计的最新文献并不多 - 尽管您可以通过挖掘关系范式“获胜”之前的旧论文来获得一些有价值的见解。
Bigtable 等数据库的基本见解当然是，在 Web 应用程序和其他读取繁重的应用程序中，鉴于廉价磁盘存储的可用性，最好的方法是针对读取进行优化，并在写入方面做更多工作.规范化则相反——最小化磁盘上的数据复制，从而使写入更容易、更便宜，但读取更难。几乎所有关系数据库设计的差异都源于这一事实。
另一个结果（可能需要更多关注）是，当您针对读取进行优化时，您必须提前知道您将参与哪种类型的读取，而标准化结构或多或少与读取无关。
【讨论】：
只是为了确定...您确实阅读了关于 bigtable 的谷歌 paper 对吗？
像 hadoop 这样的技术就是基于这篇最初的论文。
【讨论】：