从最基本层面看，数据库只需做两件事：向它插入数据肘，它就保存数据之后查询时，返回那些数据本文讨论如何存储输入的数据，并在收到查询请求时，如何重新找到数据。为何关注数据库内部的存储和检索呢？你不可能从头开始实现存储引擎，往往需要从众多现有的存储引擎中选择适合业务的存储引擎。 为针对特定工作负载而对数据库调优时，就得对存储引擎底层机制有所了解。针对事务型工作负载、分析型负载的存储引擎优化存在很大差异。
多对多关系是不同数据模型之间的重要区别特征。若数据大多是一对多（树结构数据）或记录之间无关系，则文档模
没有一成不变的系统需求，想法和目标在不断变化：适配新外部环境，新用例，业务优先级变化，用户要求新功能，新平台取代旧平台，法律或监管要求变化，业务增长促使架构演变等。组织、流程方面 ，敏捷开发模式为适应变化提供了很好参考。敏捷社区还发布了很多技术工具和模式，以帮助在频繁变化的环境中开发软件，例如TDD和重构。这些敏捷开发技术多数还只是针对小规模、本地模式（例如同一应用程序中的几个源代码文件）环境。我
软件大部分成本其实不在最初开发阶段，而是在于整个生命周期内的持续投入，包括维护与bug修复，监控系统来保持正常运行、故障排查、适配新平台、搭配新场景、技术缺陷完善及增加新功能。可惜许多程序员不喜欢维护这些所谓的遗留系统，例如修复他人埋下的bug或使用过时的开发平台或被迫做不喜欢的工作。每个遗留系统总有过期理由，所以很难给出通用建议该如何对待它们。但换个角度，可从软件设计时就开始考虑，尽可能减少维护
每人都有直观认识，即什么代表可靠或不可靠。对于软件，典型的期望包括：应用程序执行用户所期望的功能可容忍用户出现错误或不正确的软件使用方法性能可应对典型场景、合理负载压力和数据量系统可防止任何未经授权的访问和滥用上述目标都支持才算 “正常工作”，那么我们可以认为可靠性代表：即使发生某些错误，系统仍可继续正常工作。可能出错的事情称为错误（ fault ）或故障，系统可应对错误称为容错（fault to
即使系统现在可靠，不代表将来一定可靠。发生退化的最常见原因是负载增加：并发用户从最初的10,000 增长到 100,000或系统目前处理数据量超出之前很多倍。可扩展性，描述系统应对负载增加的能力。它不是衡量一个系统的一维指标， 谈论“系统X是可扩展 ”或“不扩展”无太大意义。相反，讨论可扩展性通常得考虑：“若系统以某种方式增长，应对措施有啥”， “该如何添加计算资源来处理额外的负载”3.1 描述负
Copyright © 2005-2025 51CTO.COM 版权所有 京ICP证060544号
