what is the status of FameDB

On 22 jan 2011, at 11:10, Mariano Martinez Peck wrote:
> On Fri, Jan 21, 2011 at 5:12 PM, Tudor Girba <[hidden email]> wrote:
> Just a question: Would the new slate disks not alleviate the problem of the disk speed?
>
> For Gemstone, Hernan Wilkinson did some test 1 o 2 years ago, and the difference was....mmmm I dont remember, but I think 40x faster. All the Gemstone migrations and I don't remember what more, was done with that HDD. So, yes, at least in Gemstone it changes a lot.

Latency for reading is 65-75 microseconds. That is a lot better than hard disks. For writing the situation is different. There  SSDs can be comparable to a HD (up to a few times faster) when having to clear a page. You'll only notice this after all pages of the SSD have been written. Before that, performance will be spectacular. Documentation on real (long term) write performance of SSDs is hard to get/interpret.

http://www.slideshare.net/matsunobu/ssd-deployment-strategies-for-mysql

And of course SSDs are still more than 100 times slower than ram.

Stephan



_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev

On 21.01.2011, at 17:12, Tudor Girba wrote:

> Just a question: Would the new slate disks not alleviate the problem of the disk speed?

It is hard to tell. Usually you can assume that an OODB is more partitioned (data wise) than a relational database. This leads to more seeks on a hard drive. SSDs being much faster in doing seeks than normal hard drives may speed up a databases like gemstone a lot. Taking gemstone this is only one of the important factors.
All object reads go through a shared page cache. This is the biggest performance gaining factor. If you can have a huge shared page cache where your model fits into a large extent than this will be really fast. The more your active object memory doesn't fit into the more disk performance gets important.

Norbert


_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev

On 24 jan 2011, at 23:47, Norbert Hartl wrote:

> It is hard to tell. Usually you can assume that an OODB is more partitioned (data wise) than a relational database. This leads to more seeks on a hard drive.

Not when using an OO model and following the navigation. Objects that are created together are close together. A simple example: An order has orderlines. In an OODB you would expect the orderlines to be on the same (or next) page on disk. With a RDBMS, you need to access two tables, and have two seeks. A full table scan over orders though is of course slower with an OODB, as more pages need to be loaded.

Stephan
_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev

On 28.01.2011, at 11:56, Stephan Eggermont wrote:

>
> On 24 jan 2011, at 23:47, Norbert Hartl wrote:
>
>> It is hard to tell. Usually you can assume that an OODB is more partitioned (data wise) than a relational database. This leads to more seeks on a hard drive.
>
> Not when using an OO model and following the navigation. Objects that are created together are close together. A simple example: An order has orderlines. In an OODB you would expect the orderlines to be on the same (or next) page on disk. With a RDBMS, you need to access two tables, and have two seeks. A full table scan over orders though is of course slower with an OODB, as more pages need to be loaded.
>
I don't know if we are talking about the same. You are saying "two seeks". You mean database "seeks"? I meant hard disk seeks which are probably a few hundreds when doing a query like you stated above. I think your example is a bit misleading because it is IMHO oversimplified and combines with assumptions I cannot share.

Can you give evidence for what you are stating? I think you cannot assume that objects created together (time wise) are written together. That seems only be valid if you name a certain database technology name. That would be the case if you just add objects and claim new pages if your current one is full. Furthermore I think there is a big distinction between objects that are created together and objects that are used together. The latter one being much more important.
In the RDBMSses I know the index and the data is stored in a format that needs less overhead if you query a lot of objects of the same kind. So the load of an RDBMs can be anticipated by a query whereas that it is seldom the case for an OODB. It is exactly like you said. You follow the navigation but then you have to be sure that the data is constructed that way. Saying it would be rather easy to know you have to fetch 3 rows from one page in an RDBMS environment. In an OODB you only know it at the end. Without caching you could read the same page three times. And here gemstone does a create job having a shared page cache that makes this a non-issue.


Norbert
_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev