大家好，我是豆小匠。
这期来聊聊数据存储相关的问题，包括：
- 容量评估。
- 技术选型。
- 容灾处理。
另外，文末赠送免费定制红包封面哦！
1. 容量评估
通过对容量&性能的评估，可以把业务需求转化成技术语言描述。一般需要确认的内容有：
- 存量数据初始化
例如给表增加一个字段，需不需要给存量数据初始化值，初始化后占用存储空间增加多少。
- 数据增长率
增长率包括两个方面：1）历史增长速度。 2）业务增长率。
比如说，设计一个表，用于记录每日卖豆浆的交易数据。
根据过去一个月，每天可以卖出去100w杯豆浆，每一杯记录一条交易数据，那么历史增长速度就是100w/天。
但是，这个时候创始人说了，我们今年的目标，是每个季度，销售量翻倍。由于销售量翻倍，历史增长速度会变化，所以我们要把业务增长率考虑进容量评估里。
- 数据保留时间
大部分数据都是有时效的，确认不需要的数据，清理后不仅能节省存储空间，还可以提高查询性能。在容量评估里需要考虑业务需求和存储空间的平衡，以确定数据的保留时间。
一些小型系统，归档数据可以直接放到一个归档表，归档表删除一些不需要的字段以节省空间。但是如果业务需求允许，可以选用成本更低的存储方案，达到降本增效的效果。
- 备份数据
同样是评估成本和数据性质，决定备份的方案。
这样下来，假如说数据需要保存一年，那么容量大小 = （存量数据 + 季度一数据增长速率 * 季度一天数 + 季度二…）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红包封面】
