收录了 分库分表 频道下的 50 篇内容
在谈论数据库架构和数据库优化的时候,我们经常会听到“分库分表”、“分片”、“Sharding”…这样的关键词。让人感到高兴的是,这些朋友所服务的公司业务量正在(或者即将面临)高速增长,技术方面也面临着一些挑战。让人感到担忧的是,他们系统真的就需要“分库分表”了吗?“分库分表”有那么容易实践吗?为此,笔者整理了分库分表中可能遇到的一些问题,并结合以往经验介绍了对应的解决思路和建议。
在之前的文章中,我介绍了分库分表的几种表现形式和玩法,也重点介绍了垂直分库所带来的问题和解决方法。本篇中,我们将继续聊聊水平分库分表的一些技巧。
在业务数据量比较少的时代,我们使用单机数据库就能满足业务使用,随着业务请求量越来越多,数据库中的数据量快速增加,这时单机数据库已经不能满足业务的性能要求,数据库主从复制架构随之应运而生。
近日,一家国产企业级数据库公司PingCAP刚刚获得了2.7亿美元D轮融资,在数据库行业引起了很大反响。
1、业务与技术背景 2、解决方法思考 3、拆分方法探讨 4、垂直与水平拆分策略
近期,当当开源了数据库分库分表中间件sharding-jdbc。
Sharding-JDBC 2.0.0,在经过3个里程碑的迭代之后终于正式发布。Sharding-JDBC集分库分表、读写分离、分布式主键、柔性事务和数据治理与一身,提供一站式的解决分布式关系型数据库的解决方案。
本文介绍Elastic集群架构设计的优越性。。
随着移动互联网的兴起和大数据的蓬勃发展,系统的数据量正呈几何倍数增长,系统的压力也越来越大,这时最容易出现的问题就是服务器繁忙,我们可以通过增加服务器及改造系统来缓解压力,然后采用负载均衡、动静分离、缓存系统来提高系统的吞吐量。
前文说到大部分的业务场景是读多写少,查询的qps要远高于写入。所以当业务出现查询性能下降时,可以考虑使用主从读写分离。这确实会缓解很长一段时间,如同智齿消炎后的风平浪静,但智齿不拔总有一天你会受不了反复发炎的痛苦,业务也是。查询的性能瓶颈缓解
随着后端数据库的存储量级和用户的访问流量越来越大,我们免不了需要对OLTP数据库进行分库分表操作,那么选取一个的水平分库分表方案就显得非常重要。本文详细介绍在水平分库分表中常见的一些误区,以及一些常用的手法,以帮助识别可能存在的问题、少走弯路。
本文系 Shopee 的分布式数据库选型思路漫谈。因为是“漫谈”,可能不成体系,但会着重介绍一些经验以及踩过的坑,提供给大家参考。
“警告”!前方高能!非资深开发人员尽快撤离。请握紧鼠标,抓牢键盘!
最近与同行科技交流,经常被问到分库分表与分布式数据库如何选择,网上也有很多关于中间件+传统关系数据库(分库分表)与NewSQL分布式数据库的文章,但有些观点与判断是我觉得是偏激的,脱离环境去评价方案好坏其实有失公允。