Hacker News Reader

Comment by justinsb | Hacker News Reader

We're looking for early-adopter customers with hair-on-fire problems with their database that would also make good reference customers in a few months. If you fit the bill, please contact me!

Otherwise, sorry, but you'll just have to wait :-)

To put the effort into perspective: it's not a new DB from scratch - that would be a Herculean effort - just the lowest levels. It's not based on MySQL/Drizzle; it's based on a different open-source DB with a friendlier license and more hackable code. It's a new technique for scaling cross machines, which is refreshingly simple, which is why you're not seeing too many details :-) It's not just Oracle that knows how to scale databases, BTW; Greenplum, Netezza, Vertica etc. have all built distributed databases (admittedly for OLAP workloads) in relatively short timeframes.

View on HN

I'm quite interested in how you're handling joins in a manner that is scalable. What tradeoffs did you have to make? Do you support full join semantics, or are some types of joins not supported? Its not that much of a stretch to scale out an RDBMS not using any joins, but I can't bring myself to really take your claims seriously until you elaborate on how you handle joins (if at all).

I think that FathomDB's product is scalable to the degree that the existing database vendors are able to scale using multi-node clusters. Oracle's RAC tops out at 100 nodes. All of the other vendors (Teradata, Greenplum, etc) have some niche or secret sauce that allows them to scale vertical markets like OLAP. I don't see them scaling to Google or Facebook scale with an ACID-compliant relational database. They aren't really bringing anything new to the table other than a cheaper price point.

You bring up a very good point with the join issue. In addition, I'm wondering how they're going to scale writes. This is the bottleneck that eventually chokes RAC out, as it has to hold true to ACID principles. Even without ACID guarantees, eventually the system would spiral down into a chaotic quagmire of inconsistency as it scales. You've essentially got to have an locking and/or arbitration system that can quickly return an absolutely-positively we-wrote-this-in-a-consistent-way after a write query is executed. Nevermind trying to execute MVCC transactions over a cluster of nodes.

SQL can be scaled, ACID can't. Without ACID, the warm fuzzy feeling SQL gives you isn't quite as warm and fuzzy.

(admittedly for OLAP workloads)

Well, you say that as if the difference between OLAP and OLTP was a minor thing. As far as I know OLAP is usually done on column stores with quite different properties to your regular MVCC RDBMS.

But well, I am not a database engineer. So, at least that was a response, thanks. I'll be looking forward to what you can deliver.

a different open-source DB with a friendlier license

That would be postgresql?

Reply on news.ycombinator.com