sphinx 1.10推出了不少新特性：html
好比：實時索引，字符串屬性，prefork 和 threads支持，及SphinxSE 中的option添加等mysql
詳細請查閱原文：http://www.sphinxsearch.com/docs/manual-1.10.html#rel110sql
我的以爲 sphinx 1.10-beta 兩個最大的新特性：字符串索引和實時索引。對sphinx使用來講是一個很大的飛躍數據庫
字符串索引：能夠很方便的存儲，若是結合實時索引的話，就已經造成了貌似nosql同樣的數據緩存層。並且，不少數據沒必要二次在數據庫中查詢，天然對
程序開發和運維有很大的幫助。檢索出來後直接使用其數據，不過這個和全部緩存數據同樣，注意在數據更新操做的時候須要同步更新這裏的sql_attr_string
或rt_attr_string緩存
實時索引(Real-time indexes)：
優勢：
此功能是我的對sphinx的最大期待。在正式部署中，sphinx real-time 能夠當成一個相似 memcache的數據存儲插件，充分利用其查詢、分佈式
部署的便捷性，作到數據層次化管理。緩解數據庫的壓力。同時還支持事務操做，這個在不少nosql中是所缺乏的。這，簡直就是sql和nosql的混合體啊^_^併發
不足：
今天特別對實時索引進行了功能性的測試。雖然此功能很新穎且實用。但現階段，若部署在生產環境下可能會遇到如下幾個問題：運維
a、數據插入問題：Real-time的功能採起的是相似 標準sql的語句執行數據存儲。如：nosql
insert into(id,gid,title,content) values(1,234,’hello sphinx ‘,’I am superman!’);分佈式
這裏的id必須人工計算：不能像mysql的auto_increment對主鍵進行自動累加。
另外，不能使用標準sql 的函數 max獲取最大值，如：select max(id) from testrt,(sphinxQL中提示可使用函數，但我在嘗試過，系統提示語法錯誤，可能暫時只針對 非實時索引sphinxSE方式)
若是數據多的話，並且併發量比較大的話，在程序端實現起來天然會出現異常。函數
我這裏暫時採用了一個辦法處理這個問題：
查詢 最大的id，並每次進行累加
select * from testrt order by id desc limit 1;
獲取結果集的 id即爲最大，至關於mysql中的auto_increment 變量。而後再對每次數據插入進行累加。具體作法能夠參照前一篇的程序代碼
b、數據刪除：只能使用惟一的語句 delete from testrt where id=123; 若是數據量大的話，必須在邏輯層循環刪除。並且不支持 in操做，不過文檔中已提到，in操做已經在
計劃中了，期待着。 另外，不能所有清空數據，不能像 數據庫操做的 truncate table那樣便捷。若索引很大並想重建索引的話，那就。。。等着抓狂吧
c、索引數據更新：sphinx沒有提供標準sql的update操做(其實也不必)，而是採起了相似mysql 的replace 語法。
實例：repalce into(id,gid,title,content) values(1,234,’hello sphinx ‘,’I am superwomen!’); 不過遺憾的是不能進行條件更新
d、查詢：Real-time的sql查詢仍是很方便，或者很健全，好比：對字段查詢、屬性過濾、分組聚合、排序、評分等。徹底知足一個搜索引擎的查詢需求。但此版本仍是缺乏支持一些
數據庫的經常使用函數。正如剛纔提到的max、min等；以及對字段的較複雜的操做。
好比：select count(gid) as amount from testrt;就會報語法錯誤，這個例子能夠採起變通的方式處理
select * from testrt group by gid;
其結果集中存在 @groupby @count變量值
文檔中有說起在sphinxSE中可使用函數，不過在這裏暫時用不了，仍是期待！
綜上所述：sphinx的實時索引特性，暫時在生產部署上功能可能欠缺一些，必須採用其餘辦法變通，故，生產需謹慎，仍是期待正式版吧！
以上便是對sphinx 1.10的2個新特性的體驗報告^_^。固然以上的結論只是因我的在工做中可能會遇到的問題而提出的，我不能指望sphinx徹底取代數據庫 可是，sphinx小弟弟，你能幫就多幫幫你大哥mysql吧，你看他天天累得cpu冒汗，還分佈式的累，不容易啊！