cassandra performance looking great...
So we wrote 1,000,000 rows into cassandra and ran a simple S-SQL(Scalable SQL) query of PARTITIONS n(:partition) SELECT n FROM TABLE as n WHERE n.numShares = :low and n.pricePerShare = :price It ran in 60ms So basically playOrm is going to support millions of rows per partition. This is great news. We expect the join performance to be very similar since the trees of pricePerShare and numShares are really no different than the join trees. So, millions of rows per partition and as many partitions as you want, it scales wonderfully…..CASSANDRA ROCKS Behind the scenes, there is a wide row per partition per index so the above query behind the scenes has two rows each with 1,000,000 columns. Later, Dean
Re: cassandra performance looking great...
Try to get Cassandra running the TPH-C benchmarks and beat oracle :) On Fri, Sep 7, 2012 at 10:01 AM, Hiller, Dean dean.hil...@nrel.gov wrote: So we wrote 1,000,000 rows into cassandra and ran a simple S-SQL(Scalable SQL) query of PARTITIONS n(:partition) SELECT n FROM TABLE as n WHERE n.numShares = :low and n.pricePerShare = :price It ran in 60ms So basically playOrm is going to support millions of rows per partition. This is great news. We expect the join performance to be very similar since the trees of pricePerShare and numShares are really no different than the join trees. So, millions of rows per partition and as many partitions as you want, it scales wonderfully…..CASSANDRA ROCKS Behind the scenes, there is a wide row per partition per index so the above query behind the scenes has two rows each with 1,000,000 columns. Later, Dean
Re: cassandra performance looking great...
Now that would be cool. Right now though, to many other features need to be added like a GUI on top of the ad-hoc query tool is the next top priority so one can do any S-SQL statement and ad-hoc query the heck out of a noSQL store. We may even be able to optimize our queries to be even faster with a new lookahead nested loop join that we have not implemented yet which fetches the next block of data before we needed it for comparisons. (DBMS only has nested block loop join which blocks on disk I/O each time it reads a block). Dean On 9/7/12 8:22 AM, Edward Capriolo edlinuxg...@gmail.com wrote: Try to get Cassandra running the TPH-C benchmarks and beat oracle :) On Fri, Sep 7, 2012 at 10:01 AM, Hiller, Dean dean.hil...@nrel.gov wrote: So we wrote 1,000,000 rows into cassandra and ran a simple S-SQL(Scalable SQL) query of PARTITIONS n(:partition) SELECT n FROM TABLE as n WHERE n.numShares = :low and n.pricePerShare = :price It ran in 60ms So basically playOrm is going to support millions of rows per partition. This is great news. We expect the join performance to be very similar since the trees of pricePerShare and numShares are really no different than the join trees. So, millions of rows per partition and as many partitions as you want, it scales wonderfullyŠ..CASSANDRA ROCKS Behind the scenes, there is a wide row per partition per index so the above query behind the scenes has two rows each with 1,000,000 columns. Later, Dean
