4同行回答
社保省级大集中模式的基础是数据集中，不仅在物理上而且在逻辑上都要求最终建立统一的数据记录系统，以便于各业务模块之间、各地域之间统一有机地共享全部业务数据和人员信息。数据集中之后要求数据库服务器必须具备充分的扩展能力，以便保证业务发展时始终保持单一的数据映像，不改变IT架构的逻辑，不影响业务既有的规则与流程。
数据集中之后单一数据库的数据量将跳跃性地提升。数据服务器必须保证在超大数据量的情况下仍能保证业务处理的服务水平，特别是联机实时处理和批量数据汇总的服务水平。大集中后数据库服务器将同时为多种类型的业务应用提供数据服务，这些业务应用特点不尽相同，服务水平和响应时间要求都有差异。要求数据库服务器必须能够满意地保证所有业务类型的服务水平要求，同时提高有效的资源利用率。从业务特点来讲，大致有下面几种分类：
1. 联机事务处理（OLTP）：必须能够高效地处理省中心核心业务的联机处理，包括人力资源、劳动就业、社会保障五险业务、社保卡业务，信息交换业务和公共服务业务，等等。业务量参照覆盖人口数计算。
2. 批量处理（Batch）：月末/年末结算/测算(征缴费、养老待遇、拨/付款、查询统计，等等）。必须能够按照业务部门的要求在规定的时间窗内完成任务，保证业务的正常开展。例如：对于单项业务的月度征缴核算等任务要求在30分钟内完成；对于单项业务全省的月度并发核算要求在60分钟内完成；对于单项业务全省范围的查询统计要求在60分钟内完成。上述批处理业务包括夜间执行或白天与联机业务并发执行。
3. 查询与数据挖掘（OLAP): 针对各种业务主体建立数据模型并进行分析，支持宏观决策。
4. 数据流转：比如在生产库、交换库和决策库等数据资源之间进行数据抽取、转换、与加载等任务。
5. 数据维护：针对各种数据资源库进行数据加载、备份与恢复，在规定的时间窗内完成，并不影响业务的正常开展。覆盖全省的基础信息库、各个系统的业务经办库、公共服务信息库、各种交换信息库、数据仓库和主题分析库等等。必须提供足够的数据吞吐能力，高效地完成上述任务。
那么话说回来，x86架构是不是能单独支撑大集中架构，我相信没有一位懂行的省级领导敢拍板用x86服务器来做大集中。理由很简单，x86服务器在业界内很少作为核心数据库服务器是有原因的，比如x86服务器单机整体故障率每年2%，x86服务器的可靠性低是核心数据库服务器的最大隐忧；再如，数据库一般属于I/O比较繁重的负载类型，而x86服务器另外一个致命的瓶颈在于I/O处理能力不强，导致 CPU利用率上不去的根本原因。举个例子来说，医保大集中以后，先不说性能能否支撑的问题，就是三天两头的宕机，老百姓看不了病买不了药的负面影响天天上头条，谁也受不了。但这不是说大集中完全排除x86，术业有专攻，各有各的所长，我个人认为比较合理的一种场景就是前端应用集群可以利用x86部署，后端核心的数据库服服务器至少用高端的小型机或LinuxONE服务器是一种合理的架构选择。
大集中后只是业务的集中而已，对于计算资源的需求还是可以分散处理的，X86架构不是不能够支撑，而是需要换一种架构进行支撑，如果只是单台设备肯定是无法支撑的。
如果想采用集中式的架构，一台LINUXONE就可以了，计算资源可以动态调配，可以根据业务负载的高低动态调整资源。
如果想采用分布式架构，那就购买多台X86组建虚拟化资源池，可以达到同样的效果。
收起这里我就不谈具体的分析方法了。单就集中后的业务负载对基础平台的要求来说，不论是LINUX ONE还是x86架构就现在的通用配置和处理能力来说都是能够支撑的。只是需要根据业务处理数量大小，选择不同的配置就可以了。
收起