2012年11月系统架构设计师案例分析答案及解析.pdfVIP

一、问答题

1、请详细阅读有关数据架构方面的描述，回答问题。

【说明】

某软件公司欲开发一个基于Web

2.0的大型社交网络系统。就该系统的数据架构而言，李工决定采用公司熟悉的数

据架构，使用通用的商用关系型数据库，系统内部数据采用中央集中方式存储。

该系统投入使用后，初期用户数量少，系统运行平稳。6个月后，用户数出现了爆

炸式增长，系统暴露出诸多问题，集中表现在：

1.用户执行读写操作时，响应时间均变得很慢；

2.随着系统功能的扩充，原有数据格式发生变化，又出现新的数据格式，维护困难

；

3.数据容量很快超过系统原有的设计上限，数据库扩容困难；

4.软件系统不断出现宕机，整个系统可用性较差。

经过多次会议讨论，公司的王工建议采用NoSQL数据库来替代关系数据库，以解

决上述问题。但李工指出NoSQL数据库出现时间不长，在使用上可能存在风险。

公司技术人员对NoSQL数据库产品进行了认真测试，最终决定采用NoSQL数据库

来替代现有的数据库系统。

【问题1】

分别解释产生问题(1)～(4)的原因。

【问题2】

请针对问题(1)～(4)，分别指出NoSQL数据库的哪些特点促使公司最终采用了NoSQ

L数据库。

【问题3】

请指出该系统采用NoSQL数据库时可能存在的问题。

参考答案：

【问题1】答案：

其原因主要是：

(1)用户响应时间慢。大型社交网络系统要根据用户个性化信息来实时生成动态页

面和提供动态信息，所以基本上无法使用动态页面静态化技术，因此数据库并发负

载非常高，往往要达到每秒上万次读写请求。关系数据库应付上万次SQL查询还勉

强可以，但是应付上万次SQL写数据请求，硬盘I/O就已经无法承受了。特别是涉

及到多表连接操作，会导致响应变慢。

(2)数据格式变化。大型社交网络系统随着用户的使用，会不断地增加新的功能，

导致原有数据格式发生变化，甚至出现新的数据格式。但关系数据库中采用元组方

式组织数据，难以使用新型数据格式，难以维护。

(3)数据容量超过设计上限。对于大型社交网络系统，往往会在很短时间内产生海

量数据。关系数据库多采用中央数据存储，使得数据容量受限于前期设计的上限，

很难实现数据容量的横向扩展。

(4)系统可用性差：关系数据库采用中央数据存储，容易成为系统的性能瓶颈，单

点故障很容易导致系统崩溃，负载过高往往导致系统出现宕机现象。

【问题2】答案：

针对问题(1)，NoSQL数据库支持高并发数据访问，性能较高。

针对问题(2)，NoSQL数据库的数据存储结构松散，能够灵活支持多种类型的数据

格式。

针对问题(3)，NoSQL数据库能够支持海量数据的存储，且易于横向扩展。

针对问题(4)，NoSQL数据库基于分布式数据存储，不存在单点故障和性能瓶颈，

系统可用性高。

【问题3】答案：

该系统采用NoSQL数据库时可能存在的问题有：

(1)NoSQL数据库的现有产品不够成熟，大多数产品处于初创期。

(2)NoSQL数据库并未形成一定的标准，产品种类繁多，缺乏官方支持。

(3)NoSQL数据库不提供对SQL的支持，学习和应用迁移成本较高。

(4)NoSQL数据库支持的特性不够丰富，现有产品提供的功能比较有限。

解析：

问题1主要分析系统中出现的四个问题的原因。对于用户响应时间慢，是因为系统

并发负载高，关系数据库在处理高并发写数据请求时存在压力；数据格式变化是因

为关系数据库的组织方式难以适应新型数据格式的变化；数据容量超过设计上限是

因为关系数据库的数据存储方式难以实现数据容量的横向扩展；系统可用性差则是

因为关系数据库的单点故障容易导致系统崩溃。

2、阅读以下关于分布式系统设计的叙述，回答问题。

【说明】

某软件公司拟开发一套电信领域的分布式系统，该系统后台多个功能模块同时运行

时的计算负载较大，且需要控制不同的特定电信硬件设备，由于硬件体积和I/O端

口冲突等原因，这些设备需要分散安装在多个不同计算机系统中。该系统上线运行

后将为企业最终用户提供7×24小时的不间断服务，而用户的单次接入服务往往需

要后台多个模块共同协作完成。基于上述原因，该系统后台软件模块需分布在局域

网内的多台计算机上。

项目组决定基于ISO的开放分布进程(ODP)规范来进行系统架构的设计与开发，近

期项目组召开了多次会议，对架构设计阶段的关键问题进行了讨论分析。

【问题1】

ODP从5个标准的视点组织分析系统的架构，这些视点描述了同一系统的不同重要

方面，请根据图中不同视点所关注的核心内容，将备选的架构视点填入图中的(1)

～(5)。

备选答案