Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

MagLev is a Gemstone object database server, it has nothing to do with this. When it's done, I'm sure the combo will be Nginx + Maglev instead of Nginx + (phusion passenger + mysql).

I've been playing with Gemstone and Seaside lately, it's freaking blazing fast and persistence is automatic, no mapping code at all. You put objects somewhere and they just stay there. No mapping at all beats the crap out of mappings + migrations.

Gemstone is going to make one hell of a web app platform. Especially since you can just add more boxes to the db cluster for scaling it. Only one server can write, but reads are distributed automatically across all servers in the cluster.



How do they make Gemstone so fast? They have to track every assignment to every persistent object, right? How does Gemstone handle data that doesn't fit in memory?


> How do they make Gemstone so fast?

Gemstone is like a smart memcached + relational db. They call it a shared page cache, but it's basically like memcached but not just a cache and with brains.

A transaction commits through the cache to disk and the same object format is used by every layer removing the need to constantly re-serialize. The client talks to the cache, the cache talks to the back end store when it decides it needs to page something in.

As for change tracking, I'm fairly certain there's a write barrier at the vm level, change anything and the barrier is broken causing the object to added to a commit list.

As for larger than memory queries, no different than a relational store, you work in batches paging in data as necessary. If you're talking about a single transaction that modifies more than will fit in ram, I have no idea, I've never had to do something like that.


There still is (and needs) the concept of migrations in Gemstone.


Not necessarily. You can migrate old instances of a class to the new version of a class, but unlike a relational database, you don't have to. Unlike a relational db, an object db allows storage of many different versions of the same class to be stored. It's up to the application to decided if it needs a particular version to run.

You could for example add a new instance variable and change the way something is calculated and as long as the public interface of the class doesn't change you don't have to migrate the old instances; the new calculation could apply from this date forward.


I know. What you say reinforces my point. There is (and it needs) to have the conception of migration. Nothing wrong. It is a necessity.

But it is an important point, because DB migration is always around, not something that happens magically.




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

Search: