On Sat, Feb 4, 2012 at 8:54 PM, Yiming Sun yiming@gmail.com wrote:
Interesting idea, Jim. Is there a reason you don't you use
metadata:{accountId} instead? For performance reasons?
No, because the column comparator is defined as
CompositeType(DateType, AsciiType), and all column names
Thanks for the clarification, Jim. I didn't know the first comparator was
defined as DateType. Yeah, in that case, the beginning of the epoch is the
only choice.
-- Y.
On Mon, Feb 6, 2012 at 11:35 AM, Jim Ancona j...@anconafamily.com wrote:
On Sat, Feb 4, 2012 at 8:54 PM, Yiming Sun
Yiming, I am using 2 CF's. Performance wise this should not be an issue. I
use it for small files data store. My 2 CF's are:
FilesMeta
FilesData
2012/2/5 Yiming Sun yiming@gmail.com
Interesting idea, Jim. Is there a reason you don't you use
metadata:{accountId} instead? For performance
Thanks R.V.!! We are also dealing with many small files, so this sounds
really promising.
-- Y.
On Sun, Feb 5, 2012 at 9:59 AM, R. Verlangen ro...@us2.nl wrote:
Yiming, I am using 2 CF's. Performance wise this should not be an issue. I
use it for small files data store. My 2 CF's are:
Thanks Andrey and Chris. It sounds like we don't necessarily have to use
composite columns. From what I understand about dynamic CF, each row may
have completely different data from other rows; but in our case, the data
in each row is similar to other rows; my concern was more about the
I also made something like this a while ago. I decided to go for the
2-rows-solution: by doing that you don't have the need for super columns.
Cassandra is really good at reading, so this should not be an issue.
Cheers!
2012/2/4 Yiming Sun yiming@gmail.com
Thanks Andrey and Chris. It
Interesting idea, R.V. But what did you do with the row keys?
On Sat, Feb 4, 2012 at 2:29 PM, R. Verlangen ro...@us2.nl wrote:
I also made something like this a while ago. I decided to go for the
2-rows-solution: by doing that you don't have the need for super columns.
Cassandra is really
I just kept both row keys the same. This was very trivial for fetching them
both. When you have A, you can fetch B, and vice versa.
2012/2/4 Yiming Sun yiming@gmail.com
Interesting idea, R.V. But what did you do with the row keys?
On Sat, Feb 4, 2012 at 2:29 PM, R. Verlangen
I've used special values which still comply with the Composite
schema for the metadata columns, e.g. a column of
1970-01-01:{accountId} for a metadata column where the Composite is
DateType:UTF8Type.
Jim
On Sat, Feb 4, 2012 at 2:13 PM, Yiming Sun yiming@gmail.com wrote:
Thanks Andrey and
R.V., I am a little confused. I was under the impression that you cannot
have two rows with the same key - unless you were referring to two
different CFs?
On Sat, Feb 4, 2012 at 6:11 PM, R. Verlangen ro...@us2.nl wrote:
I just kept both row keys the same. This was very trivial for fetching
Interesting idea, Jim. Is there a reason you don't you use
metadata:{accountId} instead? For performance reasons?
On Sat, Feb 4, 2012 at 6:24 PM, Jim Ancona j...@anconafamily.com wrote:
I've used special values which still comply with the Composite
schema for the metadata columns, e.g. a
On 4 February 2012 06:21, Yiming Sun yiming@gmail.com wrote:
I cannot have one composite column name with 3 components while another
with 4 components?
Just put 4 components and left last empty (if it is same type)?!
Another question I have is how flexible composite columns actually are.
On 4 February 2012 06:21, Yiming Sun yiming@gmail.com wrote:
I cannot have one composite column name with 3 components while another with
4 components?
Just put 4 components and left last empty (if it is same type)?!
Another question I have is how flexible composite columns
13 matches
Mail list logo
