Home
| Calendar
| Mail Lists
| List Archives
| Desktop SIG
| Hardware Hacking SIG
Wiki | Flickr | PicasaWeb | Video | Maps & Directions | Installfests | Keysignings Linux Cafe | Meeting Notes | Linux Links | Bling | About BLU |
On 08/29/2010 02:42 PM, Dan Ritter wrote: > On Sun, Aug 29, 2010 at 08:34:44AM -0400, Mark Woodward wrote: > >>> You must be able to run this on many machines with a load balancer. >>> >>> >> These days? You'd be surprised at the capacity of $600 worth of computer >> supplies. Its enough to run all but the very big sites. >> > I wouldn't be surprised at all. Now, after you've got it up and > running... what do you do for maintenance? Both software and > hardware. What do you do when you get slashdotted, or the moral > equivalent of same? What do you when the power supply fails? OK, > you spent the money for dual power supplies. What do you do when > the motherboard fails? > Seriously, think about a solution I just deployed. Its kind of kool. Two cheap computers, both well able to keep up with being "slash-dotted." A direct wire between the two of them for replication and synchronization. Full fail-over with a load balancer. (assuming the load balancer doesn't fail). In almost 20 years of doing this stuff, I've never seen a reasonable quality computer that wasn't over clocked fail after a 30 day burn in under two years. I've seen hard disks go, but they usually give you a sector error here and there in the dmesg log well before real failure. Infant mortality is the killer, after that, the systems usually run until obsolete. I have a site currently in service with vintage 1999 dual SMP motherboards and power supplies. I've only replaced the disks and blown out the fans every two or three years. There is a serious value discussion that should take place that a lot of companies never consider. Full redundancy is expensive, it can be difficult to maintain, and like a fire extinguisher, its hard to know if it will work when you need it. If you will lose value (based on a worst case failure/repair time cycle) that exceeds the cost of a redundant system, then you have to deal with that. Otherwise, it isn't even a real problem in a business sense. Then you have to look at the probability of failure, what the likely failures will be and what steps you can take to mitigate the problems. A "hot spare" and a rolling backup, will probably keep your down time to less than an hour if you or your IT guys keep near an internet connection. > >> Funny, but "stored procedures" are probably the best way to implement a >> lot of functionality. They are "pre-compiled" by the databases, are >> faster than raw queries, and can be modified without touching the web >> code. My advice is to avoid databases that don't have such features. I >> could start my "don't even think about using MySQL rant." >> > Some sites can't support the license fees for Oracle or DB2. > I would say most, but I basically agree. > That leaves MySQL and Postgres, for SQL databases, and a whole > host of non-SQL systems of various sorts. No matter what you > start with, you may want to change it later on. Stored > procedures will make that a nasty pain. > Only if you want to switch databases mid-stream, and no database will be without problems. It is virtually impossible to go from MySQL to a real database without re-writing tables and writing a data reformatter to take MySQL database extracts and load them into something else. Some NoSQL to SQL or some other system, isn't going to be pretty. I usually go postgresql. If you need Oracle clustering, then that's what you need, but postgres does just fine. > Oh, and "modify the stored procedures without touching the web > code" is completely backwards. Your web code is going to be > changing all the time, because that's what people see and touch > and is where they make change requests. If you've got stored > procedures, you're going to have to change them to support the > new web code, all the time. If you must use them, minimize them. > See, I think this approach is somewhat backwards. Where possible, the DBA and the database should provide as much "service" to the web code. For instance: select shopping_cart_contents($cart); The function will return the contents of a cutomers shopping cart. Now, the whole implementation of shopping cart can change without affecting the web design. I have actually done this and changed the whole shopping cart system out from under the app and had it work without any problems. It is a well understood practice to isolate "knowledge of data structure" from the use of the data. Its just another API. > -dsr- > >
BLU is a member of BostonUserGroups | |
We also thank MIT for the use of their facilities. |