Apache Puts Out Cassandra 1.2 NoSQL Database

[phoronix]

Phoronix: Apache Puts Out Cassandra 1.2 NoSQL Database

The Apache Software Foundation has announced the release of Cassandra. Version 1.2 of the Cassandra big data "NoSQL" distributed database introduces several new features to the open-source project...

http://www.phoronix.com/vr.php?view=MTI2Njg

[Linuxhippy]

Phoronix: Apache Puts Out Cassandra 1.2 NoSQL Database

So what ......?

[mark45]

So what ......?

As Michael's official spokesman I'm informing you the decision was based upon the fact it appeared on slashdot and on general phoronix news cadence requirements. For more details please read the EULA you agreed with when becoming a member of the forum. If you don't agree with anything see you in the courtroom.

[uid313]

Please not another query language.
Does every database need its own query language?

If you switch or migrate to another database solution then you have to rewrite your database queries. It leads to vendor lock-in.

Can't we all get along and use à standard common query language?

Isn't there XPath or XQuery or something?

[kazetsukai]

Preface: I'm a PHP developer who sticks to MVC. I've spent the last two years writing a search engine that uses Oracle, MySQL, MongoDB, LDAP, (and soon, probably, CouchDB). I'm not some idiot who sticks database connection code into their view.

Please not another query language.
Does every database need its own query language?

To give a counterexample: As Mongo shows, no. There is no "query language", it uses a purely programmatic interface which greatly simplifies your business logic / model layers. That being said, there are significant differences between traditional rowstore databases such as Oracle/MySQL and columnstores like Cassandra. SQL doesn't make a hell of alot of sense unless you force users into a rowstore-like convention. Great example of that: InfiniDB. Columnstore, but with a MySQL interface. Ass-kicking performance, too.

If you switch or migrate to another database solution then you have to rewrite your database queries. It leads to vendor lock-in.

False... if you're locked into one database because of the query language, you're doing it wrong. Your database code should be abstracted from your models using ORM or another common API layer. To support additional database engines, write ORM layers for them. Done.

Can't we all get along and use à standard common query language?

Again, Cassandra is a columnstore database, so SQL doesn't make a hell of alot of sense for what the product does. Mongo, being a recordstore (with no strict "schema"), also shouldn't have to fit into an arbitrary query "language" either... they're nonsensical.

Query languages in general are the problem, we need more purely programmatic interfaces to databases. I'd say one of the biggest drawbacks of MySQL/Oracle is that they rely on the developer to pass them STRINGS of data hacked together with escaping functions, rather than something that makes sense to a developer.

<?php 

// MySQL Database Connection 
$dbh = new mysqli('localhost', 'my_user', 'my_password', 'userdatabase');
if($result = $dbh->query('SELECT * FROM users WHERE FIRSTNAME = '.$dbh->real_escape_string($name))){
     // Cycle through results
    while ($row = $result->fetch_object()){
        $user_arr[] = $row;
    }
    // Free result set
    $result->close();
}

// Mongo Connection
$m = new Mongo();
// Use the user database
$db = $m->userdatabase;

$user_arr = $db->users->find(array('FIRSTNAME' => $name));

?>

One of the most basic advantages here is that I can specify 'FIRSTNAME' as a variable in the Mongo Connection case. To do that with MySQL, I either have to write complex query language building logic, or I have to write lots of specific use case queries with placeholder variables to handle each scenario.

Query languages are the bane of a developer's existence. There's a reason why Hibernate (Java) and Active Record (Ruby) are so popular... For PHP, I recommend replacing MySQL as your database swiss-army-knife with Mongo. It is faster in every regard and "the Oracle" isn't looming over your head.

[uid313]

Preface: I'm a PHP developer who sticks to MVC. I've spent the last two years writing a search engine that uses Oracle, MySQL, MongoDB, LDAP, (and soon, probably, CouchDB). I'm not some idiot who sticks database connection code into their view.

You should take a look at MariaDB, I've heard it is same as MySQL but faster and better.

You should also take a look at PostgreSQL, it seems like a nice database, I've heard it is much more strict and sane than MySQL.

[kazetsukai]

You should take a look at MariaDB, I've heard it is same as MySQL but faster and better.

You should also take a look at PostgreSQL, it seems like a nice database, I've heard it is much more strict and sane than MySQL.

Both use SQL based query languages and (at least in MariaDB's case-) don't scale up well. Postgres is heavy analytic but suffers in performance in many areas.

Calpont's InfiniDB is probably the best scaling SQL database I've seen yet. On a single i7 workstation / 12GB of RAM, I was able to do analytic queries (distinct count, count(*) + group by, etc) against a ~500,000,000,000 "row" table in about 2.5s (without indexes, unnecessary). All cores light up 100%, RAM usage minimal, and the disks are screaming. Really maximizes the hardware. MySQL reaches that response time at 20,000,000 rows (with indexes) with the same hardware.

I'd love to have tried their commercial product with 14 nodes in a scale-out configuration.

That being said, Mongo took over an 80M row database I was hosting on InfiniDB and brought some complex 0.8s query times down to 0.015s. Heavy reliance on Indexes and it eats your RAM alive but no CPU or disk usage. The database is obviously cheating (indexes in RAM ) but that means high-volume in addition to big-data, and you can even host the database itself on a VM (with ample RAM). I could also use the dynamic schema nature of recordstore to bring the same dataset down from 80M documents to about 500,000 documents (consolidation of canonicals, etc), so I still have a lot of optimization left to do.