Inversion of Control（IoC）是一种设计原则，它将程序对象或部分程序的控制权转移到外部容器或框架中。
Principle（尽管一些人将其称为一种模式Pattern）。控制权指的是除了类本身主要职责以外的其他职责。使用数据库来管理应用程序的数据，是数据持久化最常见的选择之一。数据库能够快速存储和检索信息，提供数据完整性保障，并在单个应用实例的生命周期之外实现持久化。市面上有无数种数据库可供选择，以满足项目需求和个人偏好。
然而，直接从应用程序操作数据库并不总是容易的。数据结构表示方式的差异常常带来挑战，表达不同实体之间关系的细微之处也很困难。为了解决这些问题，人们开发了许多工具，作为核心应用与数据层之间的接口。
在本文中，我们将探讨三种常见方法之间的差异：原生 SQL、Query Builder和 ORM。我们将比较每种方法的优缺点，并在最后提供一个常用术语表，帮助你熟悉一些关键概念。
以下是每种方法的优缺点概览：
| 方法 | 面向数据库/编程 | 手动管理程度 | 抽象层级 | 复杂度 |
|---|---|---|---|---|
| 原生 SQL | 面向数据库 | 高 | 无 | 低 |
| Query Builder | 混合 | 低 | 低 | 低 |
| ORM | 面向编程 | 低 | 高 | 高 |
数据库表结构的设计会随着与之交互的软件变化而不可避免地演进。能够安全、可靠地将表结构过渡到新需求至关重要。
虽然数据库迁移工具通常可以更新实际的数据结构，但数据本身也必须转换到新格式、迁移到不同的表或列，并更新以符合新的预期。这些过程虽然不一定复杂，但在客户端仍在使用的线上系统中执行时尤为敏感。
幸运的是，有一种称为扩展与收缩模式的多步骤流程，可在不中断系统服务的情况下，安全地逐步将客户端迁移到使用新的数据结构。本指南将探讨扩展与收缩模式是什么，它如何实现新旧结构之间的无缝过渡，以及如何将其应用于各种数据库转换。
扩展与收缩模式是一种数据库管理员和软件开发人员可用来将数据从旧数据结构迁移到新数据结构而不影响系统正常运行时间的流程。它通过一系列独立的步骤来应用变更，旨在后台引入新结构、为线上使用准备数据，然后无缝切换到新结构。
该流程可用于修改许多正在使用的接口，但对数据库表结构变更尤其有用。除了将数据和客户端迁移到新数据结构之外，扩展与收缩模式还有一个优势：如果在过程中的任何阶段出现问题，或者需求发生变化，你都可以轻松地回滚变更。
数据库模式（Database schemas）定义了关系型数据库所管理数据的结构与相互关系。尽管在项目初期制定一个经过深思熟虑的schema至关重要，但随着需求的不断演进，对初始schema进行更改往往难以甚至无法避免。由于schema决定了数据的形态与边界，任何变更都必须谨慎实施，以符合使用该schema的应用程序的预期，并避免丢失数据库系统当前已存储的数据。
在本文中，我们将介绍什么是数据库模式迁移、它们解决了哪些问题以及不同的实现策略。我们还将探讨它们所解决的各种痛点以及可能带来的一些潜在陷阱。
数据库迁移（Database migrations），又称 schema 迁移、数据库 schema 迁移，或简称迁移，是一组受控的变更，用于修改关系型数据库中对象的结构。迁移帮助将数据库 schema 从当前状态过渡到新的期望状态，无论是添加表和列、删除元素、拆分字段，还是更改类型和约束。
迁移以编程管理的方式对数据结构做增量的、通常是可逆的变更。数据库迁移工具的目标是使数据库变更可重复、可共享且可测试，同时避免数据丢失。通常，迁移工具会生成描述将数据库从已知状态转换到新状态所需的确切操作集的产物。这些产物可以被纳入常规的版本控制系统中，以便跟踪变更并在团队成员之间共享。
尽管防止数据丢失通常是迁移工具的目标之一，但删除或破坏性修改当前包含数据的结构可能会导致数据被删除。为应对这种情况，迁移通常是一个受监督的过程，涉及检查生成的变更脚本，并进行必要的修改以保留重要信息。
理想情况下，Kubernetes 节点的存储资源是无限的，Pod 和容器也不会因为磁盘空间不足而运行失败。但是在现实世界中，节点的资源是有限的。节点无法凭空生成更多的磁盘空间，当节点的可用存储容量不足时，就会出现磁盘压力问题。不过我们可以通过正确的监控和管理，可以防止磁盘压力问题影响workload的性能。
在 Kubernetes 中，节点磁盘压力是指节点的可用磁盘空间不足，导致节点无法运行新的 Pod。当该问题发生时，Kubernetes 会触发节点压力驱逐（node-pressure eviction），将一些 Pod 从节点中驱逐出去，以释放磁盘空间。
重要的是，kubernetes 节点磁盘压力问题通常是逐个节点发生的。换句话说，一个节点的磁盘空间不足，不会影响其他节点的运行。这是因为 workload 只能使用所在节点的磁盘空间。因此，如果某个Pod开始占用过多的磁盘空间，它也只会使用所在节点的磁盘空间，而不会影响其他节点的运行。
也就是说，如果你部署了很多存储密集型的 Pod，那么大多数的节点甚至所有节点都可能面临磁盘压力问题。
我们还应明确知晓，节点磁盘压力发生在节点持久化存储空间不足时，而不是指由 RAM 提供的临时或短暂存储空间。
B树在许多软件中都扮演着基础角色，尤其是数据库管理系统（DBMS）。MySQL、PostgreSQL、MongoDB、Dynamo 等众多系统都依赖 B 树通过索引来高效地查找数据。当你读完这篇文章时，你将了解 B 树和 B+ 树的工作原理，数据库为何使用它们来构建索引，以及为什么将 UUID 作为主键可能不是一个好主意。你还将有机会体验我们讨论的数据结构的交互式动画。准备好点击按钮吧。
计算机科学领域有大量的数据结构可供选择，用于在计算机上存储、搜索和管理数据。B树就是这样一种数据结构，它在数据库应用中被广泛使用。B树以计算机程序员所说的树状结构存储被称为键值对的数据。对于不熟悉计算机科学家如何使用“树”这个术语的人来说，它实际上看起来更像一个根系。
下面是本博客的第一个交互式组件。借助它，你可以直观地看到B树的结构，还能了解在添加键值对以及更改每个节点的键值对数量时会发生什么。点击“添加”或“Add random”按钮几次来试试看，在我们深入细节之前，先直观感受一下它的工作原理。
通用唯一识别码（Universally Unique Identifiers，也称为 UUID）旨在让开发人员能够在不了解其他系统的情况下生成唯一的 ID，从而保证 ID 的唯一性。在分布式架构中，当有多个系统和数据库负责创建记录时，UUID 特别有用。你可能认为在数据库中使用 UUID 作为主键是个不错的主意，但如果使用不当，它们可能会严重影响数据库性能。
在本文中，你将了解在 MySQL 数据库中使用 UUID 作为主键的缺点。
RESTful接口现在很普遍，但是如果你作为一名web开发者，你应该知道对于不同的情况如何去选择一个最合适的HTTP方法有点困难。
对于开发REST接口来说，更新一个资源是常见的事，这里有两个开发者经常使用的HTTP方法：PUT和PATCH，一般你会选择哪一个？
这两个方法看起来作用相同，都是更新一个服务的资源，但它们底层确是完成不同的事情。本篇文章将帮助你理解PUT和PATCH请求之间的区别，以便你可以设计一个专业的生产级别的API。