服务器在线10月16日报道 LGR电讯公司拥有一个容量为310TB的甲骨文数据库，供其电信运营商客户端的2500名人员日常使用。 这个数据库提供了一项名为CDRlive的LGR服务，运营商用户可以通过这项服务访问呼叫数据记录。这个数据库日夜不停实时更新，一年365天保持全天24小时供查询之用。
LGR电讯公司主要向电信行业供应数据库软件和服务，公司的首席架构师Hannes van Rooyen表示："数据库不可能按批作业，每天都要新增130亿条记录，由于在线更新进程与用户查询的数量是一样的，因此它每天需要更新130亿次"
这个数据库保持超过1PB存储容量的磁盘运转，这个数据库容量在过去的四年里已经增长了十分之一。预计明年至少会增长一倍。
大部分企业的数据库容量不会超过数百TB，但是它们也面临着与LGR电讯公司同样的数据库问题，即数据量暴增、用户数量增长、查询越来越复杂以及快速变化的信息等。面对数据库可选厂商数量的不断增长，对于多数公司来说是时候重新评估他们的数据库战略了。
新一代数据库看起来与LGR电讯公司的数据库大致相同，它们都以相当快的速度不断增长，变化多元化，需要能跟上公司事务快速发展的关键业务流程。 不管你的公司拥有250GB还是250TB的数据，你都会面临同样的问题，那就是你是否拥有合适的体系结构？ 它是否是合适的平台？ 数据库的空间是否已经快要满载了？ 新的用户能使用什么服务？ 如果从批量加载模式升级到持续更新模式？ 技术发展日新月异，我们如何知道我们的系统是合适的系统？
所有上述问题都与管理可升级性有关。 控制可升级性也许意味着接受并行进程和Teradata与IBM等厂商提供的平面扩容体系结构，目前甲骨文和微软等厂商推出的新产品中也具备的这些新功能。 这些产品还需要对现有的数据库进行更有效的管理，包括量化需求、评测备选解决方案以及提前做好潜在问题的预防工作。
可升级性的多元化
三大关键趋势都集中在如何推动数据库经理人所面对的可升级性挑战，而且这些挑战的难度还在不断增长。首先需要解决的问题是大家众所周知的：数据量的快速增长。根据WinterCorp咨询公司的市场调研显示，最大的数据库每隔两年就会翻上三倍。
由此可见LGR的数据库增长的是如何的迅速。到2012年将接近3PB的容量。包括零售业，卫生保健和金融服务公司运作的数百个其他类型的数据库也将在接下来的几年中达到PB的容量，上千家数据库的容量将超过100TB。在很多情况下，竞争的压力迫使企业收集和存储更多的数据，这样他们就能更好的进行分析，了解，争取和保留最具价值的用户。
数据库对时限的要求也愈发敏感。LGR数据库中数据的周转速度就是佐证：每天进出的数据记录达到数十亿条，几分钟之内就能载入数据库并且立刻就能发挥作用。如果移动电话用户由于使用问题来电咨询："我们需要查证到底发生了什么，涉及什么问题等等，此时用户还在电话那端"van Rooyen这样说道"同时，你希望客服人员能知道用户的使用记录"，只有这样，问题才能很快得到解决，用户能得到更好的服务，企业也能更好的运转。
数据的高频率使用也被称为"运营商业智能"，这不是个新兴的概念。Teradata公司早在几年前就推出了被称作"战术数据库"的产品。IBM公司的动态数据库也是采用即时数据的类似概念。但是企业所面临的扩容压力还是在不断增长。
战术数据库帮助员工必须立刻做出决定。这些决定中有许多都是比较类似和重复性的。我应该向这名用户提供什么服务？我该如何对待工厂发生的非预期性出货？企业通过随时更新的数据系统的做出决策，这样就能得出更好的结论。
运营商业智能的概念对数据库扩容影响深远。它带来了更大规模的用户群；更高频率的数据使用；最新数据的需求以及不能容忍任何宕机的业务流程支持。
第三种趋势就是数据的复杂性日益攀升，数据查询，工作负载和分析都急需扩容。当数据库只从事比如预告更新和直接报告等简单工作，他们能在不产生新问题的情况下稳步增长。但当数据库需要对复杂的非预期性查询做出交互反应时，特别是要对上万亿条记录执行大规模的复杂连接，汇总，分类和计算时，扩容的需求就更加迫切。
多数现在的数据库都要执行复杂查询，分析和报告。这些数据库比过去实施的任务和计划更加复杂多变，用户要面对数千个表格，成百上千行还有数据之间交错复杂的相互关系。
增长元素的多维化
要阐述多维增长现象没有比易趣更好的例子了。易趣公司体系架构和运营部门资深总监奥利弗.瑞伯杰表示，易趣公司数据库执行的查询中大约有85%都是试探性的。这些查询多数都来自终端用户，数据库管理员几乎没有机会来应用调整工具。瑞伯杰表示”这些查询要用到搜索引擎，我们必须保证引擎的运转”。
易趣公司的数据库中包含了将近5PB的磁盘存储空间，分布在主要系统和二级系统中，这两个系统都能运行TB容量的数据。用于灾难恢复的二级系统离主要系统的所在地有1,000英里的距离。每个系统都有公司数据库核心数据的完整副本。两个副本都每隔15分钟就更新一次，24小时昼夜不停保持运转，可以连续进行激活服务查询。
每天都要超过5000名用户进行将近1000万次的查询。每天日常更新的记录数量从100亿条到150亿条不等。会涉及到数千个表格，查询从简单的查找到持续数小时的复杂分析都有可能。系统面对每个不同级别的工作任务都要采用不同服务级别来持续管理混合的工作负载。
系统扩容的增长速度也更加惊人：去年易趣的用户数量增长了25%，查询的数量翻倍。系统的规模在过去的四年中每年都至少翻了一番。
易趣的经历说明数据库不仅是核心数据数量的增长。他们会立即向多维扩展，包括数据量，用户的数量，查询量，数据延迟和数据查询的复杂性。基础架构和支出的决策必须考虑到所有这些方面的增长因素。
规划五步走
显然不要向企业经理人灌输增长的多元化概念。他们将系统扩容作为简化购买系统和数据库能力的方法，这样就无需担心多维增长的问题。他们期望数据库的增长不会导致成本的激增，企业商业活动的无理由中断或者性能的巨大损失。
听起来有些可怕是吗？下面的五步走计划能帮助大家应对愈演愈烈的数据库增长和满足企业对系统扩容的期望值：
1。开发量化需求。根据文件的量化需求来制定系统的，可测算的工业流程。这些需求应该包括数据规模的运转评估，数据库和工作负载的宏观架构，服务级别的对象和运作进度表。这些关键性的输入能为开发物理数据库和评估可选对象提供大量的所需信息。
数据库的宏观架构涵盖了大型表格的结构和可能的规模，最常用的相互关系的可能设置以及最具价值的数据的可能分布情况。工作负载的宏观架构包括了10到25个查询或者主要性能挑战和预期频率中所占的处理类型。
在进行评估时，关键的一点是对这些数据进行实践，绝对的精确远不及扩容要重要。正确的扩容就好比你要明白你是要建造一辆客车还是一辆货车。不用太快决定这些事情：包含一组数据的文件，和决策者商量评估内容，然后将他们用于管理流程和体系架构的决策当中。
2.预测长期需求。只要几年时间，你的数据库可能就会比现在所用的扩大几倍。要对数据库的长期需求做出正确的预测，将最新应用软件，扩展的目标领域，数据细节的额外标准以及新用户，新工具，新数据源等各种因素考虑在内。长期需求应该定义出系统将如何与扩容的每个方向一起成长。
不要妄自推断现有的增长率，因为他们无法反映出技术和支持主要新机遇的实践活动的变化情况。在零售业领域，当销售报表出炉时，数据扩容就会出现爆炸性增长，当网络点击数据也会增长数据库容量。在供应链领域，如果RFID全面配置后，系统扩容的下一个大动作就将来临。根据过去的趋势进行推断可能会让未来趋势的影响大打折扣。
3.关键风险确认。文件需求的流程无论是与厂商，用户，文献公司还是咨询顾问有关，都应该提高风险意识：”如果不能及时载入数据就会损失金钱”或者”如果我们在周末出现宕机或故障，我们就完蛋了”。
并非所有的需求都是同等重要；要把优势兵力集中在那么对于企业目标至关重要的需求上。对于欺诈侦测应用软件来说，不管任何情况下都要在几分钟载入数据或者几秒内接收数据是很关键的。除了高峰时间要实现这个目标是很简单的，然而要定位欺诈的准确时间才是最关键的，否则就会花费很多的金钱。因此在高峰时段 快速提取数据成为关键因素。在其他领域，反应时间可能很重要，比如面向用户的查询等。如果在进行一个中等难度的查询时用户正和呼叫中心服务人员交谈，那么可能要开一个两秒钟的窗口。这可能就成为一个风险。
当数据量小和使用明确时，需求就比较容易得到满足，但是如果第二年数据量发生爆炸性增长会发生什么呢？窍门是关注流程的两大特点：忽略那些可能导致业务损失的目标，忽略没有证据支持的目标，因为这些都有风险。
4.根据目标决定解决方案。这一步很关键。根据需求可能面临的主要风险去选择解决方案，然后量体裁衣进行开始开发。
对于这个步骤，扩容和复杂性都是很现实的。不要忽略扩容的多向性。根据真实的完整数据库运行工作负载的现实模拟，将未来三年内可能涉及的应用软件的运行情况都考虑在内。
5.管理缺口。真实的分析和测试经常能反映出数据库无法满足所有的需求。如果是这样，在它成为问题之前就把现实情况传达给决策者。通过对备选方案的评估，你可以使用备选方案进行真实数据的讨论。在目前可行的预算下，用户能接受4秒的反应时间吗？或者他们将预算增加50%，反应时间就能提高到2秒？我们应该利用公司使用量不超过10TB数据的标准平台或者花费3个月时间来评估其他的备选方案，如今我们是否了解数据库里的数据可能在一年半时间里会超过100TB？
一项系统的工程方法会让一切都尽在掌控。随着数据库需求朝着六个不可思议的方向快速膨胀，我们要为已有的成果提供备选方案。那里面临更高的风险，你就要对那里的数据进行分析，测算和建立可靠的风险规划。决策者要及时调整和讨论数据库的更新换代，为可能的损耗做好准备。
实现扩容
为应对多元化数据库增长而设计的新技术趋势死面向高度并行体系架构的。上个月甲骨文公司宣布的Exadata Storage Server就是针对保护数据流免受风险侵袭而设计的，它能提高输入/输出深度任务的执行速率。微软公司也透露说他们将在新一代SQL服务器中融入去年早期收购所得的DATAllegro技术，从而改善服务器输入/输出带宽和处理器并行处理能力。几乎每家厂商都在积极开发低成本硬件设备。虽然大型的对称多处理器服务器暂时不会从我们的视野中消失，但人们更加偏重和青睐可平面扩容的体系架构。
在二十世纪九十年代，常规的思维认为大规模并行处理还只是小生境体系架构，主要用于特殊时期的极端需求。但是大规模并行处理逐渐变的更加可靠，易于管理和可用，一时间几乎每家厂商都对可升级性充满期待。因此无论你是称它为大规模并行处理，集群或者其他什么，并行体系架构都成为数据库研发人员首选的方式，他们想通过并行体系架构来实现数据库扩容和应对快速发展的体系架构。需要铭记的最重要的事情是企业的难题无法通过购买新的硬件设备或体系架构来解决。他们必须通过解决方案的需求决策来解决，然后执行满足这些需求的系统。
为了实现数据库扩容，要遵循任何数据库研发计划的三个推荐：使用系统的管理流程来处理升级问题。避免升级管理中的七个想当然。重视量化需求和对研发周期的每个步骤进行测试和评估。有了系统的方法，你将实现企业的期望和拥有具备长期商业价值的可升级数据库。
