But you have to start by paying like $1k/mo, it's not serverless (at least the last time I checked). Get CRDB instead.
Google Cloud Spanner is now half the cost of Amazon DynamoDB
301–310 of 371 posts
Re: Google Cloud Spanner is now half the cost of Amazon DynamoDB
#302Shame I don't trust GCP anymore
Re: Google Cloud Spanner is now half the cost of Amazon DynamoDB
#303Earlier quoted context omitted.
Which columnar databases are doing the above in-memory?
SQL Server supports in-memory columnstore tables. I’m not an expert but I suspect SAP HANA also. If you squint, any database engine is “in memory” if there is more buffer than data. Or just use a RAM disk!
> If you squint, any database engine is “in memory” if there is more buffer than data.
That is sadly not true, I remember one lonely night debugging a MSSQL 2012 instance that was _very_ slow, and it turned out that for a simple query (one join, 100 rows in one table and 10 in the other, 100 result in total, one where clause) it forced writing the result to disk before evaluating the WHERE condition. Unable to fight the scheduler I've ended up making a ramdisk for this data.
Re: Google Cloud Spanner is now half the cost of Amazon DynamoDB
#304Earlier quoted context omitted.
Except for projects for which NoSQL is a better fit than a RDBMS, no? If I'm writing a chat app with millions of messages and very little in the way of "relationships", should I use Postgres or some flavor of NoSQL? Honest question.
This is going to feel like a non-answer: but if you need to ask this question in this format, save yourself some great pain and use Postgres or MongoDB, doesn't really matter which, just something known and simple. Normally you'd make a decision like this by figuring out what your peak demand is going to look like, what your latency requirements are, how distributed are the parties, how are you handling attachments,…
Thanks, I really appreciate this. DynamoDB was pretty simple to setup, all things considered. Some growing pains, but it's a dead simple schema.
I'm using SenseDeep's OneTable which was pretty interesting to learn https://doc.onetable.io/ in case others reading this are curious.
Re: Google Cloud Spanner is now half the cost of Amazon DynamoDB
#305Earlier quoted context omitted.
I used DynamoDB as part of the job a few years ago and never got single-millisecond responses - it was 20ms minimum and 70+ on a cold-start, but I can accept that optimising Dynamo's various indexes is a largely opaque process. We had to add on hacks like setting the request timeout to 5ms and keeping the cluster warm by submitting a no-op query every 500ms to keep it even remotely stable. We couldn't even use DAX be…
> We had to add on hacks like setting the request timeout to 5ms and keeping the cluster warm by submitting a no-op query every 500ms to keep it even remotely stable. This sounds like you're blaming dynamo for you/your stack's inability to handle connections / connection pooling.
Yeah that TLS handshake is an absolute killer if you run it for every request.
Re: Google Cloud Spanner is now half the cost of Amazon DynamoDB
#306Google also has a history of massively spiking the cost of its services. Vendor lockin is a dangerous thing.
This definitely happened with Google Maps, where Google was clearly the dominant player. Has it happened to other services? It seems far less likely to happen for business cloud services where they are a distance 2nd (3rd?) to AWS. I know of some examples (admittedly ancient) where they have reduced costs: https://cloudplatform.googleblog.com/2015/05/Pay-Less-Comput...
>Has it happened to other services?
BigQuery initially was a lot more powerful, then they started adding a bunch of resource limits on queries that you could only overcome by paying up. Not a direct fee increase, rather you paid the same fee for a worse product.
Re: Google Cloud Spanner is now half the cost of Amazon DynamoDB
#307Earlier quoted context omitted.
We have an old "quiet part out loud" corporate story. It's about how one arm of Google using our service and wondering why it had so much downtime, only for us to point at their GAE arm and say "when they're down, we're down". They went and talked to GAE and - funny enough - were able to correlate the downtime they observed with GAE downtime. GAE uptime improved, for a little while. Yeah, we're on AWS now too.
Does Google run on GCP?
Mostly not.
Re: Google Cloud Spanner is now half the cost of Amazon DynamoDB
#308And for many projects, Postgres is still cheaper than both. Having used both, I would much, much rather do the work to fit my project in Postgres/CockroachDB than use either Spanner or DynamoDB, which have WAY more footguns. Not to mention sudden cost spikes, vendor lock in, and god knows what else. AWS and GCP (and Azure, and Oracle cloud, and bare Kubernetes via an operator, and...) support Postgres really well. Ju…
I know the spanner marketing blurb says you can scale down etc. But I think in practice spanner is primarily aimed at use cases where you'd struggle to fit everything in a single postgres instance. Having said that I guess I broadly agree with your comment. It seems like a lot of people like to plan for massive scale while they have a handful of actual users.
My team bought the "scale down" thing and got bit.
Using Spanner is giving up a lot for the scalability, and if you ever reach the scale where a single node DB doesn't make sense anymore, I don't know if Spanner is still the answer, let alone Spanner with your old design still intact. For one, Postgres has scaling options like Citus. Or maybe you don't need a scalable DB even at scale, cause you shard at a higher layer instead.
Re: Google Cloud Spanner is now half the cost of Amazon DynamoDB
#309And for many projects, Postgres is still cheaper than both. Having used both, I would much, much rather do the work to fit my project in Postgres/CockroachDB than use either Spanner or DynamoDB, which have WAY more footguns. Not to mention sudden cost spikes, vendor lock in, and god knows what else. AWS and GCP (and Azure, and Oracle cloud, and bare Kubernetes via an operator, and...) support Postgres really well. Ju…
Postgres is the database God himself would have made.
It's the best, but it's far from perfect. Default mode is non-ACID, and going `serializable` mode makes it very slow. Spanner is always ACID... but always slow.
Re: Google Cloud Spanner is now half the cost of Amazon DynamoDB
#310Earlier quoted context omitted.
> I was left with a feeling that most of it is inconsistent garbage papered over with lambda functions This sounds more like an indictment of the system design than the cloud provider. What are some of these “3am” topics that made GCP a better choice?
Small examples included (I’m on my phone so these are from memory and you’ll have to forgive the lack of great detail): 1) having the project/account your in visible at the top at all times. We used SSO for “accounts” which is AWS’s way of completely separating resources; the long string that is returned is not unique in the start and the remainder is cut off: so all accounts/projects looked the same, was impossible…
“2) Autoscaling groups with that had human readable incrementing “names”, in AWS instances have hex slugs as instance names and you can give an instance a special “Name” label: but any new machines created with an ASG will just reuse the same name label making them hard or impossible to tell apart.
The AWS official solution for this is to have a lambda function hook on the scale event and give your new node an incremented name label. Given that AWS is pricy to save me time: I do not personally consider this an elegant solution”
Why were you even messing with the instance name? This is a ridiculously simple problem to solve with tags on your ASG. And AWS even did the courtesy of propagating those tags across the ASG and all its instances.
https://docs.aws.amazon.com/autoscaling/ec2/userguide/ec2-au...