恍然大悟PHP和PYTHON和RUBY的关系

PHP和PYTHON和RUBY三者的关系简单的各用一句话来概括:

PHP一句话来总结就是:Quick And Dirty 
PYTHON用一句话来总结就是:Quick And Clean, But Not Convenient For Web Development 
RUBY用一句话来总结就是:Code For Fun And Quick For Web

发现和很多网友的IT历程一样,先经历PHP然后接触PYTHON跟着RUBY。

PHP必须会因为很多应用级的程序都用它,PYTHON肯定要精因为很喜欢它。。RUBY也许也会学好它听说帮助开阔思维。

当然。。其实没啥必然关系。。。

标签: php, Python, 关系, ruby

恋爱的诚信

 

        几个朋友的男伴都跑掉了。一个突然消失,一个突然放弃,一个拍了三天拖突然离场,理由是:「我不喜欢经常想着妳的感觉,像发疯。」

         很男人都不懂得处理恋爱,却需要女人的性和爱。看上一个女人,不经思索想见到她,很快便和她海誓山盟,共同建筑梦,毫不犹豫表达想在一起。可这份坚定和激情是意想不到的虚弱,经不起考验。面对现实时,发现原来恋爱需要细心、投入、付出、经营,放下自我和私欲,简单说,原来是需要承担和负责任的,比想象中麻烦。感到压力和无力,错误估计了自己能投入爱的能力时间,无法平衡惯性的自我放纵和包庇(误称为「自由」)。强壮的男人在这关头会求进取,自我革命;软弱的男人只想到自己,想放弃,选择逃跑,怕面对对方,更怕面对自己。 

       逃跑的、消失的男人最伤害女人的不是他们的离开,而是没有种不交代,制造了创伤。创伤,是因为那不只是女方自制的痛,而是因为信任了共同承诺的恋爱意向,对感情和关系有合理期待和投入,可尊贵的爱突然被背弃,真挚单纯的爱被诱骗,没有被尊重,叫你自行负责被出卖的情绪打击。这伤害不是天灾也不是无常,而是来自弱者制造的人祸。

        发现无法承担关系不是罪,但应承担和交代,善后才离场。无能做个好恋人,也应做个好男人

关于NoSql的学习

1.主流的Nosql 数据存储系统

facebook、twitter和digg使用的cassandra

日本前两位的社交网站使用的 Tokyo Cabinet、Tokoy Tyrant (TT)

   提供更加丰富的查询的mongoDB

 

2. Nosql 能做什么,有什么特性

通过数据分区复制来达到高可靠性(High Availability)和高可伸缩性(High Scalability

以文件的形式同样可以满足海量数据存储(Huge Storage),cassandra在数据达到

各个节点是对称的,没有中心节点,这样就保证了不会出现单点故障(有中心点就存在中心点down掉的可能,这时候所有的应用就不可用了)

 

3. Nosql 不能做什么

关联查询,以cassandra的hector为例,必须通过自己生成的ID来做分布操作,查询时也是分两步查询




Java代码


  1. 我们可以先生成一个uuid 用于关联   
  2.   
  3. guid = post.first.to_guid   
  4.   
  5. 我们可以用如下类似外键的方式来做关联   
  6. multiblog.insert(:Comments, guid,   
  7.    {UUID.new=>'I like this cat. - Evan'})   
  8. multiblog.insert(:Comments, guid,   
  9.    {UUID.new=>'I am cuter. - Buttons'})  

 

模糊查询

group by 操作

order by操作

 

4. 基于如上的一些缺点,Nosql并不能完全代替了关系数据库,他在复杂业务面前显得脆弱无比,只能用于一些简单的业务。当然应该有方法解决如上一些难题, 比如order by应该可以用通过程序来排序,但是这肯定不是最好的方法,效率也不高, Nosql不能满足如上业务的根本问题在于存储结构过于简单,如果它也可以和搜索引擎的索引一样,能够建立8种文件的存储结构,肯定也是可以满足 like查询, order by操作的。这又和海量存储有矛盾,当一个value被存储成非常复杂的结构时,字节数会变的异常的大。

 

5. 培训中一些问题的总结和理解

(1) 做了一个hector的小例子,查询时报运行出错,而在linux客户端运行是正常返回查询结果的。

分析:说明连接的机器是没有问题,问题在集群配置上

解决方法:只启动了一台机器,却把副本数设置成了2,导致客户端java程序查询时会出错。

storage-conf.xml里面replicationFactor设置为1,重启,ok了

 

(2) 什么是CAP原理

这里是网上找的一个解释,CAP原理中,有三个要素:

  • 一致性(Consistency)
  • 可用性(Availability)
  • 分区容忍性(Partition tolerance)

CAP原理指的是,这三个要素最多只能同时实现两点,不可能三者兼顾。因此在进行分布式架构设计时,必须做出取舍。而对于分布式数据系统,分区容忍性是基本要求,否则就失去了价值。因此设计分布式数据系统,就是在一致性和可用性之间取一个平衡。对于大多数web应用,其实并不需要强一致性,因此牺牲一致性而换取高可用性,是目前多数分布式数据库产品的方向。

Nosql正式牺牲了这种一致性,而保证了其它两个方面,试验中可以看到,数据存储速度不是那么块,通常两秒钟以后才能得到数据。

 

(3). 当有5台机器,配置了2个副本,两个副本如何存储

采用一致性hash 算法(consistent Hashing),先求出服务器节点的hash值,并将其映射到0~2^32的圆上,然后用同样的方法求出存储数据的键的hash值,并映射到圆上,然后 从数据映射的位置开始顺时针查找,将数据存储在找到的第一个节点上,如果超过了2^32仍然找不到,这样就保存在第一个节点上。

 

这样添加了一个节点后,只有添加节点的逆时针第一台机器上的数据需要迁移。迁移量小。

 

(4). cassandra删除数据如何操作

Thrift是其自带的api,hector只是对其进行封装,删除是有相应Api的,只是不能保证数据立刻同步,但最终会一致的,前面已经说了它牺牲了一致性。

 

(5). Cassandra在数据最很大时,数据库文件可以分开吗?

这本身就是不存在一个表的概念,你可以将相同的数据结构定义为两个CF,对于没有定义两个,当文件太大的时候是否会分出来,节省读入内存的文件占用,需要研究。

 

(6). Cassandra负载是由客户端来处理吗?如果不是,那么客户端是如何知道从哪里取数据?

应该是由客户端路由的,需要进一步研究

 

接下来的重点是看代码,弄清楚原理,考虑是否可以对cansandra存储结构进行修改,是否可以解决如上的缺点