directmemory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jan Kotek <>
Subject Re: MapDB
Date Sat, 10 Nov 2012 17:07:55 GMT

you are right.
Performance difference between inMemory and onDisk store is only 50% if 
data fits into memory.
MapDB does not use page buffer like most databases. It leaves page 
caching on OS.

instead MapDB has instance cache for already deserialized objects.


On 10/11/12 15:36, Julien Vermillard wrote:
> Hi, just a small comment.
> As mapDB use memory mapped files (mmap) using it for offloading memory to
> disk is probably not a performing idea since the O/S will already cache the
> file in memory the file for you :
> You will basicly have two memoery cache and the O/S will beat the
> directmemory one.
> My 2 cents,
> Julien
> On Wed, Nov 7, 2012 at 8:54 AM, Raffaele P. Guidi <
>> wrote:
>> Hi and thanks for your interest and offer! I know and appreciate your
>> project and made plans to integrate it as disk store since the early days.
>> We sure need good serialization libraries, in fact, in addition to provide
>> support for many different ones (kryo, msgpack, protostuff, etc) we
>> recently welcomed lightning (an unsafe based serializer by Christophe
>> Engelbert) as a subproject to complement our codebase with a fast (and
>> in-house) choice.
>> I think we have more than one reason to integrate and share code:
>>     1. DirectMemory could make good use of mapdb to serialize least
>>     frequently used items to disk and free memory
>>     2. DirectMemory could implement a MapDB disk based store in addition to
>>     the bytebuffer and unsafe ones
>>     3. MapDB could take advantage of DM's componentization approach to
>>     support multiple serializers (we believe each one has its advantages in
>>     different scenarios)
>>     4. MapDB could use DM to write items to an off-heap before writing to
>>     disk (asynchronously) to improve speed
>>     5. We could merge our serialization efforts (I believe lightning is very
>>     fast and worth to be considered) and provide an even better solution or
>> two
>>     alternative implementations
>> In both cases we would be open to contribution in different forms - just
>> contributing patches or with you to join us and the ASF as module or
>> subproject (the latter options have to undergo a formal vote by all project
>> members, of course) as I strongly believe that merging efforts would bring
>> to a better and more complete product.
>> What do you think about it?
>> Regards,
>>      Raffaele

View raw message