4 ms·
This doesn't answer the question - you described /how/ you solved some problem, not what problem you're actually solving. (Mind you, at my writing this is the
by srl 13y ago
This doesn't answer the question - you described /how/ you solved some problem, not what problem you're actually solving.
(Mind you, at my writing this is the top comment, so I don't think you're getting many downvotes. But your comment irked me, so there you go.)
- res0nat0r 13y ago> not what problem you're actually solving. > targetting expressions over billions of time series events from users.
- collyw 13y agoYou moved back to MySQL. What was the motivation to move to Map Reduce in the first place if a well understood technology, MySQL, works fine? (sorry if I am posting a lot on this topic. I am really interested in finding answers rather than trying to prove any point that relational databases are better in case anyone thinks otherwise).
- willvarfar 13y ago(Poster) we moved from mysql+innodb/myisam to hadoop because of performance problems. We did test and evaluate hadoop, and then jumped. Then tokudb comes along (technically we moved back to mariadb) and puts performance advantage firmly back on mysql's side. I imagine impala and presto and any other column based, non-map-reduce engines would give tokudb a fairer fight though.
- _random_ 13y agoHearing to what problems a technology failed to solve is usually even more interesting. It cuts the hype.
- kamakazizuru 13y agosure - but that's not the original question. Maybe the OP is just curious to understand some in production use cases (and the approach to their implementation) - and isn't that interested to know the edge cases where it doesn't work.
- _random_ 13y agoMaybe his case is an edge case.
- kamakazizuru 13y agoright - but then he would've framed the question as "what are the cases where mapreduce really doesn't make sense".
- pwang 13y ago> run targetting expressions over billions of time series events from users.