3 ms·
The problems with that are easy to see though: you need lots of RAM if your database is non-trivial in size. You also need to write the state to the database co
by nawitus 12y ago
The problems with that are easy to see though: you need lots of RAM if your database is non-trivial in size. You also need to write the state to the database continuously to prevent data loss from failures. Not saying the idea doesn't have use cases, of course. Redis (for example) is pretty popular these days, but I don't see how it'll become the default go-to database.
- mantrax5 12y agoYes, you need to write continuously. Basically you need a transaction log. Redis unfortunately botches that part a bit (it has no performant and reliable way of persisting every change before acknowledging a "commit"), but that's roughly the idea. However not all of your state will be persistent, so you write only the persistent parts. For example, if you need to have an index for quick access to items based on some criteria, you don't need to store the index on disk, you can always rebuild it on startup from the rest of the data. While there's an upper limit for the amount of data you can store this way (it has to fit in RAM), it fits very favorably in web scenarios, where you have read-heavy write-light data access patterns, and you never have to touch the disk in order to read a piece of data (guaranteed).