1.區段查詢
索引系統需要通過主查詢來獲取全部的文檔信息,一種簡單的實現是將整個表的數據讀入內存,但是這可能導致整個表被鎖定並使得其他操作被阻止(例如:在MyISAM格式上的INSERT操作),同時,將浪費大量內存用於存儲查詢結果,諸如此類的問題吧。 爲了避免出現這種情況,CoreSeek/Sphinx支持一種被稱爲 區段查詢的技術. 首先,CoreSeek/Sphinx從數據庫中取出文檔ID的最小值和最大值,將由最大值和最小值定義自然數區間分成若干份,一次獲取數據,建立索引。現舉例如下:
sql_query_range = SELECT MIN(id),MAX(id) FROM documents
sql_range_step = 1000
sql_query = SELECT * FROM documents WHERE id>=$start AND id<=$end
只要在配置文件裏面寫三條語句即可
from後面要跟的是你數據庫裏面的表名,如這裏的表就是document
2.增量索引代替實時索引
有這麼一種常見的情況:整個數據集非常大,以至於難於經常性的重建索引,但是每次新增的記錄卻相當地少。一個典型的例子是:一個論壇有1000000個已經歸檔的帖子,但每天只有1000個新帖子。
在這種情況下可以用所謂的“主索引+增量索引”(main+delta)模式來實現“近實時”的索引更新。
這種方法的基本思路是設置兩個數據源和兩個索引,對很少更新或根本不更新的數據建立主索引,而對新增文檔建立增量索引。在上述例子中,那1000000個已經歸檔的帖子放在主索引中,而每天新增的1000個帖子則放在增量索引中。增量索引更新的頻率可以非常快,而文檔可以在出現幾分種內就可以被檢索到。
確定具體某一文檔的分屬那個索引的分類工作可以自動完成。一個可選的方案是,建立一個計數表,記錄將文檔集分成兩部分的那個文檔ID,而每次重新構建主索引時,這個表都會被更新。
分辨要在mysql裏建表,然後修改配置文件
# in MySQL
CREATE TABLE sph_counter
(
counter_id INTEGER PRIMARY KEY NOT NULL,
max_doc_id INTEGER NOT NULL
);
# in sphinx.conf
source main
{
# ...
sql_query_pre = SET NAMES utf8
sql_query_pre = REPLACE INTO sph_counter SELECT 1, MAX(id) FROM documents
sql_query = SELECT id, title, body FROM documents \
WHERE id<span style="color:#ff0000;"><=</span>( SELECT max_doc_id FROM sph_counter WHERE counter_id=1 )
}
source delta : main
{
sql_query_pre = SET NAMES utf8
sql_query = SELECT id, title, body FROM documents \
WHERE id<span style="color:#ff0000;">></span>( SELECT max_doc_id FROM sph_counter WHERE counter_id=1 )
}
index main
{
source = main
path = /path/to/main
# ... all the other settings
}
# note how all other settings are copied from main,
# but source and path are overridden (they MUST be)
index delta : main
{
source = delta
path = /path/to/delta
}
寫好之後,還要寫兩個批處理文件,一個做增量索引,一個合併索引。
增量索引:g:/service/coreseek/bin/indexer -c g:/service/coreseek/etc/csft_mysql.conf --rotate main_delta
合併索引:g:/service/coreseek/bin/indexer -c g:/service/coreseek/etc/csft_mysql.conf --merge main main_delta --rotate
寫好之後,再將兩者放入到任務計劃裏,差不多5分鐘做一次增量索引,每天1點半時候做一次主索引