usecase: All content tagged as usecase in NoSQL databases and polyglot persistence
[…] at some point i got in need of some function to serialize forms into deep json objects so that i can push whatever the form has, directly to couchdb.
Displaying a photo submission form now requires a single lookup. The form is stored as a document in a top-level collection, and the set of custom fields become embedded documents within that.
Worldwide spam volumes this year are forecast to rise by 30% to 40% compared with 2009. Spam recently reached a record 92% of total email. Spammers have turned their attention to social media sites as well. In 2008, there were few Facebook phishing messages; Facebook is now the second most phished organization online. Even though Twitter has managed to recently bring its spam rate down to as low as 1%, the absolute volume of spam is still massive given its tens of millions of users. Dealing with spam introduces a number of Big Data challenges. The sheer size and scale of the data is enormous. In addition, spam in social media involves the need to understand very complex patterns of behavior as well as to identify new types of spam.
Make sure you check these 10 problems that can use Hadoop.
Mozilla has previously published about their detailed plan and extensive investigation into Cassandra, HBase, and Riak that led to choosing Riak. This time they are publishing some extensive Riak benchmark results (against both Riak 0.10 and Riak 0.11 running Bitcask) — they are using Riak benchmarking code, included in the list of correct NoSQL benchmarks and performance evaluations solutions. Both the results, their analysis , and interpretation are fascinating.
Our goal in running these studies was, simply put, no surprises. That meant we needed to run studies to that profiled:
- Stability, especially for long running tests
- Performance when we introduced variable object sizes
- Performance when we introduced pre-commit hooks to evaluate incoming data
I guess Mozilla Test Pilot is one of the Riak’s most interesting case studies.
Yesterday I read a post over at the EngineYard blog about a use case for Redis (in the name of being a polyglot, trying new things, etc.), and I just had to scratch my head. I love Redis — it rocks my world — but that example was too much for me. If you just want to store a set of ids somewhere to avoid normalization headaches, introducing Redis is overkill… just do it in MySQL!
He goes on and proposes a MySQL solution in which friends IDs are serialized as a comma separated list. Frankly speaking, I do see quite a few advantages Redis has compared to this one:
- Redis knows how to handle sets
- you don’t have to deal with de-duplication
- (most probably) the storage is optimized
- with manual serialization you’ll have to deal with all concurrency issues occurring when updating these lists
So what is the advantage of Ben’s suggested solution?