Menu
By "durable" I mean, the server can crash at any time, and as long as the disk remains in tact, no data is lost (see ACID). Seems like that's what journaling mode is for, but if you enable journaling, doesn't that defeat the purpose of operating on in-memory data? Read operations might not be affected by journaling, but it seems like journaling would kill your write performance.
688
You can have none, partial or full persistence of your data on Redis. The best decision will be driven by the project's technical and business needs. According to the Redis documentation about persistence you can set up your instance to save data into disk from time to time or on each query, in a nutshell.
There is no query language (only commands) and no support for a relational algebra. You cannot submit ad-hoc queries (like you can using SQL on a RDBMS). All data accesses should be anticipated by the developer, and proper data access paths must be designed. A lot of flexibility is lost.
Redis as an in-memory data store with high availability and persistence is a popular choice among application developers to store and manage session data for internet-scale applications.
As Redis is an in-memory storage, you cannot store large data that won't fit you machine's memory size. Redis usually work very bad when the data it stores is larger than 1/3 of the RAM size. So, this is the fatal limitation of using Redis as a database.
Redis is not usually deployed as a "durable" datastore (in the sense of the "D" in ACID.), even with journaling. Most use cases intentionally sacrifice a little durability in return for speed.
However, the "append only file" storage mode can optionally be configured to operate in a durable manner, at the cost of performance. It will have to pay for an fsync() on every modification. To configure this, set these two options in your .conf file:
appendonly yes appendfsync always From the docs: How durable is the append only file?
Check redis.conf, you can configure how many times Redis will fsync() data on disk. There are three options:
- Fsync() every time a new command is appended to the append log file. Very very slow, very safe.
- Fsync() one time every second. Fast enough, and you can lose 1 second of data if there is a disaster.
- Never fsync(), just put your data in the hands of the Operating System. The faster and unsafer method.
(Note that the default for appendfsync in the configuration file shipping with Redis post-2.0.0 is everysec, and not always.)
148
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
