Why old-school PostgreSQL is so hip again

Re:Why old-school PostgreSQL is so hip again by orangejewce on Monday December 11, 2017 @12:31PM (#15898584)

Spark is not a buzzword if you do analytics, it's the preferred platform, especially over native Hadoop. Honestly most developers have no idea what the heck Spark is or how to use it. NoSQL/Kafka yes, Analytics/Machine Learning is still far too complicated for most to stand up on their own.

[ Parent | on HN ]

Re:Why old-school PostgreSQL is so hip again by sidlls on Monday December 11, 2017 @09:09PM (#15902524)

Spark has a place: at large scale. For 100s of GB to a few TB of data PostgreSQL works very well. At least, it does for my team. I don't want Spark, Kafka, NoSQL or any other modern fad near my team's data. It's just not appropriate.

[ Parent | on HN ]

Re:Why old-school PostgreSQL is so hip again by jack9 on Monday December 11, 2017 @12:54PM (#15898752)

Kafka was useful in a project because of the semantics for what amounts to writing to file from network sockets.

Spark is a terribly inefficient solution to any known/stable data processing or analytics jobs. If you want a common format to trade with buddies, it's useful now. I expect something else will come along to replace that fad tech.

[ Parent | on HN ]

Re:Why old-school PostgreSQL is so hip again by tabacof on Monday December 11, 2017 @01:10PM (#15898921)

>Spark is a terribly inefficient solution to any known/stable data processing or analytics jobs.

Can you expand on that?

[ Parent | on HN ]

Re:Why old-school PostgreSQL is so hip again by mdekkers on Monday December 11, 2017 @03:00PM (#15899883)

Spark is a terribly inefficient solution to any known/stable data processing or analytics jobs.

You gave a typo there.

Spark is a terribly inefficient solution to any known/stable data processing or analytics jobs I have ever come across.

There, fixed that for you.

[ Parent | on HN ]

Re:Why old-school PostgreSQL is so hip again by jack9 on Thursday December 14, 2017 @07:26PM (#15928737)

I don't think that's fixed, because it's not what I assert.

Any job that is predictable, can be done faster and cheaper with some C (or Go) and ad-hoc delegation to load balanced VMs. Spark is difficult to optimize for consistent processes, poor on resource usage, and requires specialized knowledge. Just pay for someone who has done a little embedded programming and stop creating buzzword jobs because a prototype went to production without comparison.

[ Parent | on HN ]