5 ms·
It's an engineering decision - Flikr has to host a large amount of data for very little cost, since most users aren't paying. Space isn't cheap by the Petabyte!
by rtghnyhjm 16y ago
It's an engineering decision - Flikr has to host a large amount of data for very little cost, since most users aren't paying. Space isn't cheap by the Petabyte!
The design for a system where you had multiple redundant copies of all the data and could roll back any changes to the data set is different - and would cost a lot more.
- sdizdar 16y agoHere is what I don't understand. They have multiple redundant copies in case of unlikely scenario of disaster, but they have no copies or protection in case of quite likely scenario of operator error. This seems backward to me. EDIT: I don't believe that Yahoo! Flickr does not have a way to recover these things. Or I'm completely wrong.
- InclinedPlane 16y agoI think it's likely that Flickr has a way to recover the data but the front line support personnel don't, and they don't want to have some dev spend a few hours to fix a single customer's problem, even if it was Flickr's mistake.
- hrktb 16y agoReverting a full db should be straightforward (stop the db server and revert a dump). For a single account it's more of a pita. Retrieving all the datas associated with one account, put it in a format readable from the production environment and recommit all the changes while dealing with the potential errors and inconstencies seems quite a huge deal. Messing unrelated data in the process would also be a nightmare. Of course, not deleting anything from the start wouod be the way.
- gaius 16y agoIt's trivial in Oracle, just do a Flashback Query. You would just need to support that in whatever front end interface the customer support people use.