从MySQL到HBase:数据存储方案转型的演进

本文讲述了MySQL在一家O2O创业公司的应用历程,包括单实例阶段、主从复制、读写分离及垂直拆分等阶段,并分析了每个阶段的优势与不足。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

一、集群化方案

1、MySQL应用的演化

MySQL与HBase说到最核心的点,是一种数据存储方案。方案本身没有对错、没有好坏,只有合适与否。相信多数公司都与MySQL有着不解之缘,部分学校的课程甚至直接以SQL语言作为数据库讲解。我想借自身经历,先来谈谈MySQL应用的演化。

只有MySQL

笔者之前曾在一家O2O创业公司工作,公司所有数据都存储在同一个MySQL里,而且没有任何主备方案。相信这是很多初创公司会用到的一个典型解决办法,当时这台MySQL为用户、订单、物流服务,同时也为线下分析服务。

f7f9b665d53789a12a522a7bda73880a65532483

单实例的问题:

d47e62d2b349aca45e42305ed6714efbe5ed61d9一旦MySQL挂了,服务全部停止;
d47e62d2b349aca45e42305ed6714efbe5ed61d9一旦MySQL的磁盘坏了,公司的所有服务都没有了 (一般会定时备份数据文件)。

主从方案

随着业务增加,单个DB是无法承载这么多请求的。于是就有了主从复制、读写分离的解决方案。

1812d4a4c1861162db00b1153ffee9ef508c17cb

master只负责写请求,slave同步master用来服务读请求:

d47e62d2b349aca45e42305ed6714efbe5ed61d9为了扩展读能力可以增加多个slave;
d47e62d2b349aca45e42305ed6714efbe5ed61d9允许slave同步有一定的延迟;
d47e62d2b349aca45e42305ed6714efbe5ed61d9一致性要求严格的,可以指定读主库。

主从功能的问题:

d47e62d2b349aca45e42305ed6714efbe5ed61d9需要增加管理Proxy层,分配写请求、读请求;
d47e62d2b349aca45e42305ed6714efbe5ed61d9节点故障:其它节点应该快速接管故障节点的功能。

垂直拆分

业务继续增长,master甚至无法承载所有的写请求,数据库需要按业务拆分。

b8c017d71435315babb0fa6aa303e65b081f98a4

垂直拆分的问题:

d47e62d2b349aca45e42305ed6714efbe5ed61d9线下分析,需要在业务代码里join各个表。因为拆成多个库,已经无法join了。
d47e62d2b349aca45e42305ed6714efbe5ed61d9不容易做数据库的事务性,用户余额减少与下单成功的情况下无法使用MySQL的事务功能。

转载于:https://my.oschina.net/u/3611008/blog/1833477

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值