SegmentSearcher doesn't need to opened bloom object cache in each call .get(). It just should search with assigned data objects.

Add some default values, allows to insert just data type, without specifying descriptor. Make it work even without configuring bloom filter. Add option to define type withou desceiptor, just with class. Add default values per data type.

Add some documentation how to use index

In class SstIndexImpl method getStream() return stream that doesn't close underlying resources.

Segment cache could be cleared in a following was:

final SegmentCache<K, V> sc = new SegmentCache<>(
        segmentFiles.getKeyTypeDescriptor(), segmentFiles,
        segmentPropertiesManager);
sc.clear();

It's not effective. Cache should not be loaded into memory. It's in SegmentFullWriter.close().

verify parameters, eg delta cache size can't be smaller that 2.

Use wal for cache with puts and deletes. After successful flushndelete wal and start new one. When index starts after ctrl+c than recovery from wal.

provide false positive probability in bloom filter. It's most important parameter in bloom filters.

Segment contains few objects that helps with search process. It's cache, bloom filter and scarce index. All of them should be cached on one place and still be accessible from segment.

It large data files it's different to have buffer 4KB and have 1MB for reading whole data it's two times faster to use 1MB buffer.

hasNext and next methods are not suitable, they require preloading element it could faul, when next element is unloaded from delta cache. Use tryAdvance method

Add flush() to index. It allows "commit" changes to work with them further. Document it.

Some object should provide information about expected consumed index memory. If I know key and value size it could be computed.

During index closing SegmentDataProvider.invaliidate() is not called.

When cached data are unloaded from memory, call close() on them. It allows implements search as random access file. It's question if such feature is necessary.

Segment iterator should work after flushing. Because of that it can't iterate through data in cache. Iterator should just use data from segment. Event read part should check it's value in cache. There will be problem in case of tombstone in cache..

Fix security problems with log4j. There are 6 of them.

After writing data to segment segment could be compacted and splitter. Because of that after writing index searcher should always be unloaded from memory to enforce it's refresh.

When there are multiple duplicated write operations than properties hold invalid value of number of keys in segment. Because of that splitter segments are not equally sized.

When iterator starts read values, one value is changed that old value is returned. For example there are pairs in segment [a,1],[b,1],[c,1] following commands are executed:

iterator.next() --> [a,1]
put(b,2)
iterator.next() --> [b,1]

Last call should return [b,2]

When flushing pairs to segment. There should be introduces, two parameters fro delta cache size:

• max size for searching and reading
• max size for flushing, it temporally allows to exceed previous value to prevent from repeating compacting during flushing

In logs are number formatted simply 3740512. To improve readability it should be 3 740 512.

When delta cache has similar size to main index and delta cache is full of delete command of already stored keys. In that case splitting function can't correctly estimate where is half of keys and could fail.