You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@cassandra.apache.org by Pavel Kirienko <pa...@gmail.com> on 2013/07/08 11:07:56 UTC
Purpose of BLOB datatype
Hi all,
I am curious why there is BLOB datatype that accepts HEX strings only.
HEX encoding requires twice as much space as original data, thus it is
rather ineffective. Instead, base64 encoding with ASCII datatype seems more
effective in terms of space, and I believe it doesn't impose noticeable
performance penalty either.
So, are there any special use cases for BLOBs, or should I give up on them
and use ASCII + base64 for my binaries?
Thanks in advance,
Pavel.
Re: Purpose of BLOB datatype
Posted by Pavel Kirienko <pa...@gmail.com>.
> If you do have blobs, the preferred way is to not encode them in strings
at all, but rather to use prepared statement (which don't involve a
conversion to string).
Awesome.
Thanks.
On Mon, Jul 8, 2013 at 1:44 PM, Sylvain Lebresne <sy...@datastax.com>wrote:
> If you do have blobs, the preferred way is to not encode them in strings
> at all, but rather to use prepared statement (which don't involve a
> conversion to string).
>
> --
> Sylvain
>
>
> On Mon, Jul 8, 2013 at 11:07 AM, Pavel Kirienko <
> pavel.kirienko.list@gmail.com> wrote:
>
>> Hi all,
>>
>> I am curious why there is BLOB datatype that accepts HEX strings only.
>>
>> HEX encoding requires twice as much space as original data, thus it is
>> rather ineffective. Instead, base64 encoding with ASCII datatype seems more
>> effective in terms of space, and I believe it doesn't impose noticeable
>> performance penalty either.
>>
>> So, are there any special use cases for BLOBs, or should I give up on
>> them and use ASCII + base64 for my binaries?
>>
>> Thanks in advance,
>> Pavel.
>>
>>
>
Re: Purpose of BLOB datatype
Posted by Ollif Lee <ol...@gmail.com>.
fine, thanks.
On Tue, Jul 9, 2013 at 11:24 PM, Pavel Kirienko <
pavel.kirienko.list@gmail.com> wrote:
> > Do you know any direct ways in CQL to handle BLOB, just like DataStax
> Java driver?
>
> Well, CQL3 specification explicitly says that there is no way to encode
> blob into CQL request other than HEX string:
> http://cassandra.apache.org/doc/cql3/CQL.html#constants
>
>
>
> On Tue, Jul 9, 2013 at 6:40 PM, Ollif Lee <ol...@gmail.com> wrote:
>
>> Thank you for your patience. That is what I have expected.
>> PS. Do you know any direct ways in CQL to handle BLOB, just like DataStax
>> Java driver?
>>
>>
>> On Tue, Jul 9, 2013 at 4:53 PM, Sylvain Lebresne <sy...@datastax.com>wrote:
>>
>>> > Pls explain why and how.
>>>
>>> Why and how what?
>>>
>>> Not encoding blobs into strings is the "preferred way" because that's
>>> obviously
>>> more efficient (in speed and space), since you don't do any encoding
>>> pass.
>>>
>>> As for how, "use prepared statement" was the "how". What are the exact
>>> lines of
>>> code to use to do prepared statements will depends on the client driver
>>> you
>>> use, and you should check your driver documentation.
>>>
>>> But, to give you an example, if you use the DataStax Java driver
>>> (https://github.com/datastax/java-driver), this might look something
>>> like:
>>>
>>> PreparedStatement st = session.prepare("INSERT INTO foo(myKey, myBlob)
>>> VALUES (?, ?)");
>>> String myKey = ...;
>>> ByteBuffer myBlob = ...;
>>> session.execute(st.bind(myKey, myBlob));
>>>
>>>
>>> --
>>> Sylvain
>>>
>>
>>
>
Re: Purpose of BLOB datatype
Posted by Pavel Kirienko <pa...@gmail.com>.
> Do you know any direct ways in CQL to handle BLOB, just like DataStax
Java driver?
Well, CQL3 specification explicitly says that there is no way to encode
blob into CQL request other than HEX string:
http://cassandra.apache.org/doc/cql3/CQL.html#constants
On Tue, Jul 9, 2013 at 6:40 PM, Ollif Lee <ol...@gmail.com> wrote:
> Thank you for your patience. That is what I have expected.
> PS. Do you know any direct ways in CQL to handle BLOB, just like DataStax
> Java driver?
>
>
> On Tue, Jul 9, 2013 at 4:53 PM, Sylvain Lebresne <sy...@datastax.com>wrote:
>
>> > Pls explain why and how.
>>
>> Why and how what?
>>
>> Not encoding blobs into strings is the "preferred way" because that's
>> obviously
>> more efficient (in speed and space), since you don't do any encoding
>> pass.
>>
>> As for how, "use prepared statement" was the "how". What are the exact
>> lines of
>> code to use to do prepared statements will depends on the client driver
>> you
>> use, and you should check your driver documentation.
>>
>> But, to give you an example, if you use the DataStax Java driver
>> (https://github.com/datastax/java-driver), this might look something
>> like:
>>
>> PreparedStatement st = session.prepare("INSERT INTO foo(myKey, myBlob)
>> VALUES (?, ?)");
>> String myKey = ...;
>> ByteBuffer myBlob = ...;
>> session.execute(st.bind(myKey, myBlob));
>>
>>
>> --
>> Sylvain
>>
>
>
Re: Purpose of BLOB datatype
Posted by Ollif Lee <ol...@gmail.com>.
Thank you for your patience. That is what I have expected.
PS. Do you know any direct ways in CQL to handle BLOB, just like DataStax
Java driver?
On Tue, Jul 9, 2013 at 4:53 PM, Sylvain Lebresne <sy...@datastax.com>wrote:
> > Pls explain why and how.
>
> Why and how what?
>
> Not encoding blobs into strings is the "preferred way" because that's
> obviously
> more efficient (in speed and space), since you don't do any encoding pass.
>
> As for how, "use prepared statement" was the "how". What are the exact
> lines of
> code to use to do prepared statements will depends on the client driver you
> use, and you should check your driver documentation.
>
> But, to give you an example, if you use the DataStax Java driver
> (https://github.com/datastax/java-driver), this might look something like:
>
> PreparedStatement st = session.prepare("INSERT INTO foo(myKey, myBlob)
> VALUES (?, ?)");
> String myKey = ...;
> ByteBuffer myBlob = ...;
> session.execute(st.bind(myKey, myBlob));
>
>
> --
> Sylvain
>
Re: Purpose of BLOB datatype
Posted by Sylvain Lebresne <sy...@datastax.com>.
> Pls explain why and how.
Why and how what?
Not encoding blobs into strings is the "preferred way" because that's
obviously
more efficient (in speed and space), since you don't do any encoding pass.
As for how, "use prepared statement" was the "how". What are the exact
lines of
code to use to do prepared statements will depends on the client driver you
use, and you should check your driver documentation.
But, to give you an example, if you use the DataStax Java driver
(https://github.com/datastax/java-driver), this might look something like:
PreparedStatement st = session.prepare("INSERT INTO foo(myKey, myBlob)
VALUES (?, ?)");
String myKey = ...;
ByteBuffer myBlob = ...;
session.execute(st.bind(myKey, myBlob));
--
Sylvain
Re: Purpose of BLOB datatype
Posted by Ollif Lee <ol...@gmail.com>.
Pls explain why and how.
On Mon, Jul 8, 2013 at 5:44 PM, Sylvain Lebresne <sy...@datastax.com>wrote:
> If you do have blobs, the preferred way is to not encode them in strings
> at all, but rather to use prepared statement (which don't involve a
> conversion to string).
>
> --
> Sylvain
>
>
> On Mon, Jul 8, 2013 at 11:07 AM, Pavel Kirienko <
> pavel.kirienko.list@gmail.com> wrote:
>
>> Hi all,
>>
>> I am curious why there is BLOB datatype that accepts HEX strings only.
>>
>> HEX encoding requires twice as much space as original data, thus it is
>> rather ineffective. Instead, base64 encoding with ASCII datatype seems more
>> effective in terms of space, and I believe it doesn't impose noticeable
>> performance penalty either.
>>
>> So, are there any special use cases for BLOBs, or should I give up on
>> them and use ASCII + base64 for my binaries?
>>
>> Thanks in advance,
>> Pavel.
>>
>>
>
Re: Purpose of BLOB datatype
Posted by Sylvain Lebresne <sy...@datastax.com>.
If you do have blobs, the preferred way is to not encode them in strings at
all, but rather to use prepared statement (which don't involve a conversion
to string).
--
Sylvain
On Mon, Jul 8, 2013 at 11:07 AM, Pavel Kirienko <
pavel.kirienko.list@gmail.com> wrote:
> Hi all,
>
> I am curious why there is BLOB datatype that accepts HEX strings only.
>
> HEX encoding requires twice as much space as original data, thus it is
> rather ineffective. Instead, base64 encoding with ASCII datatype seems more
> effective in terms of space, and I believe it doesn't impose noticeable
> performance penalty either.
>
> So, are there any special use cases for BLOBs, or should I give up on them
> and use ASCII + base64 for my binaries?
>
> Thanks in advance,
> Pavel.
>
>