数据那些事儿

起源

作为一个 php web 从业人员, 很少有人能跑的开 php + mysql , 同时也就意味着: 你就逃不脱 数据那些事儿.
曾经在数据这块非常的痛苦, 离职第一家公司交接工作的时候, 自己写的脚本挂了不少, 于是一个星期离职变成了 3个星期, 当时非常的不爽, 因为准备去的公司薪资翻了一倍, 这2个星期都是 钱 (坏笑)呀. 但是还和组长争吵了一番, 最好还给出了 也许我就是不是适合做数据 这样的结论. 现在想想真的很幼稚, 幼稚得连道歉的勇气都没有.
好歹经历了1年+的工作了, 现在想想, 当时确实太幼稚了, 跳来跳去, 只是换了不同的形式和数据打交道罢了.

大数据

我其实特别喜欢说一句话: 数据量到了几百万, 就不是mysql能优化了. 当然这样一个不加任何修饰的话, 在面试的时候被一个钻牛角尖的面试者喷过. 我简单的举一个例子:
一张表有2个字段: 自增id + code(数据格式为 char 8), code上面有索引, 数据量为100w, 数据引擎为 innodb, 你如果使用 join 查询所有相同的 code, 用时 2s. 这里可以简单的理解为 100w * 100w 的查询, 每一条都需要遍历到. 但是场景是需要查询其中几条或者几十条而已, 所以上千万的数据, mysql 还是ok的, 不过就要注意应用环境了.
我其实想说的另一层意思: 数据量到了一定量级, 就需要考虑更高级点的技术了. 基于mysql的查询无非就是那么几个:

1. 减少sql数量, 一个sql取得多个需要的数据
2. 索引是否得当(explain 走起)
3. 引擎是否对, 90%的场景都是 innodb + myisam

但是当数据量上去了, 瓶颈就出现了, 比如第一家公司使用数据仓库来存储非常大的数据量, 对外的接口和操作mysql没有什么差别, 但是同一个查询的速度几乎提高了 100%.
现在很多互联网公司本质都是大数据公司, 于是就火了2个东东: mongodb + hadoop. 在慕课网上面分别看了部分教程, mongodb 是nosql 中非常具有代表性的, 其中2个场景的应用中非常适合: 基于地理位置的范围查询 + 全文字符串检索. hadoop 其实更倾向于架构, 将数据分块存储在多台服务器上面, 既解决的了高并发的查询分发, 也解决的数据备份的问题.

爬虫

不是所有的数据都是放在数据库里面等着你分析.
爬虫的原理其实很简单: 访问url, 获取html源码, 在源码中正则匹配到所需的数据, 然后存到数据库中. 但是当数据到达一定量级, 框架的重要性就体现出来了. 框架的最大功能就是将爬虫的各个步骤分工, 简单的技术解释就是 同步单进程 -> 异步多进程. 不过值得一提的是, 大数据 + 多进程 会带来一个比较头疼的问题 -- 死锁.

来一张百度脑图: http://naotu.baidu.com/file/ace201847fdb8e85369a5424bec08ad4

最有效的爬虫逻辑是理解对面程序员在写页面时的逻辑, 这样才能找准主次

使用浏览器访问链接的时候是会执行页面带有的js的, 比如链接中的 # , 才会看到需要的页面, 实际页面的是什么使用 wget 就可以看到, 正确的链接应该类似这样的 ?pg=2(get请求)

网络包分析工具: fiddler, wireshark

• 重试机制

在处理 json/xml/数据库/文件 时都有可能失败, 所以需要 重试机制

my $try = 0;while(1){    eval{ };    if($@){ }else{ last; }    last if $try++ > 3;}