Database design 有关如何设计大型web应用程序的资源和指南

在web开发的任何方面（html/css、数据库开发、服务器端逻辑等），都有大量信息（书籍、博客等）。即使是涵盖所有这些主题的书籍，也能让你尽快开始使用你的个人网站。如今，在高速互联网接入和内容容易传播的时代，我错过了一个很好的资源，它提供了如何设计易于扩展的大规模web应用程序的见解、最佳实践和设计指南，其特点是：

• 高效的数据库数据建模
• 跨多个（数据库或应用程序）服务器传播数据
• 高效数据库查询指南
• 如何自动化服务器端流程（cron作业设计：如何操作以及哪些用例是合理的）
• 缓存：何时和如何缓存
• 如何存储/访问数百万（用户）图像？数据库与硬盘？命名约定
• [……]

---

可能看起来非常广泛，但与任何建立互联网公司的人都相关，因此，迟早都会面临这些问题。再次强调，我关注的是技术架构问题，而不是如何在内部管理工作流程，如本文所述（）。有人知道好的资源吗？

我在这里冒险一试，我猜你不会找到一个涵盖你全部问题的资源，因为问题的篇幅可能有数千页

因此，以下是一些快速建议，以帮助您开始：

数据建模：

• 数据模型资源书，第1卷
• 数据模型资源书，第3卷
• 数据与现实

前两本书的大部分内容描述了一些常见的建模需求，并逐步构建了模型的更高级版本。最终的结果不是快速开发模型的减少，而是深入了解在复杂度上升时如何进行工程权衡。一个好的经验法则——支持广泛场景的通用和灵活的数据模型往往更复杂，更难查询。只有当它们为企业提供有形价值时，才应追求它们。否则它们就会变成人为的复杂性。最后一本书更古老，更具哲理。它描述了应用程序中常见的建模问题，并帮助您以不同的方式思考这些问题

跨多台服务器传播数据：

• 对于这些问题，有一些非常新颖的解决方案，比如“Datomic”，但如果您想继续使用MySQL/PostgresSQL等常用工具，我将不太关注“拆分”数据存储，而更多地关注规范化数据以减少不必要的冗余。最终，可以使用表分区来帮助归档和减轻针对大型表的麻烦查询。另外，如果您不在数据库中存储资产（图像等），那么数据库会有多大的可能？许多现代数据库在磁盘上都有压缩数据，因此一个500 GB的数据库通常可以存储1-2TB的客户信息

• SQL和关系理论——C.J Date，关于一般关系理论的优秀书籍

Cron作业： 我想看一下您选择的数据库/操作系统的文档，PostgreSQL、MySQL、SQL Server、Oracle等都有多年的历史，可以批量或按需运行针对它们的作业。你很可能需要3大类的常规动作：

• 定期运行的备份例程
• 每小时/每夜/每周运行的索引例程（取决于活动）
• 一致性检查以确保不发生数据损坏

您可能还需要ETL工具或脚本解决方案之类的工具。我建议首先使用一种通用语言（Python、Ruby等），然后根据需求对特定部分进行专门化。一个很好的例子是ETL例程，首先对API运行直接命令可能会很好，但最终规模可能决定直接SQL解决方案

至于使用模式，我想说的是，你想要的作业是幂等的，这样你就可以随时运行它们而不必担心后果。这比听起来更困难，但往往会导致更好的设计。事实上，我认为，即使是您的数据模型也应该尽可能做到非破坏性。依靠插入和视图进行更改，而不是删除/更新。一旦您的体系结构依赖于更新（或删除），这通常是一个好迹象，表明您正在做一些事情，如果出现任何问题，可能会给您带来严重的麻烦

缓存：这在很大程度上取决于应用程序所需的内容。我建议您研究诸如“Memcached”、“索引视图”、“变更数据捕获”之类的技术，或者像“apachesamza”这样的项目。经常请求但很少更改的信息通常最容易缓存。有时，您可以对数据进行建模，以便在缓存中包含较旧的信息，然后从实时数据存储中添加最新的信息。这样，您就不必不断地从运行数据库中提取大量信息，而只需要缓存中不存在的最新信息

• Martin Kleppmann设计的数据密集型应用程序似乎很好地涵盖了其中一些主题。虽然整本书还没有出版

存储/访问数以百万计的图像：我倾向于将它们存储在数据库中，而不是将它们放在文件系统中。命名可能必须是唯一的密钥，可以安全地与文件夹中的其他文件组合，而不必担心冲突。guid/唯一标识符可能需要研究。在这里，操作系统约束可能也很重要，有些系统对