When you configure the NodeTableCompression parameter, IDOL Server compresses data in the nodetable directory before storing it, to reduce the disk footprint.
The overhead of compressing and decompressing document data might incur a performance penalty. However, on some systems that are bound by I/O rather than processor bottlenecks, the performance might be only marginally affected, or even improved, because the reduced volume of reading and writing data can largely offset the increased computational costs of the compression.
You can specify the compression algorithm to use. Micro Focus recommends that you use lz4 compression , which provides the best balance between performance and reduction of disk footprint over a range of data sets. However, you might want to trial multiple compression options to determine the most appropriate value for your use case. The zlib and lz4hc methods tend to reduce the data size most, but these are more computationally expensive. The snappy method is comparable with lz4 in terms of performance and compression methods, but might perform better on certain data sets.
Indexes that consist mainly of very short documents, such as Twitter feeds, might not compress effectively.
If you change this setting after you have indexed data, IDOL Server does not immediately recompress your index. When you run an index action that adds data or rewrites existing data (such as DREREPLACE), it uses the new compression method. You can also run a DRECOMPACT index action with the NodeTableCompactWindowKB parameter set to apply the new compression method to your index.
You can only increase compression by using the DRECOMPACT index action. For example, if you change NodeTableCompression from lz4 to Off, the compaction does not decompress your data.
|
|