在 Web 开发的任何方面（html/css、数据库开发、服务器端逻辑等）都有大量信息（书籍、博客……）。即使是涵盖所有这些主题的书籍，也可以让您尽快开始使用您的个人网站。如今，在高速互联网访问和内容容易传播的时代，我错过了一个很好的资源，可以提供有关如何设计易于扩展的大型 Web 应用程序的见解、最佳实践和设计指南，其中包括：
可能看起来非常广泛，但与任何建立互联网公司的人相关，因此迟早会面临这些问题。同样，我关注的是技术架构问题，而不是这里讨论的如何内部管理工作流程（更大规模的 Web 项目规划）。有谁知道好的资源吗？
我会在这里冒险并猜测您不会找到涵盖整个问题的资源，因为问题的绝对大小将是数千页。
因此，这里有一些快速建议可以帮助您入门：
数据建模：
前两本书的大部分内容都在描述一些常见的建模要求，并逐步构建更高级的模型版本。最终结果不是用于快速开发的嵌入式模型，而是深入了解当复杂性上升时需要做出哪些工程权衡。一个好的经验法则——支持广泛场景的通用和灵活的数据模型往往更复杂且难以查询。只有当它们为企业提供有形价值时，它们才应该被追求。否则它们就会变得人为的复杂性。最后一本书更老，更富有哲理。它描述了应用程序中的常见建模问题，并帮助您以不同的方式思考它们。
跨多个服务器传播数据：
这些问题有一些非常新颖的解决方案，比如“Datomic”之类的东西浮现在脑海，但假设你想继续使用 MySQL/PostgresSQL 等常用的东西，我会较少关注“拆分”数据存储，而更多地关注规范化数据以减少不必要的冗余。最终，表分区可用于帮助归档和减轻针对大表的麻烦查询。另外，如果您不将资产（图像等）存储在数据库中，那么数据库有多大可能会变得那么大？许多现代数据库都在磁盘上压缩了数据，因此一个 500 GB 的数据库通常可以存储 1-2TB 的客户信息。
SQL 和关系理论 - CJ Date，关于一般关系理论的优秀书籍。
Cron Jobs：我会求助于您选择的数据库/操作系统的文档，PostgreSQL、MySQL、SQL Server、Oracle 等都有多年的批量或按需运行作业的历史。很有可能您将需要 3 大类例程：
您还可能需要诸如 ETL 工具或脚本解决方案之类的东西。我会建议首先使用通用语言（Python、Ruby 等），然后根据需求选择特定部分并对其进行专门化。一个很好的例子是 ETL 例程，起初针对您的 API 运行直接命令可能工作正常，但最终规模可能决定直接 SQL 解决方案。
至于使用模式，我想说您希望拥有幂等的工作，这样您就可以始终运行它们而不必担心后果。这比听起来要困难得多，但通常会带来更好的设计。事实上，我认为即使是你的数据模型也应该尽量做到无损。依靠插入和视图来实现更改，而不是删除/更新。一旦你的架构依赖于更新（或删除），这通常是一个好兆头，如果出现任何问题，你正在做的事情可能会给你带来严重的麻烦。
缓存：这在很大程度上取决于您的应用程序需要什么。我建议研究诸如“Memcached”、“索引视图”、“更改数据捕获”之类的技术，或“apache samza”之类的项目。经常请求但很少更改的信息通常是最容易缓存的。有时，您可以对数据进行建模，以便在缓存中包含较旧的信息，然后从实时数据存储中添加最新信息。这样，您就不会专注于不断地从操作数据库中提取大量信息，而只是关注缓存中不存在的最新信息。
存储/访问数以百万计的图像：我倾向于将它们存储在数据库中，而是将它们放在文件系统上。命名可能必须是唯一的密钥，可以安全地与文件夹中的其他文件组合，而不必担心冲突。Guids/Unique Identifiers 可能需要调查。操作系统限制在这里可能也很重要，一些系统对可以存储在单个目录中的文件有非常明确的限制。请注意，由于数据库现在有效地存储了指向文件的指针，因此您必须将针对这些文件的操作视为与数据库一起发生的事务。将它们直接存储在数据库中是可能的，但会使您的数据库管理更加困难。这是权衡，您是更愿意管理操作系统还是复杂的数据库。
其他实用建议：专注于使您的架构和数据模型尽可能简单。很容易让自己陷入极其复杂的数据模型和架构中，结果却发现运行最慢的元素与最终的设计几乎没有关系。更简单架构的另一个优点是更容易立即适应您的头脑。扩展/扩展架构从来都不是一件容易的事，但是扩展一个直接的设计（即使这意味着巨大的变化）肯定会比扩展一个非常复杂的设计更容易。