3 ms·
I should have clarified, I meant around 5GB per one type of data. Maybe a table or dataset that needs to be merged. For instance if you had a product database
by drawkbox 17y ago
I should have clarified, I meant around 5GB per one type of data. Maybe a table or dataset that needs to be merged. For instance if you had a product database table that needed to be joined with another GB large or set of data at runtime.
At that point, even in RDBMS you have to stop with the joins and flatten. I have experienced these limits in Oracle and MSSQL around 20-30 million row tables.
Scalable fundamentals like database flattening, dimensional modeling etc are all what key value stores give you from the start. But really a good mix works best or project specific, just saying in the future with TB, PB of data the JOIN is a historic remnant.
It is possible one day that RDBMS will be seen as one of those evil optimizations that we made in our small relative worlds at the time.
- gaius 17y agoI've tables much, much larger than that. It is possible one day that RDBMS will be seen as one of those evil optimizations that we made in our small relative worlds at the time. I doubt that for the simple reason that relational databases are maths: the relational algebra and relational calculus. There's no such theoretical underpinning to object databases.
- drawkbox 17y agoI doubt that for the simple reason that relational databases are maths: the relational algebra and relational calculus. There's no such theoretical underpinning to object databases. True, the relational architecture is moved to the object or code level, if you think about it in relation to size, it makes more sense there for the future. The RDBMS was the brain but it is also the storage, code will now dictate how to use the storage and not the storage itself, the storage is becoming a component.