数据库与存储架构

合集下载

云数据库的架构与使用方法

云数据库的架构与使用方法

云数据库的架构与使用方法随着云计算的快速发展,云数据库的使用在企业和个人之间变得越来越普遍。

云数据库架构通过将数据存储在云服务提供商的服务器上,使得用户可以随时随地安全地访问和管理自己的数据。

本文将介绍云数据库的架构以及使用方法,帮助读者更好地了解和使用云数据库。

一、云数据库架构云数据库的架构包括以下几个核心组件:1. 云服务器:云服务器是提供计算资源的基础设施。

它们负责创建和维护虚拟服务器实例,用于执行云数据库上的各种操作。

2. 存储层:存储层负责存储用户数据。

云数据库提供了多种存储引擎,包括关系型数据库、文档数据库和键值存储数据库等。

用户可以根据自己的需求选择适合的存储引擎。

3. 安全层:安全层确保用户数据的安全性和机密性。

它包括数据加密、访问控制和用户身份验证等功能。

用户可以根据自己的需求配置相应的安全设置。

4. 横向扩展:云数据库的架构设计支持横向扩展。

通过增加更多的服务器和存储节点,可以提高数据库的性能和可伸缩性,满足不同用户的需求。

二、云数据库的使用方法1. 选择云数据库类型:在使用云数据库之前,用户需要选择适合自己需求的数据库类型。

常见的云数据库类型包括关系型数据库、文档数据库和键值存储数据库等。

用户可以根据自己的业务需求和数据特点选择适合的数据库类型。

2. 创建数据库实例:在选择了合适的数据库类型之后,用户需要创建数据库实例。

数据库实例是云数据库服务的基本单位,用于存储用户的数据和执行数据库操作。

用户可以在云服务提供商的控制台中创建数据库实例,并选择合适的配置参数。

3. 导入和导出数据:用户可以通过各种方式将数据导入到云数据库中,例如使用命令行工具或者通过 API 接口。

同样地,用户也可以将数据导出到本地环境进行备份或者其他用途。

4. 数据库管理:云数据库提供了一系列管理工具和功能,帮助用户更好地管理数据库。

这包括创建数据库表和索引、执行查询和更新操作、监控数据库性能等功能。

用户可以根据自己的需求使用这些工具和功能进行数据库管理。

数据库的存储结构

数据库的存储结构

第五章数据库的存储结构5.1数据库存储介质的特点●内存容量低(一般只有几百M,最多一两个G),价格高,速度快,数据易丢失(掉电、当机等)。

一般做DBMS(或CPU)和DB之间的数据缓冲区。

实时/内存数据库系统中使用内存存放实时数据。

●硬盘容量高(一般有几十G,多到一两百G),价格中,速度较快,数据不易丢失(除非物理性损坏)。

一般做用来存放DB。

实时/内存数据库系统中使用硬盘存放历史数据库。

●移动硬盘(USB接口)容量高(一般有几十G),价格中,速度较快,数据不易丢失(除非物理性损坏)。

一般做用来做备份。

●光盘容量低(一般650M/片,但光盘可在线更换,海量),价格低,速度中,数据不易丢失(除非物理性损坏)。

一般做用来做备份。

●磁盘(软盘)容量低(一般有几M,优盘多到一两百M),价格中,速度较慢,数据不易丢失(除非物理性损坏)。

一般数据库不使用磁盘。

●磁带容量低(但可在线更换,海量),价格低,速度最慢,且要按顺序存取,数据不易丢失(除非物理性损坏)。

一般做用来做备份。

按速度从高到低:内存、硬盘、USB盘(移动硬盘和优盘)、光盘、软盘、磁带。

按在线容量从大到小:硬盘、移动硬盘、内存、光盘、磁带、优盘、软盘。

物理块:512byte/1K/2K/4K/8K原因:(1)减少I/O的次数;(2)减少间隙的数目,提高硬盘空间的利用率。

ORACLE逻辑块与物理块(init.ora中db_block_size定义逻辑块大小)缓冲块和缓冲区(即SGA中的Data Buffer Cache)延迟写(delayed write)技术/预取(Prefetching)技术(ORACLE中由DBWR进程完成数据的读写)5.2记录的存储结构5.2.1 记录的物理表示1.Positional Technique2.Relational Technique3.Counting Technique5.2.2 记录在物理块上的分配不跨块组织(unspanned organization)跨块组织(spanned organization)5.2.3 物理块在磁盘上的分配1.连续分配法(continuous allocation)2.链接分配法(linked allocation)3.簇集分配法(Clustered Allocation)4.索引分配法(Indexed Allocation)5.2.4 数据压缩技术1.消零或空格符法(null suppression)如:#5表示5个空格,@6表示6个零等。

数据管理与储存的数据存储方案

数据管理与储存的数据存储方案

数据管理与储存的数据存储方案随着信息技术的不断发展和应用范围的扩大,各个领域的数据量都在快速增长。

为了有效管理和储存海量数据,数据存储方案显得尤为重要。

本文将介绍一些常见的数据存储方案,包括传统的关系型数据库、分布式文件系统和云存储,同时探讨它们的优点和适用场景。

一、关系型数据库关系型数据库是一种经典的数据存储方案,它通过表格的形式将数据存储起来,并建立了数据之间的关系。

常见的关系型数据库管理系统(RDBMS)有MySQL、Oracle和SQL Server等。

关系型数据库具有以下优点:1. 结构化数据:关系型数据库适合存储结构化的数据,可以通过表格模式来定义数据的结构和数据之间的关联。

2. 事务支持:关系型数据库支持事务处理,具有较高的数据一致性和可靠性。

3. 查询功能强大:关系型数据库支持SQL查询语言,用户可以通过简单的查询语句获取所需的数据。

然而,关系型数据库也存在一些局限性。

首先,关系型数据库的扩展性有限,无法适应大规模数据的存储和处理需求。

其次,关系型数据库的结构化数据模型不能满足非结构化数据的存储需求,如图像、音频和视频等。

二、分布式文件系统分布式文件系统是一种将文件数据分布式存储在多台服务器上的存储方案。

它通过将文件切片并分散存储,提高了数据的可用性和并发访问性能。

常见的分布式文件系统有Hadoop分布式文件系统(HDFS)和谷歌文件系统(GFS)。

分布式文件系统的优点包括:1. 可扩展性:分布式文件系统可以通过增加服务器节点来扩展存储容量和处理能力,适合大规模数据存储和处理。

2. 容错性:分布式文件系统将数据冗余地存储在多个节点上,当某个节点出现故障时,可以自动从其他节点中恢复数据。

3. 并发访问:多个客户端可以同时访问分布式文件系统中的文件,提高了数据的并发处理能力。

然而,分布式文件系统的数据读写效率较低,对小文件的处理效果不佳,并且需要额外的维护和管理工作。

三、云存储云存储是一种将数据存储在云端的存储方案。

数据中心架构详解数据中心三大基础架构2024

数据中心架构详解数据中心三大基础架构2024

引言概述:数据中心是现代企业和组织的核心基础设施,它承载着大量的数据存储和处理任务。

为了能够高效地管理和处理这些数据,一个合理的数据中心架构是必不可少的。

本文将深入探讨数据中心架构的三个基础要素:网络架构、存储架构和计算架构,以帮助读者更好地理解数据中心的设计和运维。

网络架构:1. 网络拓扑结构:数据中心通常采用三层网络架构,包括核心层、汇聚层和接入层,这样可以提供高可用性和可扩展性。

2. 网络设备:常见的网络设备有路由器、交换机和防火墙等,它们通过虚拟局域网(VLAN)和交换虚拟化技术(VXLAN)等实现数据的传输和隔离。

3. SDN技术:软件定义网络(SDN)可以提高网络的灵活性和可编程性,使得数据中心网络的管理更为简便和高效。

4. 高可用性和负载均衡:通过配置冗余设备和使用负载均衡算法,可以避免单点故障,并实现对网络流量的均衡分配。

存储架构:1. 存储设备:数据中心采用不同类型的存储设备,如磁盘阵列、网络存储设备(NAS)和存储区域网络(SAN)等,以满足不同的存储需求。

2. 存储协议:常见的存储协议有网络文件系统协议(NFS)和块存储协议(如iSCSI和FCP),它们用于数据中心中的文件共享和块级存储。

3. 存储虚拟化:通过存储虚拟化技术,可以将物理存储资源抽象成逻辑存储池,并实现数据的动态迁移和资源的动态分配。

4. 数据保护和备份:在数据中心中,数据的安全性和可靠性非常重要。

通过定期备份、快照和复制等手段,可以保护数据免受损坏和丢失的风险。

5. 存储性能优化:通过使用高速存储介质(如固态硬盘)和优化数据访问模式,可以提升数据中心的存储性能和响应速度。

计算架构:1. 服务器硬件:数据中心中常用的服务器硬件包括标准服务器、刀片服务器和高密度服务器等,可以根据实际需求选择适合的硬件平台。

2. 虚拟化技术:利用虚拟化技术,可以将物理服务器划分为多个虚拟机,实现资源的共享和利用率的提升。

3. 容器化技术:容器化技术(如Docker)可以更加轻量级地实现应用的部署和扩展,提供更高的灵活性和效率。

数据库数据的存储结构

数据库数据的存储结构

数据库数据的存储结构
数据库数据的存储结构主要有以下几种:
1. 表格存储结构:是一种基于行和列的存储结构,每个表格由
若干个行和列组成,每个行代表一条记录,每个记录包含若干个字段,每个字段代表一个数据项。

2. 堆积存储结构:是一种适用于大规模数据存储的存储结构,
所有数据按照插入顺序依次存放在一个堆积中,并用指针将它们连接
起来。

这种存储结构的操作效率较低,但占用空间少。

3. 平衡树存储结构:是一种基于树结构的存储结构,数中每个
节点代表一条记录,每个节点有若干个子节点,子节点代表比该节点
的键值小或大的记录,平衡树通过动态平衡调整提高了数据检索效率。

4. 散列表存储结构:是一种基于散列算法的存储结构,每个记
录的存储位置由一个散列函数计算得出,因此该存储结构的查找效率
很高,但空间利用率逊于平衡树和表格存储结构。

5. 文件系统存储结构:是一种基于文件系统的存储结构,将数
据库存储在独立的文件中,并提供相应的操作接口,可以读写整个文
件或一部分,因此应用较为广泛。

数据仓库的基本架构

数据仓库的基本架构

数据仓库的基本架构数据仓库是一种面向主题、集成、非易失、相对稳定和历史数据的数据集合。

它采用了一种特定的架构来存储和管理数据,以便支持企业的决策和分析需求。

数据仓库的基本架构由以下几个主要组件组成:数据源、ETL过程、数据存储和访问层。

1. 数据源(Data Sources)数据源是数据仓库的起点,它包括企业内部的各个业务系统、外部数据提供商和第三方数据供应商等。

数据源可以是关系数据库、平面文件、Web服务等各种数据存储形式。

数据源中的数据通常以不同的格式和结构存在,这就需要进行数据整合和转换。

2. ETL过程(Extraction, Transformation and Loading)ETL是数据仓库的核心过程,它包括数据的抽取、转换和加载。

数据抽取是指从数据源中提取需要使用的数据,可以使用不同的技术和工具来实现,如SQL查询、文件导入等。

数据转换是指对抽取的数据进行清洗、整合、转换和规范化等处理,以满足数据仓库的要求。

数据加载是指将转换后的数据加载到数据仓库中,可以采用增量加载或全量加载的方式。

3. 数据存储(Data Storage)数据存储是指将经过ETL处理后的数据存储到数据仓库中。

数据仓库通常采用分层的存储结构,包括原始数据层、中间数据层和目标数据层。

原始数据层存储从数据源中抽取的原始数据,中间数据层存储经过转换和整合后的数据,目标数据层存储已经满足分析和查询需求的数据。

4. 数据访问层(Data Access)数据访问层是用户和数据仓库之间的接口,它提供了各种查询、分析和报表功能,以满足用户对数据的不同需求。

数据访问层可以通过各种方式进行数据查询,例如使用SQL查询语言、OLAP分析工具、报表生成工具等。

它还可以提供更高级的分析功能,如数据挖掘、机器学习和数据可视化等。

除了以上的基本架构组件,数据仓库还需要考虑数据安全性、性能优化、数据质量管理和元数据管理等问题。

数据安全性要求对数据进行权限控制、数据加密和数据备份等操作,以保证数据的安全和完整性。

关系数据库与图数据库的存储结构比较

关系数据库与图数据库的存储结构比较

关系数据库与图数据库的存储结构比较引言在当今数字化时代,数据的处理和管理成为各行各业的重要组成部分。

关系数据库和图数据库作为两种主要的数据库管理系统,它们在存储结构上存在着明显的差异。

本文将对关系数据库和图数据库的存储结构进行比较,并分析其优缺点。

关系数据库的存储结构关系数据库采用的是表格的方式来组织和存储数据。

数据在表中以行和列的形式进行存储,其中行代表一个记录,列代表记录中的一个特定属性。

这种结构使得关系数据库非常适用于结构化数据的管理,例如企业的账目、员工信息等。

关系数据库的存储结构是基于关系代数和元组运算的。

它使用了多个表格,每个表格都包含若干个字段,而一个字段包含特定的数据类型。

数据通过主键-外键关系来进行表之间的关联。

这种结构使得数据之间的关系和约束得以准确地定义和维护。

图数据库的存储结构图数据库以图的形式来表示和存储数据。

图是由节点和边组成的数据结构,节点代表实体,边代表节点之间的关系。

图数据库适合存储非结构化和半结构化数据,例如社交网络、知识图谱等。

图数据库的存储结构是基于图论和网络分析的。

它通过属性图或标签关系来描述图中的实体和关系。

图数据库使用了内存指针和索引等技术来提高数据的查询效率,同时具备高度可扩展的特点。

这种结构使得图数据库能够更加灵活地处理复杂数据模型和关系。

关系数据库与图数据库的对比存储模型和数据结构关系数据库采用表格的形式存储数据,具有严格的结构和预定义的架构。

数据以行和列的形式进行组织,适用于结构化数据和预定义模式的管理。

而图数据库则采用图的形式存储数据,能够灵活地处理非结构化和半结构化数据。

它不依赖于预定义的模式,更适合于处理复杂数据模型和关系。

数据查询和操作关系数据库使用SQL语言进行数据查询和操作,具有广泛的应用和成熟的生态系统。

SQL查询能够进行复杂的数据关联和聚集操作,适用于复杂的数据处理需求。

而图数据库使用图查询语言(如Cypher)来处理图数据。

数据仓库的基本架构

数据仓库的基本架构

数据仓库的基本架构数据仓库是一个用于集成、存储和管理企业中各种数据的系统。

它的设计和架构对于数据的有效管理和分析至关重要。

在本文中,我们将详细介绍数据仓库的基本架构,包括数据仓库的组成部分、数据仓库的层次结构和数据仓库的实施步骤。

一、数据仓库的组成部分1. 数据源:数据仓库的数据源可以包括企业内部的各种数据库、文件、日志等。

数据源的选择和数据提取的方法取决于企业的需求和数据的特点。

2. 数据提取和转换:数据提取和转换是将数据从数据源中提取出来并进行清洗、转换的过程。

这个过程包括数据的抽取、清洗、转换和加载等步骤,以确保数据的质量和一致性。

3. 数据存储:数据存储是数据仓库的核心组成部分,用于存储从数据源中提取出来的数据。

常见的数据存储方式包括关系型数据库、多维数据库和分布式文件系统等。

4. 元数据管理:元数据是描述数据的数据,用于帮助用户理解和使用数据仓库中的数据。

元数据管理包括元数据的收集、存储和维护等过程。

5. 数据访问和查询:数据仓库的用户可以通过各种方式访问和查询数据,包括SQL查询、OLAP分析、报表生成等。

数据访问和查询的方式取决于用户的需求和技术的支持。

二、数据仓库的层次结构数据仓库的层次结构包括三个主要层次:操作型数据层、集成型数据层和决策型数据层。

1. 操作型数据层:操作型数据层是数据仓库的最底层,用于存储企业内部各种操作型数据,包括交易数据、日志数据等。

这些数据通常以原始的、细粒度的形式存储。

2. 集成型数据层:集成型数据层是数据仓库的中间层,用于将操作型数据进行整合和转换,以满足用户的查询和分析需求。

在这一层次上,数据会进行清洗、聚合和转换等处理。

3. 决策型数据层:决策型数据层是数据仓库的最上层,用于存储已经经过整合和转换的数据,供用户进行决策分析和业务报告等。

在这一层次上,数据会根据用户的需求进行汇总、计算和分析等操作。

三、数据仓库的实施步骤1. 确定需求:在实施数据仓库之前,首先需要明确企业的需求和目标。

  1. 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
  2. 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
  3. 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。

数据库与存储架构前言决定应该赋予数据库什么样的存储和配置,已经成为一项杂乱无章的工作,这种现象我见得多了。

数据库工程师一般都是数据库的专家,而对于存储配置的低层细节几乎一无所知。

另外存储管理员和工程师也往往不知道数据库如何利用下层的存储,以及数据库、索引文件、记录文件,当然还有文件系统和卷管理器的需求和最佳配置又是什么。

这往往造成了存储资源利用率低,增加了整体成本,导致性能降低甚至可能无法满足你的需求,此外预算也总是很紧张,而管理上又要求有效地利用可获得的预算。

本文将解决数据库管理员和存储工程师在解决架构问题而进行协作时的一些问题。

数据库与存储架构配置组件大部分数据库的端到端存储架构所需硬件和软件如下:数据库* 控制文件(Control file)* 表空间(Table space)* 索引文件(Index file)* 重做日志(亦称在线日志,Redo log)操作系统文件系统和卷管理器(如果数据库运行在裸设备上,这一项可能没有关系)、主机总线适配器(HBA)、存储硬件。

以上每一部分都拥有多个组件,具有多种特性和功能,对整体性能影响显著。

数据库数据库应用本身具有多重特性和功能,必须加以考虑。

Oracle的组件如下:控制文件――记录数据库的物理结构,用于激活数据库表空间――来自数据库各行各列的实际数据索引文件/空间――Oracle中并不需要索引,不过大型数据库总会用到索引,因为在数据库中进行查找时,索引可以大幅提升查找速度重做日志――被激活的数据库请求,允许你在数据库崩溃后进行重建并重新启动(这些日志本质上类似于文件系统日志)因为上述组件都有不同类型的访问模式,所以每种文件类型均被存储在不同的文件系统中,并有调节选项。

其它数据库也拥有相似的文件类型,需要以相似的方式考虑。

控制文件大部分数据库都建议使用多个控制文件以确保可靠性。

控制文件并不需要常写常读,不过你必须确定各文件被放置在不同的RAID集上,适用于不同的RAID控制器。

表空间表空间一般是数据库中量最大的数据。

当读取列上的大表时,表空间可以由更大的I/O请求访问。

根据大小和更新频率的不同,表空间常常位于更大的数据条带化RAID-5上,以便获得较RAID-1更高的密度和提升的性能。

索引文件/空间在许多数据库中,索引文件是被访问频率最高的数据。

查找索引文件有可能需要很大的IOPS(每秒I/O操作)。

另外,有时候数据库被重新索引,这在计算上非常密集,并且需要大量的I/O带宽。

因为数据库和所需的查找类型不同,索引空间也许会很大,一般来说,根据传统的UNIX文件尺寸,索引文件的大小为2 GB。

重做日志重做日志文件中存放了各种记录,你可以撤销对数据库的各种操作,这些被称为重做记录。

重做记录用于循环缓冲器中,因为它一般是小I/O,所以用RAID-1就不错。

由于需要两个或以上的重做日志文件,通常将日志文件放在不同的RAID-1卷上。

操作系统数据库一般都需要具备操作系统的一些特性和功能,如共享内存和标志等。

另外,数据库也经常利用计算机内大量的内存,这通常由改变数据库中的可调参数来实现。

在许多操作系统中,I/O请求的大小限制在256 KB或128 KB,不能改变,所以如果必须对存储和操作系统完成更多的请求,就会影响到I/O性能。

文件系统和卷管理器架构决策中最重要的事情之一就是为每个数据库组件确定最理想的卷管理器和文件系统设置,对于每种类型的I/O,你可能希望进行不同的设置,请考虑以下的I/O类型:长和短的连续块长和短的随机块长和短的多重数据流块所有的读所有的写多线程对所有这些类型的I/O来说,只有一组设置的文件系统表现得都不好,而且我敢说对于上述任何两种类型的I/O来说,只有一组可调参数的文件系统也无法做好,也不可能通过改变参数来提升性能。

设计中要确定的两个关键因素是:1.对于所要处理的I/O类型,什么是最好的卷管理器和文件系统2.对于该文件系统和卷管理器,什么又是最好的可调参数几年前我曾做过一个数据库,由于一些原因而无法进行扩展,不过我认为其中最主要的原因是RAID缓存在进行索引查找时未得到有效利用。

RAID的读访问率小于20%,而且我认为大部分是不规则的连续读(先对几个请求连续读,然后随机跳过几个,又开始连续读)。

检查卷管理器后,我发现了问题所在。

每个文件系统有32个LUN(逻辑单元号),每个LUN为8 GB。

文件系统上的数据条设置为32 KB,与RAID分配相符。

每个索引文件是2 GB。

考虑到RAID缓存的工作方式,你必须先读两个连续块再读第三个块,这是常用的算法,因此在下一个I/O到达缓存之前,需要32 KB*32 LUN*2,即2 MB的连续读数据。

RAID缓存利用率如此低下并不奇怪。

客户被告知他们有两个办法提升性能,一是为卷管理器数据条分配2 GB,这样每个索引文件均被连续分配;二是使用另一种文件系统,可以使数据进行循环而不是条带化。

循环状态下,每个开放的系统请求都会被分配给另一个LUN,并且被打开的文件中所有数据也都会被分配在那个LUN上。

当我们使用循环分配方法和读缓存测试这种配置时,访问率从20%上升到80%,性能也超过了当时客户的要求。

主机总线适配器(HBA)即使价值2,000美元的HBA也会对大型数据库的性能造成重大影响。

对HBA要考虑两个地方:1.未处理的I/O请求量2.可以实现的最大请求量大多数HBA在驱动器软件中将未处理的请求量默认值设置为16,这就限制了发送给RAID设备的命令数,即使拥有很多的磁盘驱动器和随机I/O,这个数值也可能无法充分利用存储资源。

许多操作系统和设备驱动器都限制了I/O请求的大小,使之小于从表空间读或向表空间写所需的请求量。

应该将设备驱动器内所设的限制更改为允许更大的请求量。

当然,对每个设备驱动器和操作系统要做不同的设置,而且有意思的是,这些设置常常改变。

存储硬件存储硬件很可能是为数据库构建系统时最重要的部分之一。

你也许希望拥有许多不同的LUN,以便用于数据库中将发生的各种类型的I/O。

举例来说,一般情况下你希望:重做日志文件拥有高带宽需求(64 KB),发送到重做日志的I/O大部分是写索引查找拥有高带宽小块随机I/O(8 KB),并且多数情况下对索引的I/O大部分是读表空间拥有大块I/O(256 KB),并且一般情况下对表空间的I/O大部分是读正如你所看到的,一种大小是无法满足所有需求的,因此你必须完成以下几组匹配工作:1.RAID级别与典型的读/写访问类型2.数据条宽度与请求大小3.带宽需求与RAID级别和请求大小4.缓存策略与所处理的I/O类型这些似乎都不太容易,不过如果你从最基本的问题着手,解决起来也不难。

重做日志根据重做日志的大小和带宽量,你可能最初会认为需要RAID-5数据条。

这其实要看情况而定,因为大多数10K RPM磁盘的数据传送速度为外磁道柱面每秒69 MB,内磁道柱面每秒39 MB,15K RPM 的磁盘则更快。

另外再加上RAID缓存的大小,你就无须使用RAID-5了。

真正的决定因素在于:1.带宽需求――每秒多少MB的日志数据2.日志的大小――能够适应缓存吗?3.你的RAID速度你必须收集到上述三项重要信息,用各种不同的数据库和系统工具查看系统,确定重做日志的表现是否会限制数据库的性能和扩展,而如果是,那么重做日志的I/O需求又是什么。

索引文件索引文件的结构相当简单。

如果你需要速度快一些,就使用数据条带化值很小的RAID-1加上一块高性能15K磁盘。

因为索引文件是小块读文件,并且常常是随机I/O,所以这是目前最快的方式。

表空间根据表的大小及其被访问和查找的方式,RAID-1有时是更好的方法,不过其它时候RAID-5就是最佳选择了。

关键是决定表空间的I/O请求大小是多少,请求的大小常常取决于数据库中的可调参数。

结论关于不同操作系统上的各种可调数据库有许多书籍和文献供参考,下面是我读过觉得有用的几本:在Solaris平台上配置和调节数据库(Configuring and Tuning Databases on the Solaris Platform)》,作者:Allan N. Packer,Sun微系统公司出版社,出版商:Prentice Hall(2001年12月5日),ISBN:0130834173。

Oacle9i性能调节方法和技巧(erformance Tuning Tips & Techniques)》,作者:Richard J. Niemiec,出版商:McGraw-Hill Osborne Media(2003年5月12日),ISBN:0072224738。

《创建一个自调节Oracle数据库:自动化Oracle9i动态SGA性能[Oracle焦点系列](Creating a Self-Tuning Oracle Database: Automating Oracle9i Dynamic SGA Performance [Oracle In-Focus series])》,作者:Donald K. Burleson,出版商:Rampant TechPress(2003年8月1日),ISBN:0972751327。

数据库的构建正如其它应用一样,你需要确定数据库对文件系统/卷管理器、HBA和RAID的I/O 模式,同时牢记性能需求和成本问题。

由于数据库很复杂,调节起来有些难度,不过现在有很多工具供你查看数据,帮助你理解潜在的I/O问题。

相关文档
最新文档