
Cloud Spanner is now production-ready - jonas21
https://cloudplatform.googleblog.com/2017/05/Cloud-Spanner-is-now-production-ready-let-the-migrations-begin.html
======
theDoug
One line summary: “99.999% availability and strong consistency — without
compromising latency”

(I work at G)

~~~
jfoutz
5 minutes a year is really impressive.

~~~
MichaelRenor
Especially considering that all of AWS database solutions require a 20 minute
maintenance window _per week!_

~~~
acchow
What are they doing during those 20 minutes?

Define "maintenance window" \- the DB becomes read-only? Or unreachable? This
sounds insane to me.

~~~
ReidZB
Actions that require database downtime/restarts can happen during the
maintenance window. For example, if you change a DB parameter that requires a
database restart, you can tell AWS to restart the DB during the next
maintenance window. Same goes for DB engine upgrades and the like.

If you're running anything production-worthy, you'll be using one of AWS's
multi-AZ/failover solutions for your production RDS instances. In that case,
the database will perform a failover in those instances so there isn't
downtime.

~~~
snoman
> In that case, the database will perform a failover in those instances so
> there isn't downtime.

Have you done that? I have and there's been downtime every time (~5m).

------
makmanalp
I think people calling this expensive are missing the point - the main use
case for this is large organizations that truly need to scale globally, at
which point you'd probably sink many times the money to have that problem
magically solved for you.

~~~
nickpsecurity
Not to mention Spanner was first to pull off this combo of performance,
consistency, and availability. The others claiming similar things are one
pulled off market and one just beginning (unproven). It's not just cost:
they're either going to have to clone Spanner with clean-slate project,
exhaustively analyze/test CochroachDB to see if it's mission-ready, or invent
their own magic that does what most DB vendors couldnt pull off. They'd be
spending a lot of money on something that would likely crash and burn when all
the odd errors hit it.

Most enterprises that _have_ to maintain global consistency are better off
with Spanner. I doubt there's many, though, that really need that vs splitting
stuff into locales that are consistent in a smaller, geographical area that
allows regular, DB clusters.

~~~
xj9
_better off using non-free software for mission-critical services_

it may be true that spanner is currently better than any free software option,
but you are _much_ better off contributing to a free software project that
solves this problem than paying google to keep developing their non-free
alternative.

~~~
nickpsecurity
FOSS and commercial sector tried and failed to do stuff like that for over a
decade. I agree developing it is better in the long term but most don't have
the skill to solve that problem. Better to buy a proven solution, make sure
you can exit it (not sure what Spanner is like here), and switch if a FOSS
solution emerges.

------
oxplot
For those interested, Cockroach DB whose version one stable just got released
lately, is taking the same approach as Spanner and is open source. In fact, it
was started by a few folks from Google who worked on Spanner and other related
tech.

~~~
richdougherty
I know Spanner uses atomic clocks to get tight time bounds on transactions.
Since CockroachDB doesn't use atomic clocks they have to use a slightly
different approach:

"While Spanner provides linearizability, CockroachDB’s external consistency
guarantee is by default only serializability, though with some features that
can help bridge the gap in practice."

"A simple statement of the contrast between Spanner and CockroachDB would be:
Spanner always waits on writes for a short interval, whereas CockroachDB
sometimes waits on reads for a longer interval."

[https://www.cockroachlabs.com/blog/living-without-atomic-
clo...](https://www.cockroachlabs.com/blog/living-without-atomic-clocks/)

------
gfodor
So, can someone explain why this isn't the RDBMS holy grail? (serious
question)

~~~
brandur
I don't think there's any question at this point that Spanner is really cool.
The vast majority of cloud databases out there (even brand-new ones like
Azure's Cosmos) are still implicitly trying to convince you that not having
ACID transactions is something that won't matter very much, and that scale is
by far more important, which isn't true. Google hasn't taken that approach
with Spanner, and it's a breath of fresh air.

I'd throw one downside out there though: lock in. While queries use standard
SQL syntax [1], all write operations are performed via a very non-standard
GRPC API [2]. I think the team certainly considered this and weighed the trade
offs, but it does mean that after you're on Spanner, you're on Spanner
forever.

[1] [https://cloud.google.com/spanner/docs/query-
syntax](https://cloud.google.com/spanner/docs/query-syntax)

[2]
[https://cloud.google.com/spanner/docs/reference/rpc/](https://cloud.google.com/spanner/docs/reference/rpc/)

~~~
boulos
We're hoping to add more compatibility layers, _but_ the semantics of reading
updates _within_ a transaction are what gave the team pause. If you don't need
that semantic, it's relatively straightforward (I assume we'll see this happen
either directly by us, or from the community).

Disclosure: I work on Google Cloud, but not on Spanner.

~~~
fdsfsafasfdas
Any chance that Google Cloud will ever expose access to F1?

~~~
boulos
The point of the SQL layer now merged into Spanner is so that people don't
have to run F1 or something like it on top. I'd expect continual improvements
there, especially if enough folks say "I'll move if X"

~~~
fdsfsafasfdas
Well, the hope would be that it would allow read-write-read sql transactions,
which to my understanding will never be implemented in Spanner.

~~~
bogomipz
Any insight into why read-write-read sql transactions will never make it into
Spanner?

~~~
elvinyung
Not sure if "never", but from the new Spanner paper[1]:

> While we have seen comparatively little demand for this feature internally,
> supporting such semantics improves compatibility with other SQL systems and
> their ecosystems and is on our long-term radar.

[1] [http://dl.acm.org/authorize?N37621](http://dl.acm.org/authorize?N37621)

~~~
bogomipz
Thanks for the clarification and the link.

------
_jcwu
It appears to be very expensive. I used their calculator and it says using 1
spanning node and 1GB of storage is about $657 a month.

~~~
forgot-my-pw
Yup, but cost is relative to the problem you're trying to solve.

When your app needs horizontal scaling DB with multiple regions, and you don't
have to come up with your own sharding solution, suddenly $8000 a year sounds
like a great price.

~~~
erikpukinskis
General computer science-y kind of software philosophy question:

Should we really be thinking of sharding as something you can outsource to the
infrastructure layer?

It just seems like having a stance about how the data in your specific domain
naturally shards is probably going to pay off not even the long run, but
immediately in terms of sanity checking your information architecture.

And I wonder if in 2017 we haven't gotten to the point where a cloud
application should just shard, because we're trying to think about software as
something that runs on a transient instance with access to a subset of data,
appearing and reappearing, not a giant box with everything on it.

I get that Google engineers are darn close to abstracting away that "giant box
with everything on it" behind an API, but I guess I'm asking if that's really
how we should be thinking about our code.

~~~
scott00
As with basically all software design questions, the answer is "it depends".

Writing a LOB app with 4 expected users all located in the same location, and
expected storage requirements of a gigabyte a year? Go with a traditional DB,
add replication if you need high availability, make and test your backups,
done.

Writing the new Facebook weknoweverything app that captures smartphone audio
and video continuously for all users at all times, automatically transcribes
all conversations and produces AI-driven summaries of all video, all of which
are saved forever and highly searchable? You're going to need a highly
customized data storage architecture to have a prayer of keeping up with that
data.

Somewhere in between? Some of those are good candidates for Spanner. Some
aren't.

------
oxplot
My problem with this is how it's priced. Why am I paying for instance hours
when I don't have/need instance access. I would have thought it'd be priced
like Datastore per GB used and API calls made. As it sits right now, it's
fairly expensive.

~~~
bbass
As a heavy user of datastore, i'm glad the pricing model is around instances
and data stored. Paying for reads and writes makes doing any sort of
migrations or map reduce jobs extremely expensive.

------
peterwwillis
tl;dr building an acid database that does everything at scale is hard, but we
did it

Linked paper:
[http://delivery.acm.org/10.1145/3060000/3056103/p331-bacon.p...](http://delivery.acm.org/10.1145/3060000/3056103/p331-bacon.pdf?ip=70.15.49.220&id=3056103&acc=OA&key=4D4702B0C3E38B35%2E4D4702B0C3E38B35%2E4D4702B0C3E38B35%2E5945DC2EABF3343C&CFID=937247105&CFTOKEN=75904230&__acm__=1494955296_87e3cbe7318ff2fc995cca740d707bdf)

Useful parts: "Lessons learned and challenges" p. 11. "Conclusions", p.12.

~~~
vmarsy
Your link doesn't work, it shows "An error occurred while processing your
request.". Could you provide a "BibTeX reference" or equivalent?

~~~
manigandham
The paper is called: _Spanner: Becoming a SQL System_

ACM link:
[http://dl.acm.org/citation.cfm?id=3056103&CFID=915581248&CFT...](http://dl.acm.org/citation.cfm?id=3056103&CFID=915581248&CFTOKEN=84632582)

Discussion from 2 days ago:
[https://news.ycombinator.com/item?id=14337817](https://news.ycombinator.com/item?id=14337817)

------
daxorid
Currently salivating for a self-hosted version of this. I suppose it's too
much to expect that this would ever become a reality.

~~~
hoschicz
This is basically impossible: for strong consistency, you need very accurate
clocks. Google installs GPS clocks in its data centers.

Also Bigtable, Spanners predecessor, is not open source too.

~~~
atemerev
Every GPS chip in every GPS-enabled device includes the clock — by design, it
can't work without it. So perhaps it is possible to quickly hack something
from a cheap Android phone placed somewhere near the window?

~~~
timelol
Using GPS as your time source is a fabulously good way to trash your entire
database during a leap second. See this paper for a discussion on how
essentially everybody but Google gets this wrong:
[http://crin.eng.uts.edu.au/~darryl/Publications/LeapSecond_c...](http://crin.eng.uts.edu.au/~darryl/Publications/LeapSecond_camera.pdf)

~~~
mastax
GPS time does not have leap seconds:
[http://www.oc.nps.edu/oc2902w/gps/timsys.html](http://www.oc.nps.edu/oc2902w/gps/timsys.html)

> GPS Time is a uniformly counting time scale ... The word "uniformly" is used
> above to indicate that there are no "leap seconds" in this time system.

> The GPS message contains information that allows a receiver to convert GPS
> Time into Universal Time

In fact the article you linked corroborates this, because they used GPS time
to show how inaccurate NTP servers are.

------
peterwwillis
I'm curious to see what the real-world implications of this iteration of
Spanner are against Calvin-based designs, like FaunaDB. Obviously Calvin is
better for low-latency workloads, but I'm curious about the comparison with a
mix of workloads, where latency is important but not mission-critical.

------
ethanpil
Mass market support questions:

PHP Support? Does it support views and triggers like MySQL/PostgreSQL?

~~~
grouseway
Pricing starts at $8000/year so you probably don't want to migrate your PHP
software over.

~~~
TomNomNom
Why? I'm confused as to why using PHP would be relevant to how much it costs.

~~~
alexdumitru
It's not relevant at all. People just hate PHP because it's the trend.

------
antisocial
How does this compare to Apache Cassandra?

~~~
thesandlord
Cassandra is a NoSQL database, so you get horizontal scalability but need to
deal with eventual consistency and there is no SQL support. It is similar to
Google Bigtable [0].

Spanner is a database that merges the horizontal scalability of a NoSQL
database with the strong consistency and SQL semantics of a relational
database, basically the best of both worlds. People like to call this type of
database "NewSQL."

Cassandra is also open source, Spanner is not. CockroachDB is the OSS clone of
Spanner, but there are some differences and tradeoffs to be made as with all
things.

(I work at Google Cloud)

[0] [https://cloud.google.com/bigtable/](https://cloud.google.com/bigtable/)

~~~
antisocial
Thanks, I forgot about the NoSQL part due to tunable consistency. I remembered
Cassandra as almost similar to SQL databases with horizontal scalability.

------
stygiansonic
More information about Spanner itself, the globally-synchronized clock it uses
and its relation to the CAP theorem: (By Brewer himself)
[https://research.google.com/pubs/pub45855.html](https://research.google.com/pubs/pub45855.html)

------
perrohunter
Cloud spanner gets me super exited, I wish they would show more details about
its design and architecture.

------
Narkov
I can't find any information on how you manage backups? Can I restore to a
point in time?

------
manigandham
Any rough timeline on when multiple regions will be available?

Looking at Cosmos DB for (at least readonly) regional distribution for this
now as well as the other options like scylla/cockroachdb/tidb.

------
kidsil
If the pricing is predictable enough, it could be the missing piece of a fully
serverless application.

------
iamneal
My company has been migrating to spanner, and we are starting to get pretty
familiar with it. We started building a golang sql driver for spanner, and
protoc plugin for generating a persistence layer for spanner.

[https://github.com/tcncloud/protoc-gen-
persist](https://github.com/tcncloud/protoc-gen-persist)
[https://github.com/tcncloud/sqlspanner](https://github.com/tcncloud/sqlspanner)

Both are pretty new projects, and we ran into a snag with the sql driver when
it came time to implement delete statements, but both are pretty cool, and we
would love contributors!

------
justinsaccount
Have they announced the End Of Life date yet?

~~~
johan_larson
Since Google uses Spanner in-house extensively, it is likely to be available
for a good long time.

~~~
justinsaccount
> Google uses Spanner in-house extensively

True

> it is likely to be available for a good long time.

Where does this conclusion come from?

The google mapreduce paper was released in 2004. [0]

"By 2014, Google was no longer using MapReduce as their primary Big Data
processing model" [1]

The google spanner paper was released in 2012.

If spanner lives as long as mapreduce it will be largely replaced in 5 years.

[0]
[https://research.google.com/archive/mapreduce.html](https://research.google.com/archive/mapreduce.html)

[1]
[http://www.datacenterknowledge.com/archives/2014/06/25/googl...](http://www.datacenterknowledge.com/archives/2014/06/25/google-
dumps-mapreduce-favor-new-hyper-scale-analytics-system/)

~~~
wsetchell
I think you're talking about two different things: "will Google drop support"
and "will Google invent something better"

Map Reduce is still supported today. Most teams have chosen to move to newer
infrastructure because it is better. Nobody forced those teams to move.

Here Google has not dropped support, but has invented something better.

[Disclaimer - work at Google, but not on anything related to Cloud]

~~~
gldalmaso
Google disproves Google.

[https://cloud.google.com/prediction/docs/end-of-life-
faq](https://cloud.google.com/prediction/docs/end-of-life-faq)

"As we've expanded our Cloud Machine Learning services, many of the use-cases
supported by Cloud Prediction API can be better served by Cloud Machine
Learning Engine."

In this case "invent something better" == "drop support".

