Architecture
Dec 13

--itlife365 begin
简单了解学习一个电商网站是如何处理大数据和并发,怎么处理大数据和并发架构网站,以下的内容来源于网络qq潭州学院,供参考
今天和一个做某超市的电商的一个技术核心聊的时候,学习了架构信息,wo一直在思考如何去应对大数据已经淘宝的电商网站的架构。
朋友的架构是采用的架构是:Springmvc+Mybatis+Freemarker+Nginx+Tomcat6.x+Mysql数据库,不知道是否是当心流行框架
概括起来有如下3个要点
第一:服务器负责均衡
第二:数据库主从分离
第三:安全性。

第一点服务器负责均衡
  现在的网站都是动不动就需要考虑大数据的,需要是负责均衡。
  什么是负责均衡,web负载均衡的作用就是把请求均匀的分配给各个节点,它是一种动态均衡,通过一些工具实时地分析数据包,掌握网络中的数据流量状况,把请求理分配出去。
对于不同的应用环境(如电子商务网站,它的计算负荷大;再如网络数据库应用,读写频繁,服务器的存储子系统系统面临很大压力;再如视频服务应用,数据传输量大,网络接口负担重压),不同网站应用必须使用的均衡策略(算法)是不同的。
所以均衡策略(算法)也就有了多种多样的形式,广义上的负载均衡既可以设置专门的网关、负载均衡器,也可以通过一些专用软件与协议来实现。how-to-build-bigdata-website
在OSI七层协议模型中的第二(数据链路层)、第三(网络层)、第四(传输层)、第七层(应用层)都有相应的负载均衡策略(算法),在数据链路层上实现负载均衡的原理是根据数据包的目的MAC地址选择不同的路径;在网络层上可利用基于IP地址的分配方式将数据流疏通到多个节点;而传输层和应用层的交换(Switch),本身便是一种基于访问流量的控制方式,能够实现负载均衡。
   目前,基于负载均衡的算法主要有三种:轮循(Round-Robin)、最小连接数(Least Connections First),和快速响应优先(Faster Response Precedence)。
  ①轮循算法,就是将来自网络的请求依次分配给集群中的节点进行处理。
  ②最小连接数算法,就是为集群中的每台服务器设置一个记数器,记录每个服务器当前的连接数,负载均衡系统总是选择当前连接数最少的服务器分配任务。 这要比"轮循算法"好很多,因为在有些场合中,简单的轮循不能判断哪个节点的负载更低,也许新的工作又被分配给了一个已经很忙的服务器了。
  ③快速响应优先算法,是根据群集中的节点的状态(CPU、内存等主要处理部分)来分配任务。 这一点很难做到,事实上到目前为止,采用这个算法的负载均衡系统还很少。尤其对于硬件负载均衡设备来说,只能在TCP/IP协议方面做工作,几乎不可能深入到服务器的处理系统中进行监测。但是它是未来发展的方向。服务器负责均衡 数据库主从分离 大数据 并发架构

上面是负载均衡常用的算法,基于以上负载均衡算法的使用方式上,又分为如下几种:
  1、DNS轮询
   最早的负载均衡技术是通过DNS来实现的,在DNS中为多个地址配置同一个名字,因而查询这个名字的客户机将得到其中一个地址,从而使得不同的客户访问不同的服务器,达到负载均衡的目的。
 DNS负载均衡是一种简单而有效的方法,但是它不能区分服务器的差异,也不能反映服务器的当前运行状态。当使用DNS负载均衡的时候,必须尽量保证不同的 客户计算机能均匀获得不同的地址。由于DNS数据具备刷新时间标志,一旦超过这个时间限制,其他DNS服务器就需要和这个服务器交互,以重新获得地址数 据,就有可能获得不同IP地址。因此为了使地址能随机分配,就应使刷新时间尽量短,不同地方的DNS服务器能更新对应的地址,达到随机获得地址,然而将过 期时间设置得过短,将使DNS流量大增,而造成额外的网络问题。DNS负载均衡的另一个问题是,一旦某个服务器出现故障,即使及时修改了DNS设置,还是 要等待足够的时间(刷新时间)才能发挥作用,在此期间,保存了故障服务器地址的客户计算机将不能正常访问服务器
  2、反向代理服务器
    使用代理服务器,可以将请求转发给内部的服务器,使用这种加速模式显然可以提升静态网页的访问速度。然而,也可以考虑这样一种技术,使用代理服务器将请求均匀转发给多台服务器,从而达到负载均衡的目的。
  这种代理方式与普通的代理方式有所不同,标准代理方式是客户使用代理访问多个外部服务器,而这种代理方式是代理多个客户访问内部服务器,因此也被称为反向代理模式。虽然实现这个任务并不算是特别复杂,然而由于要求特别高的效率,实现起来并不简单。

使用反向代理的好处是,可以将负载均衡和代理服务器的高速缓存技术结合在一起,提供有益的性能。然而它本身也存在一些问题,首先就是必须为每一种服务都专门开发一个反向代理服务器,这就不是一个轻松的任务。

代理服务器本身虽然可以达到很高效率,但是针对每一次代理,代理服务器就必须维护两个连接,一个对外的连接,一个对内的连接,因此对于特别高的连接请求, 代理服务器的负载也就非常之大。反向代理方式下能应用优化的负载均衡策略,每次访问最空闲的内部服务器来提供服务。但是随着并发连接数量的增加,代理服务 器本身的负载也变得非常大,最后反向代理服务器本身会成为服务的瓶颈。
  3、地址转换网关
    支持负载均衡的地址转换网关,可以将一个外部IP地址映射为多个内部IP地址,对每次TCP连接请求动态使用其中一个内部地址,达到负载均衡的目的。很多 硬件厂商将这种技术集成在他们的交换机中,作为他们第四层交换的一种功能来实现,一般采用随机选择、根据服务器的连接数量或者响应时间进行选择的负载均衡 策略来分配负载。由于地址转换相对来讲比较接近网络的低层,因此就有可能将它集成在硬件设备中,通常这样的硬件设备是局域网交换机。
 
第二 数据库主从关系的映射:
   很重要一个信息就是数据库的分离,电商的数据库业务是这样做的,业务数据的增删改进行的是在主数据库的操作,全部的查询都是在从数据库操作,大家可能就会有疑问了,那么怎么保证数据的一致性呢,是因为数据库服务进行映射和配置,当主数据库发生了数据变化会立刻同步到所有的从数据库。这样的做法的好处就是减少数据库服务器的压力。从而大大的提升查询和性能。真是一种聪明的做法。
第三:安全性
    安全性就服务器上来说,就是需要安装杀毒软件,防火墙。防止被人入侵。一般一些常用的云服务器都有提供

--itlife365 end

Jul 30
什么是条带化striping,为什么要条带化striping
what-is-striping-why-use-striping
--begin 由itlife365.com收集

    条带(strip)是把连续的数据分割成相同大小的数据块,把每段数据分别写入到阵列中的不同磁盘上的方法。简单的说,条带是一种将多个磁盘驱动器合并为一个卷的方法。 许多情况下,这是通过硬件控制器来完成的。
   当多个进程同时访问一个磁盘时,可能会出现磁盘冲突。大多数磁盘系统都对访问次数(每秒的 I/O 操作,IOPS)和数据传输率(每秒传输的数据量,TPS)有限制。当达到这些限制时,后面需要访问磁盘的进程就需要等待,这时就是所谓的磁盘冲突。避免磁盘冲突是优化 I/O 性能的一个重要目标,而 I/O 性能的优化与其他资源(如CPU和内存)的优化有着很大的区别 ,I/O 优化最有效的手段是将 I/O 最大限度的进行平衡。

    条带化技术就是一种自动的将 I/O 的负载均衡到多个物理磁盘上的技术,条带化技术就是将一块连续的数据分成很多小部分并把他们分别存储到不同磁盘上去。这就能使多个进程同时访问数据的多个不同部分而不会造成磁盘冲突,而且在需要对这种数据进行顺序访问的时候可以获得最大程度上的 I/O 并行能力,从而获得非常好的性能。由于条带化在 I/O 性能问题上的优越表现,以致于在应用系统所在的计算环境中的多个层次或平台都涉及到了条带化的技术,如操作系统和存储系统这两个层次中都可能使用条带化技术。
  条带化后,条带卷所能提供的速度比单个盘所能提供的速度要快很多,由于现在存储技术成熟,大多数系统都采用条带化来实现系统的I/O负载 分担,如果OS有LVM软件或者硬件条带设备,决定因素是条带深度(stripe depth)和条带宽度(stripe width)

  条带深度:指的是条带的大小,也叫条带大小。有时也被叫做block size, chunk size, stripe length 或者granularity。这个参数指的是写在每块磁盘上的条带数据块的大小。RAID的数据块大小一般在2KB到512KB之间(或者更大),其数值是2 的次方,即2KB,4KB,8KB,16KB这样。

条带大小对性能的影响比条带宽度难以量化的多。

  • 减小条带大小: 由于条带大小减小了,则文件被分成了更多个,更小的数据块。这些数据块会被分散到更多的硬盘上存储,因此提高了传输的性能,但是由于要多次寻找不同的数据块,磁盘定位的性能就下降了。
  • 增加条带大小: 与减小条带大小相反,会降低传输性能,提高定位性能。

根据上边的论述,我们会发现根据不同的应用类型,不同的性能需求,不同驱动器的不同特点(如SSD硬盘),不存在一个普遍适用的"最佳条带大小"。所以这也是存储厂家,文件系统编写者允许我们自己定义条带大小的原因。

       条带宽度:是指同时可以并发读或写的条带数量。这个数量等于RAID中的物理硬盘数量。例如一个经过条带化的,具有4块物理硬盘的阵列的条带宽度就是 4。增加条带宽度,可以增加阵列的读写性能。道理很明显,增加更多的硬盘,也就增加了可以同时并发读或写的条带数量。在其他条件一样的前提下,一个由8块 18G硬盘组成的阵列相比一个由4块36G硬盘组成的阵列具有更高的传输性能

       

下面先看下影响IO大小的操作系统和Oracle的相关参数:

db_block_size oracle数据块的大小,也决定了oracle一次单个IO请求中oracle数据块的大小
db_file_multiblock_read_count:在多数据块读时,一次读取数据块的数量,它和参数db_block_size一起决定了一次多数据块读的大小,它们的乘积不能大于操作系统的最大IO大小。
操作系统的数据块大小:这个参数决定了Redo Log和Archive Log操作时的数据块大小,对于大多数Unix系统来说,该值为512K。
最大操作系统IO大小:决定了一次单个的IO操作的IO大小的上限,对于大多数Unix系统来说,由参数max_io_size设置。
sort_area_size:内存中sort area的大小,也决定了并发排序操作时的IO大小。
hash_area_size:内存中hash area的大小,也决定了哈希操作的IO大小。
       在OLTP系统中,会存在大量小的并发的IO请求。这时就需要考虑选择比较大的条带深度。使条带深度大于IO大小就称为粗粒度条带(Coarse Grain Striping)。在高并行度系统中,条带深度为(n * db_block_size),其中n为大于1的整数。
        通过粗粒度条带能实现最大的IO吞吐量(一次物理IO可以同时响应多个并发的逻辑IO)。大的条带深度能够使像全表扫描那样的多数据块读操作由一个磁盘驱动来响应,并提高多数据块读操作的性能。
        在低并发度的DSS系统中,由于IO请求比较序列化,为了避免出现热点磁盘,我们需要避免逻辑IO只有一块磁盘处理。这是,粗粒度条带就不适合了。 我们选择小的条带深度,使一个逻辑IO分布到多个磁盘上,从而实现IO的负载均衡。这就叫细粒度条带。条带深度的大小为(n * db_block_size),其中n为小于多数据块读参(db_file_multiblock_read_count)大小的整数。
        可以简单的理解为并发程度高的IO采用粗粒度条带化,并发程度低的IO采用细粒度条带化。
        IO过程中,你无法保证Oracle数据块的边界能和条带单元的大小对齐。如果条带深度大小和Oracle数据块大小完全相同,而它们的边界没有对齐的话,那么就会存在大量一个单独的IO请求被两块磁盘来完成。
        在OLTP系统中,为了避免一个逻辑IO请求被多个物理IO操作完成,条带宽度就需要设置为两倍或者两倍以上于Oracle数据块大小。例如,如果条带深度是IO大小的N倍,对于大量并发IO请求,我们可以保证最少有(N-1)/ N的请求是由一块磁盘来完成。
www.HelloDBA.com写的的一篇《Oracle IO问题解析》文档中看到
比较合理的条带深度是从256K到1M

条带宽度

正如前面所述,无论是一个还是多个磁盘响应一个逻辑I/O,都要求I/O能被一次处理。因而在确定了条带深度的基础上,需要保证条带宽度 >= I/O请求的大小 / 条带深度。

此外,考虑到以后系统容量的扩充,也需要规划好条带宽度。

如今大多数LVM都支持在线动态增加磁盘。也就是在磁盘容量不足时,可以随时将新磁盘加入到一个已经使用的逻辑卷中。这样的话,在设置逻辑卷时就可以简单地将所有磁盘都归入到一个卷中。

但是,有些LVM可能还不支持动态增加磁盘,这时就需要考虑以后的容量扩充对I/O均衡的影响。因为新增加的磁盘无法加入原有卷,而需要组成一个新 的卷。但一般扩充的容量和原有容量比相对较小,如果原有卷的条带宽度比较大的话,新增加的卷的条带宽度无法达到其大小,这样就会使新、旧卷之间出现I/O 失衡。

例如,一个系统的初始配置是一个包含64块磁盘、每块磁盘大小为16GB的单一逻辑卷。磁盘总的大小是1TB。随着数据库的数据增长,需要增加 80GB的空间。把新增加的5个16GB磁盘再组成一个逻辑卷。这样就会导致两个卷上的I/O失衡。为了避免这种情况,可以将原有磁盘配置成每个条带宽度 为8个磁盘的8个逻辑卷,这样在新增加磁盘时可以也增加为8个磁盘的新卷,但必须要保证8个磁盘的条带宽度能够支持系统的每秒I/O吞吐量。

如果条带宽度设置的比较小,就需要估算出各个数据库文件的I/O负载,并根据负载量不同将它们分别部署到不同卷上分担I/O负载。

条带大小计算方法

stripe width(条带宽度):RAID中的磁盘数,就是组成这个stripe的磁盘数。例如,4个磁盘组成的RAID 0,条带宽度就是4。
4个磁盘组成的RAID 5,条带宽度就是4-1=3。

stripe depth(条带深度):单块磁盘上条带的大小,有时也称为stripe unit。
stripe size(条带大小):stripe depth×stripe width。有时也称block size块大小、chunk size簇大小、stripe length条带长度、granularity粒度,是单块磁盘上的每次I/O的最小单位。

RAID条带大小的另一个计算公式为:
条带大小=(0.25×平均定位时间×数据传输速率×(并发用户数-1)×1.024)+0.5KB。
平均定位时间=(平均延时+平均寻道时间)(ms);数据传输速率单位为:Mbps;1.024 = 1s/1000ms×1024KB/1MB(单位转换因子)。

举例来说,磁盘寻道时间是6ms,传输速率80MB,且有20个并发用户的条带大小应该为:(0.25×6×80×19×1.024)+0.5=2335.22KB(差不多2MB)。

在进行数据库IO设计的时候一定遇到设置条带深度为多少的问题。
假定为OLTP系统,针对数据文件、归档日志文件、在线日志文件,我们使用的raid类型一般为raid10、raid5
大家的条带深度一般设置为多少呢?
datafile应该是1m比较好,controlfile大概128k吧,忘记在哪个地方看到的了,redo好像也是建议1m


--END由itlife365.com收集
Tags: , ,
Jul 30

从阿里去IOE看去ioe化当理性,欲弃IBM服务器背后(zz)
什么是去IOE ,看了就基本理解了。
近日,国外媒体报道,中国多个部门,包括中国人民银行和财政部在内,正在审查商业银行是否过度依赖IBM的服务器并危害本国金融安全,并希望以国产服务器取而代之.这一报道,让去年风行一时的所谓去IOE风潮再次涌动.那么我们是否真的需要去IOE?或者说我们去IOE的最终目的是什么?

从相关报道看,去IOE话最直观的感觉就是弃用了IBM的小型机、Oracle的数据库及EMC的存储,而这些的确组成了传统企业的IT架构及应用,如果以国产服务器及软件替换的话,从安全(国家和企业等)的角度看,确实是替换的理由之一.不过我们在此说明的是,由于服务器、存储等基础的核心部件(例如芯片)及系统仍掌握在国外厂商手中,所以这个替换带来的安全也只是一种相对的安全.当然我们并非说为安全替换的理由不成立,只是如果仅以安全为由替换,有失偏颇.至少相关企业和部门在替换时,除了安全之外,还应找到其他更有说服力的的理由.

其实所谓去IOE的说法最早源于中国的阿里巴巴.因为去IOE项目实施前,阿里巴巴内部大量使用IBM的小型机,部分惠普的小型机;存储设备主要是EMC的产品,以及部分戴尔等的存储设备产品;数据库全部是Oracle的,但随着电子商务的业务快速增长发展,技术架构开始成为业务发展的制约因素,为此阿里巴巴不得不进行内部的技术架构改造,而信息化系统的核心则是数据库平台和基础硬件设备平台,为此阿里巴巴启动以三家巨头公司的名称为项目代号的项目,即去IOE.

具体来说,"去IOE"中的I,在阿里巴巴内部代表者为IBM,真实含义是去掉以IBM为代表的小型机硬件设备,不再使用集中式技术架构,改为开放式X86硬件平台的分布式技术架构提供数据服务;“去IOE”中的O,在阿里巴巴内部代表着甲骨文,真实含义是去掉Oracle数据库,也即以开源数据库产品替代甲骨文、IBM等为典型代表的商业数据库产品;“去IOE”中的E,在阿里巴巴内部代表者为EMC,真实含义是去掉以数据储存的存储设备,也即不再使用EMC、HP、戴尔等公司提供的中高档存储设备,改为使用开放通用的X86主机的本地存储.

看到这里,我们知道,所谓去IOE化最根本的动因(对于阿里巴巴而言)是市场和企业需求的驱动.即集中式部署(IOE架构)很难适应互联网大规模应用对扩展性的要求,所以所谓去IOE,其实质是分布式架构+开源系统替代了集中式架构+商用系统.当然这还要根据替换企业的性质及业务特点.那么接下来的是,诸如我们的金融行业(例如银行)是否适合去IOE呢?也就是银行的业务特点能否满足去IOE的条件而采用分布式架构+开源系统呢?

至少从目前银行的主要业务看,其对支撑其业务的IT 系统的高可靠性、高可用性、可服务性(Reliability、Availability、Serviceability简称RAS) 有极高的要求,而这恰恰是IOE构成的IT集中式架构系统的优势所在.尽管当前分布式架构+开源系统在RAS方面进展迅猛,但与集中式架构+商用系统相比尚存差距.既然如此,那么替换是否像之前业内所言带来成本上的节约呢?还是回到阿里巴巴的去IOE项目.

据称,阿里巴巴从 2010 年开始“去IOE”,整个项目耗时3年,1.7万名内部技术人员的参与努力,且之后的维持成本并不低.比如之前只需要上百台小型机的系统,被替换成1.5万台X86 服务器,必须重新架构全新的运维体系,所幸阿里巴巴是一个互联网公司,其25000 员工中17000 是IT技术人员,而其他央企、政府和银行等企业是不具备这种条件的.

从这个意义上看,去IOE具备一定的不可复制性和门槛(至少想要复制阿里巴巴的模式很难),而所谓的成本节约可能只是一种成本的转移.重要的是,这种成本的转移,让相关企业后期疲于系统的维护及运营而分散了对于自身业务的创新力,这就真的有些得不偿失了.

另外需要说明的是,作为传统IT架构和解决方案提供应商的IOE,在互联网的分布式与向外扩展(Scale-out)技术、开源软件、云服务领域也并非无所作为.例如EMC的VMware已是X86架构服务器云计算的基础,其公有云存储服务进展相当不错;开源分布式数据库MySQL实际上就隶属于Oracle;IBM则一直是开源软件的重要支持者与贡献者,而近期成立的Open Power联盟更是开放了Power内核IP授权,谷歌的加盟也使得Power未来在互联网行业的迅速推进成为可能.这也在提醒我们,IOE的本质只是一种计算方式,而IBM、Oracle和EMC只是典型的代表,但随着这些厂商的转变,IOE将被赋予新的内涵,所谓此IOE非彼IOE(计算方式的转变).单纯将IOE理解成IBM、Oracle和EMC是狭隘的.只要这些厂商与时俱进,其仍是推动产业发展不可或缺的力量.

最后,去IOE从技术解决方案看,就是从Oracle数据库+IBM小型机+EMC存储设备(IOE体系)迁移到MySQL数据库+X86服务器的模式.从这个角度看,国内服务器厂商浪潮、曙光、华为及软件企业用友等均具备了一定的替换实力.但还是前面分析的,去IOE,需要结合和考虑企业自身的业务特点、迁移的技术实力、总体拥有成本等多种因素,而不仅是简单的软硬件的迁移,这也提醒我们国内欲借此取而代之的厂商们,替换对于用户来说是个系统工程,除了软硬件的替换外,还能为用户做些什么?

综上分析,我们认为,安全并非是去IOE化惟一的因素(尽管很重要,但没有绝对的安全),而应是一个理性综合考量多种因素、由市场和用户需求驱动的系统工程(无论对于欲去IOE的客户,还是希望参与其中的相关厂商).

Tags:
Jul 24
对于MySQL,其实计算方法是类似的,所不同的是要注意存储结构的不同。
可以参考如果文章:
The basics of InnoDB space file layout – Jeremy Cole
The physical structure of InnoDB index pages – Jeremy Cole
The physical structure of records in InnoDB – Jeremy Cole
The Universal Scalability Law

The Universal Scalability Law is a mathematical definition
of scalability. It models the system’s capacity
C at a given size N. This paper demonstrates how
to use the Universal Scalability Law to predict a system’s
scalability. The process is to measure several
samples of throughput and concurrency, transform
the data, perform a least-squares regression against
it, and reverse the transformation.

以下内容摘录自《forecasting-mysql-scalability.pdf》

通过spss可以方便的得到一个类似的曲线

一般情况下,很难得到N=1的数据,其实也可以通过曲线回归,类似得到

通过方程式:y=0 + 998.5614660260804 * x + -23.70809368565541 * x*x
当x=1时:
y=975
Jul 24

无论对于什么样的数据库,什么样的系统,容量永远是一个扯不完的话题。如下佳文转于 http##www#noodba#com

容量规划是一个比较大的话题,在我看来,数据库应用包括两个方面:

一是存储容量,数据库的大小,表的大小等等,这后面涉及到一系列的问题,如维护,备份,容灾等等
二是性能方面的,比如说应用的负载增加5倍,数据库是否能处理?或者在下个预算周期前是否能支持。或者有促销,预计订单量会增加6倍,数据库的响应能否在一个合理的范围内等等,另外还可能牵涉到HA,系统降级等等问题。

第一个问题,也是一个经常遇到的问题,尤其是在一些初创快速成长的公司。
其实我也遇到过,如现在我们有个库,有一主几备,但是主库和备库在存储配置上有差异,导致备库容量不够,这个问题是一个很烦的问题。一开始硬件不到位,只能从数据库里的东西着手,清理一些可以清理的表,数据等等,另外,还有一个备库还跟主库不一致。还有就是催促开发迁移一些类似日志的表,这个过程真是吃力不讨好。

在数据库一开始就做好存储容量方面的规划,还是十分有用的,具体到数据库Oracle和MySQL上,估计得方法是比较类似的:

1 如果是在一个现有的系统上做规划:
对于Oracle:视图user_tables,user_indexes里就有我们需要的信息
TABLE_NAME NUM_ROWS BLOCKS AVG_ROW_LEN
HHHHH 19182515 1444702 561

MySQL的对应字典信息里也有:
mysql> show table status from test like ‘ccccc’\G
*************************** 1. row ***************************
Name: ccccc
Engine: InnoDB
Version: 10
Row_format: Compact
Rows: 54935
Avg_row_length: 2034
Data_length: 111788032
Max_data_length: 0
Index_length: 21676032
Data_free: 4194304
Auto_increment: 127869
Create_time: 2013-12-04 14:43:45
Update_time: NULL
Check_time: NULL
Collation: utf8_general_ci
Checksum: NULL
Create_options: row_format=COMPACT
Comment:
1 row in set (0.01 sec)

2 在一个新的系统上做规划:
如果是Oracle,已提供了一个很好的DBMS_SPACE Package 供大家使用:

CREATE_INDEX_COST Procedure This procedure determines the cost of creating an index on an existing table. The input is the DDL statement that will be used to create the index. The procedure will output the storage required to create the index.  Syntax  DBMS_SPACE.CREATE_INDEX_COST (    ddl             IN    VARCHAR2,    used_bytes      OUT   NUMBER,    alloc_bytes     OUT   NUMBER,    plan_table      IN    VARCHAR2 DEFAULT NULL); Pragmas  pragma restrict_references(create_index_cost,WNDS); Parameters  Table 134-5 CREATE_INDEX_COST Procedure Parameters  Parameter Description  ddl  The create index DDL statement  used_bytes  The number of bytes representing the actual index data  alloc_bytes  Size of the index when created in the tablespace  plan_table  Which plan table to use, default NULL  Usage Notes  ?The table on which the index is created must already exist.  ?The computation of the index size depends on statistics gathered on the segment.  ?It is imperative that the table must have been analyzed recently.  ?In the absence of correct statistics, the results may be inaccurate, although the procedure will not raise any errors.  --------------------------------------------------------------------------------  CREATE_TABLE_COST Procedures This procedure is used in capacity planning to determine the size of the table given various attributes. The size of the object can vary widely based on the tablespace storage attributes, tablespace block size, and so on. There are two overloads of this procedure.  ?The first version takes the column information of the table as argument and outputs the table size.  ?The second version takes the average row size of the table as argument and outputs the table size.  This procedure can be used on tablespace of dictionary managed and locally managed extent management as well as manual and auto segment space management.  Syntax  DBMS_SPACE.CREATE_TABLE_COST (    tablespace_name    IN VARCHAR2,    avg_row_size       IN NUMBER,    row_count          IN NUMBER,    pct_free           IN NUMBER,    used_bytes         OUT NUMBER,    alloc_bytes        OUT NUMBER);  DBMS_SPACE.CREATE_TABLE_COST (    tablespace_name    IN VARCHAR2,    colinfos           IN CREATE_TABLE_COST_COLUMNS,    row_count          IN NUMBER,    pct_free           IN NUMBER,    used_bytes         OUT NUMBER,    alloc_bytes        OUT NUMBER);  CREATE TYPE create_table_cost_colinfo IS OBJECT (    COL_TYPE   VARCHAR(200),    COL_SIZE   NUMBER); Parameters  Table 134-6 CREATE_TABLE_COST Procedure Parameters  Parameter Description  tablespace_name  The tablespace in which the object will be created. The default is SYSTEM tablespace.  avg_row_size  The anticipated average row size in the table  colinfos  The description of the columns  row_count  The anticipated number of rows in the table  pct_free  The percentage of free space in each block for future expansion of existing rows due to updates  used_bytes  The space used by user data  alloc_bytes  The size of the object taking into account the tablespace extent characteristics  Usage Notes  ?The used_bytes represent the actual bytes used by the data. This includes the overhead due to the block metadata, pctfree etc.  ?The alloc_bytes represent the size of the table when it is created in the tablespace. This takes into account, the size of the extents in the tablespace and tablespace extent management properties.

这个在提供一个手工表大小计算的方法:
大概思路就是计算每个block除去本来的block结构占用后可以存放多少条记录,对于非聚集表,大概需要如下五步:
1.计算整个block header的size,类似
DB_BLOCK_SIZE – KCBH – UB4 – KTBBH – ((INITRANS – 1) * KTBIT) – KDBH
hsize = 4192 – 20 – 4 – 48 -((5-1)*24)-14
= 4192 -182
= 4010 bytes

2.计算每个block的可用空间
available data space (availspace) =
CEIL(hsize * (1 – PCTFREE/100 )) – KDBT

3.计算每行记录的长度.
Column size including byte length =
column size + (1, if column size < 250, else 3)

4.计算block里存放的行数
Number of rows in block =
FLOOR(availspace / rowspace)

5.计算空间
total blocks=
(Total Table Rows) / (Rows Per Block)

对于索引的计算方法,参考:
http://itlife365.com/blog/post/how-to-calculate-indexes-size-when-you-create-index-on-oracle.php
http://itlife365.com/blog/post/how-to-calculate-indexes-size-when-you-create-index-on-oracle-by-dbms_space-create_index_cost.php

对于8k的block:

block_size(8192)= = kcbh + ktbbh + kdxle + kd_off + DATA + block_size * Pctfree + 4

对于MySQL,其实计算方法是类似的,所不同的是要注意存储结构的不同。
参考:http://itlife365.com/blog/post/about-Capacity-planning-mysql.php

分页: 1/1 第一页 1 最后页 [ 显示模式: 摘要 | 列表 ]