Tuesday, 17 de June de 2008
对于任何一个软件开发人员来说，架构师都是一个令人向往的角色。就连世界首富比尔盖茨在2000年卸任公司CEO的同时，也担任了微软公司的荣誉角色“首席软件架构师”，可见“架构师”这一称谓的吸引力。架构师是公司的“金领”，有着非常高的收入，很少需要考虑生存的问题，从而有更多的精力思考关键技术问题，形成“强者愈强”的良性循环。部分优秀的开发人员在工作了一定时间后，就要开始考虑自己的未来到底向哪个方向发展。如果开发人员的沟通能力强过技术能力，在补充一定的项目管理知识后，可以向技术管理的方向转型。如果其对技术一直很感兴趣，而沟通能力也不弱，则可以试着进一步加强技术修养，以期向架构师的方向发展，最终“修成正果”。
那么，到底什么是架构师呢？所谓的架构师，应该是一个技术企业的最高技术决策者。他主要负责公司软件产品或软件项目的技术路线与技术框架的制订。好的架构师都是善良的独裁者，具有很强的技术、良好的写作能力、良好的口头表达能力，能够在各个层次进行沟通。从开发人员到架构师的成长应该是阶梯式的，一般来讲开发人员在刚刚开始工作时只能开发简单的独立软件模块，慢慢的随着经验的增长，他开始接触一些相互之间有信息传递的模块，而后来，他会发现自己接到的开发任务已经不是一个独立的单体，这些任务由一些专门的软件部分组成，可能包含数据库，工作流引擎，消息服务等等各种功能模块，可能分布在不同的服务器上，所有的部分协同起来，完成软件功能。而这时候，体系结构的好坏将直接决定了系统的性能和可扩展性，而就在这时候，这名优秀的开发人员也开始思考架构师应该思考的问题了，或者说，他向成长为架构师的道路迈出了一大步。
什么是架构师最具价值的技能呢？就是要了解不同的知识，做一个“杂家”或者说“博学家”。当然，如果你的数据库技术非常棒，或者你在工作流引擎方面具有不可超越的专家知识，那也是很不错的。好的架构师有好多都是从专家成长过来的。但是，这不是架构师应该做的事情，架构师应该做的是了解所有的东西，既了解技术的宏观面，又了解技术的细节。真正的架构师不仅仅要了解软件，也要了解硬件，在关键的部位使用合适的硬件来取代软件，可以成倍甚至成百倍的提高整个系统的效率。下面我将会以互联网行业对的架构师的要求为例，向大家讲解作为架构师应该具备的知识。
互联网行业是当前最激动人心的行业之一，很多的创新都来自于这个行业，而每一个大型的网站如Google，Yahoo，Myspace等都需要解决一个非常复杂的问题，就是网站的分布式向外扩展(Scale Out)的问题。解决这个问题，需要最优秀的架构师对业务进行剖析，利用软硬件将网站进行重构，甚至根据业务研发相应的分布式技术，解决网站复杂的分布式计算的问题。如果你想在这个行业中成为一名架构师的话，需要至少掌握网络知识，硬件，软件，网站优化等方方面面的知识：
1． 网络知识。
当前的软件已经绝对不是那种仅仅跑在一台单机上的孤立应用了。不仅仅是在互联网行业，任何一个行业的软件，都要求其具有网络功能。因此，网络知识是架构师必备的知识。我们所说的网络知识，不仅仅包括TCP/IP，http等互联网行业常用的软件协议，也包括网络规划，甚至更具体的说，根据网站应用所处的地理环境进行网络规划。比如人们常说：“这世界上最远的距离不是生与死的距离，而是电信到网通的距离”（笑）如果应用是建立在中国的，就要考虑电信用户和网通用户访问网站的速度应该都比较快才可以。这时候的解决方案可能有多种，比如采用CDN（Content Delivery Network内容分发网络）使得网站的内容发布到离用户最近的服务器，又可以采用把服务器放在一些所谓的双线机房中，甚至将几种方案结合起来使用。这些都统统归到网络知识中。做为公司的架构师，要对这些知识都有所了解，才有助于在遇到问题时找到最佳答案。
2． 硬件知识。
了解硬件的极限，是架构师的基本功。我见过一些人，他们的眼中软件硬件都是没有极限的，需要资源就申请，系统性能下降了就买更高级的设备。然而，硬件的性能有很大一部分取决于I/O设备。而这些I/O设备依靠的都是机械物理运动，这种运动是有极限的。因此当资源访问量增大到一定的程度时，这种物理运动将成为瓶颈。比如说，在开发网站的过程中，记录访客的状态是一件很重要的事情，一般来说可以使用HttpSession来记录。而HttpSession的存储问题将是一个很大的挑战，尤其是多机共享Session时，将HttpSession存成文件并通过多机共享或网络备份的方式来解决分布式的问题是常用的方案，然而，架构师必须考虑到这种方案是有I/O极限限制的，很难扩展到超过一定规模的大型网络。同时，架构师应该了解目前最近的硬件发展是否对软件系统会造成一定的影响，比如在多核的条件下是否对软件编程有新的要求，是否会对运行在虚拟机和非虚拟机上的程序有影响等等。
3． 软件知识。
软件知识所包含的范围就更加广泛了。对于互联网行业来讲，架构师要了解操作系统，数据库，应用服务器等各方面的知识。比如说，如果网站使用的操作系统是Linux，就要了解这个Linux版本的性能与局限性，比如说最多可以存放的单个文件为多大。有的数据库的数据是以单个文件来存放的，虽然我们很少见到数据库中的数据多到不能再放入一条记录的情况，但是作为架构师，请时刻注意，这种可能性是有的。而且如果你有幸在一家高速成长的互联网企业中，而你所负责的应用又没有经过优化的话，可能你会很快见到这种现象。这种现象的发生可能是由于操作系统不支持大文件的原因，也可能是数据库不支持大文件。不论如何，架构师应该在这种现象发生之前就把一切都准备好。对数据库中表的拆分是架构师应该遇到的另外一个困难。一般来说增加应用服务器比较简单而增加数据库服务器则是比较复杂的问题，如果一个站点由多个数据库支持，架构师需要考虑如何在保证数据一致的情况下，让多个数据库分担压力。有些解决方案是将数据库的读写分开，使得大多数的查询sql不经过核心数据库，而只是访问数据库的副本，但事实上，这种方式也只能维护规模不大的网站。对于大型的网站来说，把业务分散到不同的数据库中，只共享必要的数据，才是合理的提高网站扩展性的解决方案。
4． 其他知识。
作为系统架构师，可能还需要对分布式系统，负载均衡，网络安全，数据监控等等各方面都有所了解。不仅仅是了解理论知识，也要对相关的产品和业界进展有一定的认识。比如说做负载均衡最好的产品是那种。目前最常用的备份策略是什么，有什么缺点。如何使用缓存，如何做好日志分析等等。
刚刚谈到的是架构师需要掌握的知识，然而，冰冻三尺非一日之寒。这个过程需要我们慢慢的积累。如果你已经进入到公司进行软件开发，请时刻关注你所开发软件的性能与可扩展性，而不仅仅局限在功能上，时刻想着任何一个简单的问题：我开发的模块如果放在多人并发的环境下会怎样，慢慢的就会有所心得。如果你还是一个在校学生，不要想着自己离架构师这个职位还很遥远。要知道，成为架构师的修炼之路是很长的，甚至可以说是终身的，因此早点进入学习状态，不断修炼自己。在学校期间学好离散数学，数据结构，操作系统，编译原理，体系结构，数据库原理等关键课程，并积极寻找机会到外面实习，增长自己的工作经验。如果有机会去到一些技术主导的公司中工作，就一定不要放弃这种机会，慢慢就会成长起来。最重要的，你会养成关注技术，勤于思考的好习惯。当有一天你发现自己对任何技术难题都可以一眼看到其本质，并能够将其分解为一个个可轻松解决的模块，你会由衷的感觉到知识给你带来的快乐，或许那一天，你已经是一个架构师了。
转载原创文章请注明，转载自：web蓝草博客–LanCao’s Web Blog[http://www.juuyou.com]
本文链接: http://www.juuyou.com/?p=112
Tuesday, 17 de June de 2008
MySpace.com有着6500万的订阅者，是因特网上增长最快的网站之一，每天还有260，000新用户注册。它经常因为性能问题而受指责，MySpace不得不处理其他网站很少碰到的或大或小的一些问题。它们是怎么做的呢？
Site: http://myspace.com
站点：http://myspace.com
平台
• ASP.NET 2.0
• Windows
• IIS
• SQL Server
内部运行情况？
• MySpace 每天处理15亿的页面页面查看，白天处理230万并发的用户
• 会员用户里程碑
- 500,000用户：简单的磕磕绊绊的体系结构
- 1百万用户：痛苦的垂直分割解决伸缩性
- 3百万用户：Scale-Out 胜过Scale-Up（按比例增加）
- 9百万用户：站点迁移到ASP.NET，增加虚拟存储
- 260万用户：MySpace拥有了64位技术
• 500,000 个帐号对于两个web服务器和一个数据库来说负担太大了
• 100-200万个帐号
- 他们使用了一种数据库体系结构，围绕着垂直分割的概念，提供不同服务比如界面登录，用户资料和博客等的网站的各部分都有单独的数据库。
- 垂直分割方案有助于分开数据库读和写的工作量，并且当用户需要一个新特征时，MySpace 将会加入一个新的在线数据库来支持它。
- MySpace 从直接使用附着于它的数据库的服务器的存储设备转换到一个存储区域网络（SAN），里面大量的磁盘存储设备由一个高速，专用网络联系到一块，同时数据库连接到SAN。到SAN的改变提高了性能，正常运行时间和可靠性。
• 300万个帐号
- 垂直分割解决方案并没有持续很长时间因为它们重复了一些水平的信息像跨过所有垂直片的用户帐号。有这么多的重复它会使系统变慢，肯定要失败。
- 个人应用比如Web站点子部分上的博客将会增长到对于单独一个数据库服务器来说太大的程度
- 在逻辑上重组所有核心数据到一个数据库里
- 把它的用户基本信息分成100万帐号一个的块，然后把所有有键的数据放到SQL Server不同实例的这些帐号中
• 900万-1700万帐号
- 迁移到ASP.NET后，使用了比先前的体系结构更少的资源。150个服务器运行新的代码就能够做原来246个服务器做的同样的工作。
- 再看看存储瓶颈。实施SAN解决了原来的一些性能问题，但是现在Web站点的需求开始间歇性地超过了SAN的I/O能力-它从磁盘存储读写的速度
- 使用每个数据库100个帐号的分开方式达到了极限，因为这已经超过了极限；
- 迁移到一个虚拟存储体系结构，那里整个SAN被当作一个大的存储池来对待，不需要特定的磁盘为特定的应用服务。现在
MySpace在设备上从相对新的SAN厂商，3PARdata方面已经标准化了。增加了一个高速缓存层—服务器放在Web服务器和数据库服务器之间，它唯一的工作就是捕获内存中频繁访问的数据对象的副本，然后把它们用于Web应用，不需要数据库查询。
• 2600万帐号
- 迁移到64位SQL server以解决它们的内存瓶颈问题。它们的标准数据库服务器配置使用64GB的RAM。
Myspace的经验能够说明什么？
• 你可以使用微软的技术构建大型网站。
• 从一开始就应该使用缓存。
• 高速缓存是一个更好的地方存储临时数据，比如Web站点上跟踪一个特定用户的会话产生的临时文件，就不再需要记录到数据库里，
• 嵌入OS特征来检测拒绝服务攻击会产生无法解释的错误
• 把数据分布到地理位置不同的数据中心，以免发生断电事故。
• 从开始就考虑使用虚拟存储/簇文件系统。它能让你大量并行IO访问，而且不需要任何重组就能够增加所需要的磁盘。
参考资料：
• Inside MySpace.com
MySpace.com的内部
转载原创文章请注明，转载自：web蓝草博客–LanCao’s Web Blog[http://www.juuyou.com]
本文链接: http://www.juuyou.com/?p=111
Tuesday, 17 de June de 2008
一个小型的网站，比如个人网站，可以使用最简单的html静态页面就实现了，配合一些图片达到美化效果，所有的页面均存放在一个目录下，这样的网站对系统架构、性能的要求都很简单，随着互联网业务的不断丰富，网站相关的技术经过这些年的发展，已经细分到很细的方方面面，尤其对于大型网站来说，所采用的技术更是涉及面非常广，从硬件到软件、编程语言、数据库、WebServer、防火墙等各个领域都有了很高的要求，已经不是原来简单的html静态网站所能比拟的。
大型网站，比如门户网站。在面对大量用户访问、高并发请求方面，基本的解决方案集中在这样几个环节：使用高性能的服务器、高性能的数据库、高效率的编程语言、还有高性能的Web容器。但是除了这几个方面，还没法根本解决大型网站面临的高负载和高并发问题。
上面提供的几个解决思路在一定程度上也意味着更大的投入，并且这样的解决思路具备瓶颈，没有很好的扩展性，下面我从低成本、高性能和高扩张性的角度来说说我的一些经验。
1、HTML静态化
其实大家都知道，效率最高、消耗最小的就是纯静态化的html页面，所以我们尽可能使我们的网站上的页面采用静态页面来实现，这个最简单的方法其实也是最有效的方法。但是对于大量内容并且频繁更新的网站，我们无法全部手动去挨个实现，于是出现了我们常见的信息发布系统CMS，像我们常访问的各个门户站点的新闻频道，甚至他们的其他频道，都是通过信息发布系统来管理和实现的，信息发布系统可以实现最简单的信息录入自动生成静态页面，还能具备频道管理、权限管理、自动抓取等功能，对于一个大型网站来说，拥有一套高效、可管理的CMS是必不可少的。
除了门户和信息发布类型的网站，对于交互性要求很高的社区类型网站来说，尽可能的静态化也是提高性能的必要手段，将社区内的帖子、文章进行实时的静态化，有更新的时候再重新静态化也是大量使用的策略，像Mop的大杂烩就是使用了这样的策略，网易社区等也是如此。
同时，html静态化也是某些缓存策略使用的手段，对于系统中频繁使用数据库查询但是内容更新很小的应用，可以考虑使用html静态化来实现，比如论坛中论坛的公用设置信息，这些信息目前的主流论坛都可以进行后台管理并且存储再数据库中，这些信息其实大量被前台程序调用，但是更新频率很小，可以考虑将这部分内容进行后台更新的时候进行静态化，这样避免了大量的数据库访问请求。
2、图片服务器分离
大家知道，对于Web服务器来说，不管是Apache、IIS还是其他容器，图片是最消耗资源的，于是我们有必要将图片与页面进行分离，这是基本上大型网站都会采用的策略，他们都有独立的图片服务器，甚至很多台图片服务器。这样的架构可以降低提供页面访问请求的服务器系统压力，并且可以保证系统不会因为图片问题而崩溃，在应用服务器和图片服务器上，可以进行不同的配置优化，比如apache在配置ContentType的时候可以尽量少支持，尽可能少的 LoadModule，保证更高的系统消耗和执行效率。
3、数据库集群和库表散列
大型网站都有复杂的应用，这些应用必须使用数据库，那么在面对大量访问的时候，数据库的瓶颈很快就能显现出来，这时一台数据库将很快无法满足应用，于是我们需要使用数据库集群或者库表散列。
在数据库集群方面，很多数据库都有自己的解决方案，Oracle、Sybase等都有很好的方案，常用的MySQL提供的Master/Slave也是类似的方案，您使用了什么样的DB，就参考相应的解决方案来实施即可。
上面提到的数据库集群由于在架构、成本、扩张性方面都会受到所采用DB类型的限制，于是我们需要从应用程序的角度来考虑改善系统架构，库表散列是常用并且最有效的解决方案。我们在应用程序中安装业务和应用或者功能模块将数据库进行分离，不同的模块对应不同的数据库或者表，再按照一定的策略对某个页面或者功能进行更小的数据库散列，比如用户表，按照用户ID进行表散列，这样就能够低成本的提升系统的性能并且有很好的扩展性。sohu的论坛就是采用了这样的架构，将论坛的用户、设置、帖子等信息进行数据库分离，然后对帖子、用户按照板块和ID进行散列数据库和表，最终可以在配置文件中进行简单的配置便能让系统随时增加一台低成本的数据库进来补充系统性能。
4、缓存
缓存一词搞技术的都接触过，很多地方用到缓存。网站架构和网站开发中的缓存也是非常重要。这里先讲述最基本的两种缓存。高级和分布式的缓存在后面讲述。
架构方面的缓存，对Apache比较熟悉的人都能知道Apache提供了自己的缓存模块，也可以使用外加的Squid模块进行缓存，这两种方式均可以有效的提高Apache的访问响应能力。
网站程序开发方面的缓存，Linux上提供的Memory Cache是常用的缓存接口，可以在web开发中使用，比如用Java开发的时候就可以调用MemoryCache对一些数据进行缓存和通讯共享，一些大型社区使用了这样的架构。另外，在使用web语言开发的时候，各种语言基本都有自己的缓存模块和方法，PHP有Pear的Cache模块，Java就更多了，.net不是很熟悉，相信也肯定有。
5、镜像
镜像是大型网站常采用的提高性能和数据安全性的方式，镜像的技术可以解决不同网络接入商和地域带来的用户访问速度差异，比如ChinaNet和EduNet之间的差异就促使了很多网站在教育网内搭建镜像站点，数据进行定时更新或者实时更新。在镜像的细节技术方面，这里不阐述太深，有很多专业的现成的解决架构和产品可选。也有廉价的通过软件实现的思路，比如Linux上的rsync等工具。
6、负载均衡
负载均衡将是大型网站解决高负荷访问和大量并发请求采用的终极解决办法。
负载均衡技术发展了多年，有很多专业的服务提供商和产品可以选择，我个人接触过一些解决方法，其中有两个架构可以给大家做参考。
硬件四层交换
第四层交换使用第三层和第四层信息包的报头信息，根据应用区间识别业务流，将整个区间段的业务流分配到合适的应用服务器进行处理。 第四层交换功能就象是虚 IP，指向物理服务器。它传输的业务服从的协议多种多样，有HTTP、FTP、NFS、Telnet或其他协议。这些业务在物理服务器基础上，需要复杂的载量平衡算法。在IP世界，业务类型由终端TCP或UDP端口地址来决定，在第四层交换中的应用区间则由源端和终端IP地址、TCP和UDP端口共同决定。
在硬件四层交换产品领域，有一些知名的产品可以选择，比如Alteon、F5等，这些产品很昂贵，但是物有所值，能够提供非常优秀的性能和很灵活的管理能力。Yahoo中国当初接近2000台服务器使用了三四台Alteon就搞定了。
软件四层交换
大家知道了硬件四层交换机的原理后，基于OSI模型来实现的软件四层交换也就应运而生，这样的解决方案实现的原理一致，不过性能稍差。但是满足一定量的压力还是游刃有余的，有人说软件实现方式其实更灵活，处理能力完全看你配置的熟悉能力。
软件四层交换我们可以使用Linux上常用的LVS来解决，LVS就是Linux Virtual Server，他提供了基于心跳线heartbeat的实时灾难应对解决方案，提高系统的鲁棒性，同时可供了灵活的虚拟VIP配置和管理功能，可以同时满足多种应用需求，这对于分布式的系统来说必不可少。
一个典型的使用负载均衡的策略就是，在软件或者硬件四层交换的基础上搭建squid集群，这种思路在很多大型网站包括搜索引擎上被采用，这样的架构低成本、高性能还有很强的扩张性，随时往架构里面增减节点都非常容易。这样的架构我准备空了专门详细整理一下和大家探讨。
对于大型网站来说，前面提到的每个方法可能都会被同时使用到，我这里介绍得比较浅显，具体实现过程中很多细节还需要大家慢慢熟悉和体会，有时一个很小的squid参数或者apache参数设置，对于系统性能的影响就会很大，希望大家一起讨论，达到抛砖引玉之效。
转自：http://purpen.javaeye.com/blog/197231
转载原创文章请注明，转载自：web蓝草博客–LanCao’s Web Blog[http://www.juuyou.com]
本文链接: http://www.juuyou.com/?p=110
Thursday, 3 de April de 2008
今天有朋友询问到lucene中的组合查询，这里就简单描述下。
组合查询使用BooleanQuery类。例如(……部分简写了)：
TermQuery tq1 = …..;
TermQuery tq2 = ……;
BooleanQuery bq = new BooleanQuery();
bq.add(tq1, true, false);
bq.add(tq2, true, false);
之后就可以用定义的IndexSearch的search方法查询bq了。
这里bq的add方法最后的true, false代表 and 条件；false, false 代表 or 条件；如果是 false, true 那就表明这条件是不允许匹配的。
PS:补充，新版本中使用方法为 bq.add(tq1, BooleanClause.Occur.MUST) 或者 bq.add(tq1, BooleanClause.Occur.SHOULD) 或者 bq.add(tq1, BooleanClause.Occur.MUST_NOT)
转载原创文章请注明，转载自：web蓝草博客–LanCao’s Web Blog[http://www.juuyou.com]
本文链接: http://www.juuyou.com/?p=107
Wednesday, 2 de April de 2008
有朋友问我JS中怎么避免和其他人写的变量,方法等命名不冲突。
实际上方法很多种，
一种就是名字取不一样贝（哈哈，好像是废话）；
另一种就是定义自己的命名空间。
JS中定义命名空间的方法很简单，例如：
<script language=”javascript”>
if(typeof com == “undefined”){
var com = {};
}
com.juuyou = {};
com.juuyou.aa = “aa”;
com.juuyou.fb = function(){
alert(”fb”);
}
alert(com.juuyou.aa);
com.juuyou.fb();
</script>
这里创建com.juuyou为一个命名空间，里面aa定义为一个变量，fb则为一个方法。
很简单吧 ^_^
PS：为什么定义com.juuyou为一个命名空间呢？因为这是我的域名嘛，倒过来写这样能保证世界上没有和我重复的人使用（当然他如果一定要用我的域名定义那也没办法T_T），或者你也可以使用你的email邮箱来命名空间哦，只要是唯一性的。
转载原创文章请注明，转载自：web蓝草博客–LanCao’s Web Blog[http://www.juuyou.com]
本文链接: http://www.juuyou.com/?p=106
Tuesday, 25 de March de 2008
这几个月来事情不断。
几个好友兼同事纷纷离开了公司。
和自己一起2个人开发365bloglink的好友也离开了公司。
自己想想也是该换换环境的时候了。
在现在的公司打拼了4年了。
有太多的记忆，和我一起进公司的几乎没有了。
中国这边的CEO也换过了一个。
感觉现在的公司不是我以前认识的公司了。
本打算最近换个工作。
目前在网上查了些。
最想去的是blogbus。
因为同样是做博客服务的。
不仅能继续在博客领域创业。
又能认识新的朋友并继续提高自己。
看了下他们定招收条件，感觉看起来简单，但实际要求严格。
属于精英小团队，而且车东也在去年加入了blogbus。呵呵。
还有3个月左右这边就应该结束了。
我也得好好准备下迎接新的人生。
争取能进入blogbus。
还得继续不停地学习啊。
转载原创文章请注明，转载自：web蓝草博客–LanCao’s Web Blog[http://www.juuyou.com]
本文链接: http://www.juuyou.com/?p=105
Wednesday, 5 de March de 2008
这些天发生了太多的事
共事的同事离职
公司的搬迁
生活上的点点事事
一切的那么多起起落落
希望一切都能有个好结果
等一切恢复平静
又是一个新生
转载原创文章请注明，转载自：web蓝草博客–LanCao’s Web Blog[http://www.juuyou.com]
本文链接: http://www.juuyou.com/?p=103
Friday, 15 de February de 2008
今天给小妹搭建了她的个人博客，不知道她能坚持写博多久。
小女孩子还是喜欢qq空间多点，毕竟那个花哨是腾云驾雾的 ><
小妹博客名字叫 “醜爾鴨的博客”
转载原创文章请注明，转载自：web蓝草博客–LanCao’s Web Blog[http://www.juuyou.com]
本文链接: http://www.juuyou.com/?p=100
Tuesday, 22 de January de 2008
有些人可以互相争吵
甚至很大声
因为他们的距离这时很远
只有大声的说
才能让对方知道自己的想法
有些人则可以轻轻细语
甚至不用说话
因为他们的距离很小很小
有时彼此的眼神
就能让互相沟通
你和他（她）的距离有多远
或者
又有多近呢
转载原创文章请注明，转载自：web蓝草博客–LanCao’s Web Blog[http://www.juuyou.com]
本文链接: http://www.juuyou.com/?p=99
Friday, 18 de January de 2008
(说法一)最近用Lucene开发全文检索。《Lucene in Action》这本书用的是Lucene 1.4。我自己下的是最新的2.1。然后就发现了很多不同的地方。
Field没了Keyword、UnIndexed、UnStored、Text这几个静态成员，只能用
Field(String, String, Store, Index)。
Keyword对应Field.Store.YES, Field.Index.UN_TOKENIZED，
UnIndexed 对应Field.Store.YES, Field.Index.NO，
UnStored对应Field.Store.NO, Field.Index.TOKENIZED，
Text对应Field.Store.YES, Field.Index.TOKENIZED。
FSDirectory.getDirectory的有两个参数的变成了depresed 了。现在要用只有一个参数的。
BooleanQuery的add方法也变了。原来是用两个boolean值组合的，现在 使用BooleanClause.Occur的几个静态成员了。
暂时就发现这点差异。[引自:http://syre.blogbus.com/logs/4736803.html]
(说法二)Field类一共有5种构造函数：
Field(String name, byte[] value, Field.Store store)
Create a stored field with binary value.
Field(String name, Reader reader)
Create a tokenized and indexed field that is not stored.
Field(String name, Reader reader, Field.TermVector termVector)
Create a tokenized and indexed field that is not stored, optionally with storing term vectors.
Field(String name, String value, Field.Store store, Field.Index index)
Create a field by specifying its name, value and how it will be saved in the index.
Field(String name, String value, Field.Store store, Field.Index index, Field.TermVector termVector)
Create a field by specifying its name, value and how it will be saved in the index.
其中：
Field.Store 表示“是否存储”，即该Field内的信息是否要被原封不动的保存在索引中。
Field.Index 表示“是否索引”，即在这个Field中的数据是否在将来检索时需要被用户检索到，一个“不索引”的Field通常仅是提供辅助信息储存的功能。
Field.TermVector 表示“是否切词”，即在这个Field中的数据是否需要被切词。
通常，参数用Reader，表示在文本流数据源中获取数据，数据量一般会比较大。像链接地址URL、文件系统路径信息、时间日期、人名、居民身份证、电话号码等等通常将被索引并且完整的存储在索引中，但一般不需要切分词，通常用上面的第四个构造函数，第三四个参数分别为Field.Store.YES, Field.Index.YES。而长文本通常可用第3个构造函数。引用[http://blog.csdn.net/colasnail/archive/2007/03/21/1536417.aspx]
(说法三)
1. 2.0以前的版本
UnIndexed: Field的值将被保存到索引文件，不为Field的值建立索引，因此不能通过该Field搜索文档。 UnStored: Field的值不被保存到索引文件，将Field的值分词后建立索引
Text: Field的值分词后建立索引。如果参数为String值将被保存，为Reader值不被保存
2. 2.0版本
用几个内部类的组合来区分Field的具体类型。
Store
COMPRESS:压缩保存。用于长文本或二进制数据
YES：保存
NO：不保存
Index
NO：不建索引
TOKENIZED：分词，建索引
UN_TOKENIZED：不分词，建索引
NO_NORMS：不分词，建索引。但是Field的值不像通常那样被保存，而是只取一个byte，这样节约存储空间
TermVector
NO：不保存term vectors
YES：保存term vectors。
WITH_POSITIONS：保存term vectors。（保存值和token位置信息）
WITH_OFFSETS：保存term vectors。（保存值和Token的offset）WITH_POSITIONS_OFFSETS：保存term vectors。（保存值和token位置信息和Token的offset）
(说法四)
关于 Field ， 2.0.0 版本和 1.4.3 版本方法相比改动比较大，具体见下表
1.4.3 版本中的下面方法都被 Field(String name, String value, Store store, Index index, TermVector termVector) 取代
Keyword(String name, String value) // only version 1.4.3
存储、索引、不分词，用于 URI （比如 MSN 聊天记录的日期域、比如 MP3 文件的文件全路径等等）
Field(String name, String value, Field.Store.YES, Field.Index.UN_TOKENIZED) // version 2.0.0
UnIndexed(String name, String value) // only version 1.4.3
存储、不索引、不分词，比如文件的全路径
Field(String name, String value,Field.Store.YES, Field.Index.NO)// version 2.0.0
UnStored(String name, String value) // only version 1.4.3
不存储、索引、分词，比如 HTML 的正文、 Word 的内容等等，这部分内容是要被索引的，但是由于具体内容通常很大，没有必要再进行存储，可以到时候根据 URI 再来挖取。所以，这部分只分词、索引，而不存储。
Field(String name, String value,Field.Store.YES, Field.Index.TOKENIZED)// version 2.0.0
Text(String name, String value) // only version 1.4.3
存储、索引、分词，比如文件的各种属性，比如 MP3 文件的歌手、专辑等等。 Field.Store.YES, Field(String name, String value,Field.Index.TOKENIZED)// version 2.0.0
Text(String name, Reader value) // only version 1.4.3
Field(String name, Reader reader) // version 2.0.0
不存储、索引、分词。
(说法五)
1. 2.0 以前的版本
Keyword: Field 的值将被保存到索引文件，为Field的值建立索引，建立索引时不需要分词。
UnIndexed: Field 的值将被保存到索引文件，不为Field的值建立索引，因此不能通过该Field搜索文档。
UnStored: Field 的值不被保存到索引文件，将Field的值分词后建立索引
Text: Field 的值分词后建立索引。如果参数为String值将被保存，为Reader值不被保存
2. 2.0 版本
用几个内部类的组合来区分Field的具体类型。
Store
² COMPRESS: 压缩保存。用于长文本或二进制数据
² YES ：保存
² NO ：不保存
Index
² NO ：不 建索引
² TOKENIZED ：分词， 建索引
² UN_TOKENIZED ：不分词， 建索引
² NO_NORMS ：不分词， 建索引。但是Field的值不像通常那样被保存，而是只取一个byte，这样节约存储空间
TermVector
² NO ： 不保存term vectors
² YES ： 保存term vectors。
² WITH_POSITIONS ： 保存term vectors。（保存值和token位置信息）
² WITH_OFFSETS ： 保存term vectors。（保存值和Token的offset）WITH_POSITIONS_OFFSETS：保存term vectors。（保存值和token位置信息和Token的offset）
(说法六)
* Field.Index有四个属性，分别是：
Field.Index.TOKENIZED：分词索引
Field.Index.UN_TOKENIZED：分词进行索引，如作者名，日期等，Rod Johnson本身为一单词，不再需要分词。
Field.Index：不进行索引，存放不能被搜索的内容如文档的一些附加属性如文档类型, URL等。
Field.Index.NO_NORMS：；
Field.Store也有三个属性，分别是：
Field.Store.YES：索引文件本来只存储索引数据, 此设计将原文内容直接也存储在索引文件中，如文档的标题。
Field.Store.NO：原文不存储在索引文件中，搜索结果命中后，再根据其他附加属性如文件的Path，数据库的主键等，重新连接打开原文，适合原文内容较大的情况。
Field.Store.COMPRESS 压缩存储；
termVector是Lucene 1.4.3新增的它提供一种向量机制来进行模糊查询,很少用。
转自:http://hi.baidu.com/gw_noah/blog/item/0646fbc4c3418daa8226ac0c.html
转载原创文章请注明，转载自：web蓝草博客–LanCao’s Web Blog[http://www.juuyou.com]
本文链接: http://www.juuyou.com/?p=98
