Live data from Hacker News

Managed Redis on Google Cloud Platform

cloudplatform.googleblog.com

21–30 of 43 posts

Re: Managed Redis on Google Cloud Platform

#22
post #18

Earlier quoted context omitted.

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.

Re: Managed Redis on Google Cloud Platform

#23

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.

Re: Managed Redis on Google Cloud Platform

#24

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.

Re: Managed Redis on Google Cloud Platform

#25
post #7

> 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,…

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.

Re: Managed Redis on Google Cloud Platform

#26
post #7

> 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,…

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

Re: Managed Redis on Google Cloud Platform

#28
post #22

Earlier quoted context omitted.

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.…

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. :-)

Re: Managed Redis on Google Cloud Platform

#29

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

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.

Re: Managed Redis on Google Cloud Platform

#30
post #7

> 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,…

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.

Post reply on HN