Nikita Ivanov (GridGrain):

Look, 90% of NoSQL usage comes from the same crowd as a typical memcached users: non-critical, “moms-n-pops” websites. 90% of IMDG/IMCG usage comes from mission critical systems.

Different customers => different requirements => different products…

Unfortunately neither my mom nor my dad are behind non-critical websites like Amazon, Facebook, Google, or LinkedIn. What about yours?

Original title and link: NoSQL Is for Moms-N-Pops Websites (NoSQL database©myNoSQL)

via: http://java.dzone.com/articles/why-memory-data-grids-are-more

Teacher asking a student:

After the Presentation the team leader asked me how it is, to migrate the db’s under various types. […] Can I migrate from a, key-value store db, like dynamo, to a, document store db, like mongoDB?

I’m not sure if this would have been reflected on the final grade, but I would have asked how many times did the teacher had to, really had to migrate data between multiple relational databases? And how many times it worked automatically? If allowed I’d have followed up with a very brief dialogue about the complexity of migrating applications to different programming languages (even when they use the same programming paradigm) and brought up examples of important differences of access and mutations of data structures. In the end I might have failed the exam though.

On a more serious note, there are so many aspects of migrating data that is very difficult to have a good short answer to this question. A sign of this problem’s complexity is the wide range of companies and products trying to solve ETL.

Original title and link: Migrating Between Two Different Types of NoSQL Databases (NoSQL database©myNoSQL)

via: https://groups.google.com/forum/?fromgroups#!topic/nosql-discussion/_Oj4rJ2Q4q8%5B1-25%5D

If you never looked into Spring Data, Tobias Trelle’s article could give you a brief overview:

Spring Data is a high level SpringSource project whose purpose is to unify and ease the access to different kinds of persistence stores, both relational database systems and NoSQL data stores.

The article is pretty clear why unification for the various relational and NoSQL databases won’t really work. The part left is ease of access, which in itself could still be an achievement. But without the unifying part I think Spring Data is just the Spring way of doing NoSQL for Spring users and not a general solution that non-Spring users would benefit of. I’m aware I’ve said this before.

Original title and link: Spring Data: One API to Rule Them All or Giving NoSQL to Spring Users (NoSQL database©myNoSQL)

via: http://www.infoq.com/articles/spring-data-intro

James Hamilton puts in perspective the last two new I/O related features coming from Amazon: the high performance I/O EC2 instances and EBS provisioned IOPS together with EBS-optimized EC2 instances:

With the announcement today, EC2 customers now have access to two very high performance storage solutions. The first solution is the EC2 High I/O Instance type announced last week which delivers a direct attached, SSD-powered 100k IOIPS for $3.10/hour. In today’s announcement this direct attached storage solution is joined by a high-performance virtual storage solution. This new type of EBS storage allows the creation of striped storage volumes that can reliably delivery 10,000 to 20,000 IOPS across a dedicated virtual storage network.

I’ve already said it, but this confirms it once again that Amazon is addressing most of the complains of running I/O intensive applications on EC2 and EBS.

Original title and link: I/O Intensive Apps and Amazon Cloud Improvements: EBS Provisioned IOPS & Optimized Instance Types (NoSQL database©myNoSQL)

via: http://perspectives.mvdirona.com/2012/08/01/EBSProvisionedIOPSOptimizedInstanceTypes.aspx

Andrew Oliver:

Yet there are obstacles to this transition. First, NoSQL lacks a dominant force. For the RDBMS, no matter which product you choose, you have at least a subset of ANSI standard SQL on which you can depend. For any of the new databases, you may have Pig, Hive, SPARQL, Mongo Query Language, Cypher, or others. These languages have little in common. For the RDBMS, you have some connector standard, at least, in the venerable ODBC. For NewDB, you must rely on a database-specific connector.

What’s needed now is for the NoSQL vendors (10gen, Cloudbase, and so on), interested parties (such as SpringSource, Red Hat, Microsoft, and IBM), and various projects to come together, take some of these separate efforts, and propose standards. First, define the query level. Then define the connector standards.

I’d like to suggest the name of this all-included query language: ingohQL. That stands for it’s-not-going-to-happen-QL.

Original title and link: The Time for NoSQL Standards Is Now (NoSQL database©myNoSQL)

via: http://www.infoworld.com/print/194998

Dan Kusnetzky proposes the following 6 features as part of an ideal transactional database:

1. SQL
2. ACID transactions
3. Data and application independence
4. Elasticity
5. Multi-tenancy
6. Geographic distribution

The real question would such a database including all these features be possible? We already know that ACID transactions and support for geographic distribution don’t mix well. SQL was created to work with the relational model, so it’ll be quite limited when considering other data models—think graphs. There are also some (good) arguments why a declarative language as SQL might not be the best fit for large scale databases. Last, but not least, designing a common API to support the different data models is not that realistic either.

Original title and link: 6 Ideal Features for Big Data Transactional Database (NoSQL database©myNoSQL)

via: http://www.zdnet.com/what-features-would-an-ideal-transaction-oriented-big-data-database-require-7000001392/

Jeff Cogswell compares some short code samples in an attempt to answer the much bigger question:

But what about the programmers, who write the client code that access the databases? Where do the disagreements leave them? From a programming perspective, is SQL really that horrible and outdated? Or is the new NoSQL really that awful to work with? Perhaps they both have strengths and good points.

I confess that reading the above made me curious about what the article would conclude. Unfortunately, by the time I’ve read the first comparison (JavaScript in NodeJS using SQL vs Mongo) I realized my expectations were too high. For a few reasons:

1. it would have been impossible to compare the APIs of all relevant NoSQL databases with a relational database;
2. it would have been very difficult to choose a generic, representative enough use case;
3. the results would have always been heavily influenced by the quality of drivers and libraries used.

Last but not least, many of the merits of the NoSQL databases are related to operational complexity and not programming complexity. As someone that did a fare amount of coding and close to zero operations, I would probably feel OK accepting a bit of programming complexity for simplified operations. But that might be just a biased opinion.

Original title and link: Which Is Better for Programmers: SQL vs. NoSQL? (NoSQL database©myNoSQL)

via: http://slashdot.org/topic/bi/sql-vs-nosql-which-is-better/

Damien Katz:

Forget SQL. Forget network, document or object databases. Forget the relational algebra. Forget schemas. Forget joins and normalization. Forget ACID. Forget Map/Reduce.

Think knowledge representation. Think knowledge collection, transformation, aggregation, sharing. Think knowledge discovery.

Think of humanity and its collective mind expanding.

A great read.

Original title and link: Why Database Technology Matters (NoSQL database©myNoSQL)

via: http://damienkatz.net/2012/06/why_database_technology_matter.html

Jeff Dickey enumerates some of the new features available in PostgreSQL—schema-less data, array columns, queuing, full-text searching, geo-spatial indexing—concluding that PosgreSQL has now everything an application needs:

Postgres has taken the features out of all of these tools and integrate it right inside the platform. Now you don’t need to spin up a mongo cluster for non-rel data, rabbitmq cluster for queueing, solr box for searching. You can just have a single postgres server. That saves a huge ops headache since each of those clusters/boxes have to be durable, replicated, and scalable.

Sounds a bit too optimistic? As we’ve learned from the NoSQL space there are no silver bullets:

Now obviously, there’s a glaring downside with this approach: you get one box. Maybe a read slave or something, but really, you can’t scale it.

As you can imagine I disagree with most of the points, the only exception being that it is great to see so many useful features packaged with PostgreSQL—these are definitely going to make like easier for some of the developers.

But when talking about MySQL and NoSQL being done:

1. MySQL is done, except it has a huge community, there are tons of developers very familiar with it, and last but not least MySQL powers massive deployments. This last part matters a lot.
2. NoSQL is done, except many NoSQL solutions tackle different problem spaces providing optimal solutions for these by staying focused. Neither Oracle, nor MongoDB, nor PosgreSQL will be able to solve all problems. The wider range of problems they are covering, the less optimal solutions they are providing for corner case or extreme scenarios.

Original title and link: MySQL Is Done. NoSQL Is Done. It’s the Postgres Age (NoSQL database©myNoSQL)

via: http://dickey.xxx/mysql-is-done-it-s-the-postgres-age

Uncle Bob:

The center of your application is not the database. Nor is it one or more of the frameworks you may be using. The center of your application are the use cases of your application. […] If you get the database involved early, then it will warp your design. It’ll fight to gain control of the center, and once there it will hold onto the center like a scruffy terrier. You have to work hard to keep the database out of the center of your systems. You have to continuously say “No” to the temptation to get the database working early.

Original title and link: NO DB - the Center of Your Application Is Not the Database (NoSQL database©myNoSQL)

via: http://blog.8thlight.com/uncle-bob/2012/05/15/NODB.html