站点维护数据库的架构需要有哪些？

同往常一样，你最佳界说你的需求，出格是，把那些超越你的范畴从而成为他人的问题的内容写成文档。若是这一步搞分清楚明了，你就帮了每一个人的大忙。你对详谁应该解决问题决议得越快，则谁人人为解决问题而做的估算和方案也就越快。以是，让咱们例建一个设想的web应用作为示例，非正式地把需求列出来。
咱们虚构的应用将是天天24小时一直在线。在流量大将会有浪涌和波峰，跟着美国的东西海岸起床时间差别，天天会有两次波峰。并且咱们的波峰足够高，从而能够在平缓期进行维护操纵，但不克不及停机，只能削减容量来做这些维护操纵。停时机直接影响零碎底线。未来，咱们会扩展到欧洲和亚洲，从而停机就更不行行了。会有时节性的高流量，在某些风行网站的首页也可以会提到咱们，从而招致流量骤增。不要紧逐个咱们可以将功用升级，而不是垮掉。
数据库的读操纵将占95%，而写占5%。大都写操纵都是单行的，会有一些庞大查询。这些查询会十分耗时，为了普及效力，不克不及不把一些汇总预先计较出来，或对某些数据做非规范化处置，这将是一个非十分耗cpu的过程。咱们将把这些耗时的阐明事情的整天职推到整天，如许一来，所用的数据会略微有些过期。有日时辰运用这些过期的数据是没问题的，而有的时辰，咱们不克不及不在一天以内对数据进行慢慢的增量更新。
数据库形式的问题尚未解决；应用尚未成熟，正在疾速开发中，包括数据库形式也在不竭变革。后果就是必需进行在线部署。从而不克不及不在出产环境中运转 alter table，作为更新数据库形式的例行伎俩，并且还不克不及影响可用性。咱们知道数据会愈来愈大，而alter破费的时间也会愈来愈长，甚至于长到没法忍耐。
连续增进的负载会跨越单台服务器的威力。能走多远其实不首要，由于只要三个数:零、1和多。无论怎样，咱们都不以为应用会增进到互联网的规模，以是咱们会思索几台到几十台之间的情况。
在必然范畴内的数据丧失是可以承受的。若是一台服务器消散了一段时间，将会损失一小笔钱，但将会无颜面临管理机构。不论怎么说，咱们仍是猛烈但愿数据库服务器是高可用的，请求一年的容机时间加起来不要跨越一天。由于，5分钟的宕机时间比损失5分钟的数据要高贵得多。

为了劫难恢复的目的，咱们请求数据库在最坏情况下能够恢复到昨天的数据，而在大都情况下，咱们当然但愿能够恢复到方才的数据，使损失的数据未几于几秒钟。但愿常规情况下恢复过程不要跨越一小时，而在最坏情况，如损失大量的数据或服务器，则但愿恢复时间未几于一天。
团队对数据库只要普通的威力，咱们的团队理论上是 ruby on rails的专家，以是高档的数据库问题仍是需求外部的协助。零碎管理团队也十分优良，但一样不太善于数据库。
记住这些，咱们来看看怎样知足这些需求。

易于胜利的事情
起头研讨特定的架构以前，我想指出一些需求方案划的事情，而不论终极的架构是甚么：
● 要做的第一件事是添加缓存层。memcached十分好用，运用 memcached可以为数据库减轻太多的负载，不消它简直太蠢了。
● 不要让用户发生异样情况，若有10000个摰友，或者1000张.照片。对付你以为本钱高贵的那些关键区域，要限定规模，不要容许无限定的增进，就能够将事情连结在合理的范畴内，而不会比及泛起问题时，再向那些招致异样的人发火。防患于已然，就不会泛起使人惊叹的事情，从而也就组成为了精良的用户体验的一部分。
● 看待需求要小心，不要将本身的网站制作标准立得高于用户的冀望，不要为应用构建过高贵的功用。显示搜索后果的准确数目，以及准确的搜索后果页面，就是一个经典的毛病。google不如许做，以是你也不需求如许做。