Forgot your password?
typodupeerror
Data Storage Programming

New PostgreSQL Guns For NoSQL Market 162

Posted by samzenpus
from the coming-for-you dept.
angry tapir (1463043) writes "Embracing the widely used JSON data-exchange format, the new version of the PostgreSQL open-source database takes aim at the growing NoSQL market of nonrelational data stores, notably the popular MongoDB. The first beta version of PostgreSQL 9.4, released Thursday, includes a number of new features that address the rapidly growing market for Web applications, many of which require fast storage and retrieval of large amounts of user data."
This discussion has been archived. No new comments can be posted.

New PostgreSQL Guns For NoSQL Market

Comments Filter:
  • by wispoftow (653759) on Friday May 16, 2014 @12:04AM (#47015229)

    NB: I love PostgreSQL with all my heart. I always upgrade to the most recent version, because they implement features that I really need. Added to the existing features of Postgres, it's totally awesome.

    But as I have moved toward "Big Data" and the market segment that these new-fangled (non-relational) databases target, I find myself wishing that Postgres would be able to run my vanilla query (*singular*) using all processors. As it is now, I have to either write some awful functions that query manually-partitioned subtables, or simply wait while it plods through all billion or so rows.

  • by michaelmalak (91262) <michael@michaelmalak.com> on Friday May 16, 2014 @12:08AM (#47015241) Homepage
    A hallmark of NoSQL is horizontal scalability. The lack of schema in NoSQL was a brief rebellion against ivory tower DBAs that has since been regretted once it was realized that merely transferred the schema and schema versioning implicitly into the source code, and spread throughout it. Sounds like PostgreSQL got the bad part of NoSQL but not the good part.
  • by mlyle (148697) on Friday May 16, 2014 @12:49AM (#47015351)

    Look at Postgres-XL [postgres-xl.org] that we just released. It's a clustered database and can do MPP execution of your queries and has good write-scalability too. (To use all the processors in each machine, you'll want to have a few data nodes per machine.) It's pretty clever about planning a lot of things.

  • Re:next for NoSQL (Score:5, Interesting)

    by greg1104 (461138) <gsmith@gregsmith.com> on Friday May 16, 2014 @03:11AM (#47015667) Homepage

    All "NoSQL" means is that the database doesn't use SQL as its interface, nor the massive infrastructure needed to implement the SQL standard. This lets you build some things that lighter than SQL-based things, like schemaless data stores. There several consistency models that let you have a fair comparison. It's not the case that NoSQL must trade consistency for availability in a way that makes it impossible to move toward SQL spec behavior.

    Differences include:

    • Less durability for writes. Originally PostgreSQL only had high durability, NoSQL low. Now both have many options going from commit to memory being good enough to move on, up to requiring multiple nodes get the data first.
    • No heavy b-tree indexes on the data.
      Key-value indexes are small and efficient to navigate,
    • No complicated MVCC model for complicated read/write mixes.

      Today NoSQL solutions like MongoDB still have a better story for sharding data across multiple servers. NoSQL also give you Flexible schemaless design, scaling by adding nodes, and simpler/lighter query and indexes.

      PostgreSQL is still working on a built-in answer for multi-node sharding. A lot of the small NoSQL features have been incorporated, with JSON and the hstore key-value index being how Postgres does that part. Both system have converged so much, either one is good enough for many different types of applications.

  • Re:No SQL (Score:2, Interesting)

    by Anonymous Coward on Friday May 16, 2014 @07:40AM (#47016561)

    The main problem is that SQL sucks.

    Compared to what? I'm not sure you have any idea what kinds of inflexible horrors preceded the relational systems. Furrthermore, SQL is based on relational algebra, which underlies the whole RDBMS concept; if you need a data manipulation language closely matching the capabilities of an RDBMS, it has to be set-oriented and based on relational algebra (or relational calculus, which is equivalent). And there you have the root cause of the problem: a serious impedance mismatch between a set-oriented query language and a regular imperative programming language (OO notwithstanding.)

    The so called "4G" languages tried to bridge this gap and failed miserably. Various ORM schemes are not brilliant, either. Ruby on Rails seemed to offer a glimmer of hope with its "convention over configuration" approach, but that ran into a myriad of exceptions and performance problems. Nevertheless, SQL is too well matched to the strengths of relational systems to be discarded without thought. I don't know what the solution is, but ditching SQL in toto isn't likely to be part of it.

  • Re:next for NoSQL (Score:2, Interesting)

    by Anonymous Coward on Friday May 16, 2014 @09:12AM (#47017289)

    "Schemaless design" always just sounds like a whitewashed buzzword for "Excel spreadsheet" to me.

    There's a very simple way to make a "schemaless design" within a relational database, and it's generally regarded as Not Best Practice (tm). You need a table with a unique PK (any old GUID or autoincrementing integer will do just fine), a FK to whatever bit of "real indexing" you need (user id or whatever), and two string fields (varchar, nvarchar, character varying, whatever your RDBMS likes to call them). One holds the "key" and the other holds the "value". Now, you need to create an index on the FK. Not a unique index, just a nonclustered, ordinary index. It really is a shit way to store data, but that's why it's Not Best Practice (tm). And now you've just reinvented "NoSQL". And best of all, you can use a real, set-theory-based data retrieval language (that is, SQL) to retrieve it! Of course, you lose all of the advantages of that very well-thought-out language by throwing all of your data into a shit-heap, but hey, you're a web designer, it's not like you're smart enough to make a query that does anything beyond "SELECT * FROM ShitHeap WHERE UserID = @UserID" anyway.

    Of course, there are advantages to a shit-heap, which the NoSQL fanboys will no doubt express vehemently about 10 seconds after I make this post. But why would you bother with one when you're already incurring the overhead of running PostgreSQL? You have the power, and you have the system set up to handle that load. Why dumb it down? Because you're dumb? Not likely. Even the dumbest of managers know when to hire an expert.

    This just reeks of "me too!" on the part of PostgreSQL. Nobody that feels a need to use NoSQL is going to consider using PostgreSQL for that task, and nobody that uses PostgreSQL is going to feel the need to use Not Best Practices (tm) in their RDBMS schema. It's a solution in search of a problem, and it's going to flop. Don't invest your time, energy, or money in it, because it will be abandoned for non-use in a year or two.

No man is an island if he's on at least one mailing list.

Working...