(完整版)数据架构规划
数据架构规划
数据架构规划摘要本文档旨在介绍数据架构规划的概念以及重要性，并提供一些建议和最佳实践来帮助组织制定和实施数据架构规划。
引言随着企业和组织日益增长的数据量，数据架构规划变得越来越重要。
数据架构规划是定义和组织数据资源的过程，以满足业务需求并支持企业的战略目标。
一个合理的数据架构规划能够提高数据的可用性、可靠性和可持续性，同时降低数据管理的复杂性和成本。
数据架构规划的重要性1. 支持业务需求：数据架构规划能够帮助组织了解和分析业务需求，并根据这些需求建立适当的数据模型和结构，以支持业务流程和决策。
2. 数据集成和一致性：通过数据架构规划，组织可以将分散的数据源整合起来，确保数据的一致性和完整性，避免数据冗余和不一致的问题。
3. 数据安全和隐私保护：数据架构规划可以帮助确定数据的访问权限和隐私保护措施，确保数据的安全性和合规性。
4. 数据可用性和性能优化：合理的数据架构规划可以提高数据的可用性和可靠性，同时优化数据访问和查询的性能，提高业务操作的效率和响应时间。
数据架构规划的步骤1. 了解业务需求：与业务部门和利益相关者合作，深入了解业务需求，并确定数据的关键功能和要求。
2. 分析现有数据资源：评估现有的数据资源和基础设施，包括数据源、数据库、存储和处理系统等，了解其优点和限制。
3. 设计逻辑数据模型：根据业务需求和现有数据资源的分析，设计逻辑数据模型，包括数据实体、属性和关系等。
4. 制定数据架构规范：基于逻辑数据模型，定义数据架构规范，包括数据分类、数据词典、命名规则、数据标准等，以统一数据的管理和使用。
5. 确定数据集成和交换方法：确定数据集成和交换的方法和工具，包括ETL（抽取、转换和加载）工具、数据传输协议等，以实现数据的共享和流转。
6. 实施数据架构规划：在数据架构规划的基础上，进行数据资源的划分、组织和配置，实施数据架构规划并监控其运行效果。
7. 定期评估和调整：定期评估数据架构规划的实施效果，并根据业务变化和技术进展进行调整和优化。
架构设计之数据架构
架构设计之数据架构一、引言数据架构是指在系统架构设计中，对数据的组织、存储、访问和管理进行规划和设计的过程。
一个良好的数据架构能够提高系统的性能、可扩展性和可维护性，确保数据的完整性和安全性。
本文将详细介绍数据架构的设计原则、组成要素以及常用的数据架构模式。
二、设计原则1. 数据一致性：确保数据在不同的应用程序和模块之间保持一致，避免数据冗余和不一致的问题。
2. 数据可靠性：确保数据的完整性和准确性，防止数据丢失和损坏。
3. 数据安全性：采取合适的安全措施，保护数据的机密性和隐私性，防止未经授权的访问和篡改。
4. 数据可扩展性：设计一个可扩展的数据架构，能够满足未来系统的扩展需求，支持大规模数据的存储和处理。
5. 数据性能优化：优化数据的访问和查询性能，提高系统的响应速度和吞吐量。
三、组成要素1. 数据模型：数据模型是描述数据结构、关系和约束的抽象模型。
常用的数据模型包括层次模型、关系模型、对象模型和文档模型等。
根据具体的业务需求和系统特点，选择合适的数据模型进行设计。
2. 数据库管理系统（DBMS）：DBMS是用于管理和操作数据库的软件系统。
常见的DBMS包括关系型数据库（如Oracle、MySQL）和非关系型数据库（如MongoDB、Redis）。
根据系统的需求和性能要求，选择合适的DBMS进行数据存储和管理。
3. 数据存储：数据存储是指将数据保存在物理介质上，包括磁盘、内存、云存储等。
根据数据的访问频率和存储需求，选择合适的存储介质和存储方案，如使用SSD提高数据的读写速度，使用分布式存储系统提高数据的可靠性和可扩展性。
4. 数据访问接口：数据访问接口是系统和数据之间的桥梁，提供对数据的访问和操作功能。
常见的数据访问接口包括SQL、NoSQL、RESTful API等。
根据系统的需求和开发技术，选择合适的数据访问接口进行设计和实现。
四、数据架构模式1. 单体架构：将所有的功能模块集中在一个系统中，数据存储在同一个数据库中。
架构设计之数据架构
架构设计之数据架构数据架构是指在软件系统中对数据进行组织和管理的方式和规范。
它关注的是数据的存储、传输和处理，以及数据的安全性和可靠性。
在架构设计中，数据架构起着至关重要的作用，它决定了系统的性能、可扩展性和可维护性。
一、数据架构的概述数据架构是整个系统架构的重要组成部分，它负责定义和管理数据的结构、存储和访问方式。
数据架构需要考虑以下几个方面：1. 数据模型：选择合适的数据模型，如关系型、面向对象等，以满足系统的需求。
2. 数据库设计：设计数据库的表结构、字段、索引等，以支持系统的功能和性能需求。
3. 数据存储：选择合适的数据存储方式，如关系型数据库、NoSQL数据库、分布式文件系统等。
4. 数据传输：定义数据在系统内部和外部的传输方式，如API、消息队列等。
5. 数据安全：确保数据的机密性、完整性和可用性，采取合适的加密、备份和恢复策略。
二、数据架构的设计原则在设计数据架构时，需要遵循一些基本原则，以确保系统的高性能、可扩展性和可维护性：1. 数据一致性：确保数据在系统内部和外部的一致性，避免数据冗余和不一致。
2. 数据完整性：保证数据的完整性，防止数据丢失或损坏。
3. 数据可扩展性：设计可扩展的数据架构，以支持系统的增长和变化。
4. 数据安全性：采取合适的安全措施，保护数据的机密性和完整性。
5. 数据性能：优化数据的存储和访问方式，以提高系统的性能和响应速度。
三、数据架构的实施步骤在实施数据架构时，可以按照以下步骤进行：1. 需求分析：明确系统对数据的需求，包括数据的类型、结构、存储量和访问方式等。
2. 数据建模：根据需求分析结果，设计数据模型，包括实体关系图、类图等。
3. 数据库设计：根据数据模型，设计数据库的表结构、字段、索引等。
4. 数据存储：选择合适的数据存储方式，并进行数据的存储和管理。
5. 数据传输：定义数据在系统内部和外部的传输方式，确保数据的安全和可靠性。
6. 数据安全：采取合适的安全措施，保护数据的机密性和完整性。
数据中心架构规划
数据中心架构规划随着互联网的迅猛发展和信息化的推进，数据中心作为企业信息系统的核心基础设施，扮演着越来越重要的角色。
良好的数据中心架构规划可以提高系统的可靠性、安全性和可扩展性，保障企业的业务连续性和稳定性。
本文将就数据中心架构规划进行讨论。
一、概述数据中心架构规划是指在企业信息系统发展过程中，根据业务需求和技术趋势，采用合适的硬件、软件和网络方案，构建稳定可靠的数据中心基础设施。
一个好的数据中心架构应该具备高可用性、高性能、易管理、可扩展、安全可靠等特性。
二、数据中心架构原则1. 高可用性：通过冗余配置、灾备机制等手段，确保系统在硬件或软件故障时仍能持续提供服务，最大限度地减少业务中断时间。
2. 高性能：合理利用硬件资源，优化系统架构，提升数据中心的计算能力和处理速度，满足大规模数据处理和高并发访问。
3. 易管理：建立完善的管理体系，包括监控、维护、备份与恢复等，实现对数据中心的高效管理和运维。
4. 可扩展：根据业务需求和发展规模，灵活调整硬件和软件配置，支持系统的快速扩容和升级。
5. 安全可靠：采用多层次的安全防护措施，包括物理安全、网络安全、数据安全等，提升数据中心的防护能力和安全性。
6. 节能环保：优化硬件设备的选择和使用，提高能源利用效率，减少电力消耗和碳排放，实现数据中心的可持续发展。
三、数据中心架构要素1. 服务器设备：根据业务需求和负载特点选择合适的服务器类型，包括高密度服务器、虚拟化服务器等，提供计算和存储资源。
2. 存储设备：采用网络存储技术，如SAN（存储区域网络）或NAS（网络附加存储）等，实现数据的存储和共享。
3. 网络设备：采用可靠的网络架构和安全设备，包括交换机、路由器、防火墙等，实现数据的高效传输和安全访问。
4. 软件系统：选择适合的操作系统、数据库和应用软件，提供稳定可靠的服务支持。
5. 机房环境：保证机房的稳定供电、恒温恒湿、防火抗灾等基础设施，确保数据中心的正常运行。
架构设计之数据架构
架构设计之数据架构一、引言数据架构是指在系统架构中对数据的组织、存储、管理和访问进行规划和设计的过程。
在现代信息化时代，数据被认为是企业的重要资产之一，良好的数据架构能够为企业提供高效、可靠和可扩展的数据管理能力，从而支持企业的业务发展和决策制定。
本文将详细介绍数据架构的设计原则、组成要素以及常用的数据架构模式。
二、设计原则1. 数据一致性：数据架构应确保数据在不同系统之间的一致性，避免数据冗余和数据不一致的问题。
2. 数据安全性：数据架构应具备良好的安全性能，包括数据的保密性、完整性和可用性，以防止数据泄露、篡改和丢失。
3. 数据可扩展性：数据架构应具备良好的扩展性能，能够适应业务规模的增长和数据量的增加，保证系统的性能和稳定性。
4. 数据可管理性：数据架构应具备良好的管理性能，包括数据的维护、备份和恢复等功能，以保证数据的可靠性和可维护性。
5. 数据可访问性：数据架构应具备良好的访问性能，能够支持快速、准确地查询和分析数据，满足业务需求。
三、组成要素1. 数据模型：数据模型是数据架构的核心，它定义了数据的结构和关系，包括实体、属性、关系和约束等。
常用的数据模型包括层次模型、网络模型、关系模型和对象模型等。
2. 数据存储：数据存储是指数据在系统中的物理存储方式，常见的数据存储包括关系型数据库、非关系型数据库、分布式文件系统等。
根据业务需求和性能要求，可以选择合适的数据存储技术。
3. 数据传输：数据传输是指数据在不同系统之间的传输和同步，常见的数据传输方式包括ETL（抽取、转换、加载）、消息队列和数据同步等。
数据传输需要考虑数据的一致性、可靠性和效率等因素。
4. 数据处理：数据处理是指对数据进行加工和计算，以满足业务需求。
常见的数据处理方式包括数据清洗、数据转换、数据聚合和数据分析等。
数据处理需要考虑数据的准确性、实时性和效率等因素。
四、常用的数据架构模式1. 集中式数据架构：集中式数据架构将所有的数据存储在一个中心化的数据库中，各个系统通过访问中心数据库来获取和更新数据。
数据规划架构设计
我们要去哪里？
数据架构
应用架构
技术架构
Vision of where we want to be？
我们怎么到达那里？
实施和迁移计划
How we plan to get there？
6
基于Zachman框架的阶段工作内容
阶 ቤተ መጻሕፍቲ ባይዱ段名称 级
1 项目启动
工作内容与交付
项目目标／范围；项目团队；项目方法论，项目计划；建模工具；启动会 材料
信息架构就是对信息的分 类、分层的组织。例如： 分层信息有决策层、管理 层、操作层等信息；分类 信息有财务信息、人事信 息、设备管理信息等
数据架构就是对数据的分 类、分层的组织。例如： 从Zachman框架体系来看 分层数据有概念数据模型 、逻辑数据模型、物理数 据模型
13
数据架构原则是指导企业数据标准化的基本原则
Entity = T ables/Segm ents/etc. R el. = Key/Pointer/etc.
e .g . D a ta D e fin itio n
Process= C o m puter F unction I/O =D ata Elem ents/Sets
e.g. Program
N ode = H ard ware/Syste m S o ftw a re
L in k = L in e S p e cifica tio n s
e.g. N etwork Architecture
D E T AILE D REPRESEN-
T AT IO N S
S ubcontractor o u t-o f-c o n te xt
How
List of Processes th e B u s in e s s P e rfo rm s
大数据架构规划范文
大数据架构规划范文
一、大数据架构
1、定义
大数据架构指的是一种利用分布式计算技术（包括机器学习、深度学习、社交网络分析等）以及大规模数据集（如传感器数据、日志数据、临
床数据等）搭建的系统，用于分析和挖掘庞大的数据信息，从而能够解决
复杂的商业或科学问题。
2、技术栈
a.硬件：大数据架构不仅需要具备高带宽及高I/O能力的存储设备系统，而且还要求具备高性能的CPU、内存、网络、GPU卡等基础设备。
b. 软件：大数据架构包括多个层次的软件系统，包括数据收集、日
志记录、分析和可视化以及推理等组件，可以采用Linux下的主流开源软
件（Hadoop Map/Reduce, Pig, Hive，HBase, Flume, Spark等）支持。
3、设计原则
a.可扩展性：实现可无缝扩展，有效的应对网站流量的突发增加。
b.高性能：支持多样化的数据处理模式，提高数据处理速度，满足实
时性的需求。
c.成本效益：在满足客户需求的同时，尽可能降低设备的成本。
d.稳定性：实现良好的服务稳定性，有效的应对访问压力和负载均衡。
二、数据架构组件
1、文件存储
文件存储是大数据架构的基础，用于存储数据，它可以是网络存储，NAS，SAN，Object Storage，HDFS等。
2、数据库。
数据架构的规划与管理方法探究
数据架构的规划与管理方法探究数据架构是数据管理的基础，它定义了数据的组织结构和关系，确保数据的可靠性、安全性和可用性。
在当今信息时代，随着数据规模的不断增长和数据应用的不断扩展，如何科学地规划和管理数据架构变得尤为重要。
本文将探讨数据架构的规划与管理方法，旨在提供参考和指导。
一、规划数据架构的步骤1. 确定需求：在规划数据架构之前，我们需要充分了解业务需求和数据管理目标。
这包括数据的收集、存储、处理和输出需求，以及数据质量要求和安全保障等方面的考虑。
2. 制定策略：根据需求确定数据架构的战略和目标。
考虑数据集成、数据流程、数据访问和数据共享等关键要素，并确定数据架构的优先级和时间规划。
3. 设计逻辑模型：基于策略确定逻辑数据模型，包括实体、属性和关系等元素的定义。
逻辑模型反映了业务场景和业务流程，为后续的物理模型设计提供了基础。
4. 构建物理模型：在逻辑模型的基础上，将数据结构和存储介质进行具体设计。
考虑数据的分布、冗余和性能等方面的需求，确定物理模型的实施方案。
5. 评估和优化：定期对数据架构进行评估和优化，以保证其与业务需求的一致性。
同时，应及时调整数据架构以适应新的业务场景和技术变化。
二、管理数据架构的方法1. 数据资产管理：建立和维护数据资产清单，包括数据的来源、属性、质量和用途等信息。
通过对数据资产进行分类、标记和评估，可以更好地保护和管理数据。
2. 数据访问和安全管理：确保数据的安全性和隐私保护。
通过权限管理和加密技术，控制数据的访问权限和使用方式，防止数据的泄露和滥用。
3. 数据质量管理：监控和改进数据的质量，确保数据的准确性、完整性和一致性。
采用数据清洗、验证和校验等方法，及时修复和纠正数据的错误和偏差。
4. 数据集成和共享管理：实现数据的集成和共享，提高数据的利用效率。
通过建立数据集成平台和共享机制，实现数据的无缝连接和流动。
5. 技术架构管理：管理和优化数据架构所使用的技术工具和平台。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
数据架构规划一．当前架构结合研发二部数据量最大的校讯通产品来描述，其他的产品在性能上出现瓶颈，可以向校讯通靠拢。
数据库整体架构：目前校讯通产品根据用户量的多少以及数据库服务资源的繁忙程度，横向采用了历史库+当前库的分库架构或者单一的当前库架构，其中历史库只作为web平台读数据库，纵向结合了applications的memcache+Sybase ASE12.5传统永久磁盘化数据库架构。
数据模型架构：原则上采用了一事一地的数据模型（3NF范式），为了性能考虑，一些大数据量表适当的引用了数据冗余，根据业务再结合采用了当前表+历史表的数据模型。
以下就用图表来进行当前数据架构的说明：横向分库数据库架构图：纵向app layer+memcache layler+disk db layer图：其中web层指的是客户端浏览器层，逻辑上：app层指的是应用服务层，mc 层指的是memcache的客户端层，ms层指的是memcache的服务层，db层指的是目前永久磁盘化的数据库层，当然在物理机器上可能app层跟mc层，ms层是重叠的部署在相同服务器上。
数据模型架构图：其中以上数据模型中除了少数几张表外其他的都有历史表存在，当然有很多表是没在这个模型图中的，这部分是核心数据模型。
这部分模型对象中也包括了一些冗余性的设计，比如用户中有真实姓名，特别是不在这个模型内，由模型核心表产生的一些统计报表，为了查询的性能冗余了合理一些学校名称，地区名称等方面的设计。
二．劣势现象1.流水表性能瓶颈当前架构的性能瓶颈集中在流水表的访问上，最大流水表的记录量达到了超5亿级别，这是由于目前外网在用的sybase数据库系统版本，没有采取很好的关于分区的技术。
曾经有过把流水表进行物理水平分割，把不同月份的数据分割放在不同的物理表上的模型改造设想，碍于产生的应用程序修改工作量大，老旧数据迁移的麻烦，再加上进行了从单库架构改造到分库架构后，数据库性能瓶颈就不是特别突出。
所以模型改造这部分工作没展开。
无论是单库或是分库的模式，出现平台访问数据库的性能瓶颈依然集中在大流水表上，在访问高峰高并发量情况下，短信的流水表进程堵塞，数据库服务I/O ,CPU的资源耗费达到顶点，在服务器硬件环境不是特别理想情况下，出现了一定概率造成用户访问缓慢甚至觉得页面无法响应现象，造成了用户体念不良影响。
2. 运营维护难点1)历史数据清理运维工作为了存储充分利用，为了性能的提升，需要定期进行不再使用的历史数据清理，由于清理的数据量庞大，传统的数据清理方法根本不可能保证一个晚上有效清理完毕，确保平台第二天正常的运行。
虽然目前已经实行了比较高效且可行的数据清理方法，但是每次实行都需要晚上到通宵进行处理，使得数据清理的运维工作特别劳累，影响到运维人员第二天的正常出勤，间接就有可能影响到数据库的正常运维监控，导致数据库问题出现。
2)防止索引失效而进行的统计量更新运维工作由于流水表数据变动量大，容易导致流水表的索引失效，从而需要定期的进行索引甚至整表的统计量更新工作，统计量更新时间跟流水表的数据总量成正比关系，所以导致统计量更新速度比较慢，不能确保在计划时间内，统计量更新的完全成功，而且目前外网安装的sybase12.5版本是最低一个的EBF版本，存在较多BUG,在索引统计量更新过程中可能导致数据库出现病态，进而影响第二天数据库的正常运行。
3.运维监控纰漏（此部分非架构原因引起）当前的数据库监控以及运维维护还存在一些纰漏，出现了多次数据库设备空间使用完毕，没有及时添加数据库设备空间导致数据库挂起问题，也多次出现了数据库日志空间占满导致数据库挂起问题。
此类问题还是比较明显，还有一类问题，不是整库挂起，而是部分业务表访问异常，运维可能监控不到，等用户访问到了这部分业务功能不正常，由用户反馈到运维这边。
4.运营统计报表在当前数据模型架构下重用性较低由于用户需求的渐进性，导致数据库统计报表在数据模型设计时没有站在至高点，随着用户需求的不断积累，数据库统计报表对象也跟着不断积累，发现目前存在比较大一部分的统计报表数据在不同数据库对象之间重复统计，没有充分发挥统计数据的重用性。
5.没利用集群技术当前的数据库架构还没采用成熟的集群技术，集群技术并不单单指单一数据库系统的集群，可以混合集群，比如内存数据库跟传统永久磁盘化数据库系统集群。
6.分库架构还可完善当前的分库架构还可以继续完善，引用成熟的数据库主从分离，读写分离技术。
7.内存数据库技术还没充分利用当前的数据库架构虽然在前端使用了memcache技术，但是还可以继续完善使用内存数据库技术再结合异步写技术，使得架构相得益彰。
8.适合海量数据高并发读写，高效率存储的非关系型数据库没充分利用当前的数据库架构还没采用正在兴起的NoSql，NewSql技术（目前部分外围系统采用了mongodb来做试验品，而这部分系统的数据量并不大，非关系型数据库海量数据高并发访问的高效性优势没有体现出来，从而也没掌握真正的使用经验），当然这种数据库也有缺点，就是数据库事务一致性，数据库的写实时性和读实时性，复杂的SQL查询，特别是多表关联查询是无法满足的。
三．改进思路在第二部分的劣势现象中，总结了当前数据库架构以及数据模型架构的缺陷，缺陷还比较多，从另外一个角度也反映了公司产品数据库架构改进和提升的空间还比较大，将来随着不断的迭代改进，可以承受的业务量提升的空间也相应的比较大。
下面就根据劣势现象进行针对性的阐述改进思路：1.流水表性能瓶颈改进Sybase12.5没有很好的解决大数据量表的性能问题，但是通过数据库转到Oracle后，充分利用Oracle分区表，分区索引的特性来提升流水表的访问性能，逻辑上表仍然是一张完整的表，只是将表中的数据在物理上存放到多个表空间(物理文件上，这样查询数据时，不至于每次都扫描整张表。
由于逻辑上仍旧一表，使得应用程序不需要修改，也避免了这个劣势点描述的带来额外许多开发工作量的问题，但是效果几乎等同水平分割数据模型。
2.大流水表运维难的改进1)历史数据清理运维工作在Oracel数库系统中，针对对大流水表每个月的数据进行分区，这样运维人员在清理历史月份的数据时候，只要通过TRUNCATE PARTITION、 DROP PARTITION的Oracle本身的分区维护命令轻松快速清理掉分区的数据（既指定月份的流水数据）2)防止索引失效而进行的统计量更新运维工作同样Oracle也有等同于sybase的统计量更新工作，在Oracle中通过对大流水表的分区工作后，进行统计量的更新工作同样就快捷简易，可以通过ANALYZE PARTITION的统计量分析维护命令可以轻松快速对指定分区的统计量进行更新。
3.运维监控纰漏的改进主要分两个方面：a)数据库剩余空间方面的监控；b)数据库出错日志的监控。
这两个监控虽然通过人为主动性的查看数据库相关信息可以监控到，但是总归还是会有疏忽遗漏的时候，只是出问题几率高低之分。
所以这里再加一道监控，就是通过数据库服务器端的监控程序主动发回有问题或者告警的信息给运维人员。
这道监控程序可以通过shell程序以及数据库程序，结合数据库日志以及剩余空间信息以短信或者邮件的方式发回给运维人员。
在数据库剩余空间方面甚至可以通过数据库本身阀值的设置，做到自动截取日志，自动添加设备。
4.运营统计报表数据模型的改进由于原先一些报表模型存在着数据统计的重复性，在晚上定时task中既占用了任务列表的总时间，也对其他并行的task运行造成了一定的资源争用，影响了数据库性能。
所以在这里提出了一种类似蒲公英性质的模型，数据通过发散模式，即插即用到不同的运营统计报表中，势必需要改进当前接近一事一地的3范式模型，把原先的数据模型拆散，从纵向和横向都接近最小粒度需求的数据模型。
使得统计数据可以重复使用，不同的统计报表通过这些原子性的统计数据再组合成报表所需要的数据，当然这里需要一个平衡，并不完全等同蒲公英模型的统计粒度越细越好，因为越细也代表着原始的统计数据量越大，一会影响原始统计的性能，二会影响组合成报表的性能，三会占用更多的存储空间。
这个平衡度需要掌控好。
5.利用集群技术当然通过了前面4点的改进之后，数据库性能会比目前的架构提升一定的性能，至于集群技术就可以作为前面4点改进后的补充和扩展，如果在改进后，依然还存在较大性能瓶颈情况下可以采用Oracle RAC技术。
甚至采用基于内存数据库的分布式数据库架构的混合集群技术。
比如在Oracle数据库及Web服务之间加一层 Ameoba 分布式数据库代理结合内存数据库的架构，6.分库架构完善改进目前的数据库架构采用了分库方式，但是主库（当前库）的读写却是没有分离的，纵观淘宝的数据库架构演进历程，确是在某个历程碑点做到了很好的读写分离，应用到DB的数据写入与查询从双向通行变成了单向通行，通行效率更高，大大避免了相互影响。
“借道行驶”的情况不再出现。
淘宝那个碑点做到了以下几点：1)写库为集中式的oracle环境,提供数据安全性保障。
2)读库使用mysql, 采用数据分片，分库分表，每台mysql放少量的数据,单个数据分片内部采用mysql复制机制。
3)读库的超大memory容量，起到了很好的cache作用，在内存中的数据查询性能远远高于在硬盘上的性能4)oracle到多台mysql按规则复制结合淘宝架构的思考，校讯通大流水也可以做到垂直分割到不同的服务器，也可以做到水品分割到不同的服务器，通过不同的服务器访问不同的流水表或者是不同范围数据的流水表，那提升性能是肯定的。
不过也要平衡考虑到应用程序开发的简便性。
7.内存数据库技术利用常见的内存数据库产品包括商业版和免费版两类。
商业版如：Altibase，Timesten，Berkley DB等。
他们在电信，金融，证券等高性能计算应用中运用较为广泛。
商业版功能强大，然而，价格比较昂贵，不适合目前“廉价PC+免费软件”的架构搭建思想。
开源领域产品主要有H2，HsqlDB，Derby，BerkeleyDB 等。
在混合集群架构中，内存数据库将承担OLTP的职责，因此除了读写性能外，功能的完备，事务等都需要作为优先评估的因素。
盛传H2是一个开源的高性能内存数据库，可以通过整合 Ameoba 与 H2，夹在applications和传统db层之间来达到内存数据库层的架构部署。
Ameoba 是分布式数据库代理，它与 MySQL 整合已经在阿里巴巴核心业务中成功运用。
如果仅将数据库节点看作一个存储，MySQL Node 和 H2 Node 并无本质区别。
JDBC驱动，DB切分，路由，皆由Ameoba 统一负责。
8.非关系型数据库的使用外围的非核心数据，但是数据量又是比较大的的业务系统数据库可以采用非关系型数据库，这是由非关系型数据库的一些基本特性决定的。