随着时间的推移扩展项目和数据库的正确方法

Question

我现在从事客户项目已有一段时间了。技术栈包括laravel8后端，MariaDB作为数据存储，Quasar（基于vue）作为通过REST API通信的前端。这种设置已经为他们服务了一段时间，现在他们正计划扩大他们的客户群，这意味着

1. 更多并发用户
2. 正在生成更多数据
3. 数据库变得臃肿

我有兴趣了解扩展系统的正确方法，并对以下问题感兴趣

1. 由于数据库是关系数据库，假设他们有一个学生为其下订单，3 年后该学生离开了，他们决定删除该学生。您如何处理这种情况以防止旧数据崩溃？不要从存储中物理删除并只是隐藏？
2. 一些文章建议引入二级甚至三级数据库，并在保持活动数据库轻量级的同时继续将旧的未使用数据迁移到那些数据库。这是一种好的方法吗？
3. 我可以探索哪些资源来更好地了解系统扩展过程。
4. 在这样的数据库中实现常量属性更改的正确方法是什么。例如John Doe 在六年级。他有考试记录，图书馆记录，费用记录等。由于这是关系数据，我们会在孩子进入不同年级时更改孩子的数据，例如 8 年级，有人试图在他 6 年级时获取他的图书馆记录，作为关系数据，它是将显示更新的成绩。他们目前有一个视图表，其中包含 student_id、grade_id、join_date、leave_date 和 leave_reason

谢谢

Answer 1

我赞同吉尔伯特所说的。

关于#2 - 我同意吉尔伯特的观点。也就是说，一种可能有用的方法是将只读数据复制到数据存储中，该数据存储旨在满足大容量读取的需求，因为读取比写入更常见。

至于只读数据存储采用何种形式 - 有很多选择。可以帮助您应对其他一些挑战的要做的一件事是进行性能和容量规划练习：

1. 形成重要的主要数据对象/记录类型的粗略列表，例如客户、订单、产品。
2. 对于每个：计算您拥有的数量，以及它们的估计增长率（例如每年或每月）。
3. 计算您在特定时期内的增长量 - 您需要支持的总量是多少。

然后：

1. 对您的技术选择进行一些研究，并了解它们支持的数量。他们的基础设施的性质如何影响这些宣传的限制？
2. 在您的托管/基础架构中执行相同的操作 - 它是如何实现的以及它可以支持什么？在您需要重新架构之前，它可以轻松扩展以支持什么？
3. 了解您的基础架构在多大程度上符合您的技术供应商制定的指南。

总之，您想了解您需要多少容量，您拥有的系统可以支持多少。如果您的基础架构合适，他们可能会支持它。

重要提示：将基础设施投入糟糕的设计并不是正确的做法。但是了解您的实际可能限制通常是一个好主意 - “希望不是策略”等等。