Comments on: NoSQL: Distributed and Scalable Non-Relational Database Systems http://www.linux-mag.com/id/7579/ Open Source, Open Standards Fri, 10 May 2013 08:56:11 +0000 hourly 1 http://wordpress.org/?v=3.1 By: pabo http://www.linux-mag.com/id/7579/#comment-7173 pabo Wed, 30 Nov -0001 00:00:00 +0000 http://www.linux-mag.com/id/7579/#comment-7173 <p>Interesting list. But I miss one really mature alternative: the ZODB, Zope Object database. It is an object-oriented database for transparently and persistently storing Python objects. It is included as part of the Zope web application server, but can also be used independently of Zope. </p> Interesting list. But I miss one really mature alternative: the ZODB, Zope Object database. It is an object-oriented database for transparently and persistently storing Python objects. It is included as part of the Zope web application server, but can also be used independently of Zope.

]]> By: desnotes http://www.linux-mag.com/id/7579/#comment-7174 desnotes Wed, 30 Nov -0001 00:00:00 +0000 http://www.linux-mag.com/id/7579/#comment-7174 <p>CouchDB is a pared down version of Lotus Notes. The main designer of CouchDB, Damien Katz, updated the Lotus Notes formula language engine before moving to MySQL where he started CouchDB and then moved back to IBM. It\'s a great non-relational database and if you have experience with Notes, it is even easier to catch on.</p> <p>desNotes<br /> desNotes@gmail.com<br /> http://desnotesdev.blogspot.com </p> CouchDB is a pared down version of Lotus Notes. The main designer of CouchDB, Damien Katz, updated the Lotus Notes formula language engine before moving to MySQL where he started CouchDB and then moved back to IBM. It\’s a great non-relational database and if you have experience with Notes, it is even easier to catch on.

desNotes
desNotes@gmail.com
http://desnotesdev.blogspot.com

]]> By: jbellis http://www.linux-mag.com/id/7579/#comment-7175 jbellis Wed, 30 Nov -0001 00:00:00 +0000 http://www.linux-mag.com/id/7579/#comment-7175 <p>IMO the more interesting nosql databases are the distributed ones -- sure, the single-node key/value stores are interesting but if you just need 2x or 5x more performance you can always throw hardware at it.</p> <p>But if you need 100x? (And a data set larger than memory...) Then you need a distributed solution.</p> <p>I did some research about a year ago to see what OSS distributed database looked most promising. I settled on Cassandra and I\'ve been contributing to that project since. (I\'m a fan of improving existing projects, rather than fragmenting things further by starting a new one.) Cassandra combines a fully distributed design (no single points of failure) with a ColumnFamily data model that allows efficient update/querying of individual columns within a row (as opposed to a monolithic blob associated with each key), a custom storage engine optimized for writes that unlike btree engines does not slow down as data size outgrows RAM, and support for clusters spanning multiple data centers. </p> IMO the more interesting nosql databases are the distributed ones — sure, the single-node key/value stores are interesting but if you just need 2x or 5x more performance you can always throw hardware at it.

But if you need 100x? (And a data set larger than memory…) Then you need a distributed solution.

I did some research about a year ago to see what OSS distributed database looked most promising. I settled on Cassandra and I\’ve been contributing to that project since. (I\’m a fan of improving existing projects, rather than fragmenting things further by starting a new one.) Cassandra combines a fully distributed design (no single points of failure) with a ColumnFamily data model that allows efficient update/querying of individual columns within a row (as opposed to a monolithic blob associated with each key), a custom storage engine optimized for writes that unlike btree engines does not slow down as data size outgrows RAM, and support for clusters spanning multiple data centers.

]]> By: alphadogg http://www.linux-mag.com/id/7579/#comment-7176 alphadogg Wed, 30 Nov -0001 00:00:00 +0000 http://www.linux-mag.com/id/7579/#comment-7176 <p>Great. Yet another \"for hits\" article jumping on the NoSQL bandwagon.</p> <p>It\'s not a \"higher-level change\" at all. It\'s dropping back down into the physical bowels of data storage when we had started rising above it with declarative \"magic\".</p> <p>I\'ll admit it\'s the backend trend du jour. Like OODBMSes, XML DBMSes, etc were and then got relegated to niche usage when placed against the more-than-acceptable performance of RDBMSes for 90% of projects, and the plethora of community, educational tools and technologies creating a rich support environment.</p> <p>The main reason this will happen with the various key-value stores that are now in vogue is that they, like the predecessors, are built to solve a very, very specific issue on high-volume, low-complexity data, which is not the norm. The NoSQL moniker is indicative of a misplaced focus. NO structured query language? Really? We want to go back to chasing pointers and recreating wrappers for access?</p> <p>However, the sea of developers that poorly understand the relational model and must continuously re-invent the wheel will likely never disappear. </p> Great. Yet another \”for hits\” article jumping on the NoSQL bandwagon.

It\’s not a \”higher-level change\” at all. It\’s dropping back down into the physical bowels of data storage when we had started rising above it with declarative \”magic\”.

I\’ll admit it\’s the backend trend du jour. Like OODBMSes, XML DBMSes, etc were and then got relegated to niche usage when placed against the more-than-acceptable performance of RDBMSes for 90% of projects, and the plethora of community, educational tools and technologies creating a rich support environment.

The main reason this will happen with the various key-value stores that are now in vogue is that they, like the predecessors, are built to solve a very, very specific issue on high-volume, low-complexity data, which is not the norm. The NoSQL moniker is indicative of a misplaced focus. NO structured query language? Really? We want to go back to chasing pointers and recreating wrappers for access?

However, the sea of developers that poorly understand the relational model and must continuously re-invent the wheel will likely never disappear.

]]> By: satpal12021 http://www.linux-mag.com/id/7579/#comment-7177 satpal12021 Wed, 30 Nov -0001 00:00:00 +0000 http://www.linux-mag.com/id/7579/#comment-7177 <p>Saltmarch Media is organizing Great Indian Developer Summit event in Bangalore. This Summit will be a boost for the Software Developing Industries. It covers the topics like .Net,Simple DB, CouchDB, NoSQL, Java and Richweb and has 1 day workshop at the end as well. Any one attending this event?</p> <p>Register @ www.developersummit.com </p> Saltmarch Media is organizing Great Indian Developer Summit event in Bangalore. This Summit will be a boost for the Software Developing Industries. It covers the topics like .Net,Simple DB, CouchDB, NoSQL, Java and Richweb and has 1 day workshop at the end as well. Any one attending this event?

Register @ http://www.developersummit.com

]]>