本文主要是从HBase应用程序设计与开发的角度，总结几种常用的性能优化方法。有关HBase系统配置级别的优化，这里涉及的不多，这部分可以参考：淘宝Ken Wu同学的博客。 继续阅读
博客搬家了~
-
量子新文
分类目录
友情链接
MySQL数据库InnoDB数据恢复工具使用总结
本文从实际使用经验出发，介绍一款开源的MySQL数据库InnoDB数据恢复工具：innodb-tools，它通过从原始数据文件中提取表的行记录，实现从丢失的或者被毁坏的MySQL表中恢复数据。例如，当你不小心执行DROP TABLE、TRUNCATE TABLE或者DROP DATABASE之后，可以通过以下方式恢复数据。 继续阅读
工程师进阶之路 四
工程师进阶之路 四 如何和“老板”沟通 我们是一线工程师的时候，和我们的直接技术管理者沟通是非常容易的。我们的技术架构、代码风格、系统扩展性、工程化全局考虑就是我们赢得信任和信赖的名片。但是随着我们的经验的日渐丰富、层级的提高，我们要面对更高层级的管理者的时候，沟通不是一件容易的事情，需要我们做更多的准备和精炼。 我们要获取资源，要获取执行方向的认同，我们必须建立和高层级管理者建立信任，给与他们持续并一致的事实称述。
只给事实
人不是机器，不是代码，我们有时候会不自觉的扭曲一些描述或者信息，让我自己看起来更能干或者让别人看起来不是那么好，有的时候甚至会在背后痛斥别人的不足。经过一次次的个人经历和重复犯上面的错误后，我知道了那样做是小人所为而已，古人说“君子之交淡如水”，从另外一个角度来解读，我认为君子间的认同和信赖，就是建立在相互沟通“事实“之上，而不是个人好恶。
清晰而不是事无巨细
在组织中，个人的层级越高所需的技术细节信息就越少，这时候需要的是更高层次的总结性信息。因此我们提供的信息应该是清晰和简洁的，更具体一点就是：
- 首先我们要提供必要的合适的上下文，这个是我们技术苦逼人最容易遗忘的事情，一上来就陈述和表达自己的信息，忘记了这个是给老板们听的，不是说给我们自己听的。
- 其次我们要提前归纳总结，把信息结构化，结构化的信息是最容易被理解而不会被演绎的；另一个角度出发，产出结构化的信息也会让我们更聚焦在”事实“之上。
- 还有就是更多的给出业务信息，更少的技术细节。
- 最后因为需要你给出的是持续一致的信息，所以一旦给出，就要保持，这意味着我们要谨慎作答。
经常会有这样的情况发生：在会议上，我们会被问及不清楚或者不知道的情况，也许是合作伙伴进度的，也学是团队里面一个人的细节情况的，或者是一个全新的技术领域或者业务点，我们要坦率的说明自己不知道，但要记住，同时我们要表述自己将会跟进刚才的问题，并且落实、汇报后续的跟进结果。
不要给意外
我觉得我最对不起我的老板的地方就是：我一直在给他意外（尽管现在要少了很多）总是让他处于救火的状态，谢谢他的宽容。总是在反省，总是在犯错。
老板不喜欢意外情况，尤其是那种需要他们在极短的时间内做出行动和决策的意外。我们要尝试去发现隐藏的风险，我总是对自己说我需要把技术男总是去挑刺别人的精力用到探究团队或者项目的风险上。
因为人的本性之一就是会倾向展现好的方面，扭捏的遮挡不好的方面（孔雀开屏我们看到的是美丽羽毛，焉知后面是光秃秃的屁股），在实际的工作中，我们面对比自己更高级别的人的时候，尤其会这样。
所以我们发现风险后，要及时称述出去，这是组织对我们的要求，我们要是没有这样的能力和正直感，我们对不起自己的位置。当然陈述不好听的东西的时候，肯定会让人不爽，自己或他人，但是我们需要这样的勇气。
陈述的技巧有很多，坦率的说我是非常不擅长技巧的人，所以我就给出一个原则吧：更早的提醒风险，总是比到事情最后发展到无法收拾再处理要好。
OBConnector —— 使用SQL访问淘宝Oceanbase 数据库
一、为什么开发OBConnector
在OBConnector之前，使用Oceanbase数据库必须通过OB项目组自定义的一套Java或C++ API。这给Oceanbase数据库在量子的使用带来三个问题
1． 前端开发人员必须学习OB API接口的使用
2． Oceanbase数据库尚处在不断完善的过程中，API接口也可能不断改进，这种接口上的改变会影响使用OB的旧程序的升级
3． 语言支持有限，要支持新的语言(如量子广泛使用的PHP,Lua)必须开发新的接口，成本较高。
OBConnector通过对SQL语言的支持解决了第一、二个问题，通过Postgres服务器端通信协议的实现解决了第三个问题。 继续阅读
大并发下的高性能编程 – 改进的（用户态）自旋锁
前言
多线程程序中，锁的使用往往成为系统性能的关键。在做地址可视化项目的时候，由于内存管理部分需要频繁的更新内存的引用计数，所以产生了使用自旋锁的想法，这篇文章我们从自旋锁的性能开始说起，由浅入深的给出了一种改进的自旋锁的实现。
工程师进阶之路（三）
工程师进阶之路 三
再谈沟通的策略
什么叫做策略，我的认识就是做事情的方法，有些时候光有很好的原则，而没有好的方法也是不行的。比如淘宝的”十月围城“事件。
哪些策略是我们在进阶之路上需要注意的呢？第一条，也是我感受最深的一条：
说”Yes“而不是”No“
我在做一名开发工程师的时候，尤其是处理需求的时候，我是经常被鼓励说”No“的。但是后来我慢慢发现，随着我越来越‘老’，我需要更多的说”Yes“了。
因为当我是一个按图索骥进行开发的一线工程师时，我的擅自行动,不加考虑的说”Yes“会让整体项目受到拖累，但是当我逐渐介入整体设计、架构设计和可行性分析的时候，我要做的事情更多是作为产品业务或者销售人员的咨询师，所以更多的情况是在深入分析需求后，站在尽可能覆盖需求的角度给出，尽可能合适的方案进行选择。
换句话说，我们的角色要求就是”找到一条可行的道路“。但是我经常会看到一些工程师在积累了一些经验和技术深度后，还是一味的说”No“，我只能在心里为他的提升暗自担心了。
不过我们一定要记住，这是一种方法，它是基于”客观、真实“的基础的，如果需求或者项目的确是不可行，通常情况是因为”法律“、”监管“和”承诺“的原因，我们一定要说”No“。有一点要注意的就是，不要混淆”资源“上的不可行和项目上本身的不可行，“资源”上的紧张我们可以通过进一步的讨论、协调解决的。
还有一个心理上的因素，也是很重要的，我们往往需要说“Yes, I can”才能让自己挺过一个个难关，正如林书豪的成功一样。“Yes”往往意味着坚持，不放弃。
不要急于申辩
在会议或者谈话中，我们越来越多的会听到对于我们的工作不利的或者不是那么正面的描述，这是正常的，而我们往往会出现一些不正常的反应，以我为例子吧，我就会想方设法的给自己辩护或者澄清干系，目的就是这个责任不应该我负。
后来开的会也多了，听到的抱怨和指责也慢慢多了，发现自己竟然慢慢“耳顺”了，汗，但是心静下来后，却听到、学到了很多以前完全听不到的东西，给了我很多反思的机会。并且由于我没有立马站在挑战者或者防御者的角度，沟通的顺畅程度也有了提升。
后来也从同事的反馈中学到了很多经验：听到不爽的东西的时候不要抱起双手，不要背过头去，反而要和对方有视线上的交流。传达你对对方的尊重和鼓励。
当然事情有两方面的，不是完全的“逆来顺受”呵呵。如果你接收到的描述完全违背您的“价值观”或者违背了公司的“政策”，你一定要及时澄清的。
对于我们技术人员来讲，还要有“协同进步”的胸怀，因为我们会收到更多的批评也会给出更多的批评，比如在技术评审、代码Review、bug跟踪、项目评审、资源协调等等。古人的“从谏如流”我觉得是一个应该学习的好心态。
在上述场合，在各种”批评“和“被批评”满天飞的情况下，我们一定要保持好一点：对事不对人。
这点说到很容易，做到却很难，很多情况下，我们做的是：你们是对事并对我个人，我是对事不对你们个人。而且很多情况下这是一个普遍的想法，“不急于为自己申辩”我认为是一个解决的办法，不要武断的把自己搅入对事情本身的讨论中。
做起来不容易，我们共勉。
mysql导入导出数据方法
摘要：在平时的mysql应用中，总会碰到导入数据，导出数据，当然有很多方法，这篇文章，主要介绍应用mysql\mysqldump命令进行数据导入导出，希望对大家有所帮助。
继续阅读
转载文章请注明，转载自：量子数科院[http://www.linezing.com/blog]。文章均为原创，版权归量子统计所有
