Add BlobCompressor to compress blob and text fields on fly

[dkropachev]

Closes #218

Column-based blobs compression

General idea

If client stores big blobs of data compressing data that goes into that field will reduce operations select/update footprint on both network and server.

Interoperability issues

1. Data will be readable only by properly configured gocql driver, cqlsh or other drivers won't be able to read it

Possible implementation of serialization/deserialization

1. Global variable + hack into marshalVarchar/unmarshalVarchar

# marshal.go

type blobCompressor interface {
	Compress([]byte) ([]byte, error)
	Decompress([]byte) ([]byte, error)
}

var MyGlobalCompressor blobCompressor

func unmarshalVarchar(info TypeInfo, data []byte, value interface{}) (err error) {
	if MyGlobalCompressor != nil {
		data, err = BlobCompressor.Decompress(data)
		if err != nil {
			return err
		}
	}
	return unmarshalVarcharRaw(info, data, value)
}

func marshalVarchar(info TypeInfo, data []byte, value interface{}) (err error) {
	if MyGlobalCompressor != nil {
		data, err = BlobCompressor.Decompress(data)
		if err != nil {
			return err
		}
	}
	return marshalVarcharRaw(info, data, value)
}

Pros:

1. Easy to use
2. Easy to implement

Cons:

1. As dirty as it gets
2. No control over cluster/session/column, compression is either globaly on or globaly off

2. Option in ClusterConfig + hack into NativeType

# marshal.go

type blobCompressor interface {
	Compress([]byte) ([]byte, error)
	Decompress([]byte) ([]byte, error)
}

type ClusterConfig struct {
	...
	BlobCompressor blobCompressor
}

type NativeType struct {
	...
	blobCompressor blobCompressor
}

func getCompressor(info TypeInfo) blobCompressor {
        nt, ok := info.(NativeType)
        if !ok {
                return nil
        }
        return nt.blobCompressor
}

func unmarshalVarchar(info TypeInfo, data []byte, value interface{}) (err error) {
	if c := getCompressor(info); c != nil {
		data, err = c.Decompress(data)
		if err != nil {
			return err
		}
	}
	return unmarshalVarcharRaw(info, data, value)
}

func marshalVarchar(info TypeInfo, data []byte, value interface{}) (err error) {
	if c := getCompressor(info); c != nil {
		data, err = c.Decompress(data)
		if err != nil {
			return err
		}
	}
	return marshalVarcharRaw(info, data, value)
}

Pros:

1. Easy to use
2. Less dirty than Global variable

Cons:

1. No control over column, compression is either on or off for all the columns in the given session.
2. Polutes NativeType

3. Custom type

type CompressedType struct{
    compressor *Compressor
    val []byte
}

func (ct *CompressedType) MarshalCQL(info TypeInfo) ([]byte, error) {
    return ct.compressor.Compress(ct.val)
}

func (ct *CompressedType) UnmarshalCQL(info TypeInfo, data []byte) (err error) {
   ct.val, err = ct.Decompress(data)
   return err
}

type Compressor struct{
	...
}

type (c Compressor) Blob() CompressedType

# How to use
...
	err = session.Query(
			`INSERT INTO gocql_test.test_blob_compressor (testuuid, testblob) VALUES (?, ?, ?)`,
			TimeUUID(), compressor.Blob().Set([]byte("my value")),
		).Exec()

Pros:

1. Maximum control over which column is compressed
2. No driver polution, could be implemented as part of lz4 package
3. Not dirty at all

Cons;

1. Usage a bit cumbersom

3. Custom type with global compressor

type CompressedType []byte

func (ct CompressedType) MarshalCQL(info TypeInfo) ([]byte, error) {
    return globalcompressor.Compress(ct)
}

func (ct *CompressedType) UnmarshalCQL(info TypeInfo, data []byte) (err error) {
   *val, err = globalcompressor.Decompress(data)
   return err
}

type Compressor struct{
	...
}

type (c Compressor) Blob() CompressedType

# How to use
...
	err = session.Query(
			`INSERT INTO gocql_test.test_blob_compressor (testuuid, testblob) VALUES (?, ?, ?)`,
			TimeUUID(), compressor.Blob([]byte("my value")),
		).Exec()

Pros:

1. Maximum control over which column is compressed
2. No driver polution, could be implemented as part of lz4 package
3. Not dirty at all

[mykaul]

I'm missing the design and the documentation for such a feature. It should not be done hastily. We need to think of interoperability and configuration. Let's have a document on this (on the issue) first.

[Lorak-mmk]

A general comment: This new feature should be properly documented. Right now there is no documentation at all for it.
I know that gocql isn't very good in this regard, but the best way to improve that is to add good docs and comments for new / changed code.

[Lorak-mmk]

IIUC assigning to this global variable activates the blob compressor?
This is very unintuitive and hard to use interface:

• not possible to have different compressors for different sessions / queries
• much harder to test, because your test now relies on global state, so you can't concurrently run tests that need different compressors.
• Harder for programmer to understand because this is another piece of state, but it's not present in any struct used (Session / query etc)

This new compressor interface is something very similar to a few policies / configurations that the driver already has (like RetryPolicy) and should be set the same way. It should be a field on session / query, with setters.

[Lorak-mmk]

I don't think default prefix should exist. It's very possible for the data to have such prefix, so it's a new footgun for a driver user: if a user just uses a compressor, like you did in tests (BlobCompressor = lz4.NewBlobCompressor(100)), it may result in corrupt data. Correct usage requires user to think about data they store in database and what prefix is safe.
Best way to make user think about this is to require explicitly passing prefix.

[Lorak-mmk]

IIUC this test checks identity of insert / select, so it would pass if there was no compressor set / marshal module didn't use the compressor, right?
If so, then it should be improved - it's an integration test so it should check that the new feature works properly with the rest of the driver, right now it doesn't do this.

[Lorak-mmk]

This +4 looks like a mistake, we compress the data with size len(data), not len(data)+4

[Lorak-mmk]

Failure here is a very unexpected condition, maybe it deserves some log entry?

[Lorak-mmk]

4+len(c.prefix) -> prefixPlusLen

[Lorak-mmk]

This compressor should have unit tests for various scenarios:

• decompressing a data without correct prefix
• compress / decompress identity
• compress, and verify that resulting buffer is correct
• decompress with incorrect len in buffer

and preferably more scenarios that you can think of.

[Lorak-mmk]

Cover letter for the PR could be a bit more elaborate

• why this feature is needed, what are the use cases (because it was not done in the issue)?
• why this specific implementation was implemented, what were the alternatives and tradeoffs?
• Why this should even be in the driver? There is nothing preventing doing the compression in code that uses the driver instead of in the driver itself, and afaik gocql strives to not add unnecessary features.

For examples of good PR cover letters see:

• Deserialization refactor: introduce new deserialization traits scylla-rust-driver#970
• Shard selecting load balancing scylla-rust-driver#791

[dkropachev]

@mykaul , @Lorak-mmk , thanks for reviewing, it. Could you please take a look at PR Description, I have layed out all the options to implement this feature. Let's take a look and decide which way to go. I myself prefere N3 and N4. This PR was indended to be Draft just to test things out, unfortunately I missclicked and could not switch it back.

[sylwiaszunejko]

I converted it to draft

[mykaul]

If client stores big blobs of data compressing data that goes into that field will reduce operations select/update footprint on both network and server.

1. Network - you have client<->server network compression.
   Server - the default is already compressing with LZ4.

Both btw use LZ4 (or snappy) by default - which is less suitable for JSON/TEXT blobs (as it has no entropy compression).
I think we should use zstd for it. (Another advantage is that I hope one day we'll do ZSTD client<->server as well...)

2. You definitely need control for it. You need to have a minimum length where it is even reasonable to do it and a percentage where it makes sense to keep it uncompressed.
3. If we do implement it, we'd want it for multiple drivers, not just gocql.
4. It's unclear to me how we determine which BLOBS to compress and which not to. JPEG blobs are not an ideal candidate, for example.

Again, it'll be easier to understand and discuss better on the issue than the PR.