tailieunhanh - 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 and around the globe, people are pumping out contributions small and large: full-length features on Vimeo, video shorts on YouTube, comments on Blogger, discussions on Yahoo! Groups, and tagged-and-titled bookmarks. User-generated content and robust crowd participation have become the hallmarks of Web . | Dynamic Reputation within social networks Given the description of static you might be tempted to select the dynamic requirement for a framework because it provides the greatest range of reputation models possible. There is a serious cost to this increases the cost of implementing testing and most importantly scaling your framework. Static reputations are easier to understand implement and test and they scale better. Look at the history of s Fail Whale a direct result of the requirement for a dynamic custom display of tweets for each and every user. Dynanism is costing them a fortune. When possible find ways to simplify your model either by adding more specific contexts or by reducing dimensions through some clever math. This book won t cover the many forms of dynamic systems in any depth as many of the algorithms are well covered in academic literature. See Appendix B for pointers to various document archives. Scale Large Versus Small Scale or the number of inputs and the database writes they ultimately generate and reputation claim value reads is probably the most important factor when considering any reputation system implementation. Small scale is any transaction rate such that a single instance of a database can handle all reputation-related reads and writes without becoming overloaded and falling behind. Large scale requires additional software services to support reading and storing reputation statements. At the point where your reputation system grows large enough to require multiple databases or distributing the processing of inputs to multiple machines then you probably need a distinct reputation framework. It becomes just too complicated 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 hundreds of writes it is easy to think that simple database API calls mixed directly into the application code as needed would be the best approach for .