6 ms·
"Remember redis is meant to hold ephemeral data in memory, so please don’t treat it as a DB. It’s best to design your system assuming that redis may or may not
by antirez 6y ago
"Remember redis is meant to hold ephemeral data in memory, so please don’t treat it as a DB. It’s best to design your system assuming that redis may or may not lose whatever is inside"
Of course I disagree with that statement. Many serious Redis use cases at big companies assume Redis is there and will hold your data. What they usually assume is that under certain cases during failovers or other serious failures you many lose some acknowledged writes that were sent immediately before. And this most of the times does not happen too. Note that many high performance applications using SQL DBs with a relaxed fsync configuration will have the same assumption. The suggestion should be more: if Redis for you is just a volatile aid, use a given setup, if it's were you store data, use another setup.
Anyway if you want to see a version of Redis where you can store also bank accounts, transactions or any other of the most critical stuff you can store in a DB make sure to check the news at Redis Conf 2020 (the conf is in streaming and free).
EDIT: But even after that announcement the biggest value for Redis is that it can be fast and provide a "best effort" consistency level that is adequate for a lot of use cases in practice. Many systems were sacrified in the temple of wanting to provide linearizability for all the use cases.
- lidHanteyk 6y agoRegardless of whether Redis is meant to hold ephemeral data in memory, it is well-known to anybody who has had to maintain a Redis instance as part of their deployment that Redis is only effective when used for ephemeral in-memory work. I understand your defensiveness, but please understand that because of your massive experience with Redis, either you have never lost data with Redis, which means that nobody besides you understands how to run your software in production, or you have lost data with Redis, which means that it's somewhat hypocritical of you to insist that Redis is durable.
- tomnipotent 6y ago> that Redis is only effective when used for ephemeral in-memory work Hogwash and there are plenty of examples out there that prove otherwise. > somewhat hypocritical of you to insist that Redis is durable If Jepsen has demonstrated anything, it's that no database is as durable as it claims to be.
- staticassertion 6y agoThere are lots of dbs that do very well under Jepsen tests.
- tomnipotent 6y agoI can't think of a single Jepsen test that hasn't demonstrated issues with data loss.
- staticassertion 6y agoJust going from the last one I read for DGraph, it did extremely well. Pretty sure etcd did well. They always have bugs somewhere, but there are huge differences between bugs that show up for very specific, niche cases, and normal "I wrote to the db and it dropped it".
- tomnipotent 6y agoFrom the latest test: "We found five safety issues in version 1.1.1—some known to Dgraph already—including reads observing transient null values, logical state corruption, and the loss of large windows of acknowledged inserts." Loss of large windows of acknowledged inserts. Durability is hard.
- staticassertion 6y agoI don't really feel like playing the quotes game... but, sure. "All of the issues we found had to do with tablet migrations" "ndeed, the work Dgraph has undertaken in the last 18 months has dramatically improved safety. In 1.0.2, Jepsen tests routinely observed safety issues even in healthy clusters. In 1.1.1, tests with healthy clusters, clock skew, process kills, and network partitions all passed. Only tablet moves appeared susceptible to safety problems." No one is here to claim that anyone is getting through any kind of rigorous testing without bugs found. But there is a huge difference between "My extremely common write path + a partition = dropped transactional writes" and "Under very specific circumstances, with worst case testing, multiple partitions, and the db in a specific state, we drop writes". There is an ocean between, say, mongodb's test results, and Dgraph's. Read Redis's evaluation, for example: https://aphyr.com/posts/283-call-me-maybe-redis https://aphyr.com/posts/283-call-me-maybe-redis "If you use Redis as a queue, it can drop enqueued items. However, it can also re-enqueue items which were removed. " "f you use Redis as a database, be prepared for clients to disagree about the state of the system. Batch operations will still be atomic (I think), but you’ll have no inter-write linearizability, which almost all applications implicitly rely on." "Because Redis does not have a consensus protocol for writes, it can’t be CP. Because it relies on quorums to promote secondaries, it can’t be AP. What it can be is fast, and that’s an excellent property for a weakly consistent best-effort service, like a cache." Again, Redis is a very different type of database, so expectations should be aligned. Further, this test is quite old. But that's a huge difference from DGraph's results. Basically, saying "Well no one does well on Jepsen" isn't really true. Lots of databases do well, but you have to adjust your definition of "do well".
- devsquid 6y agoAs with all things it totally depends on the scale you're at. Redis is an extremely reliable service. I've never "lost" data with Redis.
- rpdillon 6y agoYour comment seems to suggest that everyone that's ever used Redis except antirez has lost data. I don't think that's true. I've used Redis since 2012 across dozens of production services and never lost data, and I don't have any particular skill that makes me special.
- ComputerGuru 6y agoI was agreeing with you until > And this most of the times does not happen too. This rubs me very very wrong. There is no maybe in data integrity. Redis wasn’t designed to be ACID and shouldn’t be treated as such just because “usually” it doesn’t lose data “under the right circumstances.” If a sysadmin uses an RDBMS with relaxed fsync, they know what they are getting (and durable writes is not one of them, no usually about it). Same for Redis.
- masnao 6y ago> sysadmin we live in the age of devOps. there's no such thing as sysadmin, or god forbid, DBAs. /sarcasm
- ramraj07 6y agoFor real! Where did all those DBAs go??
- oneplane 6y agoThey retired and since no millennial wants to work for an Oracle degree no new ones came in to the field /s
- lykr0n 6y agoThey're charging $400 an hour to come in and unfuck years of devs thinking they can design databases because they read a MySQL How-to Article
- laurentdc 6y agoWe gladly paid one 800 € for three hours of work.. fixing a botched stored procedure on IBM DB2. Gray haired DBAs with the right blend of dev, ops and most importantly business domain knowledge (something many people in IT seem to overlook) are worth gold
- jcims 6y agoinfrastructure as code == infrastructure by coders
- gigatexal 6y agoFormer DBA here ... you don't disable fsync.
- antirez 6y agoNo but often you set it to fsync every second and not at every write, if you are really concerned with performances in certain kind of applications. Or in practical terms, check the synchronous_commit config option of PostgreSQL. Basically sometimes you have fsync enabled because you don't want to corrupt the log, but the writes will not wait for the WAL, so the last transactions can get lost on crash.
- gigatexal 6y agoI would just throw more money at the problem not weaken the strength of my confidence in the underlying storage subsystem or the DB by playing with the fsync behaivor willy-nilly nor even in a calculated way. I would instead just throw more money at the problem by investing in faster and faster disks -- you can do a lot with enterprise grade NVMe now.
- Scarbutt 6y agoThe querying capabilities of SQL shouldn't be ignored though, another issue is that your data must fit in memory.
- jdc0589 6y agothats not really relevant, I don't think anyone assumed it was always a drop in replacement for sql
- Scarbutt 6y agoAnyway if you want to see a version of Redis where you can store also bank accounts, transactions or any other of the most critical stuff you can store in a DB make sure to check the news at Redis Conf 2020 (the conf is in streaming and free). He sort of implies here, not for you, but it might create that impression on others, was clarifying for those.
- raverbashing 6y agoI think what the author means is: > "Remember redis (in AWS) holds ephemeral data in memory" (because EC2 machines don't persist their disk data between start/stops and a lot of people don't realize that until it is too late - hey remember that Bitcoin exchange that got bitten by this?)
- bbgm 6y agoI suspect that’s what you meant but just for clarity, Instance storage does persist for reboots (which is effectively an OS reboot), but not if you stop/start (or terminate) the instance.
- raverbashing 6y agoCorrect, I've updated the comment. Yes if you do an ordinary OS reboot the disk remains.
- watermelon0 6y agoThis was mostly applicable to older generations of EC2 instances (C3, M3, etc.) EBS is now the default when creating an instance, and instance types of newer generations generally don't have instance store at all (except disk optimized instance types, and those with "d" in the name.)
- cookiecaper 6y agoYeah, I think Amazon gave up on trying to communicate the meaning of ephemeral storage, and I think that's for the best tbh. It's too easy to have important data vanish that way. Something as simple as someone issuing a shutdown from the console is translated into an "instance stop" in AWS, which would purge the storage -- unfortunately often a lesson learned the hard way.
- jdc0589 6y agoI'm one of those people with moderate throughput production applications using Redis as a primary store (500-2000 requests per second); in a multi-region active-active setup without redis enterprise no less. Its a very real use case at a LOT of companies. Favorite datastore to date. The only thing I wish for frequently is native global change-data-capture without doing something manually with streams (I've thought about writing a replication protocol consumer, but the way resync's are handled is a little problematic)
- manigandham 6y agoHow are you doing active-active?
- jdc0589 6y agopiggybacked off Dynamodb in AWS for now unfortunately; so its more "the entire system is active-active, not just the redis bit". Reads always go to Redis in every region (no read-through), writes go to dynamodb (in global table config). Then there's a worker in each region consuming the dynamo stream and keeping it's region's redis in sync Worker is a DIY stream consumer implementation. The stream -> lambda integration works, but its super limited (and ~300ms slower to get new events on average)
- jdc0589 6y ago* writes are multiplexed to redis and dynamo in the origin region.
- manigandham 6y agoWhy is the origin region Redis not also a reader of the replication stream? Just for latency?
- jdc0589 6y agoyep. in this specific use case there can be pretty fast reads after a write, and dynamo stream latency is not great even intra-region. Via the lambda integration you should probably expect ~1000ms p99 latency intra-region, and ~2100ms p99 from, e.g, east-1 to west-2. Shave maybe 200-300ms off of those numbers if you do a DIY stream consumer without the aws provided lambda connector.
- himinlomax 6y agoUse a redis cluster to store session data, and then wonder why so many users get double login forms at times. Bad idea. Bad tool for the job.
- tobad357 6y agoWill this announcement be Day 1 or Day 2? Looking forward to it as may solve some decisions we will be doing going forward
- antirez 6y agoToday starting at 6:30 Pacific time or alike. Not sure about the time of this specific announcement.