In terms of hyper growth, Scalability Rules!

Discussions

News: In terms of hyper growth, Scalability Rules!

  1. In terms of hyper growth, Scalability Rules! (5 messages)

    Scalability Rules: 50 principles for scaling Web sites, by Martin Abbott and Michael Fisher, is a concise primer on the basics of building scalable Web applications that can accommodate incredible growth rates. Packed into a paperback about the size of a Stephen King novel are 50 simple rules for dealing with complicated systems. Abbot and Fisher's approach provides the quick, high-level overview that managers need, the depth that developers want and everything in between.

    When I first read the title, Scalability Rules, my mind tricked me into thinking it ended with an exclamation point (Scalability Rules!). While it's certainly true that scalable systems are pretty awesome, this book actually provides solid rules for building scalable systems. Abbott and Fisher have provided carefully worded explanations for  what the rules are, why they make sense, when to use each rule and how to go about applying it.

    Read more about Scalability Rules.

    Edited by: Cameron McKenzie on Sep 13, 2011 11:12 AM
  2. All these principles should be documented where possible. For example in Chapter 1 the book sentences that

    "select column from table"

    is far better then

    "select * from table"

    respect to scalability. Really? Which studies have been done regard this topic? Is this sentence the result of solid and scientific database knoledgement or simply a prejudice that the author thinks to be true?

  3. All these principles should be documented where possible. For example in Chapter 1 the book sentences that

    "select column from table"

    is far better then

    "select * from table"

    respect to scalability. Really? Which studies have been done regard this topic? Is this sentence the result of solid and scientific database knoledgement or simply a prejudice that the author thinks to be true?

    Hi Alberto,

    I'm pretty sure that the only data the authors were looking at when they wrote this book was their own experience building scalable websites and consulting with application developers about their scalability issues. They sure don't do a very good job of citing sources. However, I felt they did a very good job of explaining why they believe these rules hold true.

    For example, Rule 35 (which appears in Chapter 8) is "Don't select everything." This is where they say it's better to define specific columns than to use "SELECT *". They give two main reasons. One is that they saw "SELECT *" contributing to data mapping problems in projects where multiple developers are maintaining the application over time. The more obvious reason is that "SELECT *" tends to bring in a fair amount of extraneous data each time the query is run. This extra data transfer can create significant performance issues when it happens at great volumes. When you're dealing with millions of users, these small things can add up quickly.

    I think the concepts behind this rule - and most of the others in the book - were well defined and hold up to scrutiny.

  4. I can also speculate that with "select *" one would have to get row values by name, which might involve overhead for getting result set metadata. In contrast, with "select " one can safely get row values by index.

    As a side not, the "Chapter one" link in the article in fact references the safaribooksonline version of the whole book, with some parts are hidden/unavailable. Yet there is a lot of reading beyond chapter 1 that I enjoyed.

  5. But many of us is using some ORM tool. When your queries are generated by an ORM you completely solve the first issue: the mapping is done at class level.

    The second issue, instead, could be true. I don't think it's true repect to single query performance: I am not a DB expert, but I believe that DBMS work at row level. If you require the whole row instead of some column they are probably faster like a computer is faster on retuning a byte instead of some bits.

    Anyway I understand then if you send more data throught a network you  are taking more risk about scaling. I still believe that authors should give a proof here.

  6. Missing Scalability Rule[ Go to top ]

    Looks like one rule is missing : don't use ORM tools. 

     

    ;)