LinSoo 的最新版本是基于Hubble.net 技术衍生而来。
Hubble.net 是一个基于.net framework 的开源免费的全文搜索数据库组件。开源协议是 Apache 2.0。Hubble.net提供了基于SQL的全文检索接口，使用者只需会操作SQL，就可以很快学会使用Hubble.net进行全文检索。 Hubble.net可以实现全文索引和查询、多域检索和排序、分组统计、消重、分类、聚类、多表关联查询等等一系列全文检索和数据挖掘功能。 Hubble.net提供开放的数据库适配器接口，可以和各种数据库完美整合，为各种数据库系统附加全文检索和数据挖掘功能。 Hubble.net设计了较为完善的并发控制程序，数据的增删改查可以多线程同时并发进行，没有任何冲突。Hubble.net还进行了缓存和内存管理设计，可以帮助用户最大限度的提高查询的效率。Hubble.net力争在未来的几年内超过Lucene.net成为.net开发环境中最受欢迎的全文检索组件。基本功能有：1. 索引、2. 查询、3. 删除、4. 更新、5. 基于 SQL 的SQLClient 接口、6. 索引级别缓存、7. 查询级别缓存、8. 数据级别缓存、9. 多字段排序、10. 全文和元数据组合查询、11. 关键字权重指定、12. 字段权重指定、13. 记录权重指定、14. 索引自动优化、15. 索引手工优化、16. 自定义分词器、17. 自定义数据库适配器、18. 系统存储过程、19. 查询分析器、20. 建表，删表、21. 基于数据库现有表或视图创建索引、22. 和数据库现有表或视图索引同步、23. 分组统计、24. Match, Contains, Like 三种查询方式、25. 拆离和附加 （备份和恢复）索引。
Hubble.net 将全文搜索和关系数据库整合到一起，通过SQL语句对数据库中的数据进行全文和关系查询。Hubble.net组件本身负责对全文数据进行倒排索引，并将索引存储到表所指定的目录下，数据的存储则由和Hubble.net 关联的关系数据库完成。Hubble.net提供了一个 IDBAdpter 接口，用户可以根据这个接口实现自定义的数据库适配。如何添加自定义的数据库适配器，将在存储过程一节中阐述。建立倒排索引时需要对输入的全文文本进行分词，Hubble.net为用户提供了一个 IAnalyzer 接口来完成自定义的分词器。如何添加自定义的分词器，将在存储过程一节中阐述。Hubble.net在安装后以一个系统服务的形式存在。Hubble.net 提供一个 Hubble.SQLClient 组件来和Hubble.net的系统服务进行交互，SQLClient 的接口和Ado.net 中的SqlClient接口类型，具体将在SQLClient一节中阐述。
Hubble.net 和 关系数据库一样，存在数据库和数据库表的概念。Hubble.net 的数据库和数据表只是提供一个和对应关系数据库的映射描述关系，并不存在数据库和数据表的实体。用户在通过SQL 语句操作Hubble.net 的数据库和数据表是，Hubble.net 将自动和对应的关系数据库实体进行关联，从用户侧看，Hubble.net就像一个数据库实体。
Hubble.net负责建立文本字段的倒排索引和Untokenized字段的单值索引。关系数据库负责建立B+树索引。如果查询语句不包括对全文字段的搜索，则直接转发给数据库利用数据库的索引进行查询。
如上图所示，Hubble.net提供三种级别的缓存方案。
Index cache ：索引级别缓存用于缓存倒排索引和单值索引。这种缓存为系统自动管理，不能关闭。索引级别缓存会自动监控数据的增删改，并进行相应修改。
Query cache ：查询级别缓存对查询的条件进行缓存，Hubble.net 系统服务会将不同查询条件对应的文档ID（DocId）缓存下来，下次查询时直接从缓存中获取符合条件的文档ID，不再访问低级别缓存或索引。和索引级别缓存不同的是，当表的数据发生变化时，查询级别缓存将会失效，需要重新缓存。
Data cache ：数据级别缓存运行在客户端，客户端查询得到的数据被缓存下来，下次查询时将从数据缓存中直接获取数据，而不再到Hubble.net 系统服务中去获取数据。和查询级别缓存一样，表的数据发生变化时，数据级别缓存将会失效，需要重新缓存。
Hubble.net设计了非常完善的并发控制机制，用户的增删改查可以同时进行，不会存在任何冲突。
Hubble.net 以系统服务存在，不会像Lucene那样和应用程序共用内存。Hubble.net设计了一套内存管理机制，用户可以设置最大内存使用数量，一旦 Hubble.net使用内存超过这个数量，Hubble.net就会自动启动内存整理程序，将一些不经常使用的缓存从内存中清理掉以腾出更多的内存空间给用户。用户可以通过 SP_CONFIGURE 存储过程来查看和管理内存。
采用当今最流行的盘古分词法对关键内容进行分词处理，建立专门的分词索引数据库。
盘古分词可以对一些不在字典中的未登录词自动识别词频优先。
盘古分词可以根据词频来解决分词的歧义问题。
盘古分词在中文人名识别上较以前任何分词法取得了较大突破，这里简单演示一下中文人名的识别效果：
输入： “张三说的确实在理”
分词结果：张三/说/的/确实/在理/
但是如果输入： “李三买了一张三角桌子”
分词结果： 李三/买/了/一张/三角/桌子/
这里可以在第一个句子中盘古分词识别出张三是一个人名，从而按照人名输出了这个词，而第二句中盘古分词识别出其句子中包含的张三并不是一个人名，从而没有按中文人名来输出这个词。
有的项目需要在输出精确分词结果的同时输出单个汉字，从而保证搜索组件可以按照任意颗粒度来搜索文本。盘古分词提供了这种功能，分词结果中精确分词的权值较高，单个汉字的权值较低，通过权值的设置可以知道搜索组件找到最匹配的结果。
如 “张三说的确实在理”
分词结果： 张(0,1)/张三(0,5)/三说的(1,1)/三(1,1)/说(2,5)/的(3,5)/确(4,1)/确实(4,5)/实(5,1)/在(6,1)/在理(6,5)/理(7,1)/
括号里面第一个数字表示单词在句子中的位置，第二个数字表示权值。
盘古分词提供了对繁体中文分词的支持。国内很多站内搜索对繁体中文分词支持不是特别好，这其中就包括博客园的找找看。你可以在找找看中输出 "我的選擇"，你会发现只找到一条匹配的记录，该匹配记录匹配的是 "我的選擇" 这个整词，但如果你输入"我的 選擇" 这时就能搜到包括"我的" 和 " 選擇" 的所有记录。从这个测试中可以分析博客园的找找看在处理繁体中文时是简单根据空格或者一些符号来分割的，无法分解连续的汉字。
盘古分词可以实现繁体中文的分词
还是输入"我的選擇"
分词结果是： 我/的/選擇/
如果你用google 搜 "我的選擇",你会发现它可以同时将简体和繁体的 "我的選擇" 全部搜出来。要实现这个功能，就必须在分词时同时将简繁两种汉字输出。
还是输入"我的選擇"
分词结果是：我(0,5)/的(1,5)/选择(2,1)/選擇(2,5)/
盘古分词可以将以登录词的中文词性输出给用户，以方便用户做进一步处理。
盘古分词可以识别全角的字母和数字
英文单词通常都是靠空格等符号分割，这个比较简单，盘古分词分英文自然也没有什么问题。
一些英文简写是字母符号混合，或者是字母数字混合，这个分词起来就不能按照空格符号这样分割了，对于字母符号混合的如 U.S.A ，只要将这个词录入到字典中，盘古分词就可以分出整词。对于字母和数字混合的，盘古分词会自动作为整词输出。
对于一些标点符号，连词，助词等有时候需要在分词时过滤掉，盘古分词提供一个 StopWord.txt 文件，用户只要将需要过滤的词加入到这个文件中，并将停用词过滤开发打开，就可以过滤掉这些词。
盘古分词可以让用户对如下特性设置自定义权值:
未登录词权值
最匹配词权值
次匹配词权值
再次匹配词权值
强行输出的单字的权值
数字的权值
英文词汇权值
符号的权值
强制同时输出简繁汉字时，非原来文本的汉字输出权值。
Core Duo 1.8 GHz 下单线程 分词速度为 390K 字符每秒，2线程分词速度为 690K 字符每秒。
盘古分词提供的字典包括17万个中文常用单词，但这个字典依然不够完整，如果要分词更准确，需要适当维护一下这个字典。
中文人名的识别能力取决于 ChsSingleName.txt， ChsDoubleName1.txt， ChsDoubleName2.txt 这三个文件，它们分别表示单子人名，双字人名的首字和双字人名的尾字，如果有的人名没有分出来，需要维护这三个文件。
