优化系统和产品的方法详解

　　今天我给大家介绍一篇关于优化系统的文章，希望大家喜欢，也希望大家可以做好相关笔记，接下来跟着我一起仔细阅读文章吧。

　　JaredRosoff在ScaleOutCamp发表了一篇简洁、有效、有趣和令人信服的《8分钟mongodb教程》描述了如何进行MongoDB优化。

　　文中的方法不仅限于MongoDB，还可应用到绝大多数数据库，比如查询优化、找出你的热数据、调整文件系统、选择正确的磁盘设备、分片。下面分别对5种策略进行说明：

　　查询优化：用B-tree搜索的速度显然比全表扫描来的快，所以你需要优化你的查询语句。用explain来分析你的查询语句，如果返回的结果现实这个查询用到了cursor那么它会是一个全表扫描，也就是说它会非常慢。分析有多少条记录会满足查询条件，以及查询会执行多长时间。改进的方法就是为其增加索引。不管你是有1台还是有100台服务器。

　　找出你的热数据尺寸：在数据库前面使用Memcached其实挺可笑的，因为现在内存很便宜，你可以使用大量的内存来缓存数据库内容，MongoDB就是这样干的。热数据=活跃记录+使用过的索引。在内存中命中数据是非常快的，而从磁盘获取数据就非常慢。假设你有上十亿的用户，但只有十万用户当前是活跃的，那么你的热数据尺寸就是十万条。你需要规划足够的内存来存放那十万条热数据，保证他们能够从内存而不是磁盘里读取，别忘了索引也是需要占用内存的。

　　这个模式最强调可用性，其次强调零数据损失保护。该模式使用SYNC(同步)方式传输redo数据，因此从备用数据库收到“redo数据已经写入磁盘”确认消息所需的时间会影响主库的性能。但是在主库出现故障时，通常可以百分百保护数据。

　　然而网络故障或者备用数据库出现故障，将无法向备用数据库传输redo，而主库仍能继续接收新事物。配置最高可用时，其最长等待秒数有NET_TIMEOUT的值决定(默认30秒)，此后将放弃备用目标，即使仍然无法与备用数据库通信，也允许主数据库继续进行处理。当连接重新建立后，主库将强制切换一次日志，关闭currentredolog，防止在间隔再同步过程中redo传输进一步滞后。仅当在自动重新同步进程尚未完成前，主库又一次出现故障时才可能丢失数据。

　　调整文件系统：性能问题往往根源是在文件系统。比如EXT3已经过时了，请使用EXT4、XFS和其它高性能的文件系统。对于数据库来说并不需要每次访问都去更新文件，所以关掉文件的访问时间跟踪功能，不然会有很多不必要的磁盘写操作。在EXT3文件系统预分配一个2GB大小的文件是非常耗时的，因为它必须得在分配时完整初始化整个文件。

　　选择正确的磁盘设备：寻道时间是需要关注的问题，因为大多数时候磁盘的IO操作是随机的。寻道时间取决于机械臂在磁盘上来回移动的速度，磁盘的平均寻道操作能力是每秒钟能完成200次。高速磁盘之所以读取数据更快，是因为他们有更高的带宽容量，除此之外他们的寻道时间并没有区别。

　　使用单个磁盘时，你可以获得每秒200次寻道;而使用RAID0(跨多个磁盘)，3块磁盘可以让你获得每秒600次的寻道速度;那么使用RAID10(镜像+跨越)，6块磁盘甚至能让你获得每秒1200次寻道。所以要考虑用RAID来进行优化。如今的SSD存储就更夸张了，一次寻道只要0.1毫秒，是机械磁盘的50倍，更适用于随机的读取操作。

　　分片：如果你的程序性能很差，索引又建的不正确，磁盘设备的速度也很慢，那么单点的性能也就非常差了。改善这种情况的方法就是用分片来做横向扩展，分片可以让你把系统负责分散到由更多机器组成的高可用的replicasets集群。

　　数据将会按一定范围被切分成很多的区块，然后横向扩展到上百台服务器，上千次的写操作在被拆分后每台服务器只需要处理十来次操作。分片让横向扩展变得容易。

　　小结，大家看完本篇文章，有什么想法么？还有什么不懂的知识，可以登录课课家教育平台，我会为您解答！