一个数据库不管运行在什么IT基础设施上面，用户使用的都是数据库本身，所以从数据库使用者的角度来说，并无本质差异。本文主要考量非功能方面的特性。
针对于一个生产级别的数据库，在选择IT基础设施的时候，通常情况下需要考虑以下方面：
-
性能(Performance)：导致性能问题的原因非常多，有可能是表设计不合理，或者SQL语句写的不好，当然也有可能是基础设施的问题。DBA在选择一个基础设施的时候，需要考虑的是：（1）基础设施对性能的影响，（2）性能的指标监控和故障告警。
-
可靠性（Reliability）：包括数据库实例故障和数据损坏（Data Corruption）。数据库本身虽然有一定的机制来容忍基础设施的故障，比如redo log；但常用的关系型数据库管理系统（DBMS）毕竟是多年前的传统设计，可能禁不起折腾，如果基础设施可靠性故障太多，依然可能会导致数据丢失。
-
高可用性（High Availability）：数据库的高可用机制包括本地的高可用和容灾。其实现方式有数据库本身的机制（比如Oracle ADG、RAC），也可以采用基础设施层面的方式（比如vSphere HA，以及存储层面的复制技术）。各自有一些优缺点，下文中我们展开说明。
-
容量规划和可扩展性（Scalability）：数据库实例需要配置多少的CPU和内存，数据文件需要多大的磁盘空间，partitioning和sharding，这些在数据库创建初期以及后续的扩展中都需要考虑。当扩展的时候，可以通过在当前实例中增加资源实现垂直扩展（scale-up），也可以通过增加新的节点实现水平扩展（scale-out）。
-
安全性（Security）：数据库安全包括非常多的方面，比如数据库授权、认证、证书、应用防火墙等等。当和基础设施结合的时候，主要考虑基础设施层面的入侵防御。
-
数据备份与恢复（Safety）：数据库的备份与恢复是每个DBA的必备技能，大致方法都是使用数据库本身提供的备份机制，比如Oracle RMAN，差别不大。但是在不同的IT基础设施中，仍然会有些许差别。
-
安装、配置与升级：这本是DBA最基础的工作，针对于不同的IT基础设施，其方法和便利性依然有所差别。
-
数据库服务（Database as a Service)：企业通常会有很多应用需要数据库服务，在过去的场景中，很多都是各自为政，但是带来了很多运维的问题，所以很多企业在做DB consolidation。微服务的场景中，提倡数据库逻辑解耦，避免多个应用在共享数据库，并且每个微服务根据模块本身的需求进行选型和设计。DBA如何为应用提供database as a service，这其实是一个看似简单，但实际却很复杂的话题。
-
商业技术支持：虽然这是最后一点，但是可能却是最重要的一点。在遇到问题的时候，可以获得及时可靠的技术支持，是每个企业都需要考虑的重要方面。