jsr

The wired version of this device was in human trials ~10 years ago through cyberkinetics, a startup spun out of brown to commercialize the technology. See NYT article from 2004 talking about the start of their clinical trials: http://www.nytimes.com/2004/04/13/health/13BRAI.html

looks like your site is down?

This is not new technology. A company called cyberkinetics commercialized this 12 years ago and made it work in humans. See their coverage in wired from 2003.

http://www.wired.com/wired/archive/13.03/brain.html

Definitely an impressive benchmark by any standard. However, there are some things to be aware of:

1) They used Infiniband interconnects. Running on ethernet is likely to yield less impressive results.

2) Their benchmark does simple primary key lookups. If you start doing joins or transactions that need to hit multiple data nodes, things will slow down. Depending on your workload, this may or may not be an issue.

3) NDB is an in-memory storage engine, so you're limited to the aggregate RAM in your cluster for max storage size.

4) AFAIK, MySQL Cluster doesn't re-balance, you need to pre-determine how data is partitioned and changing it at runtime is hard. I don't know if this has changed in the later releases.

California, New York and London - Multiple positions INTERN, REMOTE, H1B welcome

10gen is the primary sponsor of the MongoDB open source database. We're hiring rapidly in all roles and we'd love to hire you!

Current list of openings here: http://jobvite.com/m?3dFtbfwg

How scalable is this? Are there capacity or transaction rate limits on Cloud SQL?

Amazing that this post hits HN the same day Oracle announces "Oracle NoSQL Database" ... http://www.oracle.com/technetwork/database/nosqldb/overview/...

OK, you hooked me with the title. But "FreeBSD + Erlang" was kind of a dissatisfying reason for how you achieved it. Would love to hear more details! How far we've come since http://www.kegel.com/c10k.html

Well put. Many of the same reasons I joined 10gen and am very happy to work with Nosh ;)

It's useful to differentiate between "SQL Databases do not scale" and "SQL Databases do not _cost effectively_ scale". The second argument is more accurate.

Vertical scaling of a DB is definitely an option for many people and has been used to scale many applications. However, the cost curve associated with buying bigger and bigger hardware is super-linear; doubling CPU & Memory in a single system leads to more than doubling the hardware cost. This can be problematic for many businesses whose revenue growth is exceeded by cost growth of the database.

Sharding is also an option for scaling, leveraged to great success by Facebook, Yahoo, and many others. However as the article points out, sharding prevents the developer from using many of the features that make a relational database a productive development environment. There are lots of foot guns that emerge in a sharded SQL environment and if you have not set up your development constraints appropriately, you can slow the pace of development considerably. This again leads to a cost problem because the incremental costs of adding features grows as you add more things like sharding around your database.

SQL is not useless and not hopeless. In a large number of cases, SQL is the right solution. However the techniques used to scale SQL tend to be options only to very large budget organisations. NoSQL solutions tend to be more cost effective in their scaling approach (scale out vs. scale up) without crippling the developers productivity. For these reasons, NoSQL solutions tend to be the better choice for the cost-conscious.