Building Web Reputation Systems- P22

Building Web Reputation Systems- P22:Today’s Web is the product of over a billion hands and minds. Around the clock andaround the globe, people are pumping out contributions small and large: full-lengthfeatures on Vimeo, video shorts on YouTube, comments on Blogger, discussions onYahoo! Groups, and tagged-and-titled Del.icio.us bookmarks. User-generated contentand robust crowd participation have become the hallmarks of Web 2.0.
Nội dung trích xuất từ tài liệu:
Building Web Reputation Systems- P22Dynamic: Reputation within social networksGiven the description of static, you might be tempted to select the dynamic requirementfor a framework because it provides the greatest range of reputation models possible.There is a serious cost to this option…it increases the cost of implementing, testing,and most importantly scaling your framework. Static reputations are easier to under-stand, implement, and test, and they scale better. Look at the history of Twitter.com’sFail Whale, a direct result of the requirement for a dynamic custom display of tweetsfor each and every user. Dynanism is costing them a fortune.When possible, find ways to simplify your model, either by adding more specific con-texts or by reducing dimensions through some clever math. This book won’t cover themany forms of dynamic systems in any depth, as many of the algorithms are well cov-ered in academic literature. See Appendix B for pointers to various documentarchives.Scale: Large Versus SmallScale—or the number of inputs (and the database writes they ultimately generate) andreputation claim value reads—is probably the most important factor when consideringany reputation system implementation.Small scale is any transaction rate such that a single instance of a database can handleall reputation-related reads and writes without becoming overloaded and fallingbehind.Large scale requires additional software services to support reading and storing repu-tation statements. At the point where your reputation system grows large enough torequire multiple databases (or distributing the processing of inputs to multiple ma-chines), then you probably need a distinct reputation framework. It becomes just toocomplicated for the high-level application to manage the reputation data model.At a low enough volume, say less than thousands of reads per minute and only hundredsof writes, it is easy to think that simple database API calls mixed directly into the ap-plication code as needed would be the best approach for speed of development. Whybother adding a layer to isolate the reputation system access to the database? Considerthat your application may not always stay small. What if it is a hit and suddenly youneed multiple databases or more reputation frameworks to process all the inputs? Thishas happened to more than a few web databases over the years, and on occasion—suchas when Ma.gnolia ended up losing all its users’ data—it can be fatal to the business.So, even for small-scale applications, we recommend a clean, modular boundary be-tween the application and the reputation system: all inputs should use a class or call alibrary that encapsulates the reputation process code and the database operations. Thatway, the calculations are centralized and the framework can be incrementally scaled.See the section “The Invisible Reputation Framework: Fast, Cheap, and Out of Con-trol” on page 287 for a specific example of this practice. Reputation Framework Requirements | 281Reliability: Transactional Versus Best-EffortReputation claims are often critical to the success of an application, commercial orotherwise. So it would seem to follow naturally that it should be a requirement that thevalue of the claims should be 100% reliable. This means that every input’s effect on thereputation model should be reflected in the calculations. There’s nothing more valuablethan the application’s contributions to the bottom line, right?There’s another reason you’d like reputation roll-ups to be reliable, especially whenusers provide the claims that are combined to create them: sometimes users abuse thesystem, and often this abuse comes in great volume if the scores have financial valueto the end users themselves. (See “eBay Seller Feedback Karma” on page 78.) If scoresare reliable and tracked on a transactional basis, the effects of the abuse can be reversed.If a user is determined to abuse the reputation system, often the correct action is toreverse all of his inputs on every target that he ever evaluated. This is the Undo anythingfeature and requires a reputation framework that is optimized to support reversibleinputs and a database that is indelible by source identifier only.So, if it’s good for business and it’s good for abuse mitigation, why shouldn’t myreputation system require transactional-style reliability throughout? The answer:performance.Every reversible input adds at least one additional database read-modify-write to storethe event. If the database is locked for each input, high-transaction rate systems cancreate a severe bottleneck waiting for resources to become available. Not only that, itat least doubles the size of the database and messaging network load, and dependingon the input-to-output ratio, may increase it by an order magnitude or more.For some applications, say Ra ...