0：停止运行，所有进程终止，关机。

1：单用户模式，用于维护系统，只有少数进程运行（类似于Windows安全模式）

2：多用户模式，除了NFS服务没有启动外，其他和运行级别3一样

3：完整的多用户模式，进入Linux系统的文本字符界面

4：没有使用（可由用户定义）

5：完整的多用户模式（带有基于X的图形界面）

6：重新引导计算机

 

默认运行级别可以通过修改/etc/inittab文件来改变

id:5:initdefault:

 

查看当前系统运行级别

runlevel

切换运行级别

init 2

 

 

1、CPU

     新的CPU，如Intel Core 2和Itanium 2现在在架构上努力将一些小的CPUs或“核”嵌入到一个物理设备上，这会使多线程并行地处理与单线程相比两倍的数据，但是每个线程的速度还是和以前是一样的。

即使将成百上千的CPU核放到一台计算机上，它也无法很快地把数据传输到这些核去处理，单个磁盘读取速度大约为60-100MB/s，虽然磁盘的读取速度一直在提高，但却无法与处理器速度的提高相比，暂且乐观地假设速度为上限100MB/s，并假设有4个I/O通道，也就是有400MB/s的速度，那么一个4TB的数据集要用10,000秒去读大约4小时才能载入数据，但用100台只有两个I/O通道的机器做相同的工作，只需要3分钟。

2、内存

单台计算机通常只有几G内存，如果输入数据是TB级的，那就需要上千台计算机才能将这些数据放入内存，即便如此，但是单台计算机仍无法处理和寻址这些数据。

3、磁盘

   单台机器的磁盘空间现在有几TB左右，但在大规模计算中，计算机产生的中间数据通常是输入数据的几倍，这也就将占有输入数据的几倍磁盘空间。在处理过程中，一些磁盘满了。

4、磁盘访问速度

      多年来磁盘存储容量快速增加的同时，其访问速度——磁盘数据读取速度——却未能与时俱进。1990年，一个普通磁盘可存储1370MB的数据并拥有4.4MB/S的传输速度，因此，读取整个磁盘中的数据只需要5分钟。20年后，1TB的磁盘逐渐普及，但其数据传输速度约为100MB/S,因此读取整个磁盘中的数据约需要两个半小时。写甚至更慢。现在有了SSD，其价格太高，容量不够，性价比比较低，普及还需要一定的时间。

5、带宽

     提起带宽，是所有站长及网站技术心中永远的痛。尤其是在国内，南北互通瓶颈、高额的带宽成本。此不多言了。

6、系统架构

7、代码执行效率

8、数据库架构

 

参考来源：http://quweiprotoss.blog.163.com/blog/static/4088288320108231113535/

 

一、数据库结构的设计

    如果不能设计一个合理的数据库模型，不仅会增加客户端和服务器段程序的编程和维护的难度，而且将会影响系统实际运行的性能。所以，在一个系统开始实施之前，完备的数据库模型的设计是必须的。

    在一个系统分析、设计阶段，因为数据量较小，负荷较低。我们往往只注意到功能的实现，而很难注意到性能的薄弱之处，等到系统投入实际运行一段时间后，才发现系统的性能在降低，这时再来考虑提高系统性能则要花费更多的人力物力，而整个系统也不可避免的形成了一个打补丁工程。

    所以在考虑整个系统的流程的时候，我们必须要考虑，在高并发大数据量的访问情况下，我们的系统会不会出现极端的情况。（例如：对外统计系统在7月16日出现的数据异常的情况，并发大数据量的的访问造成，数据库的响应时间不能跟上数据刷新的速度造成。具体情况是：在日期临界时（00：00：00），判断数据库中是否有当前日期的记录，没有则插入一条当前日期的记录。在低并发访问的情况下，不会发生问题，但是当日期临界时的访问量相当大的时候，在做这一判断的时候，会出现多次条件成立，则数据库里会被插入多条当前日期的记录，从而造成数据错误。），数据库的模型确定下来之后，我们有必要做一个系统内数据流向图，分析可能出现的瓶颈。

    为了保证数据库的一致性和完整性，在逻辑设计的时候往往会设计过多的表间关联，尽可能的降低数据的冗余。（例如用户表的地区，我们可以把地区另外存放到一个地区表中）如果数据冗余低，数据的完整性容易得到保证，提高了数据吞吐速度，保证了数据的完整性，清楚地表达数据元素之间的关系。而对于多表之间的关联查询（尤其是大数据表）时，其性能将会降低，同时也提高了客户端程序的编程难度，因此，物理设计需折衷考虑，根据业务规则，确定对关联表的数据量大小、数据项的访问频度，对此类数据表频繁的关联查询应适当提高数据冗余设计但增加了表间连接查询的操作，也使得程序的变得复杂，为了提高系统的响应时间，合理的数据冗余也是必要的。设计人员在设计阶段应根据系统操作的类型、频度加以均衡考虑。
   另外，最好不要用自增属性字段作为主键与子表关联。不便于系统的迁移和数据恢复。对外统计系统映射关系丢失（******************）。

    原来的表格必须可以通过由它分离出去的表格重新构建。使用这个规定的好处是，你可以确保不会在分离的表格中引入多余的列，所有你创建的表格结构都与它们的实际需要一样大。应用这条规定是一个好习惯，不过除非你要处理一个非常大型的数据，否则你将不需要用到它。（例如一个通行证系统，我可以将 USERID，USERNAME，USERPASSWORD，单独出来作个表，再把USERID作为其他表的外键）

表的设计具体注意的问题：

    1、数据行的长度不要超过8020字节，如果超过这个长度的话在物理页中这条数据会占用两行从而造成存储碎片，降低查询效率。
    2、能够用数字类型的字段尽量选择数字类型而不用字符串类型的（电话号码），这会降低查询和连接的性能，并会增加存储开销。这是因为引擎在处理查询和连接回逐个比较字符串中每一个字符，而对于数字型而言只需要比较一次就够了。

    3、对于不可变字符类型char和可变字符类型varchar 都是8000字节,char查询快，但是耗存储空间，varchar查询相对慢一些但是节省存储空间。在设计字段的时候可以灵活选择，例如用户名、密码等长度变化不大的字段可以选择CHAR，对于评论等长度变化大的字段可以选择VARCHAR。

    4、字段的长度在最大限度的满足可能的需要的前提下，应该尽可能的设得短一些，这样可以提高查询的效率，而且在建立索引的时候也可以减少资源的消耗。


二、查询的优化

保证在实现功能的基础上，尽量减少对数据库的访问次数；通过搜索参数，尽量减少对表的访问行数,最小化结果集，从而减轻网络负担；能够分开的操作尽量分开处理，提高每次的响应速度；在数据窗口使用SQL时，尽量把使用的索引放在选择的首列；算法的结构尽量简单；在查询时，不要过多地使用通配符如 Select * FROM T1语句，要用到几列就选择几列如：Select COL1,COL2 FROM T1；在可能的情况下尽量限制尽量结果集行数如：Select TOP 300 COL1,COL2,COL3 FROM T1,因为某些情况下用户是不需要那么多的数据的。  
在没有建索引的情况下，数据库查找某一条数据，就必须进行全表扫描了，对所有数据进行一次遍历，查找出符合条件的记录。在数据量比较小的情况下，也许看不出明显的差别，但是当数据量大的情况下，这种情况就是极为糟糕的了。
SQL语句在SQL SERVER中是如何执行的，他们担心自己所写的SQL语句会被SQL SERVER误解。比如：
select * from table1 where name='zhangsan' and tID > 10000
和执行:
select * from table1 where tID > 10000 and name='zhangsan'
一些人不知道以上两条语句的执行效率是否一样，因为如果简单的从语句先后上看，这两个语句的确是不一样，如果tID是一个聚合索引，那么后一句仅仅从表的 10000条以后的记录中查找就行了；而前一句则要先从全表中查找看有几个name='zhangsan'的，而后再根据限制条件条件tID> 10000来提出查询结果。
事实上，这样的担心是不必要的。SQL SERVER中有一个“查询分析优化器”，它可以计算出where子句中的搜索条件并确定哪个索引能缩小表扫描的搜索空间，也就是说，它能实现自动优化。虽然查询优化器可以根据where子句自动的进行查询优化，但有时查询优化器就会不按照您的本意进行快速查询。
在查询分析阶段，查询优化器查看查询的每个阶段并决定限制需要扫描的数据量是否有用。如果一个阶段可以被用作一个扫描参数（SARG），那么就称之为可优化的，并且可以利用索引快速获得所需数据。
SARG的定义：用于限制搜索的一个操作，因为它通常是指一个特定的匹配，一个值的范围内的匹配或者两个以上条件的AND连接。形式如下：
列名 操作符 <常数 或 变量> 或 <常数 或 变量> 操作符 列名
列名可以出现在操作符的一边，而常数或变量出现在操作符的另一边。如：
Name=’张三’
价格>5000
5000<价格
Name=’张三’ and 价格>5000
如果一个表达式不能满足SARG的形式，那它就无法限制搜索的范围了，也就是SQL SERVER必须对每一行都判断它是否满足Where子句中的所有条件。所以一个索引对于不满足SARG形式的表达式来说是无用的。
    所以，优化查询最重要的就是，尽量使语句符合查询优化器的规则避免全表扫描而使用索引查询。

具体要注意的：

1.应尽量避免在 where 子句中对字段进行 null 值判断，否则将导致引擎放弃使用索引而进行全表扫描，如：
select id from t where num is null
可以在num上设置默认值0，确保表中num列没有null值，然后这样查询：
select id from t where num=0

2.应尽量避免在 where 子句中使用!=或<>操作符，否则将引擎放弃使用索引而进行全表扫描。优化器将无法通过索引来确定将要命中的行数,因此需要搜索该表的所有行。

3.应尽量避免在 where 子句中使用 or 来连接条件，否则将导致引擎放弃使用索引而进行全表扫描，如：
select id from t where num=10 or num=20
可以这样查询：
select id from t where num=10
union all
select id from t where num=20

4.in 和 not in 也要慎用，因为IN会使系统无法使用索引,而只能直接搜索表中的数据。如：
select id from t where num in(1,2,3)
对于连续的数值，能用 between 就不要用 in 了：
select id from t where num between 1 and 3

5.尽量避免在索引过的字符数据中，使用非打头字母搜索。这也使得引擎无法利用索引。
见如下例子：
Select * FROM T1 Where NAME LIKE ‘%L%’
Select * FROM T1 Where SUBSTING(NAME,2,1)=’L’
Select * FROM T1 Where NAME LIKE ‘L%’
即使NAME字段建有索引，前两个查询依然无法利用索引完成加快操作，引擎不得不对全表所有数据逐条操作来完成任务。而第三个查询能够使用索引来加快操作。

6.必要时强制查询优化器使用某个索引，如在 where 子句中使用参数，也会导致全表扫描。因为SQL只有在运行时才会解析局部变量，但优化程序不能将访问计划的选择推迟到运行时；它必须在编译时进行选择。然而，如果在编译时建立访问计划，变量的值还是未知的，因而无法作为索引选择的输入项。如下面语句将进行全表扫描：
select id from t where num=@num
可以改为强制查询使用索引：
select id from t with(index(索引名)) where num=@num

7.应尽量避免在 where 子句中对字段进行表达式操作，这将导致引擎放弃使用索引而进行全表扫描。如：
Select * FROM T1 Where F1/2=100
应改为:
Select * FROM T1 Where F1=100*2

Select * FROM RECORD Where SUBSTRING(CARD_NO,1,4)=’5378’
应改为:
Select * FROM RECORD Where CARD_NO LIKE ‘5378%’

Select member_number, first_name, last_name FROM members
Where DATEDIFF(yy,datofbirth,GETDATE()) > 21
应改为:
Select member_number, first_name, last_name FROM members
Where dateofbirth < DATEADD(yy,-21,GETDATE())
即：任何对列的操作都将导致表扫描，它包括数据库函数、计算表达式等等，查询时要尽可能将操作移至等号右边。

8.应尽量避免在where子句中对字段进行函数操作，这将导致引擎放弃使用索引而进行全表扫描。如：
select id from t where substring(name,1,3)='abc'--name以abc开头的id
select id from t where datediff(day,createdate,'2005-11-30')=0--‘2005-11-30’生成的id
应改为:
select id from t where name like 'abc%'
select id from t where createdate>='2005-11-30' and createdate<'2005-12-1'

9.不要在 where 子句中的“=”左边进行函数、算术运算或其他表达式运算，否则系统将可能无法正确使用索引。

10.在使用索引字段作为条件时，如果该索引是复合索引，那么必须使用到该索引中的第一个字段作为条件时才能保证系统使用该索引，否则该索引将不会被使用，并且应尽可能的让字段顺序与索引顺序相一致。

11.很多时候用 exists是一个好的选择：
elect num from a where num in(select num from b)
用下面的语句替换：
select num from a where exists(select 1 from b where num=a.num)

Select SUM(T1.C1)FROM T1 Where(
(Select COUNT(*)FROM T2 Where T2.C2=T1.C2>0)
Select SUM(T1.C1) FROM T1Where EXISTS(
Select * FROM T2 Where T2.C2=T1.C2)
两者产生相同的结果，但是后者的效率显然要高于前者。因为后者不会产生大量锁定的表扫描或是索引扫描。

如果你想校验表里是否存在某条纪录，不要用count(*)那样效率很低，而且浪费服务器资源。可以用EXISTS代替。如：
IF (Select COUNT(*) FROM table_name Where column_name = 'xxx')
可以写成：
IF EXISTS (Select * FROM table_name Where column_name = 'xxx')

经常需要写一个T_SQL语句比较一个父结果集和子结果集，从而找到是否存在在父结果集中有而在子结果集中没有的记录，如：
Select a.hdr_key FROM hdr_tbl a---- tbl a 表示tbl用别名a代替
Where NOT EXISTS (Select * FROM dtl_tbl b Where a.hdr_key = b.hdr_key)
Select a.hdr_key FROM hdr_tbl a
LEFT JOIN dtl_tbl b ON a.hdr_key = b.hdr_key Where b.hdr_key IS NULL
Select hdr_key FROM hdr_tbl
Where hdr_key NOT IN (Select hdr_key FROM dtl_tbl)
三种写法都可以得到同样正确的结果，但是效率依次降低。

12.尽量使用表变量来代替临时表。如果表变量包含大量数据，请注意索引非常有限（只有主键索引）。

13.避免频繁创建和删除临时表，以减少系统表资源的消耗。

14.临时表并不是不可使用，适当地使用它们可以使某些例程更有效，例如，当需要重复引用大型表或常用表中的某个数据集时。但是，对于一次性事件，最好使用导出表。

15.在新建临时表时，如果一次性插入数据量很大，那么可以使用 select into 代替 create table，避免造成大量 log ，以提高速度；如果数据量不大，为了缓和系统表的资源，应先create table，然后insert。

16.如果使用到了临时表，在存储过程的最后务必将所有的临时表显式删除，先 truncate table ，然后 drop table ，这样可以避免系统表的较长时间锁定。

17.在所有的存储过程和触发器的开始处设置 SET NOCOUNT ON ，在结束时设置 SET NOCOUNT OFF 。无需在执行存储过程和触发器的每个语句后向客户端发送 DONE_IN_PROC 消息。

18.尽量避免大事务操作，提高系统并发能力。

19.尽量避免向客户端返回大数据量，若数据量过大，应该考虑相应需求是否合理。

20. 避免使用不兼容的数据类型。例如float和int、char和varchar、binary和varbinary是不兼容的。数据类型的不兼容可能使优化器无法执行一些本来可以进行的优化操作。例如:
Select name FROM employee Where salary > 60000
在这条语句中,如salary字段是money型的,则优化器很难对其进行优化,因为60000是个整型数。我们应当在编程时将整型转化成为钱币型,而不要等到运行时转化。

21.充分利用连接条件，在某种情况下，两个表之间可能不只一个的连接条件，这时在 Where 子句中将连接条件完整的写上，有可能大大提高查询速度。
例：
Select SUM(A.AMOUNT) FROM ACCOUNT A,CARD B Where A.CARD_NO = B.CARD_NO
Select SUM(A.AMOUNT) FROM ACCOUNT A,CARD B Where A.CARD_NO = B.CARD_NO AND A.ACCOUNT_NO=B.ACCOUNT_NO
第二句将比第一句执行快得多。

22、使用视图加速查询
把表的一个子集进行排序并创建视图，有时能加速查询。它有助于避免多重排序 操作，而且在其他方面还能简化优化器的工作。例如：
Select cust.name，rcvbles.balance，……other columns
FROM cust，rcvbles
Where cust.customer_id = rcvlbes.customer_id
AND rcvblls.balance>0
AND cust.postcode>“98000”
orDER BY cust.name

如果这个查询要被执行多次而不止一次，可以把所有未付款的客户找出来放在一个视图中，并按客户的名字进行排序：
Create VIEW DBO.V_CUST_RCVLBES
AS
Select cust.name，rcvbles.balance，……other columns
FROM cust，rcvbles
Where cust.customer_id = rcvlbes.customer_id
AND rcvblls.balance>0
orDER BY cust.name
然后以下面的方式在视图中查询：
Select ＊ FROM V_CUST_RCVLBES
Where postcode>“98000”
视图中的行要比主表中的行少，而且物理顺序就是所要求的顺序，减少了磁盘I/O，所以查询工作量可以得到大幅减少。

23、能用DISTINCT的就不用GROUP BY
Select orderID FROM Details Where UnitPrice > 10 GROUP BY orderID
可改为：
Select DISTINCT orderID FROM Details Where UnitPrice > 10

24.能用UNION ALL就不要用UNION
UNION ALL不执行Select DISTINCT函数，这样就会减少很多不必要的资源

35.尽量不要用Select INTO语句。
Select INOT 语句会导致表锁定，阻止其他用户访问该表。

    上面我们提到的是一些基本的提高查询速度的注意事项,但是在更多的情况下,往往需要反复试验比较不同的语句以得到最佳方案。最好的方法当然是测试，看实现相同功能的SQL语句哪个执行时间最少，但是数据库中如果数据量很少，是比较不出来的，这时可以用查看执行计划，即：把实现相同功能的多条SQL语句考到查询分析器，按CTRL+L看查所利用的索引，表扫描次数（这两个对性能影响最大），总体上看询成本百分比即可。

1 lucene简介
1.1 什么是lucene
Lucene是一个全文搜索框架，而不是应用产品。因此它并不像www.baidu.com 或者google Desktop那么拿来就能用，它只是提供了一种工具让你能实现这些产品。

1.2 lucene能做什么
要回答这个问题，先要了解lucene的本质。实际上lucene的功能很单一，说到底，就是你给它若干个字符串，然后它为你提供一个全文搜索服务，告诉你你要搜索的关键词出现在哪里。知道了这个本质，你就可以发挥想象做任何符合这个条件的事情了。你可以把站内新闻都索引了，做个资料库；你可以把一个数据库表的若干个字段索引起来，那就不用再担心因为“%like%”而锁表了；你也可以写个自己的搜索引擎……

1.3 你该不该选择lucene
下面给出一些测试数据，如果你觉得可以接受，那么可以选择。
测试一：250万记录，300M左右文本，生成索引380M左右，800线程下平均处理时间300ms。
测试二：37000记录，索引数据库中的两个varchar字段，索引文件2.6M，800线程下平均处理时间1.5ms。

2 lucene的工作方式
lucene提供的服务实际包含两部分：一入一出。所谓入是写入，即将你提供的源（本质是字符串）写入索引或者将其从索引中删除；所谓出是读出，即向用户提供全文搜索服务，让用户可以通过关键词定位源。

2.1写入流程
源字符串首先经过analyzer处理，包括：分词，分成一个个单词；去除stopword（可选）。
将源中需要的信息加入Document的各个Field中，并把需要索引的Field索引起来，把需要存储的Field存储起来。
将索引写入存储器，存储器可以是内存或磁盘。

2.2读出流程
用户提供搜索关键词，经过analyzer处理。
对处理后的关键词搜索索引找出对应的Document。
用户根据需要从找到的Document中提取需要的Field。

3 一些需要知道的概念
lucene用到一些概念，了解它们的含义，有利于下面的讲解。

3.1 analyzer
Analyzer是分析器，它的作用是把一个字符串按某种规则划分成一个个词语，并去除其中的无效词语，这里说的无效词语是指英文中的 “of”、 “the”，中文中的“的”、“地”等词语，这些词语在文章中大量出现，但是本身不包含什么关键信息，去掉有利于缩小索引文件、提高效率、提高命中率。
分词的规则千变万化，但目的只有一个：按语义划分。这点在英文中比较容易实现，因为英文本身就是以单词为单位的，已经用空格分开；而中文则必须以某种方法将连成一片的句子划分成一个个词语。具体划分方法下面再详细介绍，这里只需了解分析器的概念即可。

3.2 document
用户提供的源是一条条记录，它们可以是文本文件、字符串或者数据库表的一条记录等等。一条记录经过索引之后，就是以一个Document的形式存储在索引文件中的。用户进行搜索，也是以Document列表的形式返回。

3.3 field
一个Document可以包含多个信息域，例如一篇文章可以包含“标题”、“正文”、“最后修改时间”等信息域，这些信息域就是通过Field在Document中存储的。
Field有两个属性可选：存储和索引。通过存储属性你可以控制是否对这个Field进行存储；通过索引属性你可以控制是否对该Field进行索引。这看起来似乎有些废话，事实上对这两个属性的正确组合很重要，下面举例说明：
还是以刚才的文章为例子，我们需要对标题和正文进行全文搜索，所以我们要把索引属性设置为真，同时我们希望能直接从搜索结果中提取文章标题，所以我们把标题域的存储属性设置为真，但是由于正文域太大了，我们为了缩小索引文件大小，将正文域的存储属性设置为假，当需要时再直接读取文件；我们只是希望能从搜索解果中提取最后修改时间，不需要对它进行搜索，所以我们把最后修改时间域的存储属性设置为真，索引属性设置为假。上面的三个域涵盖了两个属性的三种组合，还有一种全为假的没有用到，事实上Field不允许你那么设置，因为既不存储又不索引的域是没有意义的。

3.4 term
term是搜索的最小单位，它表示文档的一个词语，term由两部分组成：它表示的词语和这个词语所出现的field。

3.5 tocken
tocken是term的一次出现，它包含trem文本和相应的起止偏移，以及一个类型字符串。一句话中可以出现多次相同的词语，它们都用同一个term表示，但是用不同的tocken，每个tocken标记该词语出现的地方。

3.6 segment
添加索引时并不是每个document都马上添加到同一个索引文件，它们首先被写入到不同的小文件，然后再合并成一个大索引文件，这里每个小文件都是一个segment。

Lucene应用编程接口（API）功能强大、非常灵活、易于使用。Lucene不但提供了出众的全文搜索功能，还提供了所有补充性的过滤和排序特性。如果想把高性能、特性丰富的多重标准全文搜索机制添加到应用程序中，就需要这些功能和特性。

索引

任何Lucene应用程序的第一步就是为数据建立索引。Lucene需要使用数据创建自己的一组索引，以便它可以对数据进行高性能的全文检查、过滤和排序等操作。这是相当简单、直观的过程。首先，需要创建IndexWriter对象，可以使用该对象建立Lucene索引，并把它写到磁盘上。Lucene非常灵活，它有许多选项。这里，我们只是在“index”目录里面建立简单的索引结构：

Directory directory = FSDirectory.getDirectory("index", true);

Analyzer analyser = new StandardAnalyzer();

IndexWriter writer = new IndexWriter(directory, analyser, true);

接下来，需要为数据记录建立索引。需要为每个记录建立单独的索引。用Lucene为记录建立索引时，要为每个记录创建“文档”（Document）对象。要让全文索引发挥作用，就要为Lucene提供可以建立索引的一些数据。最简单的选项就是编写一个方法，写入记录的全文描述（包括想要搜索的各项内容），然后使用这个值作为可搜索字段。这里，我们把这个字段称为“description”。可以通过为文档添加“字段”（Field）类的新实例，来为字段建立索引，如下所示：

Field field = new Field("field", value, Field.Store.NO, Field.Index.TOKENIZED);

doc.add(field);

可以选择指定自己是否想保存该值供将来使用（Field.Store.YES），还是只是为它建立索引（Field.Store.NO）。后一个选项适用于想建立索引、但以后不想检索的大值。第四个参数表明想要如何为值建立索引。如果使用Field.Index.TOKENIZED，值就会被分析，让Lucene可以更充分地利用功能强大的全文索引和搜索特性。正如我们会看到的那样，缺点在于，无法按标记化（tokenized）的字段对结果进行排序。如果想为字段建立索引，而不需要先进行分析，那么Field.Index.UN_TOKENIZED很有用。如果只是想保存值，供将来使用，那么可以使用Field.Index.NO。下列代码表明了如何为来自库目录的条目列表建立索引：

List< Item> items = Catalog.getAllItems();

for(Item item : items) {}

Document doc = new Document();

String description = item.getTitle+ " " + item.getAuthors()+ " " + item.getSummary()...;

doc.add(new Field("description", description, Field.Store.NO, Field.Index.TOKENIZED));

... }

上述方法非常适用于全文搜索，但有时候也需要按特定字段进行更加准确的搜索。可搜索字段应当是标记化的，不过它们确实不需要保存起来（除非想直接从Lucene文档获得字段值）。设想一下：如果需要根据库目录建立全文索引，目录里面有成千上万个条目，譬如图书、文章、报纸、视频和声音等资料。下列代码说明了如何按特定库条目（这里是图书）的书名和国际标准图书编号添加可搜索的索引：

doc.add(new Field("title", item.getTitle(), Field.Store.NO, Field.Index.TOKENIZED));

doc.add(new Field("isbn", item.getISBNNumber(), Field.Store.NO, Field.Index.TOKENIZED));

doc.add(new Field("type", Item.BOOK, Field.Store.NO, Field.Index.TOKENIZED));

writer.addDocument(doc);

...

writer.close();

有时候往往会需要在表中显示搜索结果，让用户可以按列对结果进行排序。这可以用Lucene来完成，不过有一个问题：字段必须是UN_TOKENIZED。这意味着，无法对可搜索的索引进行排序：需要添加有着不同名字的另一个索引。办法之一就是用某种易于识读的方式为字段名添加前缀，如下所示：

// 按照书名字段的可搜索索引

doc.add(new Field("sort-on-title", book.getTitle(), Field.Store.YES, Field.Index.UN_TOKENIZED));

// 按照国际标准图书编号字段的可搜索索引

doc.add(new Field("sort-on-isbn", book.getISBNNumber(), Field.Store.YES, Field.Index.UN_TOKENIZED));

全文搜索

Lucene的全文搜索比较容易实现。典型的Lucene全文搜索如下所示：

Searcher is = indexer.getIndexSearcher();

QueryParser parser = indexer.getQueryParser("description");

Query query = parser.parse("Some full-text search terms");

Hits hits = is.search(query);

这里，我们使用索引程序按“描述”（description）字段执行全文搜索。Lucene返回“搜索结果”（Hits）对象，我们可以使用该对象获得匹配文档，如下所示：

for (int i = 0; i < searchResults.length(); i++) {

Document doc = searchResults.doc(i);

String title = (String) doc.getField("title");

System.out.println(title);}

对这部分代码进行扩充以实现多重标准搜索需要多一些工作量。我们这里使用的关键字类是“过滤器”（Filter）类，顾名思义，这个类可以对搜索结果进行过滤。“过滤器”类实际上是一个抽象类。有几种类型的过滤器类可以定义准确的过滤操作。QueryFilter类可以根据Lucene查询表达式来对搜索结果进行过滤。这里，我们构建了一个过滤器，把搜索结果限制为图书，使用了“类型”（type）字段：

Query booksQuery = new TermQuery(new Term("type",Item.BOOK));

Filter typeFilter = new QueryFilter(booksQuery);

RangeFilter类可以把搜索结果限制为某个范围的值。下列过滤器就把搜索结果限制为日期从1990年到1999年的条目，使用了year字段（最后两个布尔字段表明限制值是不是包括在内）：

Filter rangeFilter = new RangeFilter("year", "1990", "1999", true, true);

ChainedFilter类可以使用“与”（AND）、“或”（OR）、“异”（XOR）或者“与非”（ANDNOT）等逻辑操作符来合并其他过滤器。在下一个示例中，我们把搜索结果限制为只有与上述两个条件都匹配的文档：

List< Filter> filters = new ArrayList< Filter>();

filters.add(typeFilter);

filters.add(rangeFilter);

Filter filter = new ChainedFilter(filterList, ChainedFilter.AND);

可以把同一操作符应用于所有过滤器，也可以提供一组操作符，这样就可以提供不同的操作符供每个过滤器使用。不过，应当认真考虑用于多重标准搜索的操作符。譬如说，在典型的多重标准搜索中，可能会让用户使用复选框（图书、文章和视频等），从而选择他们需要的文档类型。来自这些复选框值的过滤器通常需要使用“或”（OR）表达式来进行合并。 另一方面，酒店预订网站可能会提供房间号、类别或者酒店位置等搜索标准。这些是限制性的标准，它们需要使用“与”（AND）表达式来进行合并。

以下是一个比较完整的示例，它使用了我们上面讨论过的所有特性：

public List< CatalogItem> search(String expression, boolean displayBooks, boolean displayArticles, boolean displayVideo) {

List< Filter> filters = new ArrayList< Filter>();

//显示图书

if (displayBooks) {

　Query booksQuery = new TermQuery(new Term("type",Item.BOOK));

　filters.add(new QueryFilter(booksQuery)); }

// 显示文章

if (displayArticles) {

　Query articlesQuery = new TermQuery(new Term("type",Item.ARTICLE));

　filters.add(new QueryFilter(articlesQuery)); }

// 显示录像

if (displayVideo) {

　Query videoQuery = new TermQuery(new Term("type",Item.VIDEO));

　filters.add(new QueryFilter(videoQuery)); }

Filter filter = new ChainedFilter(filterList, ChainedFilter.OR);

QueryParser parser = indexer.getQueryParser("description");

Query query = parser.parse(expression);

hits = is.search(query, filter);

... }

结果排序

对搜索结果进行排序是用户对Web应用程序的一个常见需求。如今JavaServer Faces和Tapestry等许多基于组件的Web框架拥有表组件，让用户可以对每一列进行排序，就像Struts这些较为传统的模型－视图－控制器框架那样。一旦返回了搜索结果，就有可能在内存中对它们进行排序。不过，这种方法浪费严重，而且效率低下。无论是传统的关系数据库应用程序，还是Lucene应用程序，在源处执行排序操作要有效得多。

正如我们在前面看到的那样，Lucene可以建立专门用来对结果进行排序的索引。可以只对这些字段执行排序操作，因为对关系数据库中的未索引字段进行排序是不明智的。要使用这些字段，就要使用“排序”（Sort）类。使用这个类的最简单的方法就是，只要创建一个新实例，并提供想要进行排序的列。然后把这个“排序”（Sort）实例传递给search()方法，如下所示：

Sort sort = new Sort("name");

hits = is.search(query, filter, sort);

除了这个简单示例外，Lucene还提供了一系列广泛的排序功能。只要利用列名字来指定布尔标记，就可以进行逆序排序。这里，我们按名字进行递减排序：

Sort sort = new Sort("name", true);

也可以通过提供一组列名字，对几个列进行排序：

String[] sortOrder = {"lastName","firstName"};

Sort sort = new Sort(sortOrder);

如果需要按每个字段使用不同的排序顺序，就要使用“字段排序”（SortField）类。这里，我们按姓进行递增排序，然后按出生日期朝廷递减排序：

SortField([] sortOrder = {new SortField("lastName"),new SortField("dateOfBirth",true)};

Sort sort = new Sort(sortOrder);

（计算机世界报 2006年12月04日 第47期 B33）

document 文挡对象 - JavaScript脚本语言描述
———————————————————————
注:页面上元素name属性和JavaScript引用的名称必须一致包括大小写
否则会提示你一个错误信息 “引用的元素为空或者不是对象\\\\\”
———————————————————————

对象属性
document.title //设置文档标题等价于HTML的title标签
document.bgColor //设置页面背景色
document.fgColor //设置前景色(文本颜色)
document.linkColor //未点击过的链接颜色
document.alinkColor //激活链接(焦点在此链接上)的颜色
document.vlinkColor //已点击过的链接颜色
document.URL //设置URL属性从而在同一窗口打开另一网页
document.fileCreatedDate //文件建立日期，只读属性
document.fileModifiedDate //文件修改日期，只读属性
document.fileSize //文件大小，只读属性
document.cookie //设置和读出cookie
document.charset //设置字符集 简体中文:gb2312
———————————————————————
常用对象方法
document.write() //动态向页面写入内容
document.createElement(Tag) //创建一个html标签对象
document.getElementById(ID) //获得指定ID值的对象
document.getElementsByName(Name) //获得指定Name值的对象
document.body.appendChild(oTag)
———————————————————————

body-主体子对象
document.body //指定文档主体的开始和结束等价于body>/body>
document.body.bgColor //设置或获取对象后面的背景颜色
document.body.link //未点击过的链接颜色
document.body.alink //激活链接(焦点在此链接上)的颜色
document.body.vlink //已点击过的链接颜色
document.body.text //文本色
document.body.innerText //设置body>…/body>之间的文本
document.body.innerHTML //设置body>…/body>之间的HTML代码
document.body.topMargin //页面上边距
document.body.leftMargin //页面左边距
document.body.rightMargin //页面右边距
document.body.bottomMargin //页面下边距
document.body.background //背景图片

document.body.appendChild(oTag) //动态生成一个HTML对象

常用对象事件
document.body.onclick=”func()” //鼠标指针单击对象是触发
document.body.onmouseover=”func()” //鼠标指针移到对象时触发
document.body.onmouseout=”func()” //鼠标指针移出对象时触发
———————————————————————
location-位置子对象

document.location.hash // #号后的部分
document.location.host // 域名+端口号
document.location.hostname // 域名
document.location.href // 完整URL
document.location.pathname // 目录部分
document.location.port // 端口号
document.location.protocol // 网络协议(http:)
document.location.search // ?号后的部分

documeny.location.reload() //刷新网页
document.location.reload(URL) //打开新的网页
document.location.assign(URL) //打开新的网页
document.location.replace(URL) //打开新的网页
———————————————————————
selection-选区子对象
document.selection
———————————————————————

images集合(页面中的图象)

a)通过集合引用
document.images //对应页面上的img标签
document.images.length //对应页面上img标签的个数
document.images[0] //第1个img标签
document.images[i] //第i-1个img标签

b)通过nane属性直接引用
img name=”oImage”
document.images.oImage //document.images.name属性

c)引用图片的src属性
document.images.oImage.src //document.images.name属性.src

d)创建一个图象
var oImage
oImage = new Image()
document.images.oImage.src=”1.jpg”
同时在页面上建立一个img /标签与之对应就可以显示

———————————————————————-

forms集合(页面中的表单)

a)通过集合引用
document.forms //对应页面上的form标签
document.forms.length //对应页面上/formform标签的个数
document.forms[0] //第1个/formform标签
document.forms[i] //第i-1个/formform标签
document.forms[i].length //第i-1个/formform中的控件数
document.forms[i].elements[j] //第i-1个/formform中第j-1个控件

b)通过标签name属性直接引用
/formform name=”Myform”>input name=”myctrl”/>/form
document.Myform.myctrl //document.表单名.控件名

c)访问表单的属性
document.forms[i].name //对应form name>属性
document.forms[i].action //对应/formform action>属性
document.forms[i].encoding //对应/formform enctype>属性
document.forms[i].target //对应/formform target>属性

document.forms[i].appendChild(oTag) //动态插入一个控件
document.all.oDiv //引用图层oDiv
document.all.oDiv.style.display=”" //图层设置为可视
document.all.oDiv.style.display=”none” //图层设置为隐藏
document.getElementId(”oDiv”) //通过getElementId引用对象
document.getElementId(”oDiv”).style=”"
document.getElementId(”oDiv”).display=”none”
/*document.all表示document中所有对象的集合
只有ie支持此属性，因此也用来判断浏览器的种类*/

图层对象的4个属性
document.getElementById(”ID”).innerText //动态输出文本
document.getElementById(”ID”).innerHTML //动态输出HTML
document.getElementById(”ID”).outerText //同innerText
document.getElementById(”ID”).outerHTML //同innerHTML

【导读】：随着计算机硬件水平的不断提高，计算机软件的规模和复杂度也随之增加。计算机软件开发从“个人英雄”时代向团队时代迈进，计算机软件项目的管理也从“作坊式”管理向“软件工厂式”管理迈进。

　　随着计算机硬件水平的不断提高，计算机软件的规模和复杂度也随之增加。计算机软件开发从“个人英雄”时代向团队时代迈进，计算机软件项目的管理也从“作坊式”管理向“软件工厂式”管理迈进。这就要求软件开发人员特别是软件项目管理人员更深一步地理解和掌握现代软件工程的理论方法，完成思想观念上的转变。笔者在此分析了10个在现代项目管理中思想观念上容易陷入的误区，希望能够抛砖引玉，引发大家更多的思索和讨论。

　　误区1：在项目的需求分析阶段，开发方与客户方在各种的问题的基本轮廓上达成一致即可，具体细节可以在以后填充。因为无论开始时有多么细致， 以后对需求的修改几乎是必然的。分析：这是一种非常危险的思想。实际上许多软件项目失败的最主要的原因就是需求阶段对问题的描述不够细致，导致后来预算超出或者时间 进度达不到要求。正确的做法是：在项目需求分析阶段，双方必须全面地尽可能细致地讨论项目的应用背景、功能要求、性能要求、操作界面 要求、与其他软件的接口要求，以及对项目进行评估的各种评价标准。并且，在需求分析结束以后，双方还要建立可以直接联系的渠道，以尽 早地对需求变动问题进行沟通。

　　误区2：软件项目的需求可以持续不断的改变，而且这些改变可很容易地被实现。分析：的确，在具体实际中由于种种原因客户方很难在需求分析阶段全面而准确地描述所有问题。随着开发进度的推进，往往会有一些需求的 改变。而现代软件工程理论也利用软件的灵活性特点通过各种方式来适应这种情况。不过，这并不表明“软件项目的需求可以持续不断的改变 ，而且这些改变可很容易地被实现”。实践表明：随着开发进度的推进，实现软件需求更改所需要的代价呈指数形式增长。假定在需求分析阶 段实现需求更改需要花费1倍的代价；那么，在系统设计和编码阶段，需要花费1.5-6倍的代价；在系统测试阶段需要花费10-20倍的代价；在软 件版本发布以后，甚至可能要花费60-100倍的代价。由此可见，在项目开展过程中，软件需求的改变应当尽量早地提出。这样才可能花费少， 容易被实现。

　　误区3：软件程序主要由代码组成，因此编码阶段是整个软件项目的最重要的阶段，应该给与大量的时间，并且集中主要的资源。分析：与以前相比，由于软件的规模和复杂度的增加，以及半自动化软件代码开发平台的出现，现代软件项目管理的中心发生了转移——不是 着重编码阶段，而是着重系统总体/详细设计阶段。一般说来，在现代软件项目管理中各种资源的合理分配比例是：项目论证、风险评估阶段3% ，项目需求分析阶段8%，系统总体/详细设计阶段45%，编码阶段10%，系统测试阶段34%.误区4：为了便于代码的维护修改，在系统的详细设计阶段文档工作应该做到写出所有程序的伪码。分析：通常伪码的最大作用是对程序的算法流程进行描述，便于人们深入了解程序的功能和实现过程。可见，在一定程度上伪码的确有利于对 程序代码的维护和修改。但是，我们知道为了保证项目文档和程序代码的一一对应关系，维护程序代码的时候同时需要对项目文档进行维护。伪码和程序代码是非常接近的，对伪码进行维护的话，相当于进行了2倍的程序代码维护。工作量是很大的。所以切合实际的方式应该是对一般 的程序文档做到程序流程图即可，对于涉及了较复杂算法的才需要伪码。

 

转自：http://it.sohu.com/20090226/n262480207.shtml