前段时间公司的师兄在面试候选人之后,发出了这样感慨:2023 年,企业太难招到人了!
而同时,脉脉(技术圈社交软件)上也是一片哀鸿,说今年互联网行情非常差。
图片来源:脉脉,侵删
也正如脉脉这位网友所言,现在做普通业务的后台开发基本都是 CRUD(数据库 “增删改查” 的意思,形容没有技术含量的活),正常情况下很少涉及高并发、海量数据的实践场景。
毕竟,技术服务于业务,如果你的业务每天就几百人使用,咱搞个能抗几千万并发的系统又有什么意义呢?
性价比不高!
但是,这些企业 HR 能不知道吗?企业面试官也不是傻子,天天在简历和面试上挑挑拣拣的,也耽误时间。有这功夫,不如在工位多摸一会鱼,不香吗?
所以啊,你用没用过,和你知不知道是两个概念。面评里一般会有几个等级的打分,分别是:
但是,有面评的前提是:你得通过简历。
如果你的简历全是 CRUD,那面试官根本不会想和你聊!
所以,为了摆脱 CRUD-candidate 的身份,今天小❤和大家聊一聊数据量增长和高并发带来的数据库问题以及如何解决。
当用户量和数据量激增时,对于 MySQL 这样的关系型数据库管理系统,如何有效地应对高并发、高性能成了工程师们一项重要的任务。
在这篇文章中,我们将探讨两种常见的数据库架构设计策略:MySQL 的拆表(Sharding)和分片(Table Partitioning)。
这两种策略都旨在应对数据规模的增大以及高并发访问的问题,但它们各有特点,适用于不同的场景和需求。
本文将通过深入拆表和分片的原理、应用场景以及优缺点,为大家揭示如何在面对不断增长的数据和流量时,保持数据库的高性能和可用性。
无论您是一名数据库工程师、开发人员,还是对数据库架构设计感兴趣的朋友,本文都将为您提供有价值的见解,帮助您更好地应对数据库扩展的挑战。
而且,数据库扩展是架构设计绕不开的一项重要话题,更是简历和面试中合理 Zhuangbility 的要点内容。
低投入,高回报,性价比极高!
接下来让我们一起深入探讨 MySQL 拆表和分片,为构建可靠的系统架构铺平道路吧~~
拆表是一种常见的数据库分割技术,通常用于解决单表数据量过大、查询性能下降以及维护困难等问题,下面是拆表的一些场景及其优缺点。
假设有一个 ChatGPT 人机对话系统,其中有一个对话表,每个对话包含多条对话句子。
在对话表 dialog
有一问一答两条数据:
dialog_id | user_id | sentence_id | content | role | state | created_at |
---|---|---|---|---|---|---|
1 | 1 | 1 | 你好啊,你叫什么名字 | prompt | unfinished | 2023-09-25 |
1 | 1 | 2 | 我叫 xin猿意码 | answer | unfinished | 2023-09-26 |
可以发现,数据库的 dialog_id、user_id、state 等信息重复冗余了。当数据量增多时,类似的数据不仅会大量浪费磁盘空间,还会在查询时影响整体性能,所以我们可以将其拆为两个表:
dialog
对话表
dialog_id | user_id | state |
---|---|---|
1 | 1 | unfinished |
sentence
对话句子表
dialog_id | sentence_id | content | role | created_at |
---|---|---|---|---|
1 | 1 | 你好啊,你叫什么名字 | prompt | 2023-09-25 |
1 | 2 | 我叫 xin猿意码 | answer | 2023-09-26 |
这只是个相对简单的拆表例子,还有一些拆表可能根据用户,或者时间来拆表。
比如,对于时间敏感的查询业务,可以将主表按年、月、日来拆为多个表,以提升查询性能。
综合考虑,拆表是一种有效的数据库性能优化方法,但需要根据具体的业务需求和数据特点来决定是否采用,以及如何进行拆表设计。
分片 是将大型数据库分成多个小片段的方法,每个片段独立运行。
使用分片场景包括:
分片也需要考虑数据一致性和查询路由的问题。通常,分片数据库需要一个中心控制节点来管理数据分布和查询路由。
比如,在上述 dialog
表例子上,我们用 user_id
作为哈希键分片。
具体做法为:把数据的 user_id
对数据分片数量取余,假设我们一共有 8 个分片,user_id
为 10 时,就将该数据插入 dialog_2
的分片中(10%8 = 2)。
查询时也是先哈希,再去对应的分片上查找数据,以此减少每个分片的数据量,提升数据库的响应速度,分片的优缺点如下。
看到这里,大家可能有点疑惑。对于数据量的增加,拆表和分片都可以起到一定的作用,也都会出现数据一致性问题,那他们的区别是啥呢?
别急,接着往下看。
MySQL的拆表和分片都是用于处理大规模数据的技术,但它们的应用场景和方式有所不同,以下是它们的联系和区别。
综上所述,拆表和分片都是用于处理大规模数据的技术,但在应用场景、管理复杂度、数据分布方式和查询方式等方面存在差异。
选择哪种技术取决于具体的需求和系统架构,一般情况下,应对高并发和海量数据,分片拆表(又叫分库分表)都会用到。
拆表和分片都可能引入数据一致性问题,但问题的性质和解决方法有所不同。
还以上述的对话表举例,原始的 dialog
表是一个单一的表,每个对话项都以对话 ID 关联。
现在,为了优化查询性能,决定将对话表拆分为两个表:dialog
和 sentence
表。
在这种情况下,数据一致性问题可能出现在以下情况下:
dialog
表插入新对话时,如果在插入 sentence
之前发生了错误,可能导致对话主表和对话句子表之间的数据不一致。dialog
表删除对话时,如果在删除相关的对话句子之前发生了错误,也可能导致数据不一致。解决这些问题的方法通常包括使用事务或一致性哈希等技术来确保数据操作的原子性。如果数据一致性对业务非常重要,建议使用数据库事务来处理这些操作。
不了解事务的朋友可以看我之前的这篇文章,解锁MySQL的黑科技:事务与隔离
假设有一个社交媒体应用程序,用户数据表存储了全球 10 亿用户的数据,现在决定将用户数据分片到不同的数据库服务器上,以提高性能。
分片的方式可能是按用户 ID 的范围进行划分,每个分片负责一定范围内的用户数据。
在这种情况下,数据一致性问题可能出现在以下情况下:
解决这些问题的方法通常包括使用分布式事务或一致性哈希等分片技术。例如,可以使用分布式事务来确保跨分片的操作是原子性的,或者使用数据复制和备份来确保故障恢复。
总之,拆表和分片都可能引入数据一致性问题,但可以通过适当的技术和设计来解决这些问题,以确保数据的完整性和一致性。
MySQL 拆表和分片的设计策略,为应对不断增长的数据和高并发访问提供了可行的解决方案,同时也伴随着各自的优势和挑战。
拆表,像一位精巧的工匠,把复杂的数据库切割成可管理的小块,为数据的水平扩展提供了坚实的基础。
而分片,似一位智慧的园丁,将数据按照规则有序地分类,使得数据库的维护和查询更加高效。
但是,无论是选择拆表还是分片,都需要根据实际需求和场景来进行权衡和决策。
本文我们剖析了这两种策略的内部工作原理,还深入探讨了它们的使用场景、优点和限制。通过这些知识,相信屏幕前的你已经对如何更好地构建和维护 MySQL 数据库有了更清晰的认识。
无论您是一名数据库专业人士,还是对技术探索充满激情的读者,都希望这篇文章能为您带来价值和启发。
如果您觉得本文对您有所帮助,请不吝点赞、关注,也欢迎分享给更多的人。
技术的进步离不开分享和交流,我是小❤,我们下期再见!