When to use Blobs in a Cassandra table (and CQL) and what exactly are the drops?

Question

I tried to better understand the design decision when creating notes in cassandra and when blob is a good choice.

I realized that I did not know when to choose blob as the data type, because I was not sure what the blob really was (or what the abbreviation meant). So I decided to read the following documentation for the blob data type:

http://www.datastax.com/documentation/cql/3.0/cql/cql_reference/blob_r.html

Blob

Cassandra 1.2.3 still supports blobs as string constants for input (to allow smoother transition to blob constant). Blobs as strings are 

now deprecated and will not be supported in the near future. if you used strings as drops, updated your client code to switch to blob constants. The blob constant is a hexadecimal number defined by the formula 0xX +, where hex is a hexadecimal character, for example [0-9a-FA-F]. For example, 0xcafe.

 Blob conversion functions A number of functions convert the native types into binary data (blob). For every <native-type> nonblob type supported by CQL3, the 

The typeAsBlob function takes an argument of the type of the type and returns it as a blot. In contrast, the blobAsType function takes a 64-bit blob argument and converts it to bigint. For example, bigintAsBlob (3) is 0x0000000000000003 and blobAsBigint (0x0000000000000003) is 3.

What I got is that it is just a long hex / binary. However, I do not really appreciate when I will use it as a column type for a potential table and as it is better or worse than another type. Also, going through some of your properties can be a good way to figure out what situations a drop is suitable for.

Answer 1

Blobs (Binary Large OBjectS) is a solution when your data does not fit into the standard types provided by C *. For example, let's say you wanted to create a forum where users were allowed to upload files of any type. To save them in C *, you should use a Blob column (or perhaps multiple blob columns, since you don't want individual cells to become large).

Another example is a table in which users are allowed to have a current photo, this photo can be added as a drop and stored along with other user information.

Answer 2

Accoring to 3.x document , the blob type is suitable for storing a small image or short string.

In my case, I used it to store a hashed value, since the hash function returns a binary file, and the best option is to save it as a binary file from the data size representation of the table. (Converting to a string and saving as a string (text) may also be fine if size is not considered.)

The results below show my test on the local computer (insert 1 million records), and the sizes are 52 626 907 (binary) and 72 879 839 (data with base64 conversion as a string). unit: byte.

 CREATE TABLE IF NOT EXISTS testks.bin_data ( bin_data blob, PRIMARY KEY(bin_data) ); CREATE TABLE IF NOT EXISTS testks.base64_data ( base64_data text, PRIMARY KEY(base64_data) ); cqlsh> select * from testks.base64_data limit 10; base64_data ------------------------------ W0umEPMzL5O81v+tTZZPKZEWpkI= bGUzPm4zRvcqK1ogwTvPNPNImvk= Nsr0GKx6LjXaiZSwATU38Ffo7fA= A6lBV69DbFz/UFWbxolb+dlLcLc= R919DvcyqBUup+NrpRyRvzJD+/E= 63LEynDKE5RoEDd1M0VAnPPUtIg= FPkOW9+iPytFfhjdvoqAzbBfcXo= uHvtEpVIkKivS130djPO2f34WSM= fzEVf6a5zk/2UEIU8r8bZDHDuEg= fiV4iKgjuIjcAUmwGmNiy9Y8xzA= (10 rows) cqlsh> select * from testks.bin_data limit 10; bin_data -------------------------------------------- 0xb2af015062e9aba22be2ab0719ddd235a5c0710f 0xb1348fa7353e44a49a3363822457403761a02ba8 0x4b3ecfe764cbb0ba1e86965576d584e6e616b03e 0x4825ef7efb86bbfd8318fa0b0ac80eaa2ece9ced 0x37bdad7db721d040dcc0b399f6f81c7fd2b5cea6 0x3de4ca634e3a053a1b0ede56641396141a75c965 0x596ec12d9d9afeb5b1b0bb42e42ad01b84302811 0xbf51709a8d1a449e1eea09ef8a45bdd2f732e8ec 0x67dcb3b6e58d8a13fcdc6cf0b5c1e7f71b416df6 0x7e6537033037cc5c028bc7c03781882504bdbd65