《大规模Web服务开发技术》的原文摘录

  • 1、GB级别的数据处理 2、内存的重要性 (查看原文)
    破军 2011-10-30 15:14:06
    —— 引自第117页
  • 3、以分布式为主的运维 (查看原文)
    破军 2011-10-30 15:14:06
    —— 引自第117页
  • 4、选择恰当的算法和数据结构 (查看原文)
    破军 2011-10-30 15:14:06
    —— 引自第117页
  • 压缩就是分析符号的出现频率,用短编码标记频繁出现的符号,用长编码标记其余符号 (查看原文)
    简体中文 2011-12-22 10:15:36
    —— 引自第127页
  • 通过基于Trie的正则表达式实现Common Prefix Search(公共前缀搜索) (查看原文)
    简体中文 2011-12-22 10:19:35
    —— 引自第112页
  • “%iowait”是 I/O 等待率。平均负载过高并且该数值也过高的话,可以认为高负载的原因就是 I/O 。 (查看原文)
    henix 2012-01-28 20:39:25
    —— 引自第47页
  • 操作系统启动之后,要先把经常使用的数据库文件 cat 一遍。这样就能全部放进内存中。 以后大家在工作中构建系统的时候,就要进行性能测试和负载测试。那时请记住,一定要把第一次测试结果放弃掉。刚开始时缓存尚未优化 (查看原文)
    henix 2012-01-28 20:43:11
    —— 引自第80页
  • 如果缓存不过来的话:就需要扩展到多台服务器上。CPU负载分散只需简单的增加数据库即可;IO负载分散则需要考虑局部性 (查看原文)
    libisthanks 2012-05-05 14:22:08
    —— 引自第69页
  • 感觉上而言 (查看原文)
    [已注销] 2013-01-28 14:41:00
    —— 引自第147页
  • <del>....</del> (查看原文)
    [已注销] 2013-01-28 14:42:41
    —— 引自第193页
  • 成长为大规模服务之后,一个人负责开发和运维当然是很困难的,所以要由多名技术人员分担。人一多,有些问题就不得不考虑了。例如,应当如何标准化开发?各个开发者随意进行的系统开发过程中,是不是该考虑一下应用程序实现方案?是否要统一编程语言、统一库函数和框架、统一代码规范使之标准化,并利用版本管理系统认真管理源代码呢?只有正确地实施这些,才能发挥多人的效率。胡乱进行的话,就算增加了人手,生产力也不会提高。 这种标准化绝不是仅仅选个工具就行的,而必须有人负责全局的推进。诸如每个开发者是否遵守标准化规约、是否存在由于开发者之间水平差异导致的低效率、新人应该如何培训等,都表明了团队管理的重要性。 (查看原文)
    tonight 2013-02-03 16:16:51
    —— 引自第11页
  • 首当其冲的就是“无法在内存中计算”。为什么说无法在内存中计算是难点呢?因为内存中放不下的话,通常就得一直读磁盘,在磁盘中找啊找啊还是找不到。数据量过大时,其输入数据量也相应增大,计算量当然也会增大,但比这更为严重的问题就是“需要读磁盘”。 (查看原文)
    tonight 2013-02-03 16:41:08
    —— 引自第28页
  • 处理大规模数据的三个重点------写程序的技巧 1、“能在内存中完成多少?”。为什么必须在内存中完成?如前所述,磁盘寻道次数极大地影响着可扩展性和性能。因此,应在最大限度减少磁盘寻道次数的意义上灵活运用内存。此外,还应充分利用局部性的分布式。 2、“使用能应对数据量增加的算法”。单纯使用线性搜索的话,1000万条数据就要计算1000万次,而使用对数据级的算法,只需几十次就可以完成。例如:线性搜索--->二叉树搜索; O(n)--->O(log n) 3、有时可以利用数据压缩和搜索等技术。通过压缩等方法缩小数据,以减少寻道次数,使磁盘读取次数降到最低,而且更容易缓存到内存中。太大的数据无法放入内存,就算保存到磁盘上,读取也要花费时间,所以压缩十分重要。 (查看原文)
    tonight 2013-02-03 17:08:07
    —— 引自第44页
  • 以Partitioning为前提进行设计 避免JOIN,利用where...in... (查看原文)
    tonight 2013-02-03 17:16:27
    —— 引自第102页
  • 稳定性措施 一、维持适当的余量(buffer) 1、内存容量、CPU负载--->使用到极限的7成 二、去除不稳定因素 1、规定SQL负载上限--->必要时将负载过高的SQL移到其他主机上 2、减少内存泄漏 3、异常行为的自律控制 自动Dos判断(mod_dossdetector) 自动重启(应用程序服务器和宿主操作系统) 自动终止耗时查询(KILL掉耗时过长的SQL) (查看原文)
    tonight 2013-02-03 18:46:43
    —— 引自第269页
  • 寻找瓶颈的基本流程: 1.查看平均负载; 2.确认CUP,I/O有无瓶颈。 1.查看平均负载 top,uptime等命令 2.查找CPU和I/O的瓶颈 sar; top; ps; strace; oprofile; vmstat (查看原文)
    流水秋鸿 2013-10-25 14:56:32
    —— 引自第33页
  • 学习负载均衡的重点是理解操作系统的运行原理: 包括: 操作系统缓存; 多线程、多进程; 虚拟内存机制; 文件系统; 根据操作系统的擅长和不擅长之处进行整体优化。 (查看原文)
    流水秋鸿 2013-10-26 16:00:57
    —— 引自第81页
  • 创建Dictionary 1将单词当做term处理 1.1 字典+ Aho-Corsick算法切分单词 1.2 使用语素分析(Mecab 等等) 2 将n-gram 当做term处理 (查看原文)
    流水秋鸿 2013-11-07 08:30:50
    —— 引自第206页
  • SSD的访问性能: 1.良好的随机访问性能; 2.内存>SSD>HDD RAID-0/10> HDD RAID-1 尽管不如内存快,但也十分迅速 3.Hatena的生产环境用的是 Intel SSD X-25E/m (查看原文)
    流水秋鸿 2013-11-25 08:46:04
    —— 引自第287页
  • 网络分界点: 1.超过1Gpbs(从路由器性能来看应该是30 万 pps)->PC路由器的极限 2.超过500台主机->一个子网的极限 由交换机的ARP表极限限制 3.全球化->一个数据中心的极限 网络架构的层次化(三层架构) 1.最小的为访问层(Access Area,一二百台) 2.上面是分发层(Distribution Area,1000台左右) 3.最上方为核心层(Core Area)或OSPF层(几万台左右) 超越10Gbps的世界 1.获取AS编号 2.连接IX进行流量交换 3.用BGP控制路由 (查看原文)
    流水秋鸿 2013-11-25 08:58:32
    —— 引自第297页