国产一级a片免费看高清,亚洲熟女中文字幕在线视频,黄三级高清在线播放,免费黄色视频在线看

對(duì)于用慣數(shù)據(jù)庫(kù)的我們，多表進(jìn)行join連接，是非常常見的一個(gè)需求，但是在我們的索引中，對(duì)join的支持，卻不是很完美，當(dāng)然這并不是由于我們的Lucene或Solr不夠強(qiáng)大，而是全文檢索與數(shù)據(jù)庫(kù)的定位不是在同一個(gè)目標(biāo)上，全文檢索，主要定位在搜索引擎上，通常是對(duì)一個(gè)大的索引進(jìn)行高效檢索，而數(shù)據(jù)庫(kù)則是定位在結(jié)構(gòu)化數(shù)據(jù)的存儲(chǔ)于與檢索，檢索功能比較薄弱，那我們的索引是不是就不支持join了，實(shí)事并非如此，Lucene里面支持join操作，這種join定位在同一份索引里，而Solr作為L(zhǎng)ucene的擴(kuò)展，又提供了兩core join的功能，下面散仙給出一個(gè)例子，盡量簡(jiǎn)單，清晰的描述出如何使用它們和理解它們的工作方式。



散仙，有2個(gè)core，分別是collection1，和collection2，里面的數(shù)據(jù)分別是：
collection1:總共有3條數(shù)據(jù)
collection1：schema 都是字符串string ;  有id，name兩個(gè)字段 ;
collection1： {1, Apple}, {2, Samsung}, {3, HTC}

collection2:總共有5條數(shù)據(jù)
collection2:schema 都是字符串string ;有id,name,brand_id 兩個(gè)字段;
collection2: {1, iPhone, 1}, {2, iPad, 1}, {3, Galaxy S3, 2}, {4, Galaxy Note, 2}, {5, One X, 3}


下面，先來看下單core的join，以collection2作為例子，測(cè)試代碼如下：

<pre name="code" class="java">
/***
* join測(cè)試
*
*
* ***/
public static void joinquery2()throws Exception{
SolrServer server1=new HttpSolrServer("http://localhost:9003/solr/collection2");
SolrQuery sq=new SolrQuery();
//sq.set("fl", "id,name");//過濾只需要返回的字段
sq.set("q", "{!join from=id  to=brand_id }brand_id:*");
QueryResponse qr=server1.query(sq, METHOD.POST);
SolrDocumentList list=qr.getResults();
System.out.println("命中結(jié)果集："+qr.getResults().size());
for(SolrDocument s:list){
System.out.println(s.toString());
}
}</pre>
運(yùn)行結(jié)果如下：
<pre name="code" class="java">五月 14, 2014 9:03:58 下午 org.apache.solr.client.solrj.impl.HttpClientUtil createClient
INFO: Creating new http client, config:maxConnections=128&maxConnectionsPerHost=32&followRedirects=false
命中結(jié)果集：5
SolrDocument{id=1, name=iPhone, brand_id=1, _version_=1468079557386960896}
SolrDocument{id=2, name=iPad, brand_id=1, _version_=1468079557408980992}
SolrDocument{id=3, name=Galaxy, brand_id=2, _version_=1468079557412126720}
SolrDocument{id=4, name=Galaxy Note, brand_id=2, _version_=1468079557416321024}
SolrDocument{id=5, name=One X, brand_id=3, _version_=1468079557420515328}
</pre>
改變，條件后，再測(cè)：
<pre name="code" class="java">/***
* join測(cè)試
*
*
* ***/
public static void joinquery2()throws Exception{
SolrServer server1=new HttpSolrServer("http://localhost:9003/solr/collection2");
SolrQuery sq=new SolrQuery();
//sq.set("fl", "id,name");//過濾只需要返回的字段
sq.set("q", "{!join from=id  to=brand_id }brand_id:2");
QueryResponse qr=server1.query(sq, METHOD.POST);
SolrDocumentList list=qr.getResults();
System.out.println("命中結(jié)果集："+qr.getResults().size());
for(SolrDocument s:list){
System.out.println(s.toString());
}
}</pre>

運(yùn)行結(jié)果如下：
<pre name="code" class="java">五月 14, 2014 9:10:04 下午 org.apache.solr.client.solrj.impl.HttpClientUtil createClient
INFO: Creating new http client, config:maxConnections=128&maxConnectionsPerHost=32&followRedirects=false
命中結(jié)果集：1
SolrDocument{id=5, name=One X, brand_id=3, _version_=1468079557420515328}
</pre>
分析運(yùn)行原理，類似sql中的寫法：

SELECT *
FROM collection1
WHERE brand_id IN (SELECT id FROM collection1 where brand_id = * )

第一步，先執(zhí)行子查詢SELECT id FROM collection1 where brand_id = *
會(huì)返回所有的id分別是，1,2,3,4,5
第二步，執(zhí)行主查詢就是

SELECT *
FROM collection1
WHERE brand_id  in (1,2,3,4,5)

而brand_id去重完之后，就只有1,2,3了，所以轉(zhuǎn)換成如下查詢：
SELECT *
FROM collection1
WHERE  brand_id(1,2,3)  in (1，2,3,4,5)

取并集后結(jié)果，就會(huì)命中brand_id=1,2,3的文檔，所以就命中了所有的文檔


再來分析下，第二個(gè)查詢，指定查詢id的join：
第一步，先執(zhí)行子查詢SELECT id FROM collection1 where brand_id = 2
會(huì)返回所有的id分別是，3,4,
第二步，執(zhí)行主查詢就是

SELECT *
FROM collection1
WHERE brand_id  in (3,4)

而brand_id去重完之后，就只有1,2,3了，所以轉(zhuǎn)換成如下查詢：
SELECT *
FROM collection1
WHERE  brand_id(1,2,3)  in  brand_id(3,4)

取并集后的結(jié)果，就會(huì)命中brand_id=3的文檔了，所以就會(huì)返回ID為5的文檔；




下面，來測(cè)下，兩個(gè)core的join，代碼如下：<pre name="code" class="java">/***
* join測(cè)試
*
*
* ***/
public static void joinquery2()throws Exception{
SolrServer server1=new HttpSolrServer("http://localhost:9003/solr/collection1");
SolrQuery sq=new SolrQuery();
//sq.set("fl", "id,name");//過濾只需要返回的字段
sq.set("q", "{!join from=brand_id to=id fromIndex=collection2}name:iPad");
QueryResponse qr=server1.query(sq, METHOD.POST);
SolrDocumentList list=qr.getResults();
System.out.println("命中結(jié)果集："+qr.getResults().size());
for(SolrDocument s:list){
System.out.println(s.toString());
}
}</pre>
結(jié)果如下：
<pre name="code" class="java">五月 14, 2014 9:30:41 下午 org.apache.solr.client.solrj.impl.HttpClientUtil createClient
INFO: Creating new http client, config:maxConnections=128&maxConnectionsPerHost=32&followRedirects=false
命中結(jié)果集：1
SolrDocument{id=1, name=Apple, _version_=1468079556974870528}
</pre>
分析類似如下SQL：

SELECT b.* FROM  collection1 b
       INNER JOIN collection2 p ON b.id=p.brand_id
       WHERE p.name="iPad";

注意collection名的先后順序，如上solrj里面的執(zhí)行，跟上面的sql的運(yùn)行規(guī)則是一樣的，所以我們最終的結(jié)果里，會(huì)返回，如果我們的條件是下面的相反組合：



<pre name="code" class="java">public static void joinquery()throws Exception{
SolrServer server1=new HttpSolrServer("http://localhost:9003/solr/collection2");
SolrQuery sq=new SolrQuery();
sq.set("q", "{!join from=id to=brand_id fromIndex=collection1}id:1");
QueryResponse qr=server1.query(sq, METHOD.POST);
SolrDocumentList list=qr.getResults();
System.out.println("命中結(jié)果集："+qr.getResults().size());
for(SolrDocument s:list){
//s.toString();
System.out.println(s.toString());
}</pre>

則運(yùn)行結(jié)果如下所示：
<pre name="code" class="java">五月 14, 2014 9:43:46 下午 org.apache.solr.client.solrj.impl.HttpClientUtil createClient
INFO: Creating new http client, config:maxConnections=128&maxConnectionsPerHost=32&followRedirects=false
命中結(jié)果集：2
SolrDocument{id=1, name=iPhone, brand_id=1, _version_=1468079557386960896}
SolrDocument{id=2, name=iPad, brand_id=1, _version_=1468079557408980992}
</pre>
原理，依舊與如上的sql一樣。只不過位置相反，調(diào)整了：

SELECT b.* FROM  collection2 b
       INNER JOIN collection1 p ON b.id=p.brand_id
       WHERE b.id=1;