CSS 与 打印控制

• 搜狐网站诚聘Java、PHP和C++工程师
• 北京: 千橡集团暨校内网诚聘软件研发工程师

• 北京: 千橡集团暨校内网诚聘软件研发工程师
• 搜狐网站诚聘Java、PHP和C++工程师

昨天买了第七个手机，然后发现自己买过的7个手机居然都是不同牌子的，
真巧。。。以下排名分先后

科健 GSM
西门子 GSM
诺基亚 GSM
普天 小灵通
中兴 小灵通
三星 CDMA
摩托罗拉 CDMA

• 北京: 千橡集团暨校内网诚聘软件研发工程师
• 搜狐网站诚聘Java、PHP和C++工程师

• 北京: 千橡集团暨校内网诚聘软件研发工程师
• 搜狐网站诚聘Java、PHP和C++工程师

• 北京: 千橡集团暨校内网诚聘软件研发工程师
• 搜狐网站诚聘Java、PHP和C++工程师

在lucene的search包下面发现一个新的类 MultiPhraseQuery

大致作用，猜测可以实现以下功能：

本来，要实现 "a (b|c|d) e" 这样一个语意的Query ，我猜测需要用 "a b e", "a c e" ,"a d e"三个PhraseQuery

来实现， 现在MultiPhraseQuery实现了这样一个方法  

public void add(Term[] terms, int position)

也就是说，可以在原来的PhraseQuery中的任意位置添加更多的term

于是也就可以方便的实现"a (b|c|d) e"这样的查询语意了。 

总结： MultiPhraseQuery是个很不错的新功能

• 搜狐网站诚聘Java、PHP和C++工程师
• 北京: 千橡集团暨校内网诚聘软件研发工程师

原文地址 ：http://wiki.apache.org/lucene-java/ImproveIndexingSpeed 

How to make indexing faster

Here are some things to try to speed up the indexing speed of your Lucene application. Please see ImproveSearchingSpeed for how to speed up searching.

Be sure you really need to speed things up.

Many of the ideas here are simple to try, but others will necessarily add some complexity to your application. So be sure your indexing speed is indeed too slow and the slowness is indeed within Lucene.

Make sure you are using the latest version of Lucene.

Use a local filesystem.

Remote filesystems are typically quite a bit slower for indexing. If your index needs to be on the remote fileysystem, consider building it first on the local filesystem and then copying it up to the remote filesystem.

Get faster hardware, especially a faster IO system.

Open a single writer and re-use it for the duration of your indexing session.

Flush by RAM usage instead of document count.

Call  writer.ramSizeInBytes() after every added doc then call  flush() when it's using too much RAM. This is especially good if you have small docs or highly variable doc sizes. You need to first set  maxBufferedDocs large enough to prevent the writer from flushing based on document count. However, don't set it too large otherwise you may hit  LUCENE-845. Somewhere around 2-3X your "typical" flush count should be OK.

Use as much RAM as you can afford.

More RAM before flushing means Lucene writes larger segments to begin with which means less merging later. Testing in  LUCENE-843 found that around 48 MB is the sweet spot for that content set, but, your application could have a different sweet spot.

Turn off compound file format.

Call  setUseCompoundFile(false). Building the compound file format takes time during indexing (7-33% in testing for  LUCENE-888). However, note that doing this will greatly increase the number of file descriptors used by indexing and by searching, so you could run out of file descriptors if mergeFactor is also large.

Re-use Document and Field instances

As of Lucene 2.3 (not yet released) there are new setValue(...) methods that allow you to change the value of a Field. This allows you to re-use a single Field instance across many added documents, which can save substantial GC cost.

It's best to create a single Document instance, then add multiple Field instances to it, but hold onto these Field instances and re-use them by changing their values for each added document. For example you might have an idField, bodyField, nameField, storedField1, etc. After the document is added, you then directly change the Field values (idField.setValue(...), etc), and then re-add your Document instance.

Note that you cannot re-use a single Field instance within a Document, and, you should not change a Field's value until the Document containing that Field has been added to the index. See  Field for details.

Re-use a single Token instance in your analyzer

Analyzers often create a new Token for each term in sequence that needs to be indexed from a Field. You can save substantial GC cost by re-using a single Token instance instead.

Use the char[] API in Token instead of the String API to represent token Text

As of Lucene 2.3 (not yet released), a Token can represent its text as a slice into a char array, which saves the GC cost of new'ing and then reclaiming String instances. By re-using a single Token instance and using the char[] API you can avoid new'ing any objects for each term. See  Token for details.

Use autoCommit=false when you open your IndexWriter

In Lucene 2.3 (not yet released), there are substantial optimizations for Documents that use stored fields and term vectors, to save merging of these very large index files. You should see the best gains by using autoCommit=false for a single long-running session of IndexWriter. Note however that searchers will not see any of the changes flushed by this IndexWriter until it is closed; if that is important you should stick with autoCommit=true instead or periodically close and re-open the writer.

Instead of indexing many small text fields, aggregate the text into a single "contents" field and index only that (you can still store the other fields).

Increase  mergeFactor, but not too much.

Larger  mergeFactors defers merging of segments until later, thus speeding up indexing because merging is a large part of indexing. However, this will slow down searching, and, you will run out of file descriptors if you make it too large. Values that are too large may even slow down indexing since merging more segments at once means much more seeking for the hard drives.

Turn off any features you are not in fact using.

If you are storing fields but not using them at query time, don't store them. Likewise for term vectors. If you are indexing many fields, turning off norms for those fields may help performance.

Use a faster analyzer.

Sometimes analysis of a document takes alot of time. For example, StandardAnalyzer is quite time consuming. If you can get by with a simpler analyzer, then try it.

Speed up document construction.

Often the process of retrieving a document from somewhere external (database, filesystem, crawled from a Web site, etc.) is very time consuming.

Don't optimize unless you really need to (for faster searching).

Use multiple threads with one IndexWriter.

Modern hardware is highly concurrent (multi-core CPUs, multi-channel memory architectures, native command queuing in hard drives, etc.) so using more than one thread to add documents can give good gains overall. Even on older machines there is often still concurrency to be gained between IO and CPU. Test the number of threads to find the best performance point.

Index into separate indices then merge.

If you have a very large amount of content to index then you can break your content into N "silos", index each silo on a separate machine, then use the writer.addIndexesNoOptimize to merge them all into one final index.

Run a Java profiler.

If all else fails, profile your application to figure out where the time is going. I've had success with a very simple profiler called  JMP. There are many others. Often you will be pleasantly surprised to find some silly, unexpected method is taking far too much time.

• 北京: 千橡集团暨校内网诚聘软件研发工程师
• 搜狐网站诚聘Java、PHP和C++工程师

    中国国企改革蠹虫肆虐，教育改革成本由穷人负担，医疗改革基本失败，三农问题怵目惊心，弱势群体诉诸司法时又遭遇司法不公等等。中国处于最原始的人吃人的初期资本主义阶段，国内和谐化是当务之急。必须解决政府腐败低效问题，以严刑峻法实行法治。

• 搜狐网站诚聘Java、PHP和C++工程师
• 北京: 千橡集团暨校内网诚聘软件研发工程师

问：

Is it possible to turn off directory locking with BDB?  How is the performance
compared to regular FSDirectory for queries?

答：

If you're thinking of using Berkeley DB as a the store behind the Lucene index
via the DbDirectory Directory implementation, here are a few things to keep in
mind:

   - always setUseCompoundFile(false)
     don't use compound lucene index files on top of Berkeley DB:
      . there is a bug that prevents this from working correctly
      . it makes no sense anyway since it duplicates what DbDirectory is
        already doing (all index files are stored in the same Berkeley DB file)
      . it slows things down

   - if you are using a transaction around all the index updates, you may want
     to consider doing all the index updates in a RAMDirectory first and then
     adding the RAMDirectory wholesale to the DbDirectory in that transaction.
     This makes indexing considerably faster (3 times for me) and does a LOT
     less thrashing around in Berkeley DB which can lead to a large number of
     transactional log files rapidly filling up your hard drive.

I'm not really sure if and how index merging works. For my use, having no
merging is good enough since I never update existing documents, but always
instead add a new version of them. The concept of version is tied to my
application and each transaction corresponds to a new version.

• 北京: 千橡集团暨校内网诚聘软件研发工程师
• 搜狐网站诚聘Java、PHP和C++工程师

4层架构

1 客户端

负责接收用户发出的搜索请求， 转发到后端 “分发服务器”

2 分发服务器

分发服务器 接收到客户端发出的搜索请求后，根据不同的客户端类型（不同来源的搜索请求），把请求转发到

不同的“业务总控服务器”。

3业务总控服务器

业务总控服务器连接到各个具体业务的服务器， 接受到分发服务器发过来的搜索请求之后， 经过业务总线

（缓存，搜索，相关搜索，定制搜索，竞价排名等等业务，组成业务流水线），组装成搜索结果，返回给分发服务器，

由分发服务器把搜索结果返回给客户端，呈现给用户。

4.业务服务器

从业务总控服务器收到搜索请求后， 由自身或者结合其他辅助服务器完成业务，将结果返回给业务总控服务器。

• 搜狐网站诚聘Java、PHP和C++工程师
• 北京: 千橡集团暨校内网诚聘软件研发工程师