On 10/3/07, Orlando Andico <[EMAIL PROTECTED]> wrote: > I've had a look at Coda and GFS2. > > Although far superior to NFS, these are still file-based. I don't see > this kind of solution scaling to million-transaction-per-second range > anytime soon. >
oh no. of course not. but i cant rely on on one machine to handle all that. i would split my "tables" long before i reach that threshold. i actually prefer a memory bound database at this rates and rely on redundancy for the reliability. making disk arrays work fast enough is too complicated even if its going to be a log structured one. but yes i have been thinking of doing a memory bound database with a log structured filesystem as a rebuild log. > > > Most people use a centralized backing DB to store the session state. > > > What if that one goes south? > > > > > > > i dont do that but they are screwed. > > You'd be surprised how many people do that. Most people, actually. > True. some of the open source mailing lists have their archives due to db and hard disk crashes. one had their servers sit in their basement floor. then the dog peed on it. maybe the dog has been wondering who is that dog that blink rapidly now and then and spewing hot air in the basement for the past year. > > Like I said, file based. Ewww. > Come on its not that bad. Its not like dos you know. I use JFS on almost all my machines now and its really good all around. > I'd like to correct an impression you might have. > > I am perfectly happy with commodity hardware. The HP DL585 for example > or IBM BladeCenter HS21 are pretty nice hardware for the buck, and > they don't cost too much. > > I don't believe in "big IBM pSeries" or "big Sun Enterprise" either. > But unless your software stack is hardware fault-tolerant, many > enterprises would still rather have the big iron with hardware > resiliency. > I see ok. I think I revise my definition of commodity hardware to include those. They actually are commodity machines. > > .. > > Of course. The guys who needs these implementations the most are the > > ones with a lot of cash. But its a matter of preferences. DB based > > applications specially those based on sql need lots of resources. > > Those who prefer non db based REST style applications can do the same > > with cheap commodity hardware. in terms of number of transactions per > > second and reliability. > > Well, the solution follows the customer. Most customers are still in a > DB-centric world. > > What use is your innovative lightweight transaction solution if nobody > uses it? I do not think you can say that your solution is truly > resilient and useful unless it's been used in a very high load > environment for a long time. > True. Well its been running for almost 4 years already but i really want that memory bound db. > > oh no. you need the multi processor server to see the benefits anyway. > > why not use commodity hardware then? they are so cheap nowadays. > > Commodity 4-way and 8-way processors exist. See above (HP DL585, > SunFire X4600). But the 8-way costs a lot more than the 4-way. > > So if I need 20 boxes, I'd rather buy one Intel Compiler license and > 20 4-way boxes, than have to buy 20 8-way boxes to make up for the > performance shortfall of using GCC. > Is it really that bad? I just upgraded to gcc 4.1.2 and im going to look for comparative tests. I was thinking more of ordinary machines you buy from pcx. hehe > > > 2) NFS! locking issues galore! horrific file lock timeouts! I can't > > > imagine this scaling up well > > > > true. i used coda instead. > > > Like I said. It's still file-based. No harm in that, many ostensibly > enterprise products are still file-based. But not as elegant as say, a > memory grid solution. Which is what Memcached is.. > Well memory is cheap nowadays. > > > I guess if you don't have that huge a revenue, you can tolerate > > > outages and less-than-enterprise class software. > > > > Not really. We have a small revenue but we cant tolerate outages. My > > boss even wanted our data to survive a nuclear strike in manila or > > amsterdam. > > > Ok, let me change that. Huge revenue OR huge transaction rate. > > It's not rocket science to build a fault-tolerant, modest-sized app. > Building a fault-tolerant app that scales WELL (say... hundred- or > thousand-server clusters), now THAT'S rocket science. There are > open-source tools for this (PVM, MPI) but they are more geared to > compute grids, which traditionally are not transactional, generally > not 24x7 available, and can tolerate hardware failure. Thats an interesting problem... -- Lay low and nourish in obscurity _________________________________________________ Philippine Linux Users' Group (PLUG) Mailing List [email protected] (#PLUG @ irc.free.net.ph) Read the Guidelines: http://linux.org.ph/lists Searchable Archives: http://archives.free.net.ph
