日期:2014-05-16  浏览次数:20468 次

LucenceSE的设计选择

需要选择的有两个设计方案

?

简单化的Storage Engine,用某种RPC机制(比如ICE)调用另一个Java写的Lucene服务

优点:

  1. Highly scalable,假设RPC机制使用ICE实现,scalability在ICEGrid上已经实现了。
  2. 实现代码简单。Storage Engine端调用ICE接口,Java进程(Lucence服务)实现ICE接口。
  3. 无技术风险。

缺点:

  1. MySQL中的LuceneSE的表字段可能和LuceneSE服务的索引字段不符。(可能是索引是已经存在的,可能是MySQL表字段写错,可能是连接上了错误的服务)。因为概念模型中,MySQL服务和LuceneSE服务是独立的,容易让人误用。
  2. 需要在发布包中加入RPC的库(比如ICE),LuceneSE的使用者(和代码阅读者)需要多知道一件事。RPC库本身的复杂性不可忽略。
  3. 更新代码时,需要同时更新MySQL端和服务端代码。

在Storage Engine里面做所有事情,用JNI起Java虚拟机,直接使用Java调用Lucene建立和使用索引

优点:

  1. 思路简单明了。
  2. 这种机制从模式(或是从使用者心理预期)上假设了索引只能通过MySQL的接口来建立。从概念上避免了MySQL表字段和索引字段的不一致性。

缺点:

  1. JNI调用Java的代码非常的冗繁。
  2. 尚不清楚JNI接口是否对所有的Java虚拟机(Sun,IBM,BEA)都通用,如果是需要用 .h+.lib/.a连编的话,接口能通用的概率就很小了。当然不排除JNI作为通用接口被各家的虚拟机所实现。
  3. 需要加入jni.h这样的代码一起发布,小小不爽。(或是在configure中要求java-devel?)
  4. 完全失去索引层面的scalability,只能在MySQL层面实现。

?

?

?