如何評價使用後綴樹以及CritBitTree壓縮數據的PiXiu方法？

01-06

題主是PiXiu方法的作者，詳情可看知乎專欄。大多數的索引演算法都沒有考慮到如何壓縮數據，PiXiu方法將兩者都考慮到了，有沒有獨特性？題主在極端有利情況下測得84%的壓縮率，在實踐中有沒有意義？

只看壓縮率，肯定有意義。除此之外，還需要關注其它指標：

我發現缺乏Benchmark是此項目最大的問題，現在我自己做個詳細的測試，拖了這麼久主要是因為白天上班很累，個人精力不足吧。

測試環境：

rMBP 2015 early

測試數據：

以 http://www.qq.com 為根出發的 10010 個高冗餘HTML頁面。更大的數據集，我覺得沒有必要。一來是麻煩；二來是我是作者，我很清楚，所用的演算法全都是線性時間複雜度和空間複雜度的。

結果：

-----------------

單Zip的意思是把整個文件夾用Mac自帶的Zip打包工具打成一個包
所有文件Gzip的意思是用Gzip的lv9把10010個文件分別打一個gz包，然後用getsize的和的方式算總大小
PiXiu的意思是我最初的PiXiu編碼，就是GitHub項目下所描述的方法
經專欄下一些評論的啟發，PiXiu方法只使用相互引用的方法壓縮了文件，但正統做法是霍夫曼樹這樣的變換，應該還有壓縮空間。於是，我得到了GzPiXiu編碼，把PiXiu壓縮過的文件使用Gzip再壓縮一遍。

最終，我得到了一個吊著打Gzip的壓縮方法。

這裡再次強調，我並沒有創造任何新演算法，只是把原有的演算法組合在了一起，做了一點微小的工作，所以叫做方法（method）。

CPU佔用率，解壓速度，etc. 待續。

贊題主的動手能力，實踐上的意義肯定是有的，起碼這個產品的設計邏輯，可以解決一些獨特場景下的某些瓶頸（如海量數據下的敏感詞過濾、分詞、前綴／後綴模糊搜索等等）。

不知道作者有沒有關注運行時的內存消耗，但是數據結構佔用內存過多，有時候會導致你的壓縮得不償失，尤其在數據量很大的時候，會很明顯（比如幾百G或者上T的數據，1萬個網頁的數據量可能有點小）

另外，我們正在招人，地點北京，對這方面感興趣的小夥伴請聯繫我吧

不是相關行業，不清楚實踐具體是如何的。不過從經驗上講，一般這種覺得我應該發現一種獨特的好方法，最後都發現實踐中都是已經有了類似的，說不定還比自己的更好更實用。

你說有沒有意義，那當然有意義啊。硬碟都是要機箱去運行的。一個伺服器2000刀，你給他來200萬個，這就是40億刀啊。這個時候你說壓縮率是84%，那就一下子省了6.4億，可以發一年工資呢！

獨特性嘛，這讓我想到了已經成為古老的化石的，當初MSRA給Bing做的那個後端，也有類似的功能。既然微軟都做了，那根據互聯網企業科技比微軟發達的政治正確的觀點，應該任何數據存儲方案都有這個壓縮功能，所以不會有獨特性（逃

貔貅方法。。。？

順便一提有沒有考慮到文件分割對於總體積的影響