Blabla

Enterprise Rails
by Dan Chak

Draft for Preview Only. Copyright ©2008 O’Reilly Media Inc.

Enterprise Rails
by Dan Chak
Table of Contents
1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 15. 16. 17. 18. 19. 20. 21. Introduction Big picture Organizing an Application Organizing with Plug-ins Organizing with Modules Database as a Fortress Building a Solid Data Model Refactoring to Third NormalForm Dealing with Domain Data Composite Keys and Domain Key / Normal Form (DK/NF) Guaranteeing Complex Relationships with Triggers Multiple Table Inheritance (MTI) View-backed Models Preview Chapter Service Oriented Architecture (SOA) Primer SOA Considerations REST Primer An XML-RPC Service Refactoring to Services A REST Web-service End-to-end Caching

14. Materialized Views

Draft for PreviewOnly. Copyright ©2008 O’Reilly Media Inc.

14
Materialized Views

When you aren’t caching anything, every page load incurs the penalty of the queries required to make up that page. Initially, when you don’t have much data, and you don’t have many users requesting pages, your application will be snappy. Unfortunately, with any amount of success, you eventually get hit with three problemsseemingly all at once: 1. 2. 3. Your application becomes popular and the traffic you need to handle has grown by orders of magnitude. As you sign new customers, gather data, and even simply exist, the amount of data in your database grows by orders of magnitude. Your application grows in complexity and more queries are required to render any given page.

Although most people would be envious of theseproblems (and the business side of your company would term them “successes”), you nonetheless have to deal with them. Caching – the act of saving some queried or calculated result for future use – is not as simple and clear-cut as it sounds. A number of subtle issues surround correct caching, which go beyond picking a cache key and storing data in the cache behind that key. The first issue is offreshness. Can your cache lag behind the true values of your data, or does it need to reflect the latest values? Next is correctness. If your goal is to keep the cache up to date, have you accounted for every situation where your cache needs to be invalidated or rebuilt? How do you know you’ve hit all of these cases? Finally is the cost amortization of keeping the cache accurate. The purpose ofcaching is to reduce database load and to speed up requests, but someone still must has pay the price for cache updates. Either the requestor who invalidates the cache, or the next person to request the invalidated items will pay part or all of the cost. Choosing the wrong strategy for rebuilding can erase all of the gains that caching was meant to achieve in the first place.

1
Draft for PreviewOnly. Copyright ©2008 O’Reilly Media Inc.

In Chapter 13, we saw that a database view can be thought of as a named query. Even though a complex query can be hidden behind a simple view name, whenever you select from that view, you pay the price of database joins, subselects, filters, and functions that may be required to calculate the view results. A materialized view is a cachedrepresentation of a database view, stored in a regular table. Rather than query from the view with arbitrary complexity, with view materialization, an indexed table can be queried instead, with O(1) response time. Chapter 21 contains an overview of caching at all layers of the application. In this chapter, we’ll look in depth at caching at a single layer where we have already gained some experience: thedatabase. The principles we will encounter at this layer are the same as those present at other layers of the application, but the database is the layer with the best tools for guaranteeing cache correctness. It is also the most mature and stable layer, so what you learn in this chapter can be applied to other caching problems for years to come, even as feature sets and APIs change for application...