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层面实现。