100T数据存进服务器分几步？

大家好，我是豆小匠。

这期来聊聊数据存储相关的问题，包括：

1. 容量评估。
2. 技术选型。
3. 容灾处理。

另外，文末赠送免费定制红包封面哦！

---

1. 容量评估

通过对容量&性能的评估，可以把业务需求转化成技术语言描述。一般需要确认的内容有：

1. 存量数据初始化

例如给表增加一个字段，需不需要给存量数据初始化值，初始化后占用存储空间增加多少。

2. 数据增长率

增长率包括两个方面：1）历史增长速度。 2）业务增长率。

比如说，设计一个表，用于记录每日卖豆浆的交易数据。

根据过去一个月，每天可以卖出去100w杯豆浆，每一杯记录一条交易数据，那么历史增长速度就是100w/天。

但是，这个时候创始人说了，我们今年的目标，是每个季度，销售量翻倍。由于销售量翻倍，历史增长速度会变化，所以我们要把业务增长率考虑进容量评估里。

3. 数据保留时间

大部分数据都是有时效的，确认不需要的数据，清理后不仅能节省存储空间，还可以提高查询性能。在容量评估里需要考虑业务需求和存储空间的平衡，以确定数据的保留时间。

一些小型系统，归档数据可以直接放到一个归档表，归档表删除一些不需要的字段以节省空间。但是如果业务需求允许，可以选用成本更低的存储方案，达到降本增效的效果。

4. 备份数据

同样是评估成本和数据性质，决定备份的方案。

---

这样下来，假如说数据需要保存一年，那么容量大小 = （存量数据 + 季度一数据增长速率 * 季度一天数 + 季度二…）x 单条数据大小 x 数据压缩率 x （1 + 一定的buffer）。

容量评估的有效期可以在一年上下浮动，更远的未来，可以留给那时候的打工人。

2. 技术选型

技术选型需要考虑的问题：数据的结构和关系、性能要求（读、写、并发等）、数据规模、可用性和容错、一致性、可扩展和成本等。

回到标题，100T放到存储服务器，分为几步？

举个例子，场景是记录日志，每条日志10KB，平均QPS为1w，需要保存14天。

容量评估：

每秒写入量：QPS * 日志大小 = 10000 * 10kb = 100MB/s

总体存储容量：100MB/s * 3600s/h * 24h * 14d = 120.96TB

---

对于日志来说，最重要的是全文搜索能力，目前一般选用Elasticsearch、时序数据库等来处理日志数据，选择的原因：

• 支持水平扩展。
• 支持高性能写入。
• 适合日志类型数据的搜索，如elasticsearch的全文搜索，时序数据库针对时间相关的查询优化等

同时，日志也支持一定的容错，不需要依赖SQL类型数据库的一些一致性特性。

回到第一部分，如果是记录豆浆交易数据，对数据一致性、高可用要求较高。而在大数据量的场景下，单机性能无法支持，可以使用集群/分布式数据库，如MySQL集群/TiDB等。

做离线数据分析时，可以把原始数据聚合到大数据存储，如Hive、ClickHouse、HBase等。

3. 容灾处理

容灾主要是分三步走：灾前，灾中，灾后。

灾前，可以通过冗余存储（如使用磁盘冗余阵列提供可用性和性能，分布式系统则可以通过复制或分片实现冗余）和监控等手段避免发生问题。

灾中：通过故障转移，异地多活等方式维持服务正常运转。

灾后：通过备份，恢复数据。

在平时，需要制定好应急预案和灾难恢复计划。

---

这期就喵到这！

领取红包封面请在公众号内回复：【2024红包封面】