LucenceSE的设计选择
需要选择的有两个设计方案
?
简单化的Storage Engine,用某种RPC机制(比如ICE)调用另一个Java写的Lucene服务
优点:
- Highly scalable,假设RPC机制使用ICE实现,scalability在ICEGrid上已经实现了。
- 实现代码简单。Storage Engine端调用ICE接口,Java进程(Lucence服务)实现ICE接口。
- 无技术风险。
缺点:
- MySQL中的LuceneSE的表字段可能和LuceneSE服务的索引字段不符。(可能是索引是已经存在的,可能是MySQL表字段写错,可能是连接上了错误的服务)。因为概念模型中,MySQL服务和LuceneSE服务是独立的,容易让人误用。
- 需要在发布包中加入RPC的库(比如ICE),LuceneSE的使用者(和代码阅读者)需要多知道一件事。RPC库本身的复杂性不可忽略。
- 更新代码时,需要同时更新MySQL端和服务端代码。
在Storage Engine里面做所有事情,用JNI起Java虚拟机,直接使用Java调用Lucene建立和使用索引
优点:
- 思路简单明了。
- 这种机制从模式(或是从使用者心理预期)上假设了索引只能通过MySQL的接口来建立。从概念上避免了MySQL表字段和索引字段的不一致性。
缺点:
- JNI调用Java的代码非常的冗繁。
- 尚不清楚JNI接口是否对所有的Java虚拟机(Sun,IBM,BEA)都通用,如果是需要用 .h+.lib/.a连编的话,接口能通用的概率就很小了。当然不排除JNI作为通用接口被各家的虚拟机所实现。
- 需要加入jni.h这样的代码一起发布,小小不爽。(或是在configure中要求java-devel?)
- 完全失去索引层面的scalability,只能在MySQL层面实现。
?
?
?