gt;>>> uuid1 : ""
>>>>>> uuid2: ""
>>>>>> uuid3: ""
>>>>>> }
>>>>>> "2010080712" : {
>>>>>> uuid1 : &qu
on't have to build up all the keys for the multi_get
and instead I can just provide and start& finish for the columns (time
frames).
Is there any performance penalty for a multi_get that includes x keys
versus a get on 1 key with a start/finish range of x?
Using your gem,
multi_get("SearchLog", ["20090101"..."20100807"], "127.0.0.1")
vs
get("SearchLog", "127.0.0.1", :start => "20090101", :finish => ""127.0.0.1")
Thanks
Yes, I use OrderPreservngPartitioner, the token considers datacenter+ip
+function+timestamp+recordId+...
On Aug 7, 2010, at 10:36 PM, Jonathan Ellis wrote:
are you using OrderPreservingPartitioner then?
On Sat, Aug 7, 2010 at 10:32 PM, Zhong Li wrote:
Here is just my personal experiences.
are you using OrderPreservingPartitioner then?
On Sat, Aug 7, 2010 at 10:32 PM, Zhong Li wrote:
> Here is just my personal experiences.
>
> I recently use Cassandra to implement a system cross 5 datacenters. Because
> it is impossible to do it in SQL Database at low cost, Cassandra helps.
>
> Cas
Here is just my personal experiences.
I recently use Cassandra to implement a system cross 5 datacenters.
Because it is impossible to do it in SQL Database at low cost,
Cassandra helps.
Cassandra is all about indexing, there is no relationship naturally,
you have to use indexing to keep a
certainly it matters: your previous version is not bounded on time, so
will grow without bound. ergo, it is not a good fit for cassandra.
On Sat, Aug 7, 2010 at 2:51 PM, Mark wrote:
> On 8/7/10 2:33 PM, Benjamin Black wrote:
>>
>> Right, this is an index row per time interval (your previous emai
On 8/7/10 2:33 PM, Benjamin Black wrote:
Right, this is an index row per time interval (your previous email was not).
On Sat, Aug 7, 2010 at 11:43 AM, Mark wrote:
On 8/7/10 11:30 AM, Mark wrote:
On 8/7/10 4:22 AM, Thomas Heller wrote:
Ok, I think the part I was missing was
Right, this is an index row per time interval (your previous email was not).
On Sat, Aug 7, 2010 at 11:43 AM, Mark wrote:
> On 8/7/10 11:30 AM, Mark wrote:
>>
>> On 8/7/10 4:22 AM, Thomas Heller wrote:
Ok, I think the part I was missing was the concatenation of the key and
partitio
On 8/7/10 11:30 AM, Mark wrote:
On 8/7/10 4:22 AM, Thomas Heller wrote:
Ok, I think the part I was missing was the concatenation of the key and
partition to do the look ups. Is this the preferred way of
accomplishing
needs such as this? Are there alternatives ways?
Depending on your needs you
On 8/7/10 4:22 AM, Thomas Heller wrote:
Ok, I think the part I was missing was the concatenation of the key and
partition to do the look ups. Is this the preferred way of accomplishing
needs such as this? Are there alternatives ways?
Depending on your needs you can concat the row key or us
The first.
On Sat, Aug 7, 2010 at 10:04 AM, james anderson wrote:
> good afternoon;
>
> On 2010-08-07, at 15:26 , Jonathan Ellis wrote:
>
>> I am using the familiar meanings from ACID:
>>
>> atomic means either the entire update will succeed or none of it.
>>
>> isolated means other threads will
Rows are sorted as UTF8 strings in 0.6 and byte[] in 0.7. That's it.
On Fri, Aug 6, 2010 at 10:09 PM, Mark wrote:
> In the "CassandraLimitations" wiki it states:
>
> " Cassandra has two levels of indexes: key and column"
>
> I understand how the column and subcolumn indexes work but can someone
good afternoon;
On 2010-08-07, at 15:26 , Jonathan Ellis wrote:
I am using the familiar meanings from ACID:
atomic means either the entire update will succeed or none of it.
isolated means other threads will not see partial updates while it is
being applied.
yes, those terms are not new.
i
I am using the familiar meanings from ACID:
atomic means either the entire update will succeed or none of it.
isolated means other threads will not see partial updates while it is
being applied.
On Sat, Aug 7, 2010 at 12:50 AM, james anderson wrote:
> good morning;
>
> On 2010-08-07, at 02:45 ,
> Ok, I think the part I was missing was the concatenation of the key and
> partition to do the look ups. Is this the preferred way of accomplishing
> needs such as this? Are there alternatives ways?
Depending on your needs you can concat the row key or use super columns.
> How would one then "qu
On Sat, Aug 7, 2010 at 11:41 AM, Peter Schuller
wrote:
>> Remember the returned results are NOT sorted, so you whenever you are
>> dropping the first by default, you might be dropping a good one. At
>> least that would be my guess here.
>
> Sorry I may be forgetting something about this thread, bu
> Remember the returned results are NOT sorted, so you whenever you are
> dropping the first by default, you might be dropping a good one. At
> least that would be my guess here.
Sorry I may be forgetting something about this thread, but AFAIK the
results from cassandra (the thrift API) are sorted
>> Another way to do it is to filter results to exclude columns received
>> twice due to being on iteration end points.
>
> Well, depends on the size of your rows, keeping lists of 1mil+ column
> names will eventually become rally slow (at least in ruby).
You only have to keep track of a singl
18 matches
Mail list logo
