Managed Redis on Google Cloud Platform(cloudplatform.googleblog.com)
cloudplatform.googleblog.com
Managed Redis on Google Cloud Platform
https://cloudplatform.googleblog.com/2018/04/Accelerating-innovation-for-cloud-native-managed-databases.html
42 comments
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 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 not an alternative implementation. I've been on the alpha and some of the bugs were actually bugs in the OSS redis.
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.
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.
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.
If yes, that's 5% redis features.
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.
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.
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
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
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.
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.
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.
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
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.
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/
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/
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...
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.
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.
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.
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.
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.
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.
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. :-)
For standard, it should be relatively seamless (no flush, minimal downtime), but I'm not gonna test right now. :-)
Ya, that's not serverless by any definition of the word. It's "managed" redis.
> 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.
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.
will this support the new upcoming Streams datastructure in redis ?
I'm looking forward to a lightweight, hosted kafka replacement using redis streams.
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)
Huge fan of RedisLabs, but I'm all for more managed Redis options.
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.
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.
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.