5.7 KiB
title, url, publishedTime
| title | url | publishedTime |
|---|---|---|
| 短文本存储技术选型 - 犬小哈专栏 | https://www.quanxiaoha.com/column/10318.html | null |
发布笔记是小红书核心功能之一，它允许用户创建、编辑和分享内容，以图文并茂的形式展示给其他用户，如下图所示。接下来，让我们来思考一个问题，对于笔记详情的展示，除了笔记的标题、图片链接、发布时间等等基础信息外，短文本数据，如笔记内容、评论内容存储在 MySQL 数据库中合适吗？
文本存储在 MySQL 合适吗？
探讨此问题时，需结合产品的体量来分析。举个栗子，如果是一个访问量不大的博客，存储在 MySQL 当然是没有任何问题的。但是，小红书拥有超过 2 亿的用户数，就需要考虑到高并发写入与读的性能问题。
大家都知道，MySQL 是关系型数据库，更擅长于存储关系数据，另外，InnoDB 作为 MySQL 的默认存储引擎，虽然其功能强大，但是涉及到大规模存储和管理文本数据时，InnoDB 存储引擎就会遇到性能瓶颈。
在 InnoDB 中，是使用行存储结构来存储数据的，每一行存储在数据页中，数据页的默认大小为 16 KB。当存储的文本数据很长时，InnoDB 会将部分数据存储在溢出页中，并在原数据页中保留一个指针指向溢出页。这种机制会导致更多的磁盘 I/O 操作，因为访问一条长文本数据需要读取多个数据页。
其效率问题，大致可总结如下：
- 磁盘 I/O 开销：由于 InnoDB 的行溢出机制，长文本数据需要多个页来存储和访问。这意味着读取和写入长文本数据时，需要更多的磁盘I/O操作，从而降低了性能。
- 数据页填充率： InnoDB 的数据页大小固定为 16KB。当文本数据长度不固定时，可能会导致数据页的填充率不高，浪费存储空间，并且增加了页碎片。
- 索引效率：对于长文本数据，InnoDB 的 B+ 树索引可能会变得低效。尤其是对 TEXT 类型列进行索引时，索引只会包含前几个字符，无法利用索引进行高效的全文检索。
- 事务开销： InnoDB 支持 ACID 事务，事务日志和回滚日志需要额外的存储和处理。对于频繁更新的大量长文本数据，这些日志会带来显著的性能开销。
所以，我们可以得出结论：性能要求较高场景下，关系型数据库不适合存储文本内容。
短文本存储技术选型
既然关系型数据库不合适，我们可以从非关系型数据库中来技术选型，如下：
-
内存型 KV 数据库：比较典型的如 Redis：
-
特点：
- 内存存储：数据保存在内存中，读写速度非常快。
- 丰富的数据类型：包括字符串、哈希、列表、集合、有序集合等。
- 内置计数功能：可以使用字符串类型的
INCR、DECR命令进行计数操作。
-
适用场景：
- 实时统计，如在线用户数、页面访问计数。
- 需要高并发读写的场景。
- 临时数据或缓存，不需要持久化数据。
-
-
分布式 KV 存储系统：如基于 RocksDB 存储引擎上构建的 Cassandra 、TiKV 等，都有非常好的扩展性和数据持久化能力，并且数据保存在磁盘上，磁盘相较于内存要廉价很多，非常适合用于存储海量的短文本数据:
-
特点
- 分布式存储：高可用性和可扩展性强。
- 支持时间序列数据：适合处理大规模时间序列数据。
- 可线性扩展：增加节点可以线性提高读写性能。
-
适用场景：
-
大规模数据存储和分析。
-
需要高可用性的系统。
-
横向扩展需求强烈的场景。
-
-
-
分布式文档数据库：数据以文档的形式存储，通常使用 JSON、BSON（Binary JSON）或 XML 格式。这使得数据结构非常灵活，适合存储半结构化或无结构的数据，典型的代表就是 MongDB ，具有强大的查询和索引功能。
-
特点：
-
文档存储：以 JSON 格式存储数据，灵活性强。
-
索引支持：支持多种索引，查询性能好。
-
分片机制：支持水平分片，数据量大时扩展性强。
-
-
适用场景：
-
半结构化数据存储，如日志、文档管理。
-
需要快速开发迭代的应用。
-
数据模式不固定或变化频繁的场景。
-
-
最终选择
针对海量的短文本存储，这里不考虑内存型 KV 数据库，一是内存非常昂贵，另外，数据持久化表现也比较一般。所以在 KV 存储系统或者分布式文档数据库中选择，若更关注于易用性，可以考虑分布式文档数据库。而针对小哈书项目，我们更在意性能，所以最终选型 KV 存储系统 Apache Cassandra。
它是一个强大、灵活且可扩展的分布式 NoSQL 数据库系统，适用于需要高可用性、高吞吐量和低延迟的应用场景。其无中心化架构、可调一致性、以及列族存储模型，使其成为处理大规模数据和实时分析的理想选择。