Oracle’s Cloudy Future • Hacker News Board

Re: Oracle’s Cloudy Future

#151

Post by js8 » Sat, Sep 24, 2016, 4:59 AM UTC

Jweb_Guru wrote: post #148

js8 wrote: post #78

Earlier quoted context omitted.

Protobuf is not a database. What comes close is DataDraw, but that is an embedded database, not a server.

I don't understand your meaning, then... lots of database systems have hardcoded fixed pointer offsets for data structures, and some even compile queries into bytecode with those hardcoded pointer paths (for instance, HyPeR does this using LLVM, and I think some other column-stores do as well). Is your issue that those databases aren't hierarchical? On modern machines, pointer chasing is much slower than predictable…

I think what IMS does is they have those pointers, but these are pointers between records on disk (to minimize IO), not in memory. And the hierarchy is essentially a pre-calculated one-to-many join. So what you do when you design IMS DB is you look at what joins you need and you build your DB structure around that. And that's where, even though IMS is still row-oriented, it differs from the relational model, which is more flexible, but at the cost of higher IO per query.

DataDraw is kinda similar, but in memory. There is a reason why it doesn't have a generic SQL interface, although it would be probably possible to build a slow one on top of it.

P.S. I don't know HyPeR, and I can't google it. And yes, it's possible that somebody already reinvented IMS, I am just not aware of it.

Re: Oracle’s Cloudy Future

#152

Post by Swannie » Mon, Sep 26, 2016, 3:34 AM UTC

sgt101 wrote: post #58

elchief wrote: post #35

Earlier quoted context omitted.

I work for a Fortune 1000, and we have production DB2, Oracle, SQL Server, PostgreSQL, MySQL, Access, and an old IBM mini computer...

wow, you need some architectural discipline there. Postgres and mysql: what was the reasoning behind that?

ROFL.

Sorry, but this story is true in every Fortune 1000, except maybe a very small number of technology companies.

Why? Line of business team X demands product Y, that only runs on prem on DB Z. Done.

Re: Oracle’s Cloudy Future

#153

Post by nasalgoat » Mon, Sep 26, 2016, 12:40 PM UTC

makomk wrote: post #100

latj wrote: post #69

Earlier quoted context omitted.

A lot of large U.S. organizations wont use software they cant buy support for. So, you can use RedHat and buy support. When you create software, your developers are going to use all kinds of tools, libraries, etc. and depending on the policies of the organization they are going to want to manage that risk. For example, if you're a bank and the devs who make your mobile app use some random authentication library that…

Part of the reason that Postgres is popular is that there are multiple companies selling support for it, several of which are also major contributors. So there's actual competition to keep prices somewhat under control.

I disagree that there's PostgreSQL support out there. When I was having serious performance issues, I did a ton of Googling and couldn't find a single place that could offer a-la-carte support, only very, very expensive yearly subscriptions from questionable places - ie. no name brand consultants or anyone connected to PostgreSQL itself.

Re: Oracle’s Cloudy Future

#154

Post by sgt101 » Mon, Sep 26, 2016, 7:48 PM UTC

Swannie wrote: post #152

sgt101 wrote: post #58

Earlier quoted context omitted.

wow, you need some architectural discipline there. Postgres and mysql: what was the reasoning behind that?

ROFL. Sorry, but this story is true in every Fortune 1000, except maybe a very small number of technology companies. Why? Line of business team X demands product Y, that only runs on prem on DB Z. Done.

Nope. It's true of every Fortune 1000 who are poor at IT and in the hands of vendors. It's not true where I work, and I am pretty sure it's not true at Microsoft, Google, Facebook...