Ok, de eerste vraag op dit forum:
Ik heb een db4o database gemaakt met 2 objecten: Person & Child.De Person heeft als een van de eigenschappen: Child.
Dus bijvoorbeeld:
c = new Child("Child", 12); p = new Person("Person", 40, c); db.Set(p);
Het numerieke veld hierboven van Person en Child is _age, dus indexen zien er als volgt uit:
IConfiguration conf = Db4oFactory.Configure(); conf.ObjectClass(typeof(Person)).ObjectField("_age").Indexed(true); conf.ObjectClass(typeof(Child)).ObjectField("_age").Indexed(true); db = Db4oFactory.OpenFile(conf, "test.odb");
Wat ik nu wil:Zoeken op de leeftijd van een Child en daarvan de Person (de 'parent') teruggeven als volgt:
IQuery query = db.Query(); query.Constrain(typeof(Person)); query.Descend("_child").Descend("_age").Constrain(age); IObjectSet result = query.Execute();
En dit werkt...Echter, de performance is dramatisch. Toegegeven, de database bevat 1.000.000 Person's en 1.000.000 onderliggende Child's.Maar klopt dit? Is het op dergelijke wijze query'en van de database inderdaad nog niet optimaal in db4o?Of moet ik de query anders opstellen?Groeten,Ernst
Hoi Ernst,
Aan de query kan het niet liggen. Het is SODA en dus kunnen er geen optimalisatie-issues aan ten grondslag liggen. Ik heb met behulp van Unit tests eens iets vergelijkbaars gedaan met 1000 woordenboeken met in elk 1000 woorden. Dit leverde zelfs een null pointer exception op onder .NET. Alle benchmarks die ik gezien heb gaan niet verder dan 300k objecten van een type.
Db4o is niet bij uitstek geschikt voor bulk operaties op enorme hoeveelheden gegevens, maar scoort des te beter op complexe object graphs. Voor zaken als het indexeren van webpagina's voor een zoekmachine zou ik db4o niet inzetten.
Heb je al eens geprobeerd om de database op te splitsen in 10 files voor de test? Het zal mij niet verbazen als het querieen van 10 databases en het samenvoegen van de resultaten sneller gaat dan het querieen van 1 enkele grote database. Wat voor een applicatie zou je db4o voor willen gebruiken uiteindelijk?
Groet,
Dirk Louwers
He Dirk,
Ik heb deze test opgezet om DB4O even flink te testen. Daarbij heb ik niet een specifieke applicatie/toepassing op het oog.
Ik zie de potentie van DB4O en de manier waarop je DB4O kan gebruiken vind ik bijzonder aantrekkelijk.Echter, voordat ik overstap naar een nieuwe database, wil ik uiteraard eerst goed kijken wat de implicaties zijn.En dat betekent: goed kijken en testen van betrouwbaarheid, wijze van gebruik, beschikbare tooling (zoals Object Manager) en dus ook performance.
Je schrijft: "Db4o is niet bij uitstek geschikt voor bulk operaties op enorme hoeveelheden gegevens". Betekent dat dat je DB4O uitsluit voor gebruik van de grotere mainstream applicaties?Is DB4O in jouw opinie een 'niche' database?
Groeten,Ernst
Ok, ik begrijp dat je dus een soort van stress-/prestatie-test aan het loslaten bent op db4o.
Persoonlijk ben ik, zeker op het moment, niet van plan om over te stappen op db4o. Er zijn scenario's waarbij db4o niet zeer geschikt is. Een van die scenario's is platte queries op grote hoeveelheden objecten van één type. db4o is in eerste instantie in het leven geroepen om embedded te kunnen werken. Ik heb zelf echter gemerkt dat er een heleboel scenario's zijn waarin db4o ook prima als back-end voor maatwerk bedrijfsapplicaties is te gebruiken. Bij, bijvoorbeeld, een ASP order tracking applicatie voor een MKB bedrijf heb je niet zo snel het probleem dat je met meer dan een paar honderd duizend objecten van één type komt te zitten die niet verplaatst kunnen worden naar een archief database (bijvoorbeeld een klassieke MySQL database middels dRS).
Naar mijn idee is een db4o database dus niet erg schaalbaar voor heel grote hoeveelheden data. Maar omdat db4o zo veel werk bespaart doordat het zo prettig werkt is het een prima kandidaat voor standaard bedrijfsapplicaties waar deze noodzaak niet bestaat. db4o hoeft dus totaal geen niche database te zijn.
Dirk