我在新浪微博上的一些技术观点(2010.5-2011.6)

电玩女神 2022-10-01 01:53 97阅读 0赞

**我在新浪微博上的一些技术观点**

新浪微博用了1年多，我的一些技术观点整理.

注册N久的sina微博，开始用用玩玩，不知道会写多久，想了解我还是到我的博客吧： [http://t.cn/h3nmq][http_t.cn_h3nmq]  
2010-5-2 21:36

博客写起来需要整理思绪，微博写起来没有顾虑，这是它们最大的区别的，所以我的理解是“博客展现更多的是我想做什么，微博展现更多的是我看到什么、听到什么和在做什么”。  
@cuteyejun：微波和博客有啥区别？？别告诉我说博客写的长，微波写的短。因为七年前我的博客（当时叫个人主页）就是写的很短的。 原文转发(2)|原文评论(7)  
2010-5-3 23:20

NoSQL只是现阶段的一个热点，它解决了现在一些大型网站部分问题，但是面对整个数据库应用技术，它只是一个过客，最终它的特性会慢慢融入到关系型数据库里。技术只是辅助，需求决定一切，如果连where条件都不能实现的数据库确切说不算是数据库管理系统，只算是一个KV式的数据存储系统。  
2010-5-14 00:16

算法是让机器做更多事情，架构是让机器和人取平衡达到同时做更多事情，算法一般可以不考虑架构，但是架构需要考虑算法。  
2010-6-20 22:21

今天一个数据库故障，可能是简单赋权语句激发了oracle的BUG，导致最后需要停机，启用备库，再重建主库。对于DBA可用性是KPI的一切，业务高峰期作业时什么事情都可能会发现，就像人在紧张时会范一些不可想像的错误。  
2010-6-23 20:02

上海世博回来了，最大的收获是极大地锻炼了自己的忍耐力，为了看一个馆，排队3个小时  
2010-7-19 12:11

软件开源原因： 1没有对手强，通过开源来吸引用户 2资源有限，希望通过互联网的力量来提高产品质量 3自己产品用到了太多开源的东西，由于怕开源协议带来纠纷，索性自己也开源 4开源的产品不是自己的主要盈利产品，无所谓，就当是为社会贡献 不过比较无扯的是一些人拿着开源的东西当自主研发。  
2010-8-17 12:14

半年的时间我感觉到一些变化与提高，主要是学习业务与了解数据库，做一些应用DBA工作，但这只是成长的基础，路还很长，接下来的工作会做一些基础方面的学习分析。一直相信没有基础功底去学习研究只会是跟随的前进，计算机体系架构就是技术基础功底之一。  
2010-8-26 23:44

现在魔兽争霸不死族越来越暗淡，怀念当年韩国5鬼的不死辉煌时代，不死族需要有更多的战术与英雄组合。  
2010-10-7 23:06

当一个人遇到许多自己无法预测的事时，就会有科学以外的想法。就好像做技术的，如果理论计算不出来，就会采用测试的数据参考。  
2010-10-13 09:08

MySQL的HandlerSocket plugin [http://t.cn/h91SeB][http_t.cn_h91SeB] 传统关系型数据库基于I/O考虑得比较多，而对于互联网一些特大型的应用并发处理需要考虑在CPU和内存方面的更少消耗。 如果SSD加速推进，基于IO成本设计的数据库模型需要做重大改变才能生存。  
2010-10-20 18:40

玉面飞龙的BLOG的文章：Who still RBO? [http://t.cn/h4Clj1][http_t.cn_h4Clj1] 发现一下不同的观点，相对RBO，CBO复杂了许多，同时也让SQL性能自动优化更智能，因此大多数DBA都认为CBO更好。但是我不认为RBO就是落后，因为有些时候RBO更稳定，开发人员更易于掌控。  
2010-10-20 21:16

面向程序员的数据库访问性能优化法则，终于整理出了第一版，后面还有很多主题要整理。 [http://t.cn/hbxlM9][http_t.cn_hbxlM9]  
2010-12-6 20:13

关于MDA，有感而发，不要总是和程序员演示生成了什么代码，多少代码之类的东西，因为现在的基础语言及框架也许就不适合于MDA，MDA要解决的问题是屏蔽代码，让程序员及业务人员用图形化的方式把系统架设出来。就好像用delphi拖拖控件就能生成界面，许多程序员根本不关心delphi生成的form代码。  
2010-12-15 18:46

昨天看完《让子弹飞》，看完后思考了许多，不知道片名叫“让子弹飞”是否合适，不知道姜文真正的意图，也许他自己也不想演清楚，因为太清楚了就不是艺术。片中的喜剧台词、XX片断、枪战镜头都只是为了符合大众的表面味口，深层的东西只有自己去思考。  
2010-12-23 12:20

《再次写给我们这些浮躁的程序员》 2010年初写过一篇博客（我们是一群和平年代充满浮躁与抱怨的程序员），一年过去了，社会好像更浮躁，也有网友问我这方面的问题，于是有了下面这篇文章，再次写给我们这些刚入行浮躁的程序员。 [http://t.cn/hGSM5j][http_t.cn_hGSM5j]  
1月29日 13:58

Oracle数据库表结构导出成Word文档工具(带源码下载)，希望这个工具能给大家工作带来帮助，想入门VBA的朋友也可以参考。 [http://t.cn/hqTiQR][http_t.cn_hqTiQR]  
2月15日 22:09

当一个系统的业务发展（或数据发展）小于摩尔定律，硬件解决性能问题成本更低，软件应该充分利用硬件特性，架构应该让系统更容易满足业务需求，而不是为了性能而限制业务。 当一个系统的业务发展（或数据发展）大于摩尔定律，系统需要在集群、算法、硬件技术上下功夫，架构应该多考虑可扩展性及性能。  
3月16日 20:38

计算机和人其实一样，当上了年纪就容易得病，最好的办法是让她减少负荷或马上退休，否则没人知道她是否有一天会不堪重负突然倒下。  
@阿里赵圣强-Vincent：最近硬件不给力，接二连三的坏，同一个存储前端卡三周内坏了两个。 原文转发(3)|原文评论(3)  
3月22日 09:12

昨天听系统服务化分享，感觉前途很艰辛，短期收益有限。对于经常变化的应用系统是否需要完全服务化需要进行可行性分析，其实感觉我们更多需要的是架构层次清晰，应用模块职责分明，基础框架完备。服务化可以让系统支持更多人的团队协作，但如果做得不好反而会让一些看似简单的需求却需要兴师动众。  
3月22日 09:33

今天做了一个愚蠢的数据订正，3个小时没成功，最后换成新方法后10分钟搞定。这是最失败的一次代码时间估算。  
4月2日 18:16

同意，关键在于架构师估算系统性能是否能满足业务发展的需求，过早与过迟调整都不太好。过早调整会引起开发成本与运维成本的增加，间接影响业务发展，过迟调整就不用说了。一个好的架构师是胸中有数，而不是变化无常。  
@Fenng：Scale Out vs. Scale Up，仁者见仁，智者见智。Scale Up 有的时候是很经济的事情，豆瓣洪强宁同学的观点我很赞同。\#QCon\# 原文转发(9)|原文评论(3)  
4月10日 11:12

我认为学习或者掌握一个东西只是一个过程，能干什么才是结果。从不羡慕满腹经纶的人，因为很多是纸上谈兵，利用知识解决实际问题才是王道，危机感和浮躁感更多是来自于自己能解决多少实际问题，而不是知道多少知识。我想没有实战能力的老师与公职人员是最具备危机感和浮躁感的。  
@grassbell：危机感和浮躁感：全身心关注工作，很少学习新的东西，虽然可以从工作中得到收获但危机感很重，担心会落伍；花很多精力去学新东西，但没有应用场景，很难深入，只是走马观花，会很浮躁，搅乱心态。关键还是平衡，还是要致力于本职工作，对新技术动向关注，需要用到的时候再去深入学习，要有这样的信心。 原文转发(12)|原文评论(5)  
4月24日 10:57

可用性太高太低都不是好事，太低客户不信任，太高成本高，如果一个企业要求可用性4个9以上，那只能说明这个企业真没事做了，技术人员瞎折腾，要建立高可用性一定会增加架构上的复杂，系统可维护性及可扩展性都受到制约，最终是技术人员和业务人员说我们的系统有多复杂，实现这个需求需要多少工程师配合  
@MarsC：Amazon 宕机股价却上涨，yahoo邮箱发布故障股价也上涨，apple天线门、数据门都是浮云，所以说可用性其实不是关键，业务是否吸引人，粘住客户才是王道 原文转发(25)|原文评论(11)  
5月3日 18:33

我们不需要摸不到的云，也许你现在还很简单，甚至不能称为专家眼里的云计算，那又怎么样，只要认为有意义就迈出去。我们的云是能要给大家用的，不要指望云能服务于大公司，MS,Google,Alibaba,Taobao,Facebook，他们需要的是超大一朵云，而且是自己也不知道什么样的云。  
6月13日 22:48

性能测试有问题，肯定是有地方要改进，但是性能测试没问题并不表示真实环境没问题。虽然经常说性能测试非常难搞，结果差强人意，但是对于高并发要求高性能的场景还是非常有必要的。  
@JavaCoding：庞大的系统前提下， 什么性能测试， 只是一张遮羞布， 复杂的系统之间的交互， 才是最可怕的。我的观点已经从微观的系统诊断走向宏观的整体性能识别上。 这需要大量的基础设施建设。感谢Dragoon团队的宏观数据建设。 原文转发(3)|原文评论(5)  
6月18日 10:40

关于表JOIN性能问题,我想表达一个观点,ORACLE做JOIN的性能很好,肯定比一般人自己写快,如果你的结果一定要用JOIN,从性能上分析用一条JOIN的SQL更好.有时我们把一条JOIN的SQL分拆成多个简单SQL,会增加网络交互,SQL解析,最后降低性能,带来的好处是模块化,为了减少表与表之间耦合,为系统扩展性设计。  
6月18日 11:05

首届中国互联网运维高峰论坛[http://t.cn/aK2icM][http_t.cn_aK2icM] 的主题《数据库性能量化》，主要想讲以下几方面内容： 1、硬件与数据库相关性能指标。 2、业务指标转变为数据库技术指标。 3、什么时候做数据库拆分？ 4、SSD将给数据库带来什么变化？  
6月19日 23:00

[http_t.cn_h3nmq]: http://t.cn/h3nmq
[http_t.cn_h91SeB]: http://t.cn/h91SeB
[http_t.cn_h4Clj1]: http://t.cn/h4Clj1
[http_t.cn_hbxlM9]: http://t.cn/hbxlM9
[http_t.cn_hGSM5j]: http://t.cn/hGSM5j
[http_t.cn_hqTiQR]: http://t.cn/hqTiQR
[http_t.cn_aK2icM]: http://t.cn/aK2icM