Page 2 of 2 FirstFirst 12
Results 11 to 14 of 14

Thread: STSdb.MTL "DataBreezing"

  1. #11

    Default

    Quote Originally Posted by blaze View Post
    I don't know on which stage is STSdb W4, but I would appreciate if STSdb.MTL could be integrated into it.
    Blaze, in STSDB W4 will be native multi threading level, so I don't see any reason to include MTL there. But in STSDB R3.5 would be good to have MTL included.
    Last edited by k.dimova; 13.06.2013 at 16:13.

  2. #12

    Default

    Quote Originally Posted by saulius_net View Post
    Blaze, in STSDB 4 will be native multi threading level, so I don't see any reason to include MTL there. But in STSDB 3.5 would be good to have MTL included.
    Never mind, it was only a proposal.

    Nevertheless, fixed some async issues in MTL, it looks stable in different long running tests, together with compactor. Compactor is a tender stuff, must be correctly or, better to say, dynamically adjusted, will work on it.

    MTL is interesting in the point that you can have 1 reading thread, which can take 20 minutes to read values from the table (it's a really brutal example). During these 20 minutes, 10 other threads can write in the same table (thread number 1 goes on to read), also during these 20 minutes 5 other threads were open for reading.
    Every of the reading threads must have its own evolution history, they don't see changes made by other threads. Who must remember all these states? Not memory cache, but the disk based tree itself , the tree becomes bigger holding all commits evolutions. Today it works like this and it's beautiful. In 20 minutes, we can say that we have lot's of wasted space, born by the middle commit statements. Nobody is interested any more in the information which was held by thread 1. Plus the fact how the tree holds the information and create commits also can bear some wasted space (in 3.5).

    We need compaction in any case and this compaction must be bound to the multi-threading. Will all functionality work in ver. 4 (and for me specially is interesting how)? Will version 4 work under Framework 3.5?

    If to run compactor in a hard mode, you can see that VFS is trying to find free secors from deleted raw files, release them and it also takes memory resources, so many caviats, the same we have to wait from the automatic defragmentation, how this all will be adjusted?

    If the project is really open-source then steps, ideas and discussions should also be open source and guys with the brilliant mind like Mr.Todorov and colleagues could teach us from their work.
    Last edited by blaze; 12.02.2012 at 23:34.

  3. #13

    Default

    Quote Originally Posted by blaze View Post
    We need compaction in any case and this compaction must be bound to the multi-threading. Will all functionality work in ver. 4 (and for me specially is interesting how)?
    It would be good receive some version4 architecture descriptions. How data storage structure was changed in general? How wasting space problem was solved? How native MTL in new version will work? Maybe Mr. Todorov can write detail post about that? Thanks in advance!

    Quote Originally Posted by blaze View Post
    Will version 4 work under Framework 3.5?
    Do you see any problems that STSDB W4 (maybe) will be only .NET4 compatible?
    Last edited by k.dimova; 13.06.2013 at 16:14.

  4. #14

    Default

    For those who still likes R3.5

    Finally balanced, MTL+Auto Tables Compactor, even in "hard" tests no memory growing and async issues. VFS and FS.GC work stable and good - I am amazed.

    STSdb Multi-Threading Layer C#

    Holds the rate up to 250 bytes per record (record itself byte[150], key long).

    We need a patch for the search-tree for version R3.5.
    Last edited by k.dimova; 13.06.2013 at 16:18.

Tags for this Thread

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  
2002 - 2014 STS Soft SC. All Rights reserved.
STSdb, Waterfall Tree and WTree are registered trademarks of STS Soft SC.