Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

New PostgreSQL Guns For NoSQL Market

samzenpus posted about 4 months ago | from the coming-for-you dept.

Data Storage 162

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."

cancel ×

162 comments

Sorry! There are no comments related to the filter you selected.

Nice touch but too late! (-1)

Anonymous Coward | about 4 months ago | (#47015165)

The industry moved away from relational databases a long time ago. Postgres is not relevant anymore.

Re:Nice touch but too late! (1, Insightful)

Bryan Ischo (893) | about 4 months ago | (#47015183)

References, please.

I have a feeling you can't produce anyway, because relational databases are still widely used.

Re:Nice touch but too late! (0)

Anonymous Coward | about 4 months ago | (#47015199)

References, please.

I think he means the web application industry - which is the target of these changes - and yes that industry did move away from relational databases long ago, you shouldn't need references for that.

Re:Nice touch but too late! (5, Insightful)

mwvdlee (775178) | about 4 months ago | (#47015207)

By "industry" you mean the 0.001% of websites that could actually benefit from NoSQL?
How many sites you visit use NoSQL? Do most webshops, blogs, news sites and forums? Does Slashdot?

Re:Nice touch but too late! (-1)

Anonymous Coward | about 4 months ago | (#47015257)

By "industry" you mean the 0.001% of websites that could actually benefit from NoSQL?

Yes as that would equate to about 200,000 websites.

How many sites you visit use NoSQL?

Lots, I don't count. But since you had some expectation that I did you must be able to answer how many websites do you visit that use NoSQL and relational databases?

Do most webshops, blogs, news sites and forums?

Some do, some dont. I wouldnt really be considering a blog page to be a web application.

Does Slashdot?

Irrelevant.

Re: Nice touch but too late! (0)

Anonymous Coward | about 4 months ago | (#47016007)

Something something Mumps, something something VA hospitals.

Re: Nice touch but too late! (0)

Anonymous Coward | about 4 months ago | (#47016247)

as a pretty big NoSQL guy ( and a SQL guy ) who loves watching everyone argue back and forth on this ( while I just keep using the best tool for the current job )

that is a pretty good one

Re:Nice touch but too late! (5, Insightful)

Simon Brooke (45012) | about 4 months ago | (#47015743)

A small minority of companies, with very special needs, are using NoSql databases for a small proportion of their operations. Those companies do include some big ones, such as Google and Twitter, but still in absolute terms the numbers are small. A tiny minority of companies have moved away from relational databases altogether. But the numbers are statistically insignificant and are likely to remain so for decades. And the relational model does have some real and enduring benefits which will make it the right tool for many jobs far into the future.

Remember this is an industry that advances very slowly indeed. Your bank, and your utility companies, are still using programs written in COBOL - technology which is fifty years behind the curve.

Re:Nice touch but too late! (0)

Anonymous Coward | about 4 months ago | (#47016289)

I still need a list of these big sites that moved from SQL. No MySQL, no Postgre, no Hadoop...

Re:Nice touch but too late! (1)

bhcompy (1877290) | about 4 months ago | (#47015435)

Well, not the industry being referenced, but many enterprise accounting and inventory databases are PICK based because they're blazing fast and completely reliable. ADP is an example of a company that sells PICK based solution. OpenQM is the open source descendant of PICK

Nice touch but too late! (0)

Anonymous Coward | about 4 months ago | (#47015647)

I think you have no idea of what the word "relational" actually means.

Whether you're writing SQL or NoSQL statements (whatever the hell they are) you'll still end up using relational theory (Todd Codd anyone?)....

ffs

Nice touch but too late! (4, Insightful)

fuzzytv (2108482) | about 4 months ago | (#47015841)

I don't know whether angry tapir knows what relational means, but I see nothing in his post IMHO suggesting he has no clue. JSON is great for storing non-relational data (hierarchies, data without fixed set of columns, ...). Not all data are purely relational, it's often a mix.

Re:Nice touch but too late! (1)

psmears (629712) | about 4 months ago | (#47015849)

(Todd Codd anyone?)

Close... acutally his name was Edgar Frank "Ted" Codd [wikipedia.org]

next for NoSQL (5, Insightful)

SchroedingersCat (583063) | about 4 months ago | (#47015177)

Next, NoSQL databases will add schema and ACID support and the circle will be complete.

Re:next for NoSQL (0)

Anonymous Coward | about 4 months ago | (#47015251)

Well, since there's now directory servers [apache.org] that support triggers, stored procedures, and views, nothing is sacred!

Re:next for NoSQL (2)

cowwoc2001 (976892) | about 4 months ago | (#47015255)

Impossible.

The entire premise behind NoSQL is trading consistency for availability (which actually means "latency" since everything is eventually available). You will never ever get ACID from NoSQL databases.

Re:next for NoSQL (4, Informative)

bdares (1042128) | about 4 months ago | (#47015471)

"NoSQL" doesn't mean "No SQL". At least, not all the time. I've heard it pronounced "Not Only SQL" more than once. RDF triple stores can also be considered NoSQL databases, and they can provide ACID. (They use SPARQL instead of SQL as a query language - hence being something other than a SQL DB.)

Re:next for NoSQL (5, Interesting)

greg1104 (461138) | about 4 months ago | (#47015667)

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:next for NoSQL (2)

cjc25 (1961486) | about 4 months ago | (#47016445)

the SQL standard.

That's cute

Re:next for NoSQL (0)

Anonymous Coward | about 4 months ago | (#47017541)

SQL Standardization [wikipedia.org]

Use your power of fanboi'ism and edit that page if you know otherwise.

Re:next for NoSQL (2, Interesting)

Anonymous Coward | about 4 months ago | (#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.

Re:next for NoSQL (1)

drinkypoo (153816) | about 4 months ago | (#47017497)

Nobody that feels a need to use NoSQL is going to consider using PostgreSQL for that task

Unless they're already using Postgres for something else, and the server is already running, and they'd like to be able to use all the same tools and scripts to manage their NoSQL databases as their PostgreSQL databases. In which case, this could be a big help.

Why so negative? Just a hobby?

Re: next for NoSQL (0)

Anonymous Coward | about 4 months ago | (#47016013)

Talk to Intersystems about that.

Re:next for NoSQL (1)

Slackus (598508) | about 4 months ago | (#47016135)

Impossible.

The entire premise behind NoSQL is trading consistency for availability (which actually means "latency" since everything is eventually available). You will never ever get ACID from NoSQL databases.

There are already NoSQL databases supporting ACID: http://ravendb.net/ [ravendb.net]

Re:next for NoSQL (1)

fuzzytv (2108482) | about 4 months ago | (#47017211)

Except that indexes are only BASE. Good luck with querying it ....

Re:next for NoSQL (0)

Anonymous Coward | about 4 months ago | (#47016145)

Impossible.

You will never ever get ACID from NoSQL databases.

CouchDB is ACID. MongoDB can also be considered ACID compliant for certain transactions.

Re:next for NoSQL (1)

fuzzytv (2108482) | about 4 months ago | (#47017579)

Except that the transactions in MongoDB can touch only a single document. Which kinda makes the whole ACID idea pointless, because that's about consistency of the whole database. Saying "it's ACID, but only within a single document" is a bit like "you can have any color, as long as it's black".

I'm not sure about CouchDB - I know it used the same approach (single-document transactions), but maybe that changed a bit.

One of the absolutely terrible things coming from the whole NoSQL movement is redefinition of existing terms. "Consistency" is a great example of that, "availability" is another one.

Re:next for NoSQL (0)

Anonymous Coward | about 4 months ago | (#47015305)

except then which will really be web-scale, then?

Re:next for NoSQL (0)

Anonymous Coward | about 4 months ago | (#47016777)

indeed [orientdb.org]

apples and oranges (0)

Anonymous Coward | about 4 months ago | (#47015185)

An RDBMS is well suited for some situations, a document database like Mongo is better for others. Json is an easy format to work with, but really shouldn't be the deciding factor between the two.

Re: apples and oranges (0)

Anonymous Coward | about 4 months ago | (#47015507)

Um, care to clarify what the usecase for Mongo is when Postgres has a faster JSON datatype?

Re: apples and oranges (1)

Anonymous Coward | about 4 months ago | (#47015745)

I prefer to use Mongo when prototyping - when the data structures are still in flux, and I want something quick, flexible, and - most importantly - right now.

That, and setting up MongoDB is a breeze: `aptitude install mongodb`, and you can start using it straight away.

How about Parallel Query Execution? (4, Interesting)

wispoftow (653759) | about 4 months ago | (#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.

Re:How about Parallel Query Execution? (5, Interesting)

mlyle (148697) | about 4 months ago | (#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:How about Parallel Query Execution? (1)

CadentOrange (2429626) | about 4 months ago | (#47015739)

Do you know if there are any plans to merge Postgres-XL into vanilla Postgres?

Re:How about Parallel Query Execution? (1)

Wootery (1087023) | about 4 months ago | (#47016525)

I like the way the linked page uses Web 2.0 when it means scalability.

Great job with the buzzwords.

Re:How about Parallel Query Execution? (2)

KingSkippus (799657) | about 4 months ago | (#47017233)

I like the way the linked page uses Web 2.0 when it means scalability.

Great job with the buzzwords.

You know, I was just going to let this go, chalked up as random Internet stranger being an asshat, but seriously. Are you SO bored or jealous of other people's achievements that you have nothing better to do than to sit around and nitpick the friggin' ad copy of a marketing page that was undoubtedly written not just for people who want to know the technical specifications of the product, but common usage applications for it also? What you're calling a "buzzword" is information that business wonks need to know when faced with the question, "Will this solve my problem/fulfill my needs?"

When you develop your own database system, you can write your own ad copy to say whatever you want it to. Or if you prefer, apply for a job at Postgres as their chief marketing guru, and if they're dumb enough to hire you, you can write its ad copy to be purely technical-oriented until the product is completely irrelevant in an actual production environment. ("Now for OS/2 Warp and BeOS!") Otherwise, forgive me if I don't put much weight into your opinion on the matter over the people who have written a kick-ass enterprise-quality system that is pretty much given away for free.

Seriously, what exactly are you implying by your comment, that PostgreSQL isn't a capable database system? That they just use buzzwords instead of actual technical brainpower and muscle as the basis of their software? Because I can tell you that to people who architect, engineer, administer, and eat database systems for breakfast, you are sadly off-base here, and this comment comes off as extremely pompous and ignorant.

Re:How about Parallel Query Execution? (0)

Anonymous Coward | about 4 months ago | (#47017045)

Nice try. This looks exactly like postgres-xc (http://postgres-xc.sf.net).

Re:How about Parallel Query Execution? (1)

Anonymous Coward | about 4 months ago | (#47016521)

Do you really have enough I/O bandwidth in the machine to keep multiple processors busy on a single query?

Re:How about Parallel Query Execution? (0)

Anonymous Coward | about 4 months ago | (#47016833)

^ This. I've a pair of hex-core Xeons sitting around with their thumbs up their cache waiting on IO. That's with quad bonded NICs to the client base and 12 x 15K rpm drives. Since I already screwed up the math, I stuffed the box full of RAM equivalent to two copies of the DB. Lesson? Use a ruler when reading specs in table printed in 8pt fonts.

Re:How about Parallel Query Execution? (0, Troll)

Anonymous Coward | about 4 months ago | (#47017255)

PostgreSQL has no built-in parallelism. Partitioning is a joke, which doesn't support global primary keys or even global indexes and there are no hints, so if your model becomes too complex for the optimizer, you have to start all over again. In other words, PostgreSQL is a bad joke, meant to sell commercial variants like EnterpriseDB, which does have all of the above, Greenplum, Netezza, Vertica or VoltDB. PostgreSQL is a bait and switch DB which is not worth serious consideration. Yes, it is free but if somethin serious is needed, you need commercial databases like SQL Server, Oracle or DB2, all of which have decent partitioning, built-in parallelism, optimizer hints and all which can run circles around PostgreSQL.

Re:How about Parallel Query Execution? (0)

Anonymous Coward | about 4 months ago | (#47017329)

Are you one of Larry's ghost shirts?

No SQL (2)

TechyImmigrant (175943) | about 4 months ago | (#47015239)

It would be nice if noSQL databases adhered to the promise in the name. They replace the query language with something sane and secure.

Re:No SQL (1)

bhcompy (1877290) | about 4 months ago | (#47015463)

Depends on what you mean by safe. Pick ENGLISH queries are strictly read only.

Re:No SQL (1)

shrewdsheep (952653) | about 4 months ago | (#47015821)

All databases are relational (noSQL or otherwise). SQL formalizes some aspects of relational algebra but this does not imply anything about the implementation nor necessarily about the interface. If you like "simpler" interfaces use ODBC/ORMs on SQL or noSQL databases.

Re:No SQL (1)

jbolden (176878) | about 4 months ago | (#47015993)

No they aren't. Object databases are not relational they are hierarchical. Associative databases are associative not relational. And many of the "NoSQL" databases the partitioning scheme changes the outcome of queries which is a complete violation of the relational concept that order of rows doesn't effect the return from invoking queries.

Re:No SQL (0)

Anonymous Coward | about 4 months ago | (#47017359)

The relational concept does not guarantee the order of rows when you didn't specify the sort order. SQL holds to this and doesn't guarantee row order unless you use the ORDER BY clause.

Different table indexes can drastically alter the row order of a resultset, and having multiple indexes can allow a query optimizer a great amount of leeway in deciding which index to use at any given moment. You are absolutely not guaranteed a particular row order in your resultsets in any RDBMS that performs well. That is by design.

If row order is important, use ORDER BY. That's what it's for. It also incurs some processing expense, so use it carefully.

Re:No SQL (1)

drinkypoo (153816) | about 4 months ago | (#47017517)

No they aren't. Object databases are not relational they are hierarchical.

The only CORBA implementation with which I've ever been familiar definitely used a relational store, and made relational queries. I think you are speaking a little too generally.

Re:No SQL (0)

Anonymous Coward | about 4 months ago | (#47016111)

This. Absolutely this.

First I heard about "noSQL databases", I thought: FINALLY. Relational is fine, mainly, schema and constraints are the bee's knees, ACID is great, databases are great. The main problem is that SQL sucks. And ORMs too. So yeah, keep what's good, replace the crap, brilliant.

Except: no. They threw away the good bits and kept the bad ones. Now all you have is an ORM and an even worse query language. :(

Re:No SQL (1)

Anonymous Coward | about 4 months ago | (#47016361)

So what's wrong with SQL? I've honestly never found myself thinking it sucks as a query language, and the parts I did think sucked outright monkey balls with package-specific functions (Oracle sucks bad for this in places...)

I hear this complaint a lot but it's never really quantified by those who say it and I'd love to know why. If what people meant to say is 'I hate having to organise my data into relational tables and hate having to deal with the process of upkeep and curating my data' then yes, that is a fair comment but that's more about the database's mode of operation itself rather than it's query language.

Re:No SQL (0)

Anonymous Coward | about 4 months ago | (#47017117)

Personally, my main issue with SQL is that you can't nest aggregates without doing a whole separate subquery. There's no syntax to handle determining the average invoice price in a fully normalized db with line-item prices eg something like AVG(SUM(price) group by invoice_id)

Quel (0)

Anonymous Coward | about 4 months ago | (#47017605)

It's my understanding that SQL was not the first nor the best but it's the one we must use ...

Take a look at http://en.wikipedia.org/wiki/QUEL_query_languages

Re:No SQL (2, Interesting)

Anonymous Coward | about 4 months ago | (#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:No SQL (0)

Anonymous Coward | about 4 months ago | (#47017325)

Yeah, but I'm specifically talking about SQL the language, not the relational model.

I'm aware of the many benefits of the model, especially, like you said, compared to what it replaced, as well as some of it flaws (for instance it can't do hierarchies very well, because it's not a subset of a cartesian product, also sorting is rather alien to it).

And it is a testament to its success that as soon as you contest the language, somebody takes it to mean that you question the model. I'm not.

The language, tho, that's something else. It was "designed" back in the days before language parsing was "solved". Ever tried to create a SQL parser using modern tools? Lex, yacc, javacc, whatever? Best of luck. For one thing, it's strongly lexer resistant, with keywords that are except when they aren't and so on. You quickly end up with a big mess. More generally it was designed when people thought the better way to make a language was to make it look like english. So people can pick it up easily, right? So, the end user can... That never happened. But the consequence is a highly denormalised (which is rather ironic in the context ;) ) language with a basic statement structure that's completely different if you're inserting, updating or selecting, and randomly positioned predicates that completely change the meaning of a sentence.

Just look at any wikipedia page about set theory. Math. I defy you to find any mathematical statement in there that even remotely looks like SQL query :)

Random musing: you know what would be a good fit for DBs? Functional languages. But their proponents are hell bent on making general purpose ones, where they just don't fit all that well.

Matthieu

Re:No SQL (0)

Anonymous Coward | about 4 months ago | (#47017485)

SQL is a fantastic tool for what it does.

"I want X, Y, and the average of all matching Z. Go get it from locations A and B. A and B are not just random places, they're related by having field M in common. Don't bother finding anything in B if it doesn't share M with A. I also only want to find things where N is true, O is 283, and P is not NULL. For calculating that average Z, group everything by Q. When you get all of that, sort it by R, in descending order."

SELECT X, Y, AVG(Z)
FROM A
JOIN B ON A.M = B.M
WHERE N = 1 AND O = 283 AND P IS NOT NULL
GROUP BY Q
ORDER BY R DESC

It's really not that hard when you think about it in terms of a rule-based search. If you can't handle this, you should probably just stay away from data in general. NoSQL isn't a cure you can handle.

Re:No SQL (0)

Anonymous Coward | about 4 months ago | (#47016159)

It would be nice if you had a clue. SQL is extremely sane, as it is based on relational algebra and set theory. NoSQL is very dumb but faster. Pick your tool for the job.

Horizontal scalability? (2, Interesting)

michaelmalak (91262) | about 4 months ago | (#47015241)

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.

Re:Horizontal scalability? (4, Informative)

mlyle (148697) | about 4 months ago | (#47015357)

We just released Postgres-XL [postgres-xl.org] so you can have horizontal scalability and MPP.

Re:Horizontal scalability? (1)

salimma (115327) | about 4 months ago | (#47015953)

Is there a reason for adopting a different license from core PostgreSQL ? Seems like it makes the information flow a one-way street (from SQL into XL but not vice versa). Looks like an interesting project! Throw in EnterpriseDB-level Oracle compatibility and there's a captive market out there

Re:Horizontal scalability? (0)

Anonymous Coward | about 4 months ago | (#47015913)

> A hallmark of NoSQL is horizontal scalability.

Yep. And you buy that with "eventual consistency" or with horribly expensive two-phase commit. It's a tradeoff grounded on basic principles [wikipedia.org] . None is better or worse; know your needs and choose your tools.

> 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.

That happens when it's done wrong. Of course, if you expect a rigid schema in your code, it's better to let your tools do it for you, and traditional SQL databases are very good at it. But sometimes you *want* flexibility.

Now, writing generic code is a bitch and something not very amenable to the short-breathed "agile" world, where you're always on the sprint. But it's fun and very rewarding (to some of us, that is).

> Sounds like PostgreSQL got the bad part of NoSQL but not the good part.

This is totally wrong. Flexibility *is* a good thing. A chainsaw *is* a good thing -- just don't apply it to your foot.

PostgreSQL hasn't thrown out "classical" schema (OK, it's always had a classical schema with a twist: it allows you to add user-definable types, functions and *indices*, which has always been extremely cool), but you can have columns with some inner structure the database knows about. What about a column containing a map (like a Perl hash) which is *indexable* so that you can efficiently select all rows in which this column contains a map "foo" => "bar"? Hstore can do that. What about a column containing an array of words, and an efficient way to query all rows in which this column contains the words "red" and "earth"? GIN indexes do that (this is the basis of PostgreSQL full text search, but instead of giving you a closed solution, you get access to the building blocks so you can build other things on top of that).

No. It's rather that PostgreSQL has kept the good things of SQL, extended them a bit, and has picked up *some* of the good things of NoSQL.

Going in the wrong direction (0)

cowwoc2001 (976892) | about 4 months ago | (#47015265)

Most people don't need NoSQL. Last I checked, most people aren't Facebook or Google. And ironically those two companies are lining up behind http://en.wikipedia.org/wiki/N... [wikipedia.org]

ACID is here to stay. We will see conventional databases improve in the latency space and NoSQL will (mostly) go away.

Re:Going in the wrong direction (5, Insightful)

Tablizer (95088) | about 4 months ago | (#47015325)

Most people don't need NoSQL. Last I checked, most people aren't Facebook or Google

Some people get overly optimistic about their start-ups or new projects. It's like planning on where to park all the beemers before you even get your first sale.

Plus no concept of maintainable software (0)

Anonymous Coward | about 4 months ago | (#47016241)

Where, perhaps, there's an interface that defines what the
storage layer does, so you can drop in whatever you want
and everything else still works.

But no: "Ugh. Interfaces. That's so 20th century. Our product
is so important and will have to scale that we can't afford all
that big-company stuff so we're going to just code away
and make sure every piece depends on lots of internals
of every other piece".

Ok, Have fun.

Re:Going in the wrong direction (1)

Anonymous Coward | about 4 months ago | (#47015771)

"NoSQL" is a band-aid while programmer competence catches up with resource constraints. This old cartoon continues to be relevant [youtube.com] , but mostly it's, "We don't know how to use this wheel, so we're going to reinvent it poorly. Eventually our duplication of effort will be complex enough that we're going to need to move something indistinguishable from the traditional system, but nobody needs to say that yet."

It's like the programming language rule that everything eventually looks like a reimplementation of LISP with syntactic sugar.

Going in the wrong direction (1)

LinuxFreakus (613194) | about 4 months ago | (#47016061)

Actually, more than you think should probably use NoSQL. It isn't really any harder if you build it that way from the start and if your startup happens to get gigantic you won't have a relational database to migrate away from as one of your problems. You'll still have problems though, and even with NoSQL you need to "do it right" or it will still have issues when it gets huge.

Going in the wrong direction (1)

LinuxFreakus (613194) | about 4 months ago | (#47016067)

And I might add that one of the most painful parts of migrating away from relational databases after you are already huge and bursting at the seams is that usually folks will have relied on the transactional consistency they provide for all the app logic and business processes. Suddenly wanting to change all that code to handle eventual consistency is not trivial at all, but if you were doing it all along because you started out that way... fewer pains.

Is it web scale? (1, Funny)

Anonymous Coward | about 4 months ago | (#47015299)

Is Postgres now web scale?

Re:Is it web scale? (1)

gargleblast (683147) | about 4 months ago | (#47015563)

Is Postgres now web scale?

That depends: are you going to blow some project to hell because you get a woody playing with software like it's a sex doll?

Re:Is it web scale? (0)

Anonymous Coward | about 4 months ago | (#47015725)

Dipshits like you read the latest post on highscalability.com and think you're a fucking Google architect.

Re:Is it web scale? (0)

Anonymous Coward | about 4 months ago | (#47016045)

Poor MongoDB, that video makes it into a punchline instead of a viable DB option

If this is anything like MariaDB (-1)

l0ungeb0y (442022) | about 4 months ago | (#47015323)

... It will be a haphazard mumbo-jumbo of bullshit.

SQL DB's should stick to being SQL and noSQL should do the same for their market.
Mixing/Mashing makes no sense, you can't take a SQL DB and just up and convert it to be noSQL without double standards and weirdness.

So instead of putting on a silly disguise and trying to pretend to be who you aren't, how about addressing the issues about who you are such as low write limits and slow transaction speeds? But hey -- maybe I don't know WTF I'm talking about.

Mutt-hater! (4, Funny)

Tablizer (95088) | about 4 months ago | (#47015331)

Mixing/Mashing makes no sense

No HalfSQL movement?

Re:If this is anything like MariaDB (5, Informative)

Anonymous Coward | about 4 months ago | (#47015439)

I am actually *using* this thing. Implemented a database with ~100K XML records, access them by arbitrary XPATh expression.

Of course "normal" access is slow, but once I agree with the customer on an access pattern, I can set up a functional index. Then we are at a couple millisecs per access (on very low-end hardware). And with GIN indexes, I can even set up things like "find all records where tag A or tag B or tag C equal one of "foo" or "bar". All for a handful millisecs. No database tuning whatsoever -- plain vanilla PostgreSQL 9.1 as it comes to us with Debian.

Of course you can't compare it with -- say -- Elastic Search, but as soon as I finish uttering "Java" my box is out of memory :-)

OK, on a more serious note: the usage patterns still are different: if you plan to have 100M biggish records, you'll probably want to throw a lot of boxes at the problem (unless the problem has a very specific structure). Then you'll probably be better off with Elastic Search or some such. OTOH if you want transactions, an SQL database it is. If you need both, you are in a tough place (cf. CAP theorem), so you gotta think hard.

I don't fucking care whether it's called SQL or noSQL if it's well-done. And PostgreSQL is damn well done. The community rocks too.

Re:If this is anything like MariaDB (3, Informative)

fuzzytv (2108482) | about 4 months ago | (#47015807)

Well, yes and no. PostgreSQL had a text-only JSON data type since long time, and was able to index keys using expression indexes. That's nothing new.

The 9.4 improvements are that the (a) JSONB is stored in a binary form, and (b) a lot of ideas from HSTORE data type, plus new ones were implemented. That means that you can create "universal" index without prior knowledge of what keys will be interesting. So then you can ask for data containing arbitrary keys, sets of keys, values, documents etc. See http://www.postgresql.org/docs... [postgresql.org]

Sure, it's not perfect and the index may get somehow big, but well ...

Re:If this is anything like MariaDB (1, Informative)

Anonymous Coward | about 4 months ago | (#47015465)

Actually PostgreSQL performs a lot better than MySQL/MariaDB, and looks after your data better. PostgreSQL has far fewer gotcha's (no database is perfect!), and is not the mess that MySQL is.

People started migrating from Oracle to PostgreSQL at version 8.0 or earlier, and now PostgreSQL is at 9.4 beta. Companies like Digg initially went to MySQL because Master/multislave was in core for MYSQL - now as of 9.0, PostgreSQL has that too.

With PostgreSQL supporting JSON, it allows people to use the NoSQL paradigm were it appears to be useful, without locking themselves out of a fully fledged relational database.

If your data is important to you, and you might need some serious DB querying stuff, then PostgreSQL should be considered.

furist 4sot (-1)

Anonymous Coward | about 4 months ago | (#47015399)

the hype (5, Insightful)

Tom (822) | about 4 months ago | (#47015679)

As a big fan of SQL database, I've been watching this NoSQL hype for a few years now, and I'm still not impressed.

No doubt, there are a few scenarios where a conventional database isn't the best solution. But quite honestly, 90% of the people jumping on the bandwaggon would be served just as well with an SQL database - except that like so many things, you need to do it right.

I'm no database expert (but I know a couple), so my SQL isn't perfectly optimized and stuff, but even with a little bit of interest I see that putting some effort into your database and query design pays off massively.

And I've seen enough cases where someone scraped their SQL database and went NoSQL for absolutely no good reason. You think you're huge and SQL is too slow? Unless you just sold to FB or Google for a couple billions, you very likely are not as huge as you think. I'm running a PostGIS database doing fairly complex geography calculations on non-trivial datasets, and it's blazing fast, and whenever it isn't one hour with an SQL expert and some experimenting makes it so, because it always, with no exception, turns out that my SQL or my database design is at fault, not the database itself.

If you've got a billion users, I will grant you that you have special needs. But every NoSQL use I have seen has been a case of people moving database work to software code instead, mostly because programmers are plenty and cheap, while experienced database experts are not.

So I'm still amused and very little impressed, and I'm certain NoSQL will go the way of Java or every other hype ever - for a while it's everyone's darling, then people realize it still doesn't give us AI and it can't make coffee, and will start to figure out where it actually is the best solution and stop using it for everything else.

Re:the hype (2)

CadentOrange (2429626) | about 4 months ago | (#47015755)

I've seen this a million times. People with poorly designed relational databases with no thought given to query plans complain that their database is slow. They then migrate said database to a NoSQL solution (typically a document database like MongoDB) and then find that it is still slow! . In a few cases, the NoSQL solution is significantly slower.

The problem is NoSQL encompasses many different types of solutions. Key value stores like Redis are pretty good (key lookups support wildcards!!!) and I use them as an alternative to memcache. Document databases like MongoDB? If you're excited about them because you don't need a schema, you're just asking for carloads of trouble down the line because you've mistakenly bought into the thinking that you can just chuck arbitrary data into Mongo and get it to perform well.

Re:the hype (2)

Common Joe (2807741) | about 4 months ago | (#47015817)

There's a pretty good book I own in paperback (electronic versions available) for high performance stuff from PostgreSQL. It's called PostgreSQL 9.0 High Performance [amazon.com] . It's probably beyond what you want, but if you're interested in looking at it, let me know and I'll bring it next time we get together.

Re:the hype (1)

dave420 (699308) | about 4 months ago | (#47015923)

And your work is entirely not intended to be performed in a NoSQL DB. There are still plenty of uses for NoSQL, and it is most certainly not hype itself (although there has been lots of hype about it). It will be here for a long, long time, as it has some incredibly useful use-cases. You should accept that there are uses you are unaware of :)

Re:the hype (0)

Anonymous Coward | about 4 months ago | (#47016369)

Educate us with a few examples then, if you will? Genuinely curious.

Re:the hype (0)

Anonymous Coward | about 4 months ago | (#47016637)

Blindingly fast for some solutions and extremely easy to develop with.

I don't particularly care about the performance but use it for proof of concepts. To fully crud out a proof of concept takes a few seconds.

Re:the hype (0)

Anonymous Coward | about 4 months ago | (#47016411)

Oh, and your reply is redundant (so sayeth the anon in a redundant comment...) At the end of OP's post he said that once the excessive hype dies down, people will just use NoSQL-style databases for their genuine advantages and not as a matter of branding. Though what those use-cases are beyond being much easier to scale, I don't know.

Re:the hype (1)

Tom (822) | about 4 months ago | (#47016679)

I do. Re-read my original posting, and this time until the end. :-)

Re:the hype (1)

complete loony (663508) | about 4 months ago | (#47015975)

I don't have a problem with relational databases, but even though I'm pretty good at writing SQL queries, I don't like SQL as a language.

There should be a middle ground somewhere between SQL, Map-Reduce and Object Oriented coding styles. I want code reuse, I want encapsulation, I want LLVM-like compiler optimisations. I want to push as much processing down to where the data is, without needing to hand optimise everything.

SQL doesn't provide much of those things.

Re:the hype (2)

Tom (822) | about 4 months ago | (#47016671)

Because it's a database.

SQL is 40 years old. In that time, dozens of programming languages, patterns and styles have come and gone. And SQL is still here, exactly because it doesn't care if your language is OO, functional, redundant, brainfuck or agile deployment for optimized synergies with next generation engagement framework whatever.

A database needs to concern itself with the data, not with the programming patterns of the application.

Re:the hype (1)

complete loony (663508) | about 4 months ago | (#47017219)

Writing queries on databases with large numbers of heavily normalised tables is a pain. Many queries end up similar or the same, with common table joins, and similar filter criteria. Sometimes this means you end up writing front end code to emit SQL, so that you can increase the flexibility of your application. And then you want to change the structure of a few tables. Good luck hunting down all of the queries in your app that need to change.

Or if a query gets too complicated for the database to use the right index. You end up re-writing the whole thing manually, using temporary tables, perhaps in a procedure.

Compilers have come a long way since databases and SQL were invented. Surely we can shift building query plans into the compilation process? Eliminate dead columns from the result set. Why stick with a just in time language when I'm sure we could build something better.

Re:the hype (1)

Daniel Hoffmann (2902427) | about 4 months ago | (#47017225)

SQL is still there because it is (almost) pure relational algebra, the math is there to prove its correctness and the math can be used to optimize your queries. You can prove that one query returns the exact same lines as another, so the DB can find and run the faster query instead of your slower one.

Re:the hype (1)

jbolden (176878) | about 4 months ago | (#47016031)

Java hasn't exactly gone away.

Anyway there are fundamental design choices.

Relational requires that table row order is completely unimportant i.e. essentially fully commutative
No SQL requires that computations on table row order is merely associative

Many many mathematical operations are associative that are not commutative. That can be a huge change in how data is manipulated computationally far far faster. You don't have to be Google or Facebook you just have to have enough data and complexity that CPU is a serious constraint (rather than disk access).

Re:the hype (1)

Tom (822) | about 4 months ago | (#47016593)

Java hasn't exactly gone away.

Which is exactly what I'm saying.

Every hype ever has always followed the same pattern. First it is the second coming of christ (or, for hypes prior to 0 AD, the first). Then, it is the solution to all your problems and everyone uses it for everything. You can't get venture capital, employment or a marriage without it. After a while, people realize that for some strange reason, sliced bread is really cool, but it isn't really the best armour and the roof is always leaking and the wheels could really be more round. Every stone table / bard / newspaper / Twitter / microtelepathy chip then sings the song of crash and burn, while some tech geeks silently figure out just what it is really good for and what not. In the end, we get sliced bread for breakfast and the rest of our lives goes back to what it used to before.

Until the next hype.

Tom = multiple /. sockpuppet using scum (-1)

Anonymous Coward | about 4 months ago | (#47016073)

Let's let TOM speak shall we:

"I'm having great conversations on this site with one of my alias accounts" - by Tom (822) on Monday April 07, 2014 @02:29PM (#46686259) Homepage FROM -> http://slashdot.org/comments.p... [slashdot.org]

APK

P.S.=> Tom *tried* to libel me & failed after I destroyed him in a technical debate on hosts files... result?

Tom ended up "eating his words" here http://slashdot.org/comments.p... [slashdot.org] spiced with "the bitter taste of SELF-defeat" + HIS FOOT IN HIS MOUTH

... apk

the hype (1)

LinuxFreakus (613194) | about 4 months ago | (#47016127)

No matter how much you optimize your schema and your queries there are limits to what one machine can handle. Depending on what your application or business needs are, this may happen MUCH sooner than a billion users. For many, merely tens of millions of really active users are enough to exceed these limits, and when you are a startup trying to grow and add features it is easier said than done to ensure that every piece of code you release is so perfect that you will not rock the boat at all, since one minor slip effects EVERYTHING. At that point your choices are custom sharding (expensive, painful, error prone). Or horizontally scalable NoSQL. Personally, I would just choose NoSQL from the start. It is not harder to use, and you have a lot more wiggle room to respond when you want to release features quickly and iterate over them to improve performance if you decide to keep them. And yes, you can use functional sharding and multiple relational databases, but sooner or later if you are successful, you will hit the same problem.

Re:the hype (2)

Tom (822) | about 4 months ago | (#47016517)

If your application is really, really simple and you need truly massive amounts of throughput, then NoSQL is no doubt the way to go.

Somewhere between 1% and 10% of the shops doing NoSQL really fall into that category. Maybe as many again might, with enough growth.

Many years ago, long before NoSQL was a thing, I was the sysadmin of one of the largest e-commerce operations in my country. We had enough users and data and throughput that a big consulting company that was tasked with developing the next-gen system for us proposed that we buy not one, but two Sun E10k. At that time, pretty much the biggest commercial machine money could buy. The current system ran on six quad-core Dell servers. Because we had optimized the living daylights out of it, with custom shared memory kernel modules for data exchange, a highly customized database installation (we were Europe's largest installation of this system, so we had pretty much every vendor support we could wish for) and, most importantly, an exceptionally well-crafted design and implementation.

You can throw NoSQL at your problem for maximum scalability. But everything in this world comes with a prize tag. You sacrifice all the advantages of SQL. As I said: The use of NoSQL very often means moving problems that a good SQL database solves for you into code. So it means more code with more potential bugs, all in order to re-invent the wheel because you think you can make it more round. :-)

But again: For a few percentage of cases, it is the right way to go, I am not saying it's all nonsense. Just saying it's a hype and it'll calm down.

Re:the hype (0)

Anonymous Coward | about 4 months ago | (#47016429)

I've seen enough cases where someone scraped their SQL database and went NoSQL for absolutely no good reason

They have a reason, and it's the same reason people have for trashing a "conventional" (i.e. functional) website in favor of a "web 2.0" disaster. The reason is merely that they bring in new (usually young) people and those people have a primal need to distinguish themselves from their predecessors. The problem is that their predecessors have already implemented a functional, usable, maintainable system, but a scrap-and-redesign, of course, assumes the opposite. It was a recipe for disaster from the beginning.

Re:the hype (0)

Anonymous Coward | about 4 months ago | (#47016569)

The true spirit behind NoSQL that all the people who are "taking sides" are missing is this: NoSQL is about using the right tool for the right job. That's it. It's not about availability over integrity. It's certainly not about schemaless databases. It's about using the right tool for the job.

Just a few years ago, most of those tools didn't exist, just the hammer that is SQL, and every problem had to be seen as a nail. Now people are starting to build wrenches and screwdrivers. Are a lot of the people using these new tools using them wrong? Hell yes they are. Picking the right tool is really damn difficult if you don't know what you're doing or even understand what you're building. Most people should just stick with SQL since it's capable (if not the greatest) of doing just about anything they're doing.

I think you're right that once the hype dies down, people will start realizing what it's all about.

Re:the hype (0)

Anonymous Coward | about 4 months ago | (#47016613)

Are you a developer?

There is an impedance mismatch between SQL databases and modern application development that has never been solved. There are tools to accomplish this (orms) but this is incredibly kludgy and a pain to maintain. Everyone has been making SQL databases behave like nosql (sort of) at the cost of efficiency and maintainability.

I can have an easy to maintain database connection up in mongo immediately with zero impedance mismatch and rapid development. I can push "mongo" collection objects all the way up to the angular UI and back down to the database with almost zero coding. I was playing with a little app last night and wanted to add crud support. It took about 10 seconds to source the mongo driver and have the code complete.

The drudgery of dealing with a database is removed. If I am doing a proof of concept or doing an app for my own use I will go nosql every time. I have had a few projects that were rapidly developed with NoSql and as a nearly final step the SQL database based repository is substituted for the NoSql repository.

For my day job I use Oracle/SQL server. Development is slow and the tools feel archaic.

Re:the hype (1)

Daniel Hoffmann (2902427) | about 4 months ago | (#47017169)

Just like to point out that performance is not the _only_ reason to switch to a noSQL database. For example, in my project we are switching our very small DB to a noSQL solution to have schema-less data. Other examples include: proper Object-Oriented mapping to the database (no hibernate hell,) graph databases, distributed databases with auto-sincronization (part of the database is on a mobile phone and when it connects to the internet it syncs with the remote server automatically.)

Sure you can do all that with a traditional relational database, but it brings a whole lot of pain.

Re:the hype (1)

Jawnn (445279) | about 4 months ago | (#47017311)

But every NoSQL use I have seen has been a case of people moving database work to software code instead, mostly because programmers are plenty and cheap, while experienced database experts are not.

This, in spades. And my life ( a large part of which is seeing to the performance of our applications) is hell because of it. If I had a dollar...

Missing the point entirely... (0)

Anonymous Coward | about 4 months ago | (#47016579)

Wow, what on earth made them think the NoSQL world just revolves around JSON? People actually want scalable, distributed stores that don't require convoluted failover - something, compared to all its competition, PostgreSQL has never properly addressed in any way.

It's not just about being a document store (1)

Dave Voecks (3197515) | about 4 months ago | (#47016993)

When we were looking into new options to supplement our MSSQL servers, we settled on Mongo. We were aware that Postgres will act as a document store in addition to being a traditional RDBMS, but our decision was largely based on 2 things: We acknowledge that we'll likely never be able to completely eliminate our use of MSSQL. So, if we need an RDBMS, it will still be there. The other main factor was that Mongo makes replication, failover, and sharding a snap, relative to other systems. We don't have a DBA to implement replication for us. So, the simplicity was a huge factor. There are billion ways to store your data, and they all come with positives and negatives. Postgres can pretty much be everything to everyone, but like any system where that's the case, it can be harder to configure (for me, a developer, anyhow... I'm sure DBAs are laughing at me).
Load More Comments
Slashdot Login

Need an Account?

Forgot your password?