Friendly: NoSQL With MySQL in Ruby
jamesgolick.com
Friendly: NoSQL With MySQL in Ruby
1–10 of 19 posts
Re: Friendly: NoSQL With MySQL in Ruby
#2I can talk for Redis but my guess is that's the same for the other datastores. In Redis to have full durability enable append-only-file: it's a text-only file, you can check by hand what's written inside your database.
In addition even while running in append only file mode, you can still ask Redis to "BGSAVE" (crete a copy of the dataset into an .rdb file in background). It's a single file and you can save it everywhere.
With the append only file, it's trivial to write a script to export ALL YOUR DATA into MySQL every 24 hours for instance. So you have your data in:
a) compact .rdb file you can backup easily. b) the append only file c) MySQL, where you can perform query to check if the data is sane.
In addition in the next months Redis will get a JSON export feature built-in, so you can also d) save data into a JSON file.
This new products are still younger than MySQL, and there are more bugs probably, but it's just a matter of being a bit more careful to use this DBs in production without concerns, experiencing a huge performance gain.
p.s. since the release of Redis 1.0 no critical bugs were found.
Re: Friendly: NoSQL With MySQL in Ruby
#3Even if NoSQL solutions are new, there are no data durability concerns in my opinion. I can talk for Redis but my guess is that's the same for the other datastores. In Redis to have full durability enable append-only-file: it's a text-only file, you can check by hand what's written inside your database. In addition even while running in append only file mode, you can still ask Redis to "BGSAVE" (crete a copy of the d…
Either way, durability wasn't the issue for us. Mongodb has no write concurrency. So, when it got so overloaded with data that queries were taking forever, we had no way to purge older data without blocking all read & write operations for hours.
Re: Friendly: NoSQL With MySQL in Ruby
#4Even if NoSQL solutions are new, there are no data durability concerns in my opinion. I can talk for Redis but my guess is that's the same for the other datastores. In Redis to have full durability enable append-only-file: it's a text-only file, you can check by hand what's written inside your database. In addition even while running in append only file mode, you can still ask Redis to "BGSAVE" (crete a copy of the d…
Actually, we do run redis in production, and it has been awesome for us. But, for this particular aspect of our application, we see about 20GB of data growth per week. So, an all-in-RAM db isn't really practical. Either way, durability wasn't the issue for us. Mongodb has no write concurrency. So, when it got so overloaded with data that queries were taking forever, we had no way to purge older data without blocking…
If MongoDB has no write concurrency MySQL is simply better from this point of view for your use case as far as I understand, but I'm not very good at MongoDB.
Btw Redis will get Virtual Memory in a few months, I hope you can reconsider it later ;)
Re: Friendly: NoSQL With MySQL in Ruby
#5Re: Friendly: NoSQL With MySQL in Ruby
#6This reminds me of Elephant, a CL OODBMS that can use Postgres as a key/value store backend. OODBs, document stores, et al. are useful but using a complete RDBMS as a backend is both overkill and inefficient in my opinion.
Re: Friendly: NoSQL With MySQL in Ruby
#7Now I just have to find a project where I'll need to use it!
Re: Friendly: NoSQL With MySQL in Ruby
#8A port anyone?
Re: Friendly: NoSQL With MySQL in Ruby
#9If only this was written in python... A port anyone?
Re: Friendly: NoSQL With MySQL in Ruby
#10Even if NoSQL solutions are new, there are no data durability concerns in my opinion. I can talk for Redis but my guess is that's the same for the other datastores. In Redis to have full durability enable append-only-file: it's a text-only file, you can check by hand what's written inside your database. In addition even while running in append only file mode, you can still ask Redis to "BGSAVE" (crete a copy of the d…
Actually, we do run redis in production, and it has been awesome for us. But, for this particular aspect of our application, we see about 20GB of data growth per week. So, an all-in-RAM db isn't really practical. Either way, durability wasn't the issue for us. Mongodb has no write concurrency. So, when it got so overloaded with data that queries were taking forever, we had no way to purge older data without blocking…