[coreseek/sphinx學習筆記3]--創建索引

[參考Coreseek 全文檢索服務器 2.0 (Sphinx 0.9.8)參考手冊，詳情見 http://www.coreseek.cn/docs/sphinx_doc_zhcn_0.9.pdf ] 

3.1 數據源
    索引數據是一個結構化的文檔的集合，其中每一個文檔是字段的集合。
    若是確有必要，一個索引的數據能夠來自多個數據源。這些數據將嚴格按照配置文件中定義的順序進行處理。全部從這些數據源獲取到的文檔將被合併，共同產生一個索引，如同他們來源於同一個數據源同樣。

3.2 屬性
    屬性是附加在每一個文檔上的額外的信息（值），能夠在搜索的時候用於過濾和排序。目前支持的屬性類型以下：
    無符號整數（1-32 位寬）
    UNIX 時間戳（timestamps）
    浮點值（32 位，IEEE 754 單精度）
    字符串敘述 (尤爲是計算出的整數值);
    多值屬性 MVA（multi-value attributes）（32 位無符號整形值的變長序列）.

3.3 多值屬性 MVA
    多值屬性 MVA(multi-valued attributes)是文檔屬性的一種重要的特例，MVA 使得向文檔附加一系列的值做爲屬性的想法成爲可能。這對文章的 tags，產品類別等等很是有用。MVA 屬性支持過濾和分組（但不支持分組排序）。目前 MVA 列表項的值被限制爲 32 位無符號整數。列表的長度不受限制，只要有足夠的RAM，任意個數的值均可以被附加到文檔上（包含 MVA 值的.spm 文件會被 searchd 預緩衝到 RAM 中）

3.4 索引
    目前在 Sphinx 中實現的惟一一種索引類型是爲優化創建索引和檢索的速度而設計的。隨之而來的代價是更新索引至關的很慢。理論上講，更新這種索引甚至可能比從頭重建索引還要慢。不過大多數狀況下這能夠靠創建多個索引來解決索引更新慢的問題

3.5 源數據的限制
    Sphinx 索引的源數據有一些限制，其中最重要的一條是： 全部文檔的 ID 必須是惟一的無符號非零整數（根據 Sphinx 構造時的選項，多是 32 位或64 位）

3.6 字符集、大小寫轉換和轉換表
    當創建索引時，Sphinx 從指定的數據源得到文本文檔，將文本分紅詞的集合，再對每一個詞作大小寫轉換，因而「Abc」，「ABC」和「abc」都被看成同一個詞（word，或者更學究一點，詞項 term）爲了正確完成上述工做，Sphinx 須要知道：
（1）源文本是什麼編碼的
（2）那些字符是字母，哪些不是
（3）哪些字符須要被轉換，以及被轉換成什麼

3.7 SQL 數據源 (MySQL, PostgreSQL)
    對於全部的 SQL 驅動，創建索引的過程以下：
（1）鏈接到數據庫
（2）執行預查詢，以便完成全部必須的初始設置，好比爲 MySQL 鏈接設置編碼
（3）執行主查詢，其返回的的數據將被索引
（4）執行後查詢，以便完成全部必須的清理工做
（5）關閉到數據庫的鏈接
（6）對短語進行排序 (或者學究一點, 索引類型相關的後處理)
（7）再次創建到數據庫的鏈接
（8）執行後索引查詢，以便完成全部最終的清理工做
（9）再次關閉到數據庫的鏈接
大多數參數是很直觀的，例如數據庫的用戶名、主機、密碼。不過，還有一些細節上的問題須要討論。

分區查詢：
    Sphinx 須要經過主查詢來獲取所有的文檔信息，一種簡單的實現是將整個表的數據讀入內存，可是這可能致使整個表被鎖定並使得其餘操做被阻止（例如：在 MyISAM 格式上的 INSERT操做），同時，將浪費大量內存用於存儲查詢結果，諸如此類的問題吧。爲了不出現這種狀況，Sphinx 支持一種被稱做「分區查詢」的技術。首先，Sphinx 從數據庫中取出文檔 ID的最小值和最大值，將由最大值和最小值定義天然數區間分紅若干份，一次獲取數據，創建索引。

後查詢（sql_post） vs. 索引後查詢（sql_post_index）：
    後查詢和索引後查詢的區別在於，當 Sphinx 獲取到所有文檔數據後，當即執行後查詢，可是構建索引的過程仍然可能由於某種緣由失敗。在另外一方面，當索引後查詢被執行時，可理所固然的認爲索引已經成功構造完了。由於構造索引多是個漫長的過程，所以對與數據庫的鏈接在執行後索引操做後被關閉，在執行索引後操做前被再次打開。

3.8  xmlpipe 數據源
    xmlpipe 數據源是處於讓用戶可以將現有數據嵌入 Sphinx 而無需開發新的數據源驅動的目的被設計和提供的。它將每篇文檔限制爲只能包括兩個可全文索引的字段，以及只能包括兩個屬性。xmlpipe 數據源已經被廢棄

3.9 xmlpipe2 數據源
    數據模式，即數據字段和屬性的完整列表，必須在任何文檔被分析以前就肯定。這既能夠在配置文件中用 xmlpipe_field 和 xmlpipe_attr_xxx 選項指定，也能夠就在數據流中用<sphinx:schema>元素指定。 <sphinx:schema>元素是可選的，但若是出現，就必須是<sphinx:docset>元素的第一個子元素。若是沒有在數據流中內嵌的數據模式定義，配置文件中的相關設置就會生效，不然數據流內嵌的設置被優先採用。

xmlpipe2 能夠識別的 XML 元素（標籤）（以及前述元素可用的屬性）以下：
（1）sphinx:docset 頂級元素，用於標明幷包括 xmlpipe2 文檔。
（2）Sphinx:schema 可選元素，它要麼是 sphinx:docset 的第一個子元素，要麼乾脆不出現。聲明文檔的模式。包括數據字段和屬性的聲明。若此元素出現，則它會覆蓋配置文件中對數據源的設定。
（3）Sphinx:field 可選元素，sphinx:schema 的子元素。聲明一個全文數據字段。惟一可識別的屬性是「name」，它指定了字段的名稱，後續數據文檔中具備此名稱的元素的數據都被看成待檢索的全文數據對待。
（4）sphinx:attr 可選元素，sphinx:schema 的子元素。用於聲明具體屬性。其已知的屬性有：
    ● 「name」，設定該屬性名稱，後續文檔中具備該名稱的元素應被看成一個屬性對待。
    ● 」type」，設定該屬性的類型。可能的類型包括「int」，「timestamp」，「str2ordinal」，「bool」和「float」
    ● 「bits」，設定「int」型屬性的寬度，有效值爲 1 到 32
    ● 「default」，設定該屬性的默認值，若後續文檔中沒有指定這個屬性，則使用此默認值。
（5）Sphinx:document 必須出現的元素，必須是 sphinx:docset 的子元素。包含任意多的其餘元素，這些子元素帶有待索引的數據字段和屬性值，而這些數據字段或屬性值既能夠是用 sphinx:field和 sphinx:attr 元素聲明的，也能夠在配置文件中聲明。惟一的已知屬性是「id」，它必須包含一個惟一的整型的文檔 ID。

3.10 實時索引更新
    有這麼一種常見的狀況：整個數據集很是大，以致於難於常常性的重建索引，可是每次新增的記錄卻至關地少。一個典型的例子是：一個論壇有 1000000 個已經歸檔的帖子，但天天只有 1000 個新帖子。
在這種狀況下能夠用所謂的「主索引＋增量索引」（main+delta）模式來實現「近實時」的索引更新。

這種方法的基本思路是設置兩個數據源和兩個索引，對不多更新或根本不更新的數據創建主索引，而對新增文檔創建增量索引。增量索引更新的頻率能夠很是快，而文檔能夠在出現幾分種內就能夠被檢索到。
肯定具體某一文檔的分屬那個索引的分類工做能夠自動完成。一個可選的方案是，創建一個計數表，記錄將文檔集分紅兩部分的那個文檔 ID，而每次從新構建主索引時，這個表都會被更新。

3.11 索引合併
     合併兩個已有的索引比從新對全部數據作索引更有效率，並且有時候必須這樣作（例如在「主索引＋增量索引」分區模式中應合併主索引和增量索引，而不是簡單地從新索引「主索引對應的數據）。所以 indexer 有這個選項。合併索引通常比從新索引快，但在大型索引上仍然不是一蹴而就。基本上，待合併的兩個索引都會被讀入內存一次，而合併後的內容須要寫
入磁盤一次。例如，合併 100GB 和 1GB 的兩個索引將致使 202GB 的 IO 操做（但極可能仍是比從新索引少）

基本的命令語法以下：
    indexer --merge DSTINDEX SRCINDEX [--rotate]
    SRCINDEX 的內容被合併到 DSTINDEX 中，所以只有 DSTINDEX 索引會被改變。若DSTINDEX 已經被 searchd 用於提供服務，則--rotate 參數是必須的。初設計的使用模式是，將小量的更新從 SRCINDEX 合併到 DSTINDEX 中。所以，當屬性被合併時，一旦出現了重複的文檔 ID，SRCINDEX 中的屬性值更優先（會覆蓋 DSTINDEX 中的值）。不過要注意，「舊的」關鍵字並不會被自動刪除。例如，在 DSTINDEX 中有一個叫作「old」的關鍵字與文檔 123 相關聯，而在 SRCINDEX 中則有關鍵字「new」與同一個文檔相關，那麼在合併後用這兩個關鍵字都能找到文檔 123。您能夠給出一個顯式條件來將文檔從 DSTINDEX 中移除，以便應對這種狀況，相關的開關是--merge-dst-range:
     indexer --merge main delta --merge-dst-range deleted 0 0 這個開關容許您在合併過程當中對目標索引實施過濾。過濾器能夠有多個，只有知足所有過濾條件的文檔纔會在最終合併後的索引中出現。在上述例子中，過濾器只容許「deleted」爲 0的那些條件經過，而去除全部標記爲已刪除（「deleted」）的記錄（能夠經過調用UpdateAttributes() 設置文檔的屬性）。