On Sat, Apr 24, 2010 at 6:27 AM, Carlos Sanchez
wrote:
> There are forEach methods in that would allow you to travel the
> keys/values/entries w/o creating the extra object (entries)
Ok. So if change was made, it'd make sense to ensure those were used
for traversal. Thanks!
-+ Tatu +-
On Sat, Apr 24, 2010 at 9:29 PM, dir dir wrote:
> I have already read Jonathan Ellis's Blog today
> (http://spyced.blogspot.com/2009/03/why-i-like-cassandra.html)
>
> in this blog, Jonathan tried to explain the difference between Cassandra and
> Hbase.
> But I have several questions. In this blog
On Sat, Apr 24, 2010 at 10:59 PM, Jonathan Ellis wrote:
> No, Framed is totally different.
You are right. Seeing both, the java and c# thrift code, I think that
there is no need to use other transport than TSocket in Java because
it seems to be using buffered stream in the TSocket implementation.
Hi Paul,
I have already read Jonathan Ellis's Blog today
(http://spyced.blogspot.com/2009/03/why-i-like-cassandra.html)
in this blog, Jonathan tried to explain the difference between Cassandra and
Hbase.
But I have several questions. In this blog Jonathan said:
1. Hbase Follows the bigtable mode
On Sat, Apr 24, 2010 at 7:17 PM, Carlos Alvarez wrote:
> On Sat, Apr 24, 2010 at 8:00 PM, Joost Ouwerkerk wrote:
>> TBufferedTransport seems to be missing from the Java library bundled with
>> cassandra-bin (0.6.1)...
>
> I think is TFramedTransport in Java.
No, Framed is totally different.
> B
I would say that HBase is a little bit more focused on reads and Cassandra
on writes.
HBase has better scans and Cassandra better multi datacenter functionality.
Erik
On Sat, Apr 24, 2010 at 8:00 PM, Joost Ouwerkerk wrote:
> TBufferedTransport seems to be missing from the Java library bundled with
> cassandra-bin (0.6.1)...
I think is TFramedTransport in Java.
BTW, I ran the test and I saw enomous improvement in performance (a
1/30 of the original time).
Don
TBufferedTransport seems to be missing from the Java library bundled with
cassandra-bin (0.6.1)...
On Sat, Apr 24, 2010 at 5:54 PM, Miguel Verde wrote:
> Yes, one should use either the TBufferedTransport or TFramedTransport in
> Java for performance reasons. These are analogous to the C# Socket c
Yes, one should use either the TBufferedTransport or TFramedTransport
in Java for performance reasons. These are analogous to the C# Socket
classes and you should see a performance improvement from buffering.
On Apr 24, 2010, at 5:31 PM, Joost Ouwerkerk
wrote:
Is this something that al
Is this something that also needs to be managed in Java? In most examples
I've seen, connections are created like this:
TSocket socket = new TSocket(location, thriftport)
TBinaryProtocol binaryProtocol = new
TBinaryProtocol(socket, false, false);
Cassandra.Clien
On Fri, Apr 23, 2010 at 4:29 PM, Heath Oderman wrote:
> Really interesting find.
> After Jonathan E. suggested py_stress and it seemed clear the problem was in
> my .net client I spent a few days debugging the client in detail.
> I ended up changing my CassandraContext instantiation to use a
>
http://ria101.wordpress.com/2010/02/24/hbase-vs-cassandra-why-we-moved/
http://spyced.blogspot.com/2009/03/why-i-like-cassandra.html
On Sat, Apr 24, 2010 at 10:20 AM, dir dir wrote:
> In general what is the difference between Cassandra and HBase??
>
> Thanks.
>
>No, it just means they don't have dependencies on each other. In this
>case, it means you could create a transactional layer on top of
>cassandra, without having to make it part of the core.
Now I Understand, thank you.
On Sun, Apr 25, 2010 at 12:46 AM, Jonathan Ellis wrote:
> On Sat, Apr 24
Ok in this particular context it means no dependencies.
Thanks for your precision.
Kind regards,
Benoit.
2010/4/24 Jonathan Ellis :
> On Sat, Apr 24, 2010 at 12:44 PM, Benoit Perroud wrote:
>> "orthogonal" means "90 degrees". Two lines are orthogonal if the
>> cross at 90 degrees.
>>
>> Two
On Sat, Apr 24, 2010 at 12:44 PM, Benoit Perroud wrote:
> "orthogonal" means "90 degrees". Two lines are orthogonal if the
> cross at 90 degrees.
>
> Two ideas are orthogonal means that they are not compatible.
No, it just means they don't have dependencies on each other. In this
case, it means
"orthogonal" means "90 degrees". Two lines are orthogonal if the
cross at 90 degrees.
Two ideas are orthogonal means that they are not compatible.
Transactions is orthogonal with Cassandra's design means that it will
require a lot of work and trade-off to implement transactions into
Cassandra.
Do you mean orthogonal like Commit and Rollback?? For example after we
perform Rollback, hence we cannot going back.
>Including "transaction" in Cassandra needs to turn 90 degrees
>the design of Cassandra
I do not understand what is the meaning of "needs to turn 90 degrees"??
Thank you.
On Sun,
"orthogonal" means "go to the opposite direction, but without going
back". Including "transaction" in Cassandra needs to turn 90 degrees
the design of Cassandra.
Kind regards,
Benoit.
2010/4/24 dir dir :
>>Transactions are orthogonal to the design of Cassandra
>
> Sorry, Would you want to tell
I'm having trouble deleting rows in Cassandra. After running a job that
deletes hundreds of rows, I run another job that verifies that the rows are
gone. Both jobs run correctly. However, when I run the verification job an
hour later, the rows have re-appeared. This is not a case of "ghosting"
In general what is the difference between Cassandra and HBase??
Thanks.
>Transactions are orthogonal to the design of Cassandra
Sorry, Would you want to tell me what is an orthogonal mean in this
context??
honestly I do not understand what is it.
Thank you.
On Thu, Apr 22, 2010 at 9:14 PM, Miguel Verde wrote:
> No, as far as I know no one is working on transaction
There are forEach methods in that would allow you to travel the
keys/values/entries w/o creating the extra object (entries)
From: Tatu Saloranta [tsalora...@gmail.com]
Sent: Friday, April 23, 2010 11:58 PM
To: user@cassandra.apache.org
Subject: Re: Trove m
On Sat, Apr 24, 2010 at 12:53 AM, Jesse McConnell
wrote:
> try LexicalUUIDType, that will distinguish the secs correctly
>
> imo based on the existing impl (last I checked at least) TimeUUIDType
> was equivalent to LongType
It uses to be true that the TimeUUIDType comparator was only comparing th
23 matches
Mail list logo
