Feeds

back to article Google goes back to the future with SQL F1 database

The tech world is turning back toward SQL, bringing to a close a possibly misspent half-decade in which startups courted developers with promises of infinite scalability and the finest imitation-Google tools available, and companies found themselves exposed to unstable data and poor guarantees. The shift has been going on …

COMMENTS

This topic is closed for new posts.
Silver badge

Trends

I never really understood the value proposition of the trendy databases for most businesses. Nearly everyone wants to be a Facebook or Google size entity (or thinks they do), but the fact is most businesses who attempt to build in scale like that are wasting their time and money.

They are building too much infrastructure instead of revenue generating product, in hopes that they someday need it. Kind of like buying an 18-wheel over the road truck when a pickup will meet your current needs just fine.

I think it is a good thing Google is looking back at SQL based systems, I believe it will be beneficial, especially for startups who want, even need, to be on the technological edge, but are vulnerable to falling over the edge by building too big.

3
1
Bronze badge

I wonder how many countries envy such a query and campaign power

I wonder how many countries envy such a query and campaign power. Why, imagine the things that could be done if one replaced "AdWords" with "Crimes and achievements" and "Campaigns" with "persons and events", and so on.

Eventually, every living person will end up in such a database, and all his or her birth, education, socioeconomic, social, criminal, work, and health factors will be on tap for anyone needing a quick socket wrench or disposable "instant agent", but one who does not know that s/he really IS a TOOL, so to speak.

OTOH, employment agencies (government or commercial) could instantly force unemployed people to take on jobs to continuously receive benefits until a real, sustained job arrives.

Anyone collecting fingerprints form dining room glasses; hairs and bodily fluids from hotel beds and hangers; blood in emergeency rooms, hair in barber shops and salons, ANYONE wanting to be paid for clandestinely forwarding such materials to some drop box could be an instant agent.

How soon before, as a matter of "business survival" before companies like Google, Yahoo, MS, and others fine-tune their meta data collection to mesh with "brokers"? Pretty soon, we all could be part of....

YuNiMaTrIx 001, attached as a node in some pri/sec/tert ajunct....(well, to bring the Borg into this), and we won't necessarily have Swedish family names...

1
2
Anonymous Coward

Re: I wonder how many countries envy such a query and campaign power

You're insane

2
0
Silver badge

Re: I wonder how many countries envy such a query and campaign power

I find it exceedingly odd that you put 'Crimes & Acheivments' in the same database in your manifesto. Are you proposing some sort of 'social karma' type system where enough achievements can dilute or even eliminate crimes?

0
0
JLV
Bronze badge
FAIL

Re: I wonder how many countries envy such a query and campaign power

Dude, it's a database article & an interesting one at that.

Your post is neither relevant nor clever.

0
0

And with Google behind F1 the 'cool kids' will either go back to SQL databases or will start rolling their own SQL-interpreters on top of their favourite NoSQL systems. I like the NoSQL approach for many use-cases but I have grown tired of inexperienced developers trying to use it for everything and proclaiming how great their achievements are when their problem never warranted a 'BigData' solution or a 'NoSQL' solution.

What amazes me is that Google is now in the position that IBM once held: whatever it does technologically, a large part of the IT industry will follow.

6
0
Bronze badge
Thumb Up

@JMiles

[I like the NoSQL approach for many use-cases but I have grown tired of inexperienced developers trying to use it for everything and proclaiming how great their achievements are when their problem never warranted a 'BigData' solution or a 'NoSQL' solution]

I have seen an internal contact/ job & customer management system proposal for a not for profit that the external developers were proposing a 'BigData' solution - SQLite would have been entirely adequate...

1
0

The point of what Google does is not SQL but ACID semantics in globally distributed systems, which is a landmark technical achievement. You should read this not as a step back but as a step forward for any storage systems that currently lack such semantics, including all conventional SQL engines, which only manage this on single node systems generally.

It doesn't quite solve that certain aspects of SQL don't scale that well (joins, distinct) and are probably a bad idea regardless of whether you can make them work or not. Though you do have a choice now. It doesn't quite solve the problem that there is a huge impedance mismatch between document and object oriented application designs and row/table oriented storage solutions. It doesn't quite solve the problem that most programmers need things like hibernate to shield them from what is a pretty rough and unforgiving language.

So, you say back to SQL, I say fully transactional, globally distributed document stores. I'll be likely to continue to prefer more expressive querying and indexing such as provided in e.g. Elastic Search; the power of doing proper declarative map reduce style processing such as provided in e.g. Cascalog, CouchDB, or Hadoop, the luxury of not having to break down my transactions into tons of sql calls, or the more powerful semantics of transactional graph databases such as neo4j. NoSQL is here to stay. It may just become properly consistent, eventually. The next ten years are going to be interesting.

7
3
Anonymous Coward

If you send tons of SQL calls per transaction you're doing something wrong.

I really don't think NoSQL is likely to grow beyond a niche market as it doesn't bring anything to the party which good RDBMSs can't already do.

I have already worked on RDBMS technology where the databases are distributed across the world and the numbers given in the article don't seem terribly different to those projects I've worked on. In fact the first distributed RDBMS DB I worked on was back in the mid 90s.

4
0
Silver badge
Facepalm

Professional

If you need to join data then SQL is the most efficient way. If you can't work out how objects (object has attribute) can be represented in tables (attribute references object) you'll struggle to get a decent SQL solution and end up hating it.

2
0

Depends on your definition of niche market of course. If you follow the money, there's quite a lot happening in the nosql world with several companies showing healthy growth doing consulting and technology on the back of tons of investments. E.g. Elasticsearch got some funding to the extent of 30M $ recently. And having used it: they're worth it. Looks to me this could become a multi billion $ market pretty soon.

0
0
Bronze badge
Flame

Way back to the future.. Hierarchical

The SIGMOD presentation highlights the two big differences that drove them from MySQL: [1] global replication & distribution (with high commit latency); [2] google protobuf for record/row/object encoding & SQL extension to query inside protobuf hierarchical messages… not especially different from what most big global banks were doing with DB2 & IMS (for the hierarchical bit) 25 years ago.

The really big difference is licences fees, commercial DBMS are priced to make money from reliable storage of financial transaction data, not “which trucks have we tried to sell to a Manhattan flat dweller”.

Until google actually open-sources their technology, it’s all just guff about how they avoided paying Oracle for enhancements to MySQL, that all users could benefit from.

1
1

As with many things in this game ...

... it eventually comes down to the right tool for the right job, and not using the trendy tech du jour because all the skinny-jean cool kids on the internet say you should. Sometimes the right thing is NoSQL, sometimes not.

0
0

As I understand it, Goolge Spanner is built using atomic clocks to synch data updates around the cluster, F1 is built on Google Spanner. This alone is going to make take up of the technology very restricted, unless Google offer access to F1 at a reasonable price.

1
0

Yep. Consistency is indeed done via time which requires extreme accuracy. Atomic clocks are involved but it does depend on what you are doing.

The other thing is that it's semi-hierarchical rather than truly relational, that helps because they can group data thus helping synch issues on updates.

2
0
JDX
Gold badge

Time to update the CV...

... with 5 years Google F1 experience

2
0

I truly think that much of the discussion around databases, and the scalability thereof, really misses the point.

Barely anyone really needs to scale. Most applications will never saturate a single, untuned mysql server, let alone anything with a bit more oomph.

The question I always encourage people to ask is, what is the data model that you need? Choose a database that implements the data model you need. Bending your app into the data model of a database you chose because it was 'scalable' is stupid.

Many applications don't fit the relational model, and many do.

If you design your application cleanly, and with the correct data model, it can be cleanly optimised to scale. If you try to ram your app into a shape that doesn't fit, it will be hard to optimise.

There is always the option of using more than one database, with different data models, at once, for different purposes.

1
0
K
Bronze badge

Meh..

Release it as open source, then I'll pat you on the back and say well done!

Until then, this is just another "look at our shiny toy" lol

0
2
Silver badge

Re: Meh..

Meh is right.

Informix had this back in XPS as a relational engine.

Had they done project arrowhead they would have it all.

Currently they have IDS as a grid type engine.

So Google re-invents a wheel because IBM sat on it.

-Just saying.

0
0

Google, NuoDB, and the rest

I concur with the fundamental thesis of this article that it will be hard for anyone to replace SQL for most database use cases / applications. NoSQL reminds me of the object-oriented database days, when the claim was made that it will replace relational database technology.

What is true is that relational database technology must evolve to support scale-out datacenter architectures. The likes of Google and NuoDB are well on their way to deliver on that promise. For NoSQL to grow beyond a 100M dollar business, it will have to embrace SQL in some form or the other.

0
0

Or just use PICK

Rather than going back to SQL after dumping NoSQL there's always the PreSQL databases that use the PICK model.

0
0
Anonymous Coward

I'm sure google only employ the finest, brightest and most optimal specimens of humanity, but for the love of God, they come across as such fucking pricks, they really do.

1
2

Transactional consistency is not just good for databases, but filesystems too!

NoSQL has always seemed like an f'ing dumb idea to me, and MySQL is a dated toy; proper SQL databases rock, because tuned SQL and query optimisers can do joins and aggregation a lot better than coders, so light mapping frameworks like MyBatis, thrash bloated NIH ORMs like Hibernate.

Use a proper free database like PostgreSQL, look as scalability info. sites and learn; just shard the data already, or riff on these ideas from Google.

Maybe this will also kick Operating System providers to see that logging (asynchronous) filesystems are junk which should have been phased out years ago, and replaced by a concurrent, queued, transactional model filesystem like ZFS; then I wouldn't see intermittent, race condition faults (NTFS in Windows is pathetic), and the painfully costly downtime to run off-line repairs on filesystems! Kudos to PCBSD and FreeNAS dists. for getting this right with ZFS. Much like a proper RDBMS, ZFS also has advanced features for free e.g. enforced data integrity, integrated RAID, datasets, snapshots, encryption, and de-duping.

It annoys me that some coders have't made the effort to property grasp concurrent development, because it can be quite time consuming to have to retroactively fix code where people either didn't think about concurrency, lazily used blocking locks, or naively left gaping holes for race conditions! Most code is or will become concurrent, even when you naively think not.

1
0
ld

What I found ridiculous is that when explaining why they do not deem Spanner relational, Google said it does not accept tables without keys. Now, what violates the relational model in SQL is precisely allowing bags, that is, tables without keys, which are not relations. It that is the point, it is precisely what makes Spanner relational!

0
0
This topic is closed for new posts.