首页 > 开发 > 综合 > 正文

你的数据库升级吗?

2024-07-21 02:39:23
字体:
来源:转载
供稿:网友

  “换数据库?我们可没想过,换一回数据库麻烦可多了,配套设备都要随着换,人力物力投入多,换个驱动程序就得4~5万,总花费要好几十万,耗时也长,其实对企业来说安稳是最重要的,没非凡需要还是别换。”泰康人寿负责技术的蔡总这样回答。
  
  “数据库还用换吗?选数据库就像选老婆,没结婚时要全面考察,下定主意后就应该睁一只眼闭一只眼,差不多就得了。”启睿北创公司数据库DBA小李这样回答。
  
  “在评估潜在的解决方案时,客户永远不要仅仅局限于考虑可见的软件成本,而应该考虑长期部署和治理数据库的真正实际实施过程中的成本。”IDC的分析家Carl Olofson这样回答。
  
  在信息时代,数据库就像汽车上的轮子和飞机上的翅膀,虽然它们都很重要,但是企业在购买和升级时也不能不计算投资回报盲目进行。
  
  怎样比较数据库
  
  企业在购买或者升级数据库时,不可避免地会进行数据库之间的比较,那么决策者凭借什么进行决策呢?Amazon.com数据库系统和工程部总监Matthew Swann这样建议:“典型的比较方法是评测数据仓库的指标和环境分析方式,企业可以看一些有限定意义的指标,诸如处理能力,执行的数据查询量,生成的报告量以及支持的用户等,并把它们带入一个能够比较不同购买方案的方程式中。”
  
  假如企业已经运行在某个厂商以一定费用的价格提供的特定平台上,并且目前企业已经具有支持一定数量的数据查询、负荷、支持的用户等领域的处理能力,那么企业就可以与其它厂商或平台进行比较,这时,企业要着眼于数据库的处理能力和进行价格的比较,从而看出哪个厂商的产品更有价值。”
  
  换还是不换
  
  数据库对企业来说是基础设施,基础设施换必然导致其它东西随着变,一般企业,尤其是中小型企业一旦选择了一个数据库就不会轻易改变,即使在今后发现不怎么合适,也尽可能采取迁就的态度。那么到底什么情况下数据库就非换不可了呢?一般假如出现下列情况,你的数据库就要考虑更换了。
  
  
  在企业数据库损坏而现有数据库又不能进行修复的情况下。
  系统平台更换比如从NT到Unix,但是数据库不能跨平台操作。
  现有数据库不能适应当前的需要,也就是企业对数据库的功能需求改变了,例如要求存储数据的类型不一样了,比如要求存储容量增加了或者是以前的速度不够,满足不了很多个线程等等。
  安全性需求改变,非凡发生在金融行业。
  企业在衡量数据库是否满足企业要求时,该重点衡量什么呢?在这点上,IBM、Oracle、Sybase、微软等研发数据库的厂商看法基本一致,归纳起来就是要考虑到自身系统的扩展能力是否符合企业所在行业的发展方向;现有应用系统是否能满足企业发展的需要;现有系统是否满足电子商务的发展需要;而且不能只考虑追求采用新技术,还要考虑新技术是否适合自身的应用环境和发展需要。
  
  现在,大企业数据库更新的周期一般为10年,中小型企业为6年,小企业改造数据库需要大约半年时间,运作起来则需要一年。大多数企业表示在考虑更换或升级数据库时会考虑数据库的性能,比如要求大容量,稳定性好;其次是维护,要求能有比较好的图形界面来对数据库进行维护;最后是价格,要求越低越好,并且希望数据库能支持越多平台越好。而企业(非凡是金融行业)大都认为换数据库的困难在于如何保证数据的安全性,即备份和恢复,用户权限要分配细致等。所以数据库厂商只要在这几方面满足了企业的需要,数据库的定单也就基本拿到手了。
  企业怎样选择
  
  但是事实上,许多企业都是趁有了一个新的项目,而现有的数据库满足不了客户的需要时,才肯更换数据库。这样看来对数据库的第一次投资很重要,最开始选择合适的数据库以后就可以省去很多麻烦,还能节省大量资金。那么企业该如何选择数据库呢?最基本的标准就是:只需要进行单纯数据存储的企业可以考虑用免费的数据库平台,对数据库要求高的企业建议使用性能比较好的商业数据库及治理系统。假如选择商业数据库,就要重点考虑到数据库治理系统的总拥有成本。
  
  终生使用费用
  
  Sybase建议企业用户在评估潜在的解决方案时,不要仅仅局限于考虑可见的软件成本,而应该考虑长期部署和治理数据库的真正实际实施过程中的成本。包括软件的许可和维护成本、治理成本(人员成本、培训成本)及系统成本(存储容量、系统规模和类别、内存容量、高可用性)等。而有助于控制成本的三个重要特性就是,易于治理、对资源的有效利用和自动资源优化。
  
  少停机
  
  Oracle提醒企业决策者在购买数据库时要问自己,所要购买的数据库能达到怎样的数据可用性,即可靠性水平怎么样?以及停机会造成什么损失?有的公司可能只重视了产品成本以及工程实施成本,却轻视了维护成本以及停机成本,所以企业必须搞清楚你要购买的数据库在运行期间的性能如何。
停机时间也是投资回报的一个测量标准,假如数据库稳定地运行,并且很少或几乎不停机,那么企业就能看到生产力提高的直接效果。
  
  技术支持
  
  在技术支持和专业技术方面,几乎所有厂商和企业都认为,假如企业和一个经验丰富的厂商打交道,那就不必太担忧,运行数据库的每个企业在专门技术上都要依靠厂商,企业独立解决所有问题的想法是不切实际的。此外,一个数据库要存能和第三方的应用软件一起运做的能力,当然假如能与厂商为该数据库专门设计的集成应用软件一起工作是最好的,则不仅能提高可靠性和性能,而且还会降低成本。因此,企业假如希望在自己有的数据库上安装其它应用软件以支持企业业务发展,最好考虑到这点。除了治理方面的考虑,数据库技术方面的衡量指标也很重要。
  
  什么企业在用
  
  Sybase建议不同的企业要选择不同的数据库,企业首先要做到心中有数,到底自己要拿数据库做什么?比如针对电子商务的数据治理而言,数据库中先进的xml和java功能必不可少。因此,正打算采用电子商务应用的企业应该寻求功能强大的数据库治理系统,这种系统必须满足上述要求,同时还能提供动态的性能和开放性来实现全面的集成特性。假如企业想要既能够运行于小到支持移动用户的笔记本电脑,大到支持上千用户的Terabytes并行系统,就需要选择那种能在不同系统中实现一致功能的数据库服务器,使得用户能够做到多次使用,而不管应用系统的规模是大还是小,从而减少了用户的投资。
  
  可伸缩性和可用性
  
  企业选择的数据库在进行大中型应用,比如试图要集中企业所有数据时,要考察数据库是否采用实时应用集群技术(application Clusters),没有应用集群技术,用户在向应用中增加更多的计算能力时,通常需要技术部门在可伸缩性和可靠性之间进行折衷,需要花几周甚至几个月的时间来配置数据,最终才能使应用平稳地运行。这些挑战以及集群系统的成本和复杂性是集群技术直到现在依然保持着非凡市场地位的主要原因。借助实时应用集群,数据库在集群系统中能够作为一个单一的数据库系统,而不需要把数据分离在多个计算机中,因此,假如用户在集群系统中增加计算机,数据库能够自动地检索出新的计算资源并充分利用,使用户能够轻易地在集群系统中增加计算能力,同时有效地改进应用的可伸缩性和可用性。通过使用应用集群技术,企业能够从一台低端计算机服务器开始,随着企业对应用需求的增长而增加更多的计算机,每增加一台服务器,企业的计算冗余也随之增加,应用的可靠性也随之增加,最重要的是,无论在集群系统中增加多少台计算机服务器,都不需要对已有应用作任何修改。这种事实上无限制的可伸缩性和完全可用性使企业在不断扩展IT系统过程中节省了成本。但同时也要注重,假如企业没那么多访问量,即对数据库应用的需求是小型时,要集群技术也是种浪费。
  数据缓存
  
  通常情况下,数据库系统都在数据缓存中执行“先进先出”的更换策略,即数据库系统建立数据缓存的链表,最新使用的数据置入链表的高端(MRU),其它数据按使用次序放置,因此维持链表需要资源。这种治理策略对统一类型的应用是合适的,但假如系统运行混合负载,应用类型包括联机事务处理和决策支持时,该治理策略就不再适应。企业要选择那些可让用户根据实际情况选择灵活的数据缓存更换策略的数据库系统,使数据库对象直接绑定数据缓存,无须频繁更换缓存数据,节省系统开销,提高系统性能。
  
  商业智能
  
  IBM认为在考察数据库的商业智能方面,要看它是否能够提供具有强劲联机分析处理(OLAP)和数据挖掘技术的先进分析服务,使用户在建立商业智能应用时无需再像过去那样,先从数据仓库中采集数据,然后在专门的分析服务器中进行处理,它们可以直接在数据库中进行数据多维分析,有效地简化了多引擎数据分析基础架构的操作过程,从而能够以更简单的技术、更少的投资实现准确、及时的商业智能治理。
  
  数据挖掘
  
  数据仓库的数据挖掘功能是高级的智能化功能,但是现在还没有做得非凡好的,这也被业界普遍认为是趋势和潮流,现在有的数据库内嵌了数据挖掘算法,提供数据挖掘模型,使用户能够轻易地开发个性化的解决方案,对包括历史信息和当前Web网站交互信息在内的所有数据进行分析,产生全面、最新和最优化的决策建议,并答应最终用户通过Web浏览器访问实时的个性化信息。数据库具有数据挖掘功能就能大幅度地提高其核心数据治理能力,能够支持更大的数据量、更多的用户、更快的响应时间和更有效的数据抽取、转换和加载(ETL)功能。
  
  应用简单性
  
  微软认为提供简洁而不简单的工具是数据库应该做到的,数据库治理员在对过期数据进行治理的问题上面临着严重挑战,其中一部分原因在于,由于新工具或新用户以不同方式对数据进行访问

发表评论 共有条评论
用户名: 密码:
验证码: 匿名发表