数据库作为IT系统的基础软件，有着非常重要的作用。那么，企业在使用数据库时，可以选择哪些方式呢？不同方法的特点是什么？本文将从使用方式、适用场景、未来发展、成本因素（人力、财务、时间）和风险点等方面进行探讨，多角度分析十二种情况（前六种是本地方式，后六种是云方式）).方法一：商业数据库+商业服务这是比较传统的方法。企业购买大型商业数据库软件，相应购买服务支持工作。这是过去三四十年来的主流使用方式。可以说也满足了各个企业的快速发展。只是随着近二十年互联网的变革，这种方式产生了不小的影响。这种方式适合传统企业，对数据库要求高，技术能力有限，未来发展相对固定。未来的发展会随着商业数据库的发展而改变。总体来说，未来云化的需求会对其产生影响。更大。此外，在国产化、自主可控等要求下，也会对这款车型产生较大的影响。成本因素从人工成本来看，整体投入不大，主要由厂家提供。自有人员主要负责完成审计、评价等工作。从财务成本分析，它是几个方案中相对最高的一个。经常能看到“某国有银行，年购库xxxx万元的消息”见诸报端。由于资金投入较大，这种方式一般仅限于大中型企业或某些特殊行业要求。就时间成本而言，它是比较小的。选择商业数据库+服务，是看重其多年的产品研发技术积累和成熟的商业交付能力。无论是产品成熟度、稳定性，还是服务支持等，一般都能在较短的时间内交付。风险分析技术风险：技术封闭不开放；不符合自我控制的要求。政治风险：如果是国外产品，也容易受到政治环境的影响。金融风险：容易被厂商绑架，经济投入不可控。人员风险：受厂家技术人员技术能力影响较大，自有人员无法承受，无法长期成长。功能风险：成熟的商业产品难以定制以满足客户的个性化需求；并且存在与其他组件集成的风险。转型风险：采用一个商业产品后，很难再对其他产品进行转型。其他说明商业产品，包括国内数据库和新兴数据库厂商。这两类解决方案作为商用产品的良好补充，在综合成本方面具有优势，但在产品功能和服务能力方面仍需进一步加强。毕竟和国外类似的商业产品和服务已经积累了40到50年。商业服务，除了原厂服务，还包括第三方服务支持公司。在后面的选择上，国外厂商的服务和国内厂商的服务还是有比较大的区别的。最近我们看到国内新兴的数据库厂商和第三方服务公司的合作，动作很多（包括培训、认证、交付等）。方式二：商业数据库+自助服务这种方式也比较常见。前一种方式，随着企业对商业软件使用的深入，对自身服务的需求变得迫切。通过建立自己的服务体系，可以更好地满足企业自身的需求。这种方式适合有一定技术积累的传统企业。未来的发展会随着商业数据库的发展而变化，总体还是比较稳定的。成本因素从人工成本来看，比前者投入更多。商业数据库产品推广多年，相关人才云集。因此，一般来说很容易招到需要的人才，价格往往也不会太高。这与背后的开源软件形成鲜明对比。财务成本投入还是比较大的，商业软件的采购成本占整体的大头。从时间成本来看，相比前者有所增加，但总体成本还是比较小的。这主要是因为商业数据库成熟的生态使得构建运维系统变得容易；而且在人才方面，也更容易补充。风险分析在风险方面与前者类似。其中，在技术风险方面，自有人员对商业产品的把控与原厂相比还有很大差距。当然相应人员的风险降低了，通过自有人员对产品的把控就更大了。其他注意事项在一些关键核心区域，还是建议使用原厂支持，降低技术风险。方式三：开源数据库+商业服务随着开源数据库的成熟，越来越多的企业开始使用开源数据库。但与商业数据库相比，开源方案对企业自身的技术能力要求更高。因此，很多考虑赶上开源浪潮的公司都采用了这种方式。适用于转型中的企业，从商业到开源，这种方式可以在一定程度上规避风险。但是，这通常是一个过渡阶段。从长远来看，还是要培养企业自身的服务能力。从成本因素来看，人力成本处于中等水平。与商业服务相比，其综合人力成本有所降低。财务成本投入普遍处于中等水平，但不同服务商之间存在较大差异。时间和成本的投入较少，但与商业解决方案相比，企业需要对商业服务做更多的技术调研。因此，在最初的评估阶段，往往需要投入更多的时间。风险分析技术风险：开源数据库本身的技术风险、企业技术选型风险和商业服务能力风险。人员风险：受厂家技术人员技术能力影响较大，需谨慎评估。功能风险：总体而言，与商业数据库相比，开源数据库在功能上还是有所欠缺。因此，这部分应该仔细评估。其他解释与商业服务不同。目前，在开源服务方面，各个厂商的能力参差不齐，没有一个相对统一的标准。一些开源数据库有所谓的“原厂”商业支持，但在国内普及度不高。方式四：开源数据库+自助服务这是一种典型的“互联网”方式，也是一种比较普遍的方式。适用于规模大、对企业定制要求高的场景。如果发展成熟，可以考虑向企业内部的私有云或数据库产品和解决方案方向发展，甚至对外赋能。成本因素这种方式的人工成本相对较高，但根据企业的使用规模和难易程度的不同，差异较大。开源数据库的发展也经历了一段时间，市场人才逐渐增多。但是，高端人才还是比较稀缺，人才成本也很高。在财务方面，主要体现在人力成本上。此外，还需要一定的基础设施投资，甚至可能大于商业解决方案的投资。时间成本相对较高。企业建立成熟的开源数据库运维体系需要一定的时间。风险分析风险分析与上述类似，突出人员风险，需要长期的培训和投入。方式五：开源定制数据库+商业服务这是方案三的特例，企业不使用原生开源产品，而是使用第三方公司定制开源解决方案，可能是纯软件，也可能是软硬件一体化.这种方法将针对开源软件的不足之处，进行定制化的改进，以满足企业级软件的需求。但这种方式，一般企业无法独立运维，需要第三方公司的商业支持。对数据库的企业级特性有很高的要求，而原有的开源数据库不能满足这种情况。非常适合短期内需要移除商业数据库的场景。随着国内对开源数据库的使用水平不断加深，越来越多的此类初创企业应运而生。非常看好这款车型未来的发展。成本因素人工成本主要来自第三方服务，一般不高。财务费用主要看计划的情况，差别还是挺大的。时间成本可以看作是一个纯商业的解决方案。风险分析技术风险：定制部分不开放，企业无法控制；此外，原始开源的版本变更可能在短期内不适用于该解决方案。人员风险：受厂家技术人员技术能力影响较大，需谨慎评估。转型风险：受方案限制，存在一定的转型风险。方法六：私有云+云服务最后一种企业私有化部署方案是基于云的折衷方案。受限于一些特殊国情，一些企业不能直接使用公有云，而急需类似公有云的平台能力。因此，一些云厂商或数据库厂商提供了私有云部署方案。可以简单理解为搬云回家。过去有一种说法，私有云将逐渐萎缩，公有云将一统天下。但从近两年国内云市场的发展情况来看，私有云发展速度的一些指标甚至超过了公有云。当我们现在谈论“toB”市场成为下一个蓝海时，这种模式也是toB服务市场的重要组成部分。这种方法适用于大型企业，从长远来看是有前途的。成本因素从成本的角度来看，人工成本投入并不大，主要取决于厂家的人员投入。在财力方面，虽然与大规模商用方案相比有一定的成本优势，但优势不是很明显。在时间和成本方面，它也比传统解决方案更长。毕竟这不是单一技术平台的更换，而是涉及到IaaS、PaaS等多个层面。风险分析的风险点除了财力之外，更多的是对厂商的技术依赖。这种方法比传统解决方案更加依赖。厂商一般会提供很好的私有云和自己的公有云解决方案；但对于其他公有云或者企业自有平台，就比较难打通。方法七：裸云+开源数据库+自助服务这是使用云的初级阶段。企业只使用云的IaaS部分，其余自建。这种方式可以充分利用公有云带来的弹性优势，将公司原有的技术积累延伸到云端。对于企业来说，这种方式也是最“顺利”的。甚至应用不需要做更多的感知，仍然像使用企业内部IT资源一样使用公有云资源。非常适合多云、跨云需求的场合。但缺点是无法利用云厂商的技术能力带来的附加值。成本因素从成本的角度，企业可以做到“最优”。在只使用裸机的情况下，完全可以按照“最低价拿到”的策略进行优化选型。在一定规模下，公有云还是有其价格优势的，更何况还可以充分利用其弹性容量，动态缩减，并根据企业的发展随时调整IT投资。人员方面，与企业自主运维相比变化不大。在时间上，由于底层交付速度的提升，还是有一定的提升。风险分析风险不大，只依赖公有云底层，很容易迁移到其他云厂商或搬回自己的。方式八：裸云+商用数据库+第三方服务/自助服务这种情况比较特殊。企业选择在公有云上构建商业数据库。但它并没有选择云厂商来提供，而是自主构建或者选择第三方厂商协助完成。这往往是一些中小型企业，其规模不足以支持私有化部署，应用依赖于商业数据库产品。企业要充分利用云的弹性，所以采用这种组合方式。成本因素财务成本主要针对基础设施层面，会低于自建。在人力和时间上，并没有太大的区别。风险分析风险在于部分商用数据库不支持云场景，企业存在一定的技术风险。要么有比较强的独立技术能力，要么依赖第三方服务商。方法九：云数据库（开源）+云平台服务这是云厂商推出的最“传统”的数据库服务，也是目前最流行的选择。云厂商基于开源数据库版本+自己的平台服务构建自己的数据库产品。其核心数据库与开源版本完全一致，各公司之间的竞争更多是平台服务能力。这种方式对企业运维要求很低，基本可以依赖云厂商提供的能力（个别高可用和容灾需求除外）。这个方案比较适合早期上云的企业，可以逐步摸索上云和原来方法的区别。在成本因素和财务成本上，与商业方案相比，无疑具有优势，但与独立开源相比，几乎没有优势。更多的是关于产品的快速交付、扩张和收缩方面的特性。此外，在人力成本方面，由于大大减少了运维工作，可以节省一定的人力，减少自身人员规模。在时间成本方面，也有所改善。风险分析数据库本身风险不大。毕竟使用的是开源的同一个版本，技术上可以迁移到其他云厂商。当数据库版本升级时，还可以享受相应的技术加成。但是对平台服务有一定的依赖，每个公司的能力不同，需要一个适配的过程。另外，运维依赖于云厂商，存在一定的技术风险。独立的技术能力会逐渐丧失。方式十：云数据库（开源定制）+云平台服务除了提供与开源一致的版本外，云厂商一般也会提供私有定制版本。它往往是基于某个版本的开源数据库的深度定制，针对某些特性进行了增强。当然，也有一些以反馈社区的形式回馈给开源（以后可能合并成新版本），但很多只存在于“云私有DB”中。如果企业对特殊场景（如限时抢购）或其他方面（如金融级数据同步）有强烈需求，可以考虑使用该方案。当然，使用也意味着与云厂商的深度绑定。另外，在平台服务方面，与上述情况类似。该方案比较适用于对数据库有一定要求，但原生开源版本不支持的情况。成本因素与以前的方法类似。风险分析风险在于绑定单一厂商，一般很难摆脱。这类似于大型商业数据库的情况。当然，你可以在应用端做一个设计，尽量减少对特性的依赖。另外，由于是定制版，未来开源版本的升级可能短时间内不支持，甚至不考虑支持，将彻底走向独立分支。企业也需要注意这一点。方式十一：云原生数据库（自研）+云平台服务一些大型云厂商，除了以上两种，还可以通过自研数据库来增加未来的产品竞争力。根据最新的Gather报告，更多云厂商的加入，也为整体数据库市场带来了生机。从预测来看，他们都一致看好云原生数据库的未来发展。与前两种方式相比，这类数据库诞生于云端，从设计之初就更多地考虑了云环境的特点，因此极具竞争力。当然，从目前来看，现有的云原生还处于“初级”阶段。未来，在解决了更大的扩展性和多读多写能力的问题后，将真正进入井喷式发展。现有各大厂纷纷聚焦这一领域，加大投资力度。对于企业来说，无疑是另一种选择，尤其是某些场景（如海量数据等），原生开源和扩展开源产品无法满足。成本因素目前各厂商都在不遗余力地推广，企业仍可从成本中获益；但从长远来看，还需要进一步观察。在人才方面，企业也需要一定的投入。毕竟这是一个全新的数据库。虽然云厂商提供了很好的交互平台，但是企业还是需要做一定的技术储备，所以人员还是需要一定的投入。从时间上来说，对于这个比较新的产品，需要做更多的测试和评估工作，所以需要更多的投入。风险分析风险与上述相似，甚至更甚。企业应用程序将完全依赖于供应商的产品。虽然很多标榜兼容开源或者商业数据库，但毕竟不是同一种产品。这也需要企业慎重评估。此外，兼容性、备份恢复、高可用、数据同步、跨云容灾等都值得研究。方法十二：云数据库（自研）+云服务+云托管平台。一些数据库厂商（如MongoDB）不希望云数据库市场被云厂商垄断，而是希望自己主导，构建不依赖于云厂商的独立生态。目前这种方法在国内见的不多，这里不做评论。
