InfoBright
Infobright’s caching is based on different assumptions and is not an equivalent to MySQL caching. In Infobright, source data packs are cached (as long as they match the memory), but not a result of query. Consequently, exactly the same query (processing a lot of data) will run faster in MySQL when run the second time. On the other hand, in Infobright even a different (e.g. another values of conditions) queries may work faster the second time, if only data packs are still avaliable in memory. Unfortunately it will not work in your case, as the data packs used in query will occupy probably much more memory than available for caching.
数值型Pack的格式
//////////////////////////////////////////////////////////////////////////// // Save format: // // <total_byte_size> - uint, the size of the data on disk (bytes), including header and dictionaries // - uchar, see Compress method definition. Special values: 255 - nulls only, 254 - empty (0 objects) // <no_obj> - ushort-1, i.e. "0" means 1 object // <no_nulls> - ushort(undefined if nulls only) // <max_val> - T_uint64, the maximal number to be encoded. E.g. 0 - only nulls and one more value. // <...data...> - depending on compression mode
字符串型Pack的格式
public abstract class DataPack<T> {
private int decomposerId;
private int outliers;
private ReentrantLock dataPackLock;
public void setDecompressorId(int decomposerId) {
this.decomposerId = decomposerId;
}
public int getDecompressorId() {
return decomposerId;
}
public abstract int size();
public abstract RCDataType get(int id);
}