Skip to main content

数据库分表的意义与数据库中单表的大小控制

转载来自:http://www.woqutech.com/?p=807

请问:MySQL库中单表的大小尽可能控制在多大?采取这种表大小限制的策略的原因是什么?一个MySQL服务器实例中,表的数量有限制吗?单个MySQL服务器实例中,表的大小的总和有限制吗?如果有,考虑的原因是什么?单台PC SERVER上建多个MySQL服务器实例,一般的实例数是多少?是基于什么样的考虑原因?
MySQL数据库分库后,我们的建议单表大小控制在10G以下。限制分拆以后的表的大小有几个好处:
1、表比较小的话,DDL操作更快。由于MySQL部分DDL操作需要锁表,所以表越小,锁表的时间就越短。
2、表越小,数据查询访问的速度越快。MySQL是B树结构,表越小,树的分层越少,IO也会比较少。
3、表越小,最终扩容到MySQL的实例数越多。将数据拆分得越散,数据分布越均匀,扩容的话,能够用更多的服务器来承担并发压力。
建议MySQL服务器的配置:2路6核cpu、192G内存,配有8块SSD或者PCIe Flash卡。这样一台服务器上一般是部署4-8个数据库实例,
这个要根据数据库硬件最大可承载的的CPU,IO(包括IO性能和IO容量),网络容量来评估。
比如双十一的时候,8个实例的flash卡MySQL数据库物理主机,就已经把网络的千兆网卡打满了。
所以需要进行充分的测试,检查在充分的压力下,数据库的能力会先遇到什么瓶颈。表的大小总和并没有限制,如果你是一个正常情况下访问量非常少的表,它的限制就可能在于单机MySQL磁盘或者flash卡的容量大小了。

Comments

Popular posts from this blog

Golang http server performance tuning practice (Golang HTTP服务器性能调优实践)

  Golang 1.8后本身自带了pprof的这个神器,可以帮助我们很方便的对服务做一个比较全面的profile。对于一个Golang的程序,可以从多个方面进行profile,比如memory和CPU两个最基本的指标,也是我们最关注的,同时对特有的goroutine也有运行状况profile。关于golang profiling本身就不做过多的说明,可以从 官方博客 中了解到详细的过程。   Profile的环境 Ubuntu 14.04.4 LTS (GNU/Linux 3.19.0-25-generic x86_64) go version go1.9.2 linux/amd64  profile的为一个elassticsearch数据导入接口,承担接受上游数据,根据元数据信息写入相应的es索引中。目前的状况是平均每秒是1.3Million的Doc数量。   在增加了profile后,从CPU层面发现几个问题。 runtime mallocgc 占用了17.96%的CPU。 SVG部分图如下 通过SVG图,可以看到调用链为: ioutil.ReadAll -> buffer.ReadFrom -> makeSlice -> malloc.go  然后进入ReadAll的源码。 readAll()方法 func readAll(r io.Reader, capacity int64) (b []byte, err error) { buf := bytes . NewBuffer ( make ([] byte , 0 , capacity )) // If the buffer overflows, we will get bytes.ErrTooLarge. // Return that as an error. Any other panic remains.   defer func() { e := recover () if e == nil { return } if panicErr , ok := e .( error ) ; ok && p...

Python 使用socket实现ftp 客服端

之前先了解ftp协议,然后解释代码 连接到ftp服务器,得到一个socket(这是一个连接到ftp命令端口socket) 发送必要request 第一步 Connect到服务器后,ftp_socket.recv(1024) 到服务器的欢迎消息(1 中的socket),不要问为什么,ftp协议规定的,应该是。 *注意的是,后面ftp_socket每一次的请求后,都要recv一次,不管你是否全部接受到了都要recv一次,不然可能后面接受不到一些消息。个人觉着这可能是ftp协议的规定:每一次request,都会给client一个response。如果 client没有接受这个response,那么下次的request不会被服务器接受,所以client的recv就会卡住! 第二步就像代码中 直到 #LIST 都是用的命令端口。 而使用数据端口时,就是用命令端口   ftp_socket.send("PASV \r\n")     new_port = ftp_socket.recv(1024)      使用命令 PASV 请求一个动态的数据端口。 解释 我理解的动态数据端口: 即你每一次请求到一个数据端口后,你只能使用一次。比如: [ INFO] 2014-11-29 22:25:44,682 [admin] [127.0.0.1] SENT: 227 Entering Passive Mode (127,0,0,1,204,82)    这是ftp服务器端发送的请求(apache ftpserver),明显括号中是你的ip(我的是本机),然后两个数字。通过查询,你要请求的数据端口:(a,b,c,d,x,y)  new_port  = x*250+y 剩下的部分就很简单了。在代码中再有点解释(后面附server端log) 最后还应该用发送一个quit命令,告诉server 我的请求完毕了。这里忘了。 一点补充:看到server端log可以发现,服务器每一次的SEND  我们都应该recv一次 #download a folder's files  import socket class ParseUrl()...

Elasticsearch error when the field exceed limit 32kb

When we post data that the field exceed the limit, elasticsearch will reject the data which error: {"error":{"root_cause":[{"type":"remote_transport_exception","reason":"[cs19-2][10.200.20.39:9301][indices:data/write/index]"}],"type":"illegal_argument_exception","reason":"Document contains at least one immense term in field=\"field1\" (whose UTF8 encoding is longer than the max length 32766), all of which were skipped.  Please correct the analyzer to not produce such terms.  The prefix of the first immense term is You can handle this: 1. you can udpate the mapping part at any time PUT INDEXNAME/_mapping/TYPENAME { "properties" : { "logInfo" : { "type" : "string" , "analyzer" : "keyword" , "ignore_above" : 32766 } } } ignore_above means that we will only keep 32766 bytes 2...