Boston Linux & Unix (BLU) Home | Calendar | Mail Lists | List Archives | Desktop SIG | Hardware Hacking SIG
Wiki | Flickr | PicasaWeb | Video | Maps & Directions | Installfests | Keysignings
Linux Cafe | Meeting Notes | Blog | Linux Links | Bling | About BLU

BLU Discuss list archive


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

NoSQL vs SQL



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
BLU is a member of BostonUserGroups
We also thank MIT for the use of their facilities.

Valid HTML 4.01! Valid CSS!



Boston Linux & Unix / webmaster@blu.org