back to article Get tooled up before grappling with Google's Spanner database

When companies started to build applications at web scale and needed services to scale to millions of requests across the globe, it quickly became apparent that relational databases just didn't work well enough. So companies like Amazon and Google built their own that could service these requests but without all the features …

  1. Tim99 Silver badge
    Big Brother

    And

    How long before Google drop it/move on to the next great thing. I would be wary of its use as a key component in my "global, relational-capable database".

    1. Anonymous Coward
      Anonymous Coward

      Re: And

      That's the database that Google is using internally; so it's likely to stay around...

    2. Paul Matencio

      Re: And

      Such a useless comment. Spanner is used internally by Google applications that bring them en of billion dollar per quarter and you believe they are going to drop it. By the way, do you also think that Google is going to drop Coogle Cloud Platform or Google Kubernetes Engine.

      1. Anonymous Coward
        Anonymous Coward

        Re: And

        "and you believe they are going to drop it. By the way, do you also think that Google is going to drop Coogle Cloud Platform or Google Kubernetes Engine."

        If it suited them. Customer impact has never previously been a concern. And unlike say Azure Stack, you cant run much of it in house if you ever need to.

    3. Anonymous Coward
      Anonymous Coward

      Re: And

      "Just don't forget the cost of that Spanner cluster! "

      Well if you do want to use Spyware as a Service cloud then the good news is that hardly anyone else is, and they are hiring hoards of increasing desperate sales staff to try and flog this stuff in the face of a complete wipeout from Azure and to a lesser degree AWS - so they are pratically giving it away!

  2. Frederic Bloggs

    Cost?

    How is that cost likely to compare with, say, an Oracle setup that attempts to do the same thing?

  3. Charlie Clark Silver badge

    The advantage of relational databases…

    … is that they're based on relational algebra and thus have a solid mathematical foundation. Removing redundancy via normalisation gives the reliability and flexibility of predicate logic. JOINs themselves are an artefact of SQL, which is itself is not relational – there is no room in relational algebra for NULL – and gets a lot of things wrong as a result. Modern relational databases can provide incredible performance (things like Swarm64 are aiming for 30 m rows/s @ 40 byte writing) which should be sufficient for most transactional workloads but this requires local clients. Worldwide replication will inherently introduce some latency. Chances are, however, that if you're hitting those kind of limits you already know these things. Unless you're doing NoSQL because "webscale" and wondering why your data keeps getting corrupt or deleted.

    The use of a dedicated network with synchronisation via atomic clocks is useful in its own right and possibly the most important aspect of the implementation.

    1. disgruntled yank Silver badge

      Re: The advantage of relational databases…

      a. How are JOINs an artifact of SQL?

      b. Once you've normalized, how will you put your data back together without a join?

      c. Isn't normalization orthogonal to the relational algebra?

      Not that I want to do without relational databases?

  4. TomPhan

    "Hence NoSQL, the collection of database-like alternatives that didn't use SQL"

    I think you'll find they actually are databases.

    1. TheVogon Silver badge

      Re: "Hence NoSQL, the collection of database-like alternatives that didn't use SQL"

      WebScale: https://www.youtube.com/watch?v=b2F-DItXtZs

  5. Kevin McMurtrie Silver badge

    Throw a spanner in

    Spanner is an interesting data store. It works great where you have billions of things and each of those things has some small varying number of other things related to it - this is the nested tables trick. Parent and nested child tables are stored together so there's no I/O seek penalty for getting them all together. For other cases it's not relational even though a flimsy SQL interpreter makes it look like it is. Updates are transactional with a compare & set type of operation, which can be done in MySQL too.

    The real question is if you trust Google. My experience is that recoverable glitches happen several times a day, momentary failures happen almost every day, and there's some significant screw-up outage at least once a month. Google believes they're perfect so Spanner comes with absolutely no monitoring dashboard.

    In my test between Google's hosted Spanner and Google's hosted MySQL 2, Spanner won by an enormous margin. Their MySQL 2 instances always seems to be abnormally slow so it's a biased test. I'd never host data on Google unless there was a real need for it.

POST COMMENT House rules

Not a member of The Register? Create a new account here.

  • Enter your comment

  • Add an icon

Anonymous cowards cannot choose their icon

Biting the hand that feeds IT © 1998–2019