查看其它 2 个回答wuke的回答
医院的需要什么类型的存储，是根据数据类型来分的，总体来看，需要落盘存储的数据大致可以分成两大类：
- 核心数据库以及核心数据仓库数据，比如 HIS 数据库， CDR 数据仓库等
- 半结构化或非结构化数据，如 PACS 数据，办公文件数据等
两大类数据对存储的需有所区别，下面分开讲解：
- 核心数据库以及核心数据仓库数据，这里即可以包括 HIS 等传统医院核心业务的数据，也包括 CDR 等中间库，主题库等数据仓库类的的数据，基本是以行或列格式存储的结构化数据，核心数据库算是 OLTP 类业务，和核心数据仓库算是 OLAP 类业务，虽然两者的要求是有区别的，但需要的底层存储往往都需要提供较高的 IOPS ，以及稳定的性能，此外也需要保障足够的可用性，因为 HIS 数据库是医院最核心业务的支撑，如果出现停机，会造成后果不堪设想的后果。出于可用性，稳定性和性能的考虑，医院在从前，往往选择冗余 SAN 交换机 + 独立 SAN 存储进行支撑，且等级要求高的医院，也做了存储级的灾备或双活以保证数据和业务的安全。在从前，这种架构很好的支撑业务的发展，但随着时间的发展，这种架构也遇到了各种问题：
（ 1 ） . 由于独立存储的特点，采购往往采用 “ 提前采购 ” 的方式，即一次规划就计划 3-5 年的数据使用量以及性能需求，一次性的前期投入，这种方法一次性投入的成本高，且很难预估准确未来几年的发展情况，往往有投资浪费
（ 2 ） . 相反的情况是，采购独立存储时，预估不足，导致容量或者性能瓶颈。如果是容量瓶颈则需要扩容硬盘空间，而传统磁盘阵列往往的经营模式是扩容时价格比较高，结果就导致了后续使用成本高；如果是性能不足，如果硬盘少导致硬盘通道少进而导致性能不足的话需要扩展更多的硬盘，不但需要停机调整业务，扩容的成本也很高，如果传统存储的瓶颈发生在磁盘阵列控制器上，就更麻烦，因为好多中端存储的磁盘控制器是很难扩展的，导致了性能瓶颈一直存在难以解决，如果是高端磁盘阵列，往往需要采用增加控制器的方式进行性能扩容，这时候扩容的成本又居高不下，经过再三考虑，往往不得不重新采购新的存储，这又牵扯到了数据迁移的时间与风险，也消耗人手。
（ 3 ） . 部分医院出于需要更高等级的业务可用性，往往做了存储阵列级别的容灾备份或者双活，但这样的成本非常高，因为需要至少两套的独立磁盘阵列和对应的授权以及服务费，这也导致了医院只能在最核心的业务上实现存储双活或存储灾备保护，很多也是很关键的业务，比如电子病历等，因为受制与成本太高，导致没有高可用保护，存在单点故障影响业务可用性，甚至可能导致数据损坏的风险。
（ 4 ）服务器，虚拟化，存储，存储双活，数据库双活分开管理，管理很复杂。如有管理配置表维护不慎，则可能引发管理风险，管理的效率也低，而且随着医院的发展， IT 系统也越来越复杂，需要 IT 管理人员投入更多的精力支撑业务发展，医院本来管理 IT 的人手就不，人手不足的情况就会越来越明显，不论什么存储，只要是和主机，虚拟化分开管理的，哪怕是独立的分布式 SAN 存储，都会遇到这样的问题。
基于以上原因，目前越来越多的医院，放弃了采购传统的 SAN 存储，而采用无单点故障的，自带数据多副本功能的，可按需投资在线扩容的，无传统 SAN 存储控制器性能瓶颈分布式块存储（如 SmartX 的 ZBS 分布式快存储），对传统存储进行替换。而且，从各级医院实际的落地案例看，医院往往更多也并不是采用存储单独替换的方式进行存储基础架构的建设，而是把服务器，虚拟化， SAN 交换， SAN 存储四者的更新合并到一起，选择用带有分布式块存储功能超融合方案，逐步的进行连带上述四个部分的整体基础架构转型。超融合是采用通用多台 x86 服务器组成集群，加上超融合系统里自带的的分布式存储软件以及虚拟化软件，将 x86 服务器上的硬盘作为存储资源池，将 x86 服务器作为计算资源池，进行整体的，分步的超融合转型，因为这么做的话，上述的四大问可以同时得到解决：
（ 1 ）首先基础架构的管理得到极大简化，超融合不需要独立的 SAN 交换机和 SAN 存储，往往就一个界面，各种资源一目了然，管理效率极大提升的同时，也极大的降低了管理的风险，解放了双手；
（ 2 ）超融合是可以基于节点扩展的，计算或存储资源不足时，可以线性在线扩展节点进超融合集群即可，无需停机，无需数据迁移，在线扩容，且一些品牌如 SmartX 的数据可以自动均衡至新扩节点，整个过程高效且低风险，同时，可线性扩展就意味着可以按需投资，不用一次先规划 5 年的资源了，完全可以在需要时再进行超融合集群，保护了投资
（ 3 ）以 SmartX 超融合为例，超融合自带的 ZBS 分布式块存储软件具备了多数据副本的能力，数据被切块且生成 2-3 个副本（几个副本看实际业务选择，重要的业务副本就多）到了多个节点，数据就具备了高可用性，一个节点出现故障时，业务虚拟机可以在 3 分钟内，自动漂移至完好的节点上运行，且过程是自动的，数据无丢失，相当于基于超融合支撑的所有主机，都自动的具备了高可用能力，这就扩大了业务高可用的覆盖面，使得所有业务都具备高可用的能力，此外超融合也支持远程灾备与双活，投资的性价比很高。
至于超融合的性能和可用性能否支持医院的核心业务，目前超融合 SmartX 已经具备众多的医院案例，从大型三甲医院到二级医院，均有使用超融合， Smart X 超融合有有大三甲医院案例，分别把 HIS 的核心数据库， CDR 数据仓库，电子病历，集成平台等核心业务系统以及对应的 oracle 数据库承载在 Smart X 超融合上，且性能优异，使用多年没出过什么问题， SmartX 超融合作作为中国金融行业的超融合软件占有率第一名，其超融合提供的安全性，而可用性，性能和稳定性也是金融核心生产级的，完全可以做到统一支撑三甲医院到二级医院的全部业务，包括核心业务，综合业务，内网和外网的所有业务，都可以通过超融合进行安全，高效的统一承载。
至于半结构化或非结构化数据，如 PACS 数据，办公文件数据等，存储的需求往往更多的体现在 PACS 数据上，因为数据增量非常快且往往需要长期保存，因此往往也是出于成本以及无单点故障，管理便捷的类似的考虑，采用软件定义的分布式的 NAS 存储进行存储，而且细分的话， PACS 数据还可以进一步细分成，三年内的热 / 温数据，以及三年以上的冷数据，两者的需求又有不同，热 / 温数据因为被访问的次数更多，因此需要的是较高的存储吞吐量，因此对存储的性能往往是有更高需求的，这个部分的软件定义分布式存储成本相对较高，而且同样对服务器资源有较高要求；而冷数据更多关注的是长期保存，数据不丢失，因此追求的往往是高性价比且安全的存储数据，性能放到次要考虑，只需要的时候能把数据较快的找回来即可，因此往往会考虑性价比优异的大 SATA 盘 + 可线性扩展的软件定义分布式 NAS 存储。也有少数医院将这部分数据归档到成本更低的对象存储，需要时将这部分数据通过接口将所需 PACS 数据调回至热 / 温层的分布式 NAS 存储进行使用，但使用对象存储目前还未成为主流，原因很简单，因为往往对象存储的接口是 rest 等接口，应用不做开发的话没法直接调用，往往需要再有个温热层的分布式 NAS 存储作为缓冲，这种方式被厂商绑定的可能性更高，因此多数医院还是使用软件定义的，低成本的分布式 NAS 存储存储冷的 PACS 数据。
由于正好热 / 温层 PACS 数据对服务器资源的需求也比较高，因此一些医院干脆选择一步到位，直接用带分布式存储功能的超融合直接承载了近三年的 PACS 数据，并将三年以上的冷 PACS 数据放至软件定义的，低成本的，独立的分布式 NAS 存储资源池上， SmartX 就有这样的三甲医院的案例，以上回答了医院不同类型的数据需要什么样的存储，以及医院在实际建设中，往往会选择什么样的方案。