Hacker News new | past | comments | ask | show | jobs | submit login

I'll bite. There is nothing in the design of relational databases that specifies that a record must be fixed length. Most good dbs don't do this at all, simply using something akin to:

Each row in your db has:

row size: row data

for each column:

cell size, cell data

In multi-value databases, which the cassandra supercolumn seems to be mimicing somewhat, your cell data can contain more cells again, and can support huge hierarchies. I like the design of these systems that keeps the relational model, but stores all related data in two places, which dramatically increases speed as you are reading related data off the same disk block. Typically this means huge performance gains as you read in large blocks (kb) off disk as it is.

In my opinion, having written a few multi dimensional indexing systems and db's from scratch (including a multi value db), there is little preventing a relational database becoming the best of both worlds. What do you think about the relational model makes it so "impossible" to scale?

I tend to think it's simply legacy code. Has anyone created a relational database with the goal of horizontal scalability from the outset?




> What do you think about the relational model makes it so "impossible" to scale?

ACID and the CAP theorem.


My point is that a better designed database, specifically for scalability may alter the point at which CAP becomes relevant for all but the largest problems. E.g. custom indexing, partitioning & caching algorithms.

We see this with vertical-specific databases, having 1-3 orders of magnitude performance advantage over traditional dbs.




Consider applying for YC's Spring batch! Applications are open till Feb 11.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: