定义拆分策略.docVIP

案例分析 苏州安久云计算机有限公司 电话：051262398988 传真：0512地址：江苏省苏州市高新区科灵路78号12栋6楼 邮编：215163 目 录 一、引言 3 二、做好准备--Familybuilder面临的挑战 3 三、定义拆分策略 4 四、数据模型应用 4 五、可靠的复制 5 六、监控组件 6 七、性能 6 一、引言 想象一下——如果您有唯一一个通过拥有超过2300万家庭成员和1.5亿亲属的庞大的社交网络沟通家庭宗族的应用程序。您每天有5万个新用户加入，并且每天的访问峰值时间长达2个小时！您的系统的增长受到云系统I/O的限制。您已经听说您的竞争对手通过减少网站功能来确保网站正常运行。您需要一个可靠的解决方案，您并不希望减少功能而失去您忠实的用户基础，同时这套方案又必须非常经济。 面对爆炸式增长摇摇欲坠的Familybuilder公司与CodeFutures公司联手开始实施数据库拆分，如今，超过百万以上的家庭成员将通过一个隐藏在背后的“零共享——全拆分”的基础服务框架上进行联系。 二、做好准备--Familybuilder面临的挑战 Familybuilder团队需要一套解决云系统I / O瓶颈的方案。当ISP解决方案不能再扩展时，他们转向了云技术。回顾过去，首席信息官Dave Blinder说：“开始时，我们并不知道会用到哪些组件”。他们将大约1200万用户转移到了运系统，并且数量在持续增长。他们开始注意到云系统中数据库和存储设备之间存在大量的等待时间。Amazon帮助提高了一些性能。不过，I / O一直是一个难题。购买专用硬件将数据迁移回到传统的数据中心不是办法，成本过高。 他们评估了几种备选方案，不过大多处于公测阶段，还未经证实可行。他们与合作伙伴RightScale公司商讨，RightScale建议采用拆分策略。Familybuilder2评估了CodeFutures公司的dbShards套件并选择该产品作为解决方案。 dbShards解决方案被实施了。在扩展到24小时不间断工作模式后，Familybuilder2拆分方案不仅行得通，而且有效地打破了云系统I / O屏障。此外，该公司系统现在利用dbShards内置的可靠的复制机制，以支持业务的成倍增长，更低的维护时间、高性能的写写操作、并行化查询和快速有计划的故障切换。 关于Familybuilder公司请访问?。 三、定义拆分策略 第一步是确定一个拆分策略。dbShards支持多种拆分策略和算法。您可以按日期范围、按数字键值和用户自定义机制进行拆分。dbShards虚拟拆分技术考虑到了在使用选定拆分策略后，若干年内应用需求的预期增长。 Familybuilder2选择了按数字键值拆分的策略，允许对数据进行跨子库拆分，并且当未来增长有需要时，可以扩展到新增的子库中。如此一来，它支持“拆分”和并行查询共存，满足所有应用需求，提供比未拆分前好得多的性能。dbShards /并行查询（他们也称其为“Go Fish”查询）同时运行于所有子库上，为应用程序整合数据而不为用户所察觉，性能远胜于传统的单数据库查询。“Go Fish”查询和dbShards的其他特性一起，简化了数据库拆分，使应用开发人员能够透明地访问拆分环境，就好像访问一个单数据库系统一样。 定义好拆分策略之后，Familybuilder2马上利用dbShards独有的全局表概念，消除了跨子库联接。全局表支持常规的“维数”或对照表，并将其自动复制到各个子库，这对应用程序而言同样是透明的。 通过对指定的应用程序优化单个子库大小（通常为10G-100G）的方法，为使内存/ CPU之间达到平衡，数据的大小总是根据有利于高性能和高扩展性的原则不断调整。 以上各项落实后，Familybuilder2已经配置好了所有子库，数据库可以开工作了。 四、数据模型应用 通过几个开发团队多年的研究积累，Familybuilder的技术团队拥有了一个数据模型，并决定采用拆分迁移来完善该模型，以更好的满足应用需求。当使用一个有着超过30GB的数据、单一的数据库进行模型转换时，Familybuilder2的团队碰到一个难题：数据库重新配置时需要的停机时间过长（可能停止营业数天）。Familybuilder2利用高性能的dbShards/加载工具集和CodeFutures公司的专长，重新设计了数据模型，只用了传统现行方法所用的时间的很小一部分，就完成了丢弃、转换和加载整个数据库的任务。现在每个子库的加载时间只有短短的几分钟，所有子库是并行加载的。 到这一步，所有子库已经加载完毕准备运行了。Familybuilder2安装了dbShard