Managed Redis on Google Cloud Platform | Hacker News Reader

Managed Redis on Google Cloud Platform

cloudplatform.googleblog.com

140 pointsdeesix42 comments

> Compatibility with the Redis protocol means you can migrate your applications with zero code changes.

Does this mean they don't actually use Redis, but have an alternate implementation of the protocol? In such a case, wouldn't it be different it terms of performance when compared to the original one. Also, keeping up with new versions should be a major overhead. If Google is still doing an alternate implementation, I wonder what could be the reason.

It's probably built on top of Google's standard production software and hardware stack, the same thing they use to run most of their standard services like search and Gmail. This tech stack tends to have evolved earlier than and separately from the public equivalent.

It generally scales and performs better than normal tech stacks, but its components are so different and so mutually interdependent that it's bad at directly running normal software. The protocol, however, can be implemented just fine.

To be clear: Even though I worked at Google in the past, I don't now, am not speaking for Google, and know nothing secret about this product. I'm extrapolating from widely known general knowledge about Google's technical infrastructure.

It's the same with Aws elasticache. There is redis underneath, still, if you want to have all the features that they provide - scale in/out, replicas, etc, you'll need to have some tools around.

I would say yes, it's still different than using the original one, but that's the way it is when you use any managed service.

Will be different, yes, but in the same way any two instances of "real" Redis will be different.

Hardware, networking, routing, load balancing, memory and disk IO, number of instances, backups/failovers etc. are going to be deciding overall performance rather than the Redis binary itself.

We have a Redis+Memcached frontend with an Apache Ignite Backend. Now we can re-use existing functionality in the clients and have new features like read-through based on a MySQL database or an automatically updated near cache on the instances themselves.

Are you talking about this https://apacheignite.readme.io/docs/redis

If yes, that's 5% redis features.

It's not an alternative implementation. I've been on the alpha and some of the bugs were actually bugs in the OSS redis.

Great. Does this support persisting to disk RDB[1] or AOF[2]?

Pricing seems reasonable?

1GB of Redis data is $0.049 per GB hour. 730 hours in a month = $0.049 * 1 * 730 = $35.77/mo.

5GB of Redis data is $0.027 per GB hour. 730 hours in a month = $0.027 * 5 * 730 = $98.55/mo.

[1][2] https://redis.io/topics/persistence

Those prices are not per hour, but per GB-hour. So multiply your second monthly price by 5. Not cheaper for more data, but definitely cheaper per GB.

Oops. Duh, that makes more sense. Updated.

I don't think this is Redis, this is something that fully supports the Redis protocol.

I wouldn't be that much surprised if underneath use a custom implentation.

Said so, arguably, RDB and AOF are not a concern of the user but of the administrator so I wouldn't expect them...

Amazon Elasticache by comparison:

1.5GB is $0.034 per hour = $24.82/mo.

6GB is $0.182 per hour = $132.82/mo.

They just run Redis on stock EC2 hardware hence the odd GB numbers.

But one advantage of AWS is that with Reserved Instance pricing you could get those numbers down by 2/3.

The standard tier is supposed to persist data (and it did, during maintenance events - it was an alpha, so yeah - there was no data loss), but not sure what they use as the logs are not yet available.

It's not data persistence per se, it's just replication to another instance in a different zone. Persistence is not currently available but plans are in place.

Disclaimer: I am an engineer at Google on the managed Redis team.

UPD: replication -> persistence not available

You mean persistence is not yet available?

"Redis persistence" to AOF or RDB is not currently available (since we are not even in Beta yet), but standard tier instances persist your data in another zone in case something goes wrong with the master instance.

Yup, but your original post said replication isn't available yet. I think you meant persistence.

Thanks for pointing that out. Fixed.

For comparison, here are the prices for managed Redis instances in Azure (Central US) [0]:

Basic Tier (single instance, no SLA)

1GB - $40.15/month

2.5GB - $65.70/month

6GB - $131.40/month

Standard Tier (Primary/secondary replicated instance, SLA)

1GB - $100.74/Month

2.5GB - $164.25/month

6GB - $328.50/month

Premium Tier (Cluster, w/persistence, SLA)

6GB - $405.15/month

[0]: https://azure.microsoft.com/en-us/pricing/details/cache/

May I ask what is the planned use case for the RDB/AOF replication? Are you expecting to have access to the snapshots while the instance is running, or you just need them for import/export or durability reasons?

Disclaimer: I am an engineer at Google on the managed Redis team.

Use case for RDB backups: for rather large redis datasets (>50GB) with long living keys (90days and beyond) I found it useful to be able to parse an RDB snapshot using the python rdbtools and iterate over the whole dataset, e.g. in order to migrate data to a different format. I found this usually more stable and reliable than using SCAN and the likes.

For this use case it seems the export feature that allows you to take a snapshot of the database at any given time might fit the needs. We will definitely consider this feature for the general availability release.

Thanks for the reply!

I wasn't aware of an export feature. As long as the export comes in a reasonable machine readable format that should be equally fine and would remove the need for access to RDB files for my use case.

Too bad you still need to provision instance and reserve max capacity.

They had a chance to outcompete AWS by providing a truly serverless Redis-like service with no upfront commitment and pay-per-use.

That’s what I expected when I first heard that GCP is working on “Serverless Redis” a year ago.

Ya, that's not serverless by any definition of the word. It's "managed" redis.

Where do you read you have to provision instances? I have to choose between Basic and Standard. But there‘s no clear indication that i have to select an instance based on my storage requirements. The pricing information does not indicate different instances for the different storage requirements, it could be, but would not really fit how the rest of gcp works.

The lowest tier says min 1GB. So I guess it starts from $35.77/mo, even if your app doesn’t need the whole 1GB.

Yes, but that‘s no indication you have to provision an instance (not serverless). Google just decided that their granularity for billing is 1GB, like aws lambda and google cloud functions are billed in second granularity and not milliseconds.

According to your definition Heroku is serverless.

Serverless widely understood as:

1. not having to deal with instances/dynos/droplets/etc.

2. Pay-per-use, no upfront payment for unused capacity

Some calling AWS DynamoDB - serverless, but having to pay for reserved capacity for each table and index, make it a bad fit for the rest of serverless stack like AWS lambda or API Gateway or even S3.

The Google redis service will be serverless if the pricing table is not mapped to „subscriptions“ you choose from but instead automatically chooses the pricing layer each hour based on your stored amount (like automated discounts for vms). Thats what i am saying: We still dont know if you have to choose first which pricing layer you want or if google automatically seitches you to the one fitting the amount you store.

Both requirements would be fullfilled on automatic selection of pricing layer: 1. You sinply store data, google handles the price/gb-hour depending on your stored amount 2. You only store data and you are only billed the stored amount (in 1GB increments)

I just wanted to say we just dont know yet whether its serverless (instance type changed automatically) or you have to choose the instant type first.

You have to pick the instance type beforehand. Back when I asked about this in the alpha, I was told changing the size of the instance flushes the cache on the basic instance and has some downtime. I can confirm this happens now that resizing is available.

For standard, it should be relatively seamless (no flush, minimal downtime), but I'm not gonna test right now. :-)

> Reach out to us to let us know what kinds of managed database services you’d like us to offer next.

Hey Google friends,

I'm not ready to move over to GCloud but I'm interested in prototyping a few applications. Here's a few things on my wishlist:

* Wrapping the cli tool for common db tasks in the way heroku does (ex: heroku pg:push - push local database to production database, heroku pg:pull - pulls production database to local).

* Simpler integration of Cloud SQL with AppEngine flex. It's not a lot of work (https://cloud.google.com/appengine/docs/flexible/python/usin...) but it would be cool to build a flex environment / provision a sql database / setup connection strings in one swoop.

* While you're at it, better AppEngine flex introductory pricing ($40 / mo for 1 vcpu, 512 mb ram) :)

Not related to managed databases but hopefully helpful. TLDR Heroku but on GCloud.

Huge fan of RedisLabs, but I'm all for more managed Redis options.

NodeChef Redis Hosting is another option that makes it easy to deploy, operate, and scale Redis in the cloud. https://nodechef.com/redis-hosting

Please use a disclaimer that this is your company if you're going to advertise

It isn't their company...

Yes it is, did you bother checking? https://news.ycombinator.com/item?id=13523349

   > coupdejarnac on Jan 30, 2017 
   > Are you a nodechef cofounder by any chance? I host with nodechef and am happy with them so far.

   > squid3 on Jan 30, 2017 
   > Yes, I am one of the co-founders. Thanks for hosting with us.

I used RedisLabs in a project about 3 years ago where I wanted durable storage, and the service was excellent. Latency in us-east-1 was low, the management interface was snappy, and scaling up storage took just a couple of clicks. I'd probably use a "locally managed" Redis service (ElastiCache in AWS, Google's service in GCP, etc.) for volatile caching in the future, since it's one less vendor to manage, but I'd recommend RedisLabs to anyone who is considering it.

will this support the new upcoming Streams datastructure in redis ?

I'm looking forward to a lightweight, hosted kafka replacement using redis streams.

https://RedisLabs.com probably will, if you just want a managed offering. They are cheaper, and the official sponsor of the redis project now with support for the latest releases.

Currently, the only available version is 3.2, so that's a no.

I'm an GAE user, and I use Memcached there. Implementation aside, how does this different than GAE's Memcached? (from perspective of running on Google Cloud)

Reply on news.ycombinator.com