首页 > 用户投稿

数据库集群 mysql表数据量太大,达到了1亿多条数据,除了分库分表之外,还有没有其他的解决方式?

mysql表数据量太大,达到了1亿多条数据,除了分库分表之外,还有没有其他的解决方式?

mysql在常规配置下,一般只能承受2000万的数据量(同时读写,且表中有大文本字段,单台服务器)。现在超过1亿,并不断增加的情况下,建议如下处理:

1分表。可以按时间,或按一定的规则拆分,做到查询某一条数据库,尽量在一个子表中即可。这是最有效的方法

2读写分离。尤其是写入,放在新表中,定期进行同步。如果其中记录不断有update,最好将写的数据放在redis中,定期同步

3表的大文本字段分离出来,成为独立的新表。大文本字段,可以使用nosql数据库

数据库集群 mysql表数据量太大,达到了1亿多条数据,除了分库分表之外,还有没有其他的解决方式?

4优化架构,或优化sql查询,避免联表查询,尽量不要用count(*),in,递归等消耗性能的语句

5用内存缓存,或在前端读的时候,增加缓存数据库。重复读取时,直接从缓存中读取。

上面是低成本的管理方法,基本几台服务器即可搞定,但是管理起来麻烦一些。


当然,如果整体数据量特别大的话,也不在乎投入费用的话,用集群吧,用tidb吧

facebook用户量十分庞大,为什么还使用mysql数据库?

尽管facebook使用mysql,但它们并不是一成不变的使用它。事实上,他们的团队已经提交了许多mysql核心和innodb插件的高性能增强。他们的主要重点是增加性能计数器到innodb。其他更改集中在io子系统上,包括以下新功能:

1innodb_io_capacity:设置服务器的io容量以确定后台io的速率限制

2innodb_read_io_threads,innodb_write_io_threads:设置后台io线程

3innodb_max_merged_io:设置可能合并到一个大io请求中的相邻io请求的最大数量

facebook使用mysql作为键值存储,其中数据随机分布在一大组逻辑实例中。这些逻辑实例分散在物理节点之间,负载均衡在物理节点级完成。facebook已经开发了一个分区方案,其中全局id被分配给所有的用户数据。他们也有一个自定义的归档方案,它基于每个用户的频繁和最近的数据。大部分数据是随机分布的。令人惊讶的是,据传facebook有1800个mysql服务器,但只有3个全职dba

facebook主要将mysql用于结构化数据存储,例如墙贴,用户信息等。这些数据在各个数据中心之间复制。对于blob存储(照片,视频等),facebook使用一个自定义的解决方案,涉及外部的cdn和内部的nfs

同样重要的是,facebook大量使用memcache,这是一种内存缓存系统,通过在ram中缓存数据和对象来加速动态数据库驱动的网站,以减少阅读时间。memcache是facebook的主要缓存形式,大大减少了数据库的负载。拥有一个缓存系统可以使facebook的速度与调用数据一样快。如果不需要访问数据库,则只需根据用户标识从缓存中获取数据

所以,“facebook使用什么数据库”似乎是一个简单的问题,你可以看到他们已经添加了各种其他系统,使其真正的具有网络可扩展性。但是,仍然可以自由地使用这样一个观点:“mysql和oracle或者mssqlserver一样好或者更好,因为就算只有facebook使用它,它也有5亿用户!”

配置mysql集群需要mysql哪个版本?

集群中,可能存在mysql主从复制。但主从主要是做读写分离的。另外主从出现故障可能性比较大。mysql集群很复杂,当然小集群比较简单,集群主要是实现高可用和高负载,主从只是集群可能用到的一个mysql功能了。比如主从读写分离keepalived自动故障切换但mysql瓶颈在于写,也就是。复杂的集群有的按照索引分开写入,有的多主……

数据库集群分布式数据库mysql集群高可用方式有哪些

原文标题:数据库集群 mysql表数据量太大,达到了1亿多条数据,除了分库分表之外,还有没有其他的解决方式?,如若转载,请注明出处:https://www.saibowen.com/tougao/23535.html
免责声明:此资讯系转载自合作媒体或互联网其它网站,「赛伯温」登载此文出于传递更多信息之目的,并不意味着赞同其观点或证实其描述,文章内容仅供参考。