数据库架构设计

数据库架构设计

最近在考虑如何能设计好一个数据库架构，下面是个人一点想法，欢迎高人指正
 

任何系统都不是独立的，是一个生态系统，数据库也是一样的，要使其在其生命周期内更好的服务于业务，在设计之初就要考虑周全。作为数据库设计者在大方向上最为关心的是如下几点，也是要实现的目标：
  数据库架构
  硬件选型
  运营维护

以一个创建平台系统为例，要经历业务架构设计，数据架构设计，应用架构设计，系统架构设计，运营维护

业务架构：公司的业务模式，实现业务流程、功能等
数据架构：实现数据共享、一致性、完整性、准确性
      数据定义：
               数据标准：如静态数据：元数据、业务对象；动态数据：订单等
               数据概念模型：根据需求分析，进行综合分析，形成独立于具体DBMS的概念模型，要理清
                        实体和实体关系
                        属性和域
                       业务规则(应用实现和数据库实现)

                   并综合考虑如下几点
                      存储哪些数据
                      数据来源
                      数据的约束规则及
                      数据怎样被使用
                      用户想看到哪些数据
                      数据与其他系统是否交互          
                      数据访问方式
    
                数据逻辑模型：将概念模型转化为某个具体的DBMS支持的模型，绘制E-R图，在本阶段要完成实体间 的关系；考虑属性的域（值的类型，范围，约束）
                数据物理模型：将E-R图转化具体的RDBMS相应的表，如果系统比较大的话，还要考虑系统架构为逻辑模型设计一个合适的物理环境。
         
        数据分布：数据业务分布与数据系统分布（集中或分布式）
        数据管理：数据模型与数据标准管理，数据分布管理，数据质量管理，数据安全管理，数据生命周期、存储维护管理

应用架构：从业务架构、数据架构考虑系统的功能边界在哪，结合CRUD矩阵等分析方法考虑系统需
                     要划分成多少个模块？如何封装模块？才能保证模块本身高内聚和松耦合，每个模块之间
                     的接口和调用关系，采用什么样的技术框架。应用架构设计有几个核心的原则：
   
                    开放-封闭原则：即对扩展开放，对修改封闭
                    高内聚低耦合原则：尽量将功能相关的内容组合在一起，封装后对外提供接口。
                    封装变化原则：越是可能发生变化的地方越要进行处理和封装，将变化的影响限制在一定范围之内。
                   平衡性原则：架构设计需要平衡多方面的要求，折衷考虑设计方案，比如性能和灵活性就常常是一对矛盾的要求。

系统架构：系统架构主要是关注的是非功能性要求的实现，如：
      1.数据安全、容灾需求
      2.维护需求
      3.扩展需求
      4.高可用需求
      5.资源、成本要求
      6.保证每一模块高内聚低耦合
      7.容量（性能和存储）需求
      8.并发访问量，高并发访问时的瓶颈，数据库？应用服务器？
      9.海量数据存储与访问优化
     10.数据库分库分表
     11.软件集群/硬件集群
     12.系统过载保护
     13.缓存机制
     14.容错能力
     15.与其他系统交互
     16.分布式处理，数据一致性、完整性、及时性

  
如果系统比较简单，数据量、访问量很小，那就没必要过多考虑系统架构，在部署上采用raid技术，分层存储，读写分离，主备技术，负载均衡等方法。    
     
通过以上就可以清晰的知道数据库架构，再配合一个数据库申请单就更全面，下面就开始硬件选型     

 
硬件选型  
方案要保证系统上线可以支撑1-2年左右，以后根据需要动态扩展；从存储空间，性能空间两个维度, 并结合系统架构考虑支撑业务需要的硬件需求，方法有两种
   1.根据监控数据，和当前类似业务对比，推断出需要的硬件  
   2.对于我们io密集型系统，可以根据访问量计算出需要的io能力，从而推断出需要的硬件