高性能数据库系统规划与设计

高性能数据库系统规划与设计邓磊leideng@Database什么是高性能数据库系统？高性能数据存储高效的数据查询高伸缩性和高可用性

数据的安全…问题Database同学们选课、查分经常遇到系统访问缓慢甚至崩溃的情况…Database性能的决定因素Database如何构建高性能数据库系统？应用层面的优化数据库设计与配置优化操作系统和硬件优化

架构的优化应用层面的优化Database应用响应请求花费了太长的时间，真正的问题是什么呢？通常的瓶颈是缓慢的查询、CPU饱和、网络延时和文件I/O不能把性能方面的问题都归咎到数据库身上，一个糟糕的应用设计使你无论怎么优化数据库也弥补不了它带来的损失寻找常见的问题Database应用是否真正使用了它取得的数据？应用里执行了太多的查询？（ORM、嵌套）应用在毫无必要的时候还连上了数据库？应用连接到数据库的次数是不是太多？使用连接池了吗？使用缓存了吗？数据库设计与配置优化DatabaseSchema与Index优化设计不良或索引不佳的schema，能把性能提高几个数量级Schema的优化和索引既需要大局观，又需要专注细节。优化通常需要权衡取舍。如为了加快查询添加索引会减慢更新的速度；非规范化的schema能加快某些类型的查询，却让其它类型查询变慢数据库配置优化Database包括缓存大小、I/O调优、并发数等。具体的配置依赖于服务器的硬件、数据量、查询类型、响应时间、事务持久性和连续性等因素。不要期望改变配置会带来巨大的性能提升。提升的具体大小取决于工作负载，通常可以选择适当的配置参数得到两到三倍的性能提升。操作系统和硬件优化Database最弱部分决定了性能，操作系统和硬件通常也会成为限制因素（如CPU饱和、内存不够、I/O饱和）。CPU内存I/O（RAID、网络存储）网络操作系统Database架构的优化构建大型、高性能应用程序分散式数据库架构其特点是业务单一、单机单业务服务、无交叉关联、简单Replication机制、依赖硬件，数据的存储和管理均由单机实现。集中式数据库架构重点是放在数据库管理和存储上。特点是集群易扩展，功能多；数据存储与应用分离；数据库结构各异，业务连接和使用方式各异。分布式数据库架构其特点是不仅关注存储和管理，并且把应用也注重起来，提供透明应用和策略的数据库服务；自动扩容、节点自动分裂与合并。案例：

LiveJournal(LJ)的优化历程案例学习LiveJournal是一个综合型SNS交友网站，有论坛，博客等功能，由BradFitzpatrick始建于1999年4月15日，目的是为了与同学保持联系，之后发展为大型网络社区平台，是网友聚集的好地方，LJ支持多国语言。

LiveJournal采用了大量的开源软件，甚至它本身也是一个开源软件。在上线后，LiveJournal实现了非常快速的增长：2004年4月份：280万注册用户。2005年8月份：790万注册用户。2011年10月份：3300万注册用户，活跃用户218万。达到了每秒钟上万次的页面请求及处理。使用了大量MySQL服务器。一台服务器一台别人捐助的服务器，LJ最初就跑在上面最终问题出现了，网站越来越慢，已经无法通过优过化应用程序来解决的地步，需要更多的服务器案例学习两台服务器用付费服务赚来的钱LJ买了两台服务器：一台叫做Kenny的Dell6U机器用于提供Web服务，一台叫做Cartman的Dell6U服务器用于提供数据库服务。案例学习四台服务器又买了两台，Kyle和Stan，这次都是1U的，都用于提供Web服务。目前LJ一共有3台Web服务器和一台数据库服务器。这时需要在3台Web服务器上进行负载均横。案例学习五台服务器又买了一台数据库服务器。在两台数据库服务器上使用了数据库同步(Mysql支持的Master-Slave模式)，写操作全部针对主数据库（通过Binlog，主服务器上的写操作可以迅速同步到从服务器上），读操作在两个数据库上同时进行。案例学习更多的服务器有钱了，当然要多买些服务器。部署后快了没多久，又开始慢了。这次有更多的Web服务器，更多的数据库服务器。案例学习现在服务器基本上够了，但性能还是有问题，原因出在架构上。什么问题呢？架构的问题案例学习架构的问题由于增加的数据库都是以Slave模式添加到应用内，这样唯一的好处就是将读操作分布到了多台机器，但这样带来的后果就是写操作被大量分发，每台机器都要执行，服务器越多，浪费就越大，随着写操作的增加，用于服务读操作的资源越来越少。案例学习架构的问题我们并不需要把这些数据在如此多的服务器上都保留一份。服务器上已经做了RAID，数据库也进行了备份，这么多的备份完全是对资源的浪费，属于冗余极端过度。那为什么不把数据分布存储呢？案例学习用户分组把不同用户的数据分布到不同的服务器上进行存储，以实现数据的分布式存储，让每台机器只为相对固定的用户服务，以实现平行的架构和良好的可扩展性。每一个用户分配一个组标记，用于标记此用户的数据存放在哪一组数据库服务器中每组数据库由一个master及几个slave组成，并且slave的数量在2-3台，以实现系统资源的最合理分配，既保证数据读操作分布，又避免数据过度冗余以及同步操作对系统资源的过度消耗。案例学习用户分组案例学习改进后的架构案例学习需要注意的问题在数据库组内不要使用自增ID，以便于以后在数据库组之间迁移用户，以实现更合理的I/O，磁盘空间及负载分布。将userid，postid存储在全局服务器上，可以使用自增，数据库组中的相应值必须以全局服务器上的值为准。在数据库组之间迁移用户时要万分小心，当迁移时用户不能有写操作。案例学习其它问题Master-Slave模式的单点问题LJ采取了Master-Master模式来解决。所谓Master-Master实际上是人工实现的，并不是由MySQL直接提供的，实际上也就是两台机器同时是Master，也同时是Slave，互相同步。案例学习最终的架构案例学习Database寻找瓶颈基准测试(Benchmarking)测量衡定系统的整体性能，有助于判断系统的处理能力，揭示影响或不影响系统性能的因素。测试指标包括：吞吐量、响应