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.
"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.
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.
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.
> 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.
> 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.
> 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.
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.
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. :-)
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.
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)
42 comments
[ 2.3 ms ] story [ 90.9 ms ] threadPricing 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
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...
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.
Disclaimer: I am an engineer at Google on the managed Redis team.
UPD: replication -> persistence not available
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/
Disclaimer: I am an engineer at Google on the managed Redis team.
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.
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 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.
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.
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.
If yes, that's 5% redis features.
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.
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.
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.
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.
For standard, it should be relatively seamless (no flush, minimal downtime), but I'm not gonna test right now. :-)
I'm looking forward to a lightweight, hosted kafka replacement using redis streams.