甚么是有掌握的网站数据库架构？

下面的数据库架构，以我的教训，是比力有掌握的。

单主服务器，多从服务器。
对付主要是读操纵的应用，传统的伸缩要领是对数据进行复制逐个有的时辰是多个复制这时候辰的伸缩可以很好地事情。运用复制从服务器分管主服务器的负载，并在从服务器上执行那些cpu耗时的操纵。
对付从服务器，要比你执行例交运维任务所需求的数目要多加一台，将这台服务器用于特定任务。从这台服务器上做备份，然后再将备份恢复归去，测试看有无问题。在这台服务器上运转耗时的cron功课，以对数据进行汇总，将这些汇总数据用于数据阐明的查询，然后将后果导出，再批量导人到主服务器。运用基于会话的读写分散战略，以分管主服务器的 select查询。这些事情要在应用程序生命周期的初期就起头做。假设一台从服务器失效了，将这台从服务器的事情转到另外一台从服务器便可，由于从服务器之间并无甚么区分。对这类简略的失效转移，可以运用各类负载平衡器来实现。
尽管这类架构很好，但依然存在一些使人头痛的问题:不易实现离线的数据库形式更新，由于常规数据库形式更新是在主服务器上完成的，在更新时会梗阻对正在进行更新的表的访问。而在 alter table号令复制到从服务器上时，复制能够会延迟，如许所分管的主服务器负载的数据就会过时或延迟。这类主-从架构很难自动实现主服务器的故障转移，由于主服务器和从服务器的设置是纷歧样的，以是，一旦主服务器失效，则必需手工进行失效转移。不外，这类单一故障点理论上其实不那末懦弱，跟着从服务器愈来愈多，从服务器的失效会比主服务器的失效更为常见。
主服务器一主服务器复制，外加从服务器。
这类体式格局理论上与ー台主服务器加多台从服务器的架构一样，但这时候辰主服务器自己同样成了从服务器。这类架构的主要优点是，在协同同的主服务器之间更易实现失效转移和失效转回。这解决了那些使人头痛的问题，如在线更新数据库形式。主要的缺陷是，向两台主服务器进行写人存在危害，会招致数据存在某种纷歧致性，这类纷歧致很难提防，泛起了纷歧致也很难解决。除非你出格小心，并运用特权级别进行限定，不然，简直就是期待着招致这类纷歧致的毛病的产生。
功用分区。
跟着应用的增进，这却是个好主见。将应用中本钱最高的那些部分移到特定的服务器或特定服务器的集群上，比方，将会话存储从主服务器上分散。我经常看到“会话”表吃掉了与其作用不成比例例的大量时间。为阐明查询另外建立一个集群，若是需求的话，运用一样的导出导人战略，将汇总后果导入主应用程序集群。将 sphinx或solr集群用于搜索。时间以及丈量工具会通知你，应用中哪些部分的本钱最高，若是预先不分明，则形成延迟的那部分就是了。这类架构对应用的支持会比力长久。
除了前面列出的有掌握的架构以外，我想下面的倡议更有掌握。同任何事情一样，一旦你理解了规则，就会经常发现规则被粉碎的情况，但我以为，除非有很好的理由，不然，这些设法不该该被丢弃。
失效转移和负载平衡。
运用负载平衡器，或者浮动的虚拟p地址。就像你知道的，失效转移是很难实现的。若是有高档的负载平衡器，就用上，或者运用平等的解决计划，即在服务器之间转移ip地址，若是做得适宜的话，这类计划很好，并且也不贵。
不消运用dns或应用程序逻辑。一块儿头如同很合理，但即刻就会酿成梦魇。运用dns查询p地址是没问题的，但不要运用dns去实现失效转移。换言之，将dns作为静态的零碎看待，不要依赖于更新dns、设置文件、应用程序中的代码或诸云云类的任何东西。
不要自动化得太多，只读服务器很容易实现失效转移，而可写的服务器就可贵多。不要试图构建自动化的失效转移。有些事情应该由人来完成。清晨3点被唤醒做失效转移，总比6点的时辰被唤醒，然后在接下来的3天没日没夜地试图恢复数据，要好得多。
acid依然是有意思的。
从一块儿头就运用全事务型零碎。非事务型零碎的假设能够曾经深深地植入了应用程序的代码中，很难查找与解决了。然后期再切换为事务型零碎，会招致不少贫苦，如死锁、锁等候超时，以及其余预想不到的举动。
高可用性请求疾速而靠得住的劫难恢复，以是在 mysql中，要运用 innodb作为存储引擎，但不要用外键、触发器、视图或存储过程，由于这些东西会招致复制问题、机能问题、备份以及其余不少问题。不要将 myisam用于读写数据，由于会招致劫难，而恢复起来则需求至关长的时间。
运用正确的工具。
对每颗钉子来讲，数据库均能够成为锤子。这可不是个好主见。不要使数据库处于关键途径上，如不要将其用于队列(队列不克不及很好地映射到数据库中，并且也是我看到的最多见的贫苦之一)。不要将应用程序的静态信息放入数据库中，如设置信息、可以放人缓存或应用程序代码中的静态查找信息、存储映像。数据库应该存储数据，而非应用程序自己。
将数据库简略化，由于这是最难于伸缩，也是最高贵的。尽能够运用文件和cron功课。比方，在存入数据库以前，将数据预先进行汇总。用简略的剧本或gnu号令行工具
做汇总，比用网站制作数据库快多少数目级!要细心研讨unix的核心工具，如sed、awk、sort和unqo这类做法，随从跟随 oracle或 sql serverl的世界中学到的做法比起来，简直就是对着干。在 oracle或 sql server的世界中，应用程序只是一种建立在大规模的数据库之上的浮现逻 辑，而数据库布满了表、视图、触发器、存储过程以及每回项微小的营业逻辑。对付庞大的营业应用，这类集中化的做法有时辰是适宜的，并且我自己就在如许的环境中事情过。可是，对付web应用，我仍是坚持我的概念:分散应用程序和数据库，将数据库仅用来存储和检索数据。