Suggested feature - wire-format aware binary extractor

Question

I would like to suggest another feature, which might or might not improve performance of querying unindexed attributes (possibly at the cost of some more bytes in the wire-format).
     We found that in case of querying caches with many keys, but no indexes on the queried attribute, the performance of the cache is quite worse than querying Oracle, for instance.
     The foremost reason of that, I believe, is that for this scenario, the primary node has to deserialize all the entries in the cache to extract a single attribute from it, compared to a database which knows the exact position and representation of that value in the database storage.
     If the cached entry did not have to be deserialized, but we knew how to pointedly extract only the particular attribute from the wire format, it could be way faster, and even some object allocations may be avoided compared to the current situation.
     I think, that providing a new extraction method could speed up this scenario, all it requires is that the extractor be faster than the deserializing the entire object. This can for example be provided by having the attributes extracted this way put to a place where it is much faster to be found, probably to a fixed position in the wire format.
     As the entries (key and value) are stored in wire-format in the backing map, the wire-format can be passed without a byte array copy to the filter or to the extractor.
     I suggest the following interfaces could be used for such an extractor and a custom filter using similar techniques:
              public interface WireFormatAwareBinaryExtractor {
              Object extractFromBinary(byte[] wireFormat, int wireFormatStartsAt, int wireFormatLength);
         public interface WireFormatAwareBinaryFilter {
              boolean evaluateBinaryValue(byte[] valueWireFormat, int valueStartsAt, int valueLength);
         public interface WireFormatAwareBinaryEntryFilter {
              boolean isKeyRequiredAsBinary();
              boolean evaluateKeyAndBinaryValue(
                        Object key,
                        byte[] valueWireFormat, int valueStartsAt, int valueLength);
              boolean evaluateBinaryKeyAndValue(
                        byte[] keyWireFormat, int keyStartsAt, int keyLength,
                        byte[] valueWireFormat, int valueStartsAt, int valueLength);
                   The two int attributes are necessary only if the byte[] contains more than the binary representation of the value or the key, but other bytes as well (e.g. the key and the value in the same array, in which case one of the array parameters can actually go; or it might contain class name or class name cache index, you know it, this is an internal detail).
     In case of the entry filter, depending on the return value of the isKeyRequiredAsBinary() method, one or the other evaluate method would be invoked.
     After this, the developer is free to choose how he modifies the wire format of his cached classes, to suit this as much as possible, if he wants to use this feature.
     I don't know how much this may or may not help with the performance of queries, but I think it can help in some cases, for example when the index cost of a cache would be too prohibitive, compared to the wins it can provide (e.g. all queries to that attribute can be prefiltered to a number of candidate keys which is way less than the entire key set size, and the values in the attribute are so diverse that the index would consume almost as much space as (or even more than) the values themselves).
     Also it is a feature which is not too complex to implement, I believe.
     Also, it would be useful to have utility methods equivalent to the read methods on the ExternalizableHelper class to be provided but with a byte[] and int (start index) instead of a DataInput in the signature.
     Or otherwise the byte[] parameters in the methods might be replaced with a seekable DataInput wrapper containing the byte[] (in which the wrapped byte[] can be changed by the loop evaluating the entries).
     Best regards,
     Robert Varga
     Message was edited by:
     robvarga

Answer 1

We found that in case of querying caches with many     > keys, but no indexes on the queried
     > > attribute, the performance of the cache is quite
     > worse than querying Oracle, for instance.
     >
     > That is to be expected.
     >
     > Please also note that Oracle (and other SQL
     > databases) are very refined and optimized
     > implementations of relational query engines, so it
     > should not be surprising when results are in their
     > favor for relational-style queries.
     >
     > > The foremost reason of that, I believe, is that for
     > this scenario, the primary node has to
     > > deserialize all the entries in the cache to extract
     > a single attribute from it, compared to a
     > > database which knows the exact position and
     > representation of that value in the database
     > > storage.
     >
     > Yes, deserialization can be quite expensive.
     >
     Yes, I am aware of it, and accept them as a trade-off for getting objects in the cache. And I was not even speaking about the relational part of RDBMS-es, only about the partially reproducable advantage of the known storage structure of a single table.
     And it was mostly just the preface text. :-)
     > > I think, that providing a new extraction method
     > could speed up this scenario, all it
     > > requires is that the extractor be faster than the
     > deserializing the entire object. This can
     > > for example be provided by having the attributes
     > extracted this way put to a place
     > > where it is much faster to be found, probably to a
     > fixed position in the wire format.
     >
     > We considered fixed-position techniques, but decided
     > against them for a number of reasons, although for
     > the use case you describe it would likely work well.
     > Our decision was based on the following:
     >
     > 1) The fixed length fields would all have to be
     > placed first into the binary structure in order for
     > those data to have fixed offsets, and
     > 2) Only the fixed length fields of the outermost
     > object would be directly extractable.
     >
     Yes, but if the developer has the freedom to choose such an extractor, it cannot hurt to provide the feature as an alternative to ReflectionExtractor and extracted value-using filters, if it is sort of straightforward to implement.
     And I believe, actually not only the first fixed length fields would be extractable, but you could also get the same sort of speed advantage, as you have when using a SAX parser instead of a DOM builder, because you don't need to instantiate objects which you do not even need, and you can skip (or at least search for the end of it) stuff which you do not need without actually instantiating it.
     > In your example, you suggested:
     >
     > Object extractFromBinary(byte[] wireFormat, int
         > wireFormatStartsAt, int wireFormatLength);     >
     > A couple things to keep in mind:
     >
     > 1) The data stored in a backing map is a Binary
     > object (com.tangosol.util.Binary)
     > 2) A Binary object can provide a Binary object within
     > it without copying:
     >
     > Binary binSub =
         > bin.toBinary(wireFormatStartsAt,
         > wireFormatLength);     >
     > 3) A Binary object can provide a BufferInput, which
     > is a combination of an Input Stream, a Data Input
     > implementation, etc.:
     >
     > ReadBuffer.BufferInput in =
         > bin.toBinary(wireFormatStartsAt,
         > wireFormatLength).getBufferInput();     >
     > .. or simply:
     >
     > ReadBuffer.BufferInput in =
         > bin.getBufferInput(wireFormatStartsAt,
         > wireFormatLength);     >
     > (See the JavaDoc documentation in com.tangosol.io
     > package.)
     >
     > 4) To extract an "int" value from offset 13, it's as
     > easy as:
     >
     > int n = bin.getBufferInput(13,
         > 4).readInt();     >
     > .. but since it's a known offset, you can simply do
     > this:
     >
     > int n =
         > bin.getBufferInput().setOffset(13).readInt();     >
     > > Also, it would be useful to have utility methods
     > equivalent to the read methods on the
     > > ExternalizableHelper class to be provided but with
     > a byte[] and int (start index) instead
     > > of a DataInput in the signature.
     >
     > BufferInput does that already, for the most part.
     >
     > > Or otherwise the byte[] parameters in the methods
     > might be replaced with a seekable
     > > DataInput wrapper containing the byte[] (in which
     > the wrapped byte[] can be changed
     > > by the loop evaluating the entries).
     >
     > That's exactly what BufferInput is.
     >
     > Check it out and tell me if we're talking about the
     > same thing.
     >
     I think we are. :-)
     >
     > In 3.2, an improved type of serialization will be
     > provided as well (as discussed previously on some of
     > the XmlBean threads), which may address this
     > question.
     >
     Can't wait to see it. When will it be released? In some post it was mentioned that 3.2 GA is tentatively scheduled for this July. Is there some update to that? :-)
     > Peace,
     >
     > Cameron.
     Thanks and best regards,
     Robert