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 wrote:
> On Sat, Feb 4, 2012 at 8:54 PM, Yiming Sun wrote:
> > Interesting idea,
On Sat, Feb 4, 2012 at 8:54 PM, Yiming Sun 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 must conform
to that
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 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:
>
> FilesMeta
> Fi
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
> Interesting idea, Jim. Is there a reason you don't you use
> "metadata:{accountId}" instead? For performance reasons?
>
>
> On
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 wrote:
> I've used "special" values which still comply with the Composite
> schema for the metadata columns, e.g. a column of
> 1970-01
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 wrote:
> I just kept both row keys the same. This was very trivial for fetching
> them both. Wh
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 wrote:
> Thanks Andrey and Chris. It sounds li
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
> Interesting idea, R.V. But what did you do with the row keys?
>
>
> On Sat, Feb 4, 2012 at 2:29 PM, R. Verlangen wrote:
>
>> I also made som
Interesting idea, R.V. But what did you do with the row keys?
On Sat, Feb 4, 2012 at 2:29 PM, R. Verlangen 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 good at read
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
> Thanks Andrey and Chris. It sounds like we don't nec
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
homogene
>
>
> On 4 February 2012 06:21, Yiming Sun 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. If
On 4 February 2012 06:21, Yiming Sun 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. If
> my data mode
Hi,
We are getting close to replacing our super-column based schema to
something more efficient, and I am trying to wrap my heads around composite
columns.
An email from another list member has clarified that composite and
non-composite columns should not be mixed in the same CF because only one
14 matches
Mail list logo
