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 |
I don't want to sound like an advertisement, but just figured I'd chime in... I work at a VoltDB, a (relatively) new database company in Billerica. We have a high-performance OLTP database that supports a relational schema, SQL access to data, and is ACID. While it is not for everyone, it is worth checking out if you have, or predict, scalability challenges. We have a community (GPL3) and commercial license. Check it out at www.voltdb.com, or feel free to email me directly at tcallaghan-FEkO67Si+AaXj1p+fO2waQ at public.gmane.org -Tim On Tue, Dec 7, 2010 at 12:17 PM, Rich Braun <richb-RBmg6HWzfGThzJAekONQAQ at public.gmane.org> wrote: > As someone noted, big sites like Facebook started with hundreds or > thousands > of users, growing over time to reach 5 or 6 orders of magnitude bigger. If > you want to compete with one of those guys today, you have to start out > with > the capacity to handle a lot more than a few thousand. But meanwhile the > breadth and maturity of open-source tools available to tackle those > challenges > has grown by about the same exponential amount. > > With some savvy using APC cache, memcached, and MySQL query-caching, you > can > easily hit 100,000 queries per second on a single back-end server. With > replication and load-balancing, you can (by hiring a team of good systems > engineers) horizontally scale to even today's Facebook load (500 million+ > users) with the same software that comes on a stock Linux distro. > > Use the good stuff. Don't settle for hobbled software. Among the good > stuff > are the technologies mentioned above: APC, memcache, MySQL 5.1, the Linux > 2.6 > kernel, WordPress, Drupal, Confluence, etc. (There have been some debates > in > the past here on the BLU list between MySQL and PostgreSQL--I know MySQL > can > handle these high data read rates, and some very capable data-write > rates--will let others comment about the alternatives.) What makes these > technologies good is they've been put to the test over time and been > tightly > optimized to deliver exceedingly high transaction rates out of RAM, without > crashing. > > -rich > > > > _______________________________________________ > Discuss mailing list > Discuss-mNDKBlG2WHs at public.gmane.org > http://lists.blu.org/mailman/listinfo/discuss >
BLU is a member of BostonUserGroups | |
We also thank MIT for the use of their facilities. |