ALL COVERED TOPICS

NoSQL Benchmarks NoSQL use cases NoSQL Videos NoSQL Hybrid Solutions NoSQL Presentations Big Data Hadoop MapReduce Pig Hive Flume Oozie Sqoop HDFS ZooKeeper Cascading Cascalog BigTable Cassandra HBase Hypertable Couchbase CouchDB MongoDB OrientDB RavenDB Jackrabbit Terrastore Amazon DynamoDB Redis Riak Project Voldemort Tokyo Cabinet Kyoto Cabinet memcached Amazon SimpleDB Datomic MemcacheDB M/DB GT.M Amazon Dynamo Dynomite Mnesia Yahoo! PNUTS/Sherpa Neo4j InfoGrid Sones GraphDB InfiniteGraph AllegroGraph MarkLogic Clustrix CouchDB Case Studies MongoDB Case Studies NoSQL at Adobe NoSQL at Facebook NoSQL at Twitter

NAVIGATE MAIN CATEGORIES

Close

NewSQL: All content tagged as NewSQL in NoSQL databases and polyglot persistence

Traditional, NoSQL and NewSQL Are All Broken. All Data in Memory

Stancey Schneider for VMware:

Over the past few years, memory has gotten cheap and is easily commoditized in the cloud. So moving your data strategy to put it all in-memory just plain makes sense. It eliminates an extra hop to read and write data from disk, making it inherently faster and the performance more consistent. It also manages to simplify the internal optimization algorithms and reduce the number of instructions to the CPU making better use of the hardware.

This is the “conclusion” after “establishing” in the post that:

  1. traditional databases are already broken because of the fixed schemas and data being persisted on disk
  2. NoSQL databases are also broken because even if they have flexible schemas, data is still persisted on disk and “replication takes time to do all the read and writes”
  3. NewSQL are also broken because “the way the databases handles the data distribution makes it so there NewSQL databases do not scale linearly”

All this FUD just to promote GemFire and SQLFire? I really thought VMware is a serious company.

Original title and link: Traditional, NoSQL and NewSQL Are All Broken. All Data in Memory (NoSQL database©myNoSQL)

via: http://blogs.vmware.com/vfabric/2013/03/why-every-database-must-be-broken-soon.html


One Database to Rule Them All?

Curt Monash took upon himself the task of writing about why a data store independent of consistency models, upfront data modeling and access algorithms is almost impossible:

To date, nobody has ever discovered a data layout that is efficient for all usage patterns.

He’s reached a similar conclusion to what I wrote in my link post. Here’s mine:

[…] a database feature an ubiquitous interface independent of consistency models, upfront data modeling, and access algorithms is never going to be efficient. Actually, I’m not even sure it would make sense being built

Here’s Curt Monash’s:

So what would happen if somebody tried to bundle all conceivable functionality into a single DBMS, with a plan to optimize the layout of any particular part of the database as appropriate? I think the outcome would be tears — for the development effort would be huge, while the benefits would be scanty. The most optimistic cost estimates could run in the 100s of millions of dollars, with more realistic ones adding a further order of magnitude. But no matter what the investment, the architects would be on the horns of nasty dilemma

Definitely more impactful.

Original title and link: One Database to Rule Them All? (NoSQL database©myNoSQL)

via: http://www.dbms2.com/2013/02/21/one-database-to-rule-them-all/


A Data Store Independent of Consistency Models, Upfront Data Modeling and Access Algorithms

Tina Groves1 in “Where Does Hadoop Fit in a Business Intelligence Data Strategy?“:

For example, the decision to move and transform operational data to an operational data store (ODS), to an enterprise data warehouses (EDW) or to some variation of OLAP is often made to improve performance or enhance broad consumability by business people, particularly for interactive analysis. Business rules are needed to interpret data and to enable BI capabilities such as drill up/drill down. The more business rules built into the data stores, the less modelling effort needed between the curated data and the BI deliverable.

That’s why Chirag Mehta’s ideal database featuring “an ubiquitous interface independent of consistency models, upfront data modeling, and access algorithms” is never going to be efficient. Actually, I’m not even sure it would make sense being built.


  1. Tina Groves: Product Strategist, IBM Business Intelligence 

Original title and link: A Data Store Independent of Consistency Models, Upfront Data Modeling and Access Algorithms (NoSQL database©myNoSQL)

via: http://www.ibmbigdatahub.com/blog/where-does-hadoop-fit-business-intelligence-data-strategy


NoSQL or NewSQL: The Ideal Database

Talking about ideal database solutions, Chirag Mehta writes in “A Journey From SQL to NoSQL to NewSQL“:

“Design a data store that has ubiquitous interface for the application developers and is independent of consistency models, upfront data modeling (schema), and access algorithms. As a developer you start storing, accessing, and manipulating the information treating everything underneath as a service. As a data store provider you would gather upstream application and content metadata to configure, optimize, and localize your data store to provide ubiquitous experience to the developers. As an ecosystem partner you would plug-in your hot-swappable modules into the data stores that are designed to meet the specific data access and optimization needs of the applications.”

Original title and link: NoSQL or NewSQL: The Ideal Database (NoSQL database©myNoSQL)

via: http://cloudcomputing.blogspot.com/2013/01/a-journey-from-sql-to-nosql-to-newsql.html


VoltDB Hits Proverbial Version 3.0

Andrew Brust for ZDNet:

In the software world, many people believe that products reach true maturity and value in their third version. A first release is about bringing an idea to market, and second releases act to stabilize the first. But it’s “v3” that really incorporates refinements that reflect user feedback and market lessons learned. It seems to me that “NewSQL” database player VoltDB is following that pattern with its own 3.0 release.

There’re no such things as a proverbial version 3.0, nor a pattern about the meaning of version 3. Anyways, congrats to the VoltDB guys!

If you want to know what’s in VoltDB 3.0, ignore the linked post and go read Introducing VoltDB 3.0 on VoltDB blog. Short version: more performance, improved SQL support, support for JSON-encoded data and defining indexes for JSON columns.

Original title and link: VoltDB Hits Proverbial Version 3.0 (NoSQL database©myNoSQL)

via: http://www.zdnet.com/voltdb-hits-proverbial-version-3-0-7000010099/


The Evolving Database Landscape

Matthew Aslett of 451group published an updated version of the database landscape graphic that is included in the group reports:

DB-landscape

Very similar, but more complete than The Database World in a Venn Diagram from Infochimps.

Original title and link: The Evolving Database Landscape (NoSQL database©myNoSQL)

via: http://blogs.the451group.com/information_management/2012/11/02/updated-database-landscape-graphic/


The Database World in a Venn Diagram

Infochimps put together a comprehensive Venn diagram of the database world in the TechCrunch article Big Data Right Now: Five Trendy Open Source Technologies

The Database World

Original title and link: The Database World in a Venn Diagram (NoSQL database©myNoSQL)


VoltDB 3.0 Will Include a New Transaction Coordination Architecture

From the VoltDB 3.0 preview notes:

VoltDB v3.0 includes a new transaction coordination architecture that reduces latency and improves transaction throughput.

In VoltDB versions 1.x and 2.x, transactions were globally ordered and ordered according to time. Each node on the cluster communicated with every other node to agree upon transaction ordering. Maintaining a global agreement based on time caused VoltDB to incur additional latency - intra-node communication agreement involving all nodes. This architecture required users to synchronize cluster node clocks using NTP, because any time drift between nodes would introduce artificial, unneeded latency to the system. This overhead, and the strict need to maintain clock synchronization has been eliminated from the VoltDB v3.0 code base.

So how does the new solution work?

Original title and link: VoltDB 3.0 Will Include a New Transaction Coordination Architecture (NoSQL database©myNoSQL)


NewSQL NuoDB Patents Elastically Scalable Distributed Database

From the patent filing:

Therefore, it is an object of this invention to provide an elastic, scalable, on-demand, distributed data processing system.

Another object of this invention is to provide an elastic, scalable, on-demand, distributed data processing system that is fault tolerant.

Still another object of this invention is to provide an elastic, scalable, on-demand, distributed data processing system that has a high degree of availability.

Yet another object of this invention is to provide an elastic, scalable, on-demand, distributed data processing system that is platform independent.

Still yet other object of this invention is to provide an elastic, scalable, on-demand, distributed data processing system that is atomic, consistent, isolated and durable.

Yet still another object of this invention to provide an elastic, scalable, on-demand, distributed data processing system that operates over the Internet without a need for dedicated high-speed communications paths.

Still yet another object of this invention is to provide an elastic, scalable, on-demand, distributed data processing system that provides transaction processing and that is adapted for implementation over a wide geographic area.

As with everything legal or patent-related I have no comments. But reading the above description makes me think that NuoDB might have patented either all distributed databases or a perpetuum mobile of databases.

Original title and link: NewSQL NuoDB Patents Elastically Scalable Distributed Database (NoSQL database©myNoSQL)

via: http://gigaom.com/cloud/database-superstar-jim-starkey-touts-nuodbs-new-patent/


The Wonderful Wizard of Oz Through a Polyglot Persistence Glass

Adrian Giordani:

Relational databases are the Yellow Brick Road of managing large structured data globally. […] In the 1939 film of The Wizard of Oz, a red brick road is intertwined with the yellow one. Similarly, a new type of database might soon offer a different path: NoSQL, or Not-Only-SQL, first coined in 2008, is promising a faster and more scalable database architecture, at least for some cases.

But who’s the Tin Woodman?

Original title and link: The Wonderful Wizard of Oz Through a Polyglot Persistence Glass (NoSQL database©myNoSQL)

via: http://www.isgtw.org/feature/following-red-brick-road-data-management


Michael Stonebraker Says in Defense of NewSQL

The reason that this is becoming a hot-button issue is because IT organizations have invested billions of dollars in investments in SQL. Adding new data management frameworks such as Hadoop will add considerable expense in terms of finding people with the skills needed to manage these platforms. Stonebraker isn’t necessarily against Hadoop; he’s just pointing out that there is no one SQL database engine that fits all requirements and that before IT organizations adopt a NoSQL approach, they should consider other SQL-compatible approaches to solving the same problem.

Translated: What do these NoSQL kids know? My products are always the best. So instead of paying them, why not continue paying me.

Original title and link: Michael Stonebraker Says in Defense of NewSQL (NoSQL database©myNoSQL)

via: http://www.itbusinessedge.com/cm/blogs/vizard/in-defense-of-new-sql/?cs=49255


Traditional SQL DaaS vs NewSQL

Mike Hogan (CEO ScaleDB) provides some very valid issues with traditional relational databases operating as Databases-as-a-Service:

When moving from a self-managed database—either in the cloud or on premise—to a DaaS, the “DBA-in-the-cloud” doesn’t have that visibility into the business requirements, performance requirements, development schedule, and more. This lack of visibility turns the already challenging task of hand-tuning the database into a near impossibility using traditional databases.

And these are just the most visible ones.

On the other hand, I totally agree with Markus ‘maol’ Perdrizat pointing out that NewSQL is not the only solution to these problems:

I agree with the problem positioning, but feel strongly that NewSQL is not a requirement to address the problem here, you can equally work a little services layer and put all the control into the hands of the user, essentially replacing (a lot of) the DBA tasks with automation and APIs.

What NewSQL gives you though, and we see that with Xeround and supposedly also ScaleDB, is the elasticity and transparent sharding that’s difficult to achieve with the more traditional Oracle, Sybase or SQL Server databases that are still often required in the enterprise space.

Original title and link: Traditional SQL DaaS vs NewSQL (NoSQL database©myNoSQL)

via: http://scaledb.blogspot.com/2011/09/lack-of-business-visibility-cripples.html