Database options was (Re: My first Magma experience ...)

Avi Bryant avi.bryant at gmail.com
Tue Apr 5 14:25:18 UTC 2005


On Apr 5, 2005 4:08 PM, Daniel Salama <dsalama at user.net> wrote:
> I modified the free OmniBase to ignore the file locking in Linux for
> the time being. Then I tried running the same benchmark I ran against
> Magma and GOODS. I had a difficult time with OmniBase, I guess grasping
> the concept of everything needing to be in a transaction, so I don't
> know if my code is right.

Daniel, did you read the OmniBase documentation?  One of the things it
mentions is #makePersistent - you have to send that to each object
that you want it to address individually (have an object id, etc). 
That object, and any it points to that haven't themselves been sent
#makePersistent, are all written out as one big blob (I think he calls
it a "cluster") to the database.  Any time anything in that cluster
changes, you have to send #markDirty to the root object and the whole
cluster will get written out again.

In your code below, I don't see a single send to #makePersistent. 
That means that your entire dataset is one huge binary blob in the
database, and on every commit you're writing the *whole thing* out to
the database.  It's no wonder it's not very fast.

So the first step would be to make the individual objects persistent. 
But even then, you've still got one massive OrderedCollection object
that contains them.  As in GOODS or Magma, you'll see much better
performance if you use a more appropriate data structure.  Since I
believe you said that all you ever need to do is append to the end and
iterate, some kind of linked list (one which has O(1) append time)
would be the best choice.

> Can anyone tell me if this code would work
> with OmniBase:
> 
>         time := Time millisecondsToRun:
>                 [[db := OmniBase openOn: 'Macintosh HD:Users:dsalama:OB'.
> 
>                 [OmniBase root at: 'FHKC834' put: (OrderedCollection new)]
>                         evaluateAndCommitIn: db newTransaction.
> 
>                 [head := FHKC834Header new.
>                 head controlNumber: (self ediData controlNumber).
>                 head referenceNumber: (self ediData referenceNumber).
>                 head date: (self ediData date).
>                 head time: (self ediData time).
>                 head members: (OrderedCollection new).
> 
>                 theBase := OmniBase root at: 'FHKC834'.
>                 theBase add: ediData.
>                 theBase markDirty]
>                         evaluateAndCommitIn: db newTransaction.
> 
>                 numCommits := 0.
>                 Transcript cr.
> 
>                 1 to: (((ediData members) size) / 100 asFloat) ceiling do:
>                         [:lp |
>                         txn := db newTransaction.
>                         theBase := txn root at: 'FHKC834'.
>                         head := theBase first.
> 
>                         1 to: 100 do:
>                                 [:i |
>                                 (self ediData members at: (lp - 1 * 100 + i)) notNil
>                                         ifTrue: [(head members) add: (self ediData members at: i)]].
>                         txn commit.
>                         numCommits := numCommits + 1.
>                         txn abort.
>                         Transcript show: '.']] ensure: [db close]].
>          db close.
> 
>         Transcript cr; show: (time/1000) asFloat; show: ' seconds to load into
> GOODS in ';
>                 show: numCommits; show: ' commit(s)'.
> 
> It's supposed to commit every 100th element of the members attribute.
> The reason I post this message is because it's been running for over 3
> hours and it hasn't finished. I find it hard to believe that OmniBase
> would take this long.
> 
> Thanks,
> Daniel
> 
> On Apr 4, 2005, at 12:27 PM, Avi Bryant wrote:
> 
> > On Apr 4, 2005 5:41 PM, Daniel Salama <dsalama at user.net> wrote:
> >> My understanding from David is that the commercial license does not
> >> have Linux file locking support. I'd be willing to buy a commercial
> >> license immediately if I knew the support for Linux was there.
> >
> > The second you have a commercial license, I can send you:
> >
> > - An up to date version of OmniBase (commercial) with the linux file
> > locking merged in
> > - The version of OSProcess it depends on
> > - A tarball of the unix VM source modified to work properly with
> > OmniBase
> > - A prebuilt VM for Mac OS X with the above modifications (if that's
> > useful)
> >
> > However, please do note that you can do a huge amount of evaluation,
> > testing and development *without* the locking support and *without*
> > using the commercial version... both of those are only things you
> > would really need for a deployment scenario.
> >
> > Avi
> 
>



More information about the Squeak-dev mailing list