ZDN-blog
Technorati-claim
Taalkeuze
Snelheid invoegen objectdatabases
2 juni 2010, door Johan Stuyts. Permanente link naar dit artikel.
Ik wilde weten hoeveel opslagruimte verschillende objectdatabases nodig hadden. Dus ik schreef een paar simpele programma's om objecten in de databases in te voegen. Tijdens het draaien van deze programma's bleek dat er bij sommige objectdatabases al bij een laag aantal (honderdduizenden) objecten problemen optraden. Ik heb het doel van de test toen gewijzigd om te kijken hoe de objectdatabases zich gedragen als er veel objecten ingevoegd worden.
De onderstaande resultaten zijn gebaseerd op de out-of-box-experience (OOBE) van de objectdatabases. Het is dus goed mogelijk dat de objectdatabases veel beter kunnen presteren, maar hier moet je dan wel wat moeite voor doen.
Deze test licht maar een aspect uit van de vele aspecten die belangrijk zijn bij de keuze van een objectdatabase: multithreading, querymogelijkheden, betrouwbaarheid, beveiliging, enz. Hou daar rekening mee als je een keuze moet maken.
De volgende producten heb ik getest. Ik geef niet alle namen vrij om te voorkomen dat ik mogelijk de licentievoorwaarden schendt:
| ObjectDB | |
|---|---|
| Versie | 1.04 Server 2522 |
| Licentie | Commercieell |
| APIs | JDO 1.0 met proprietary uitbreidingen |
| Gebruikte API | JDO 1.0 (enhanced classes) |
| ObjectDB | |
| Versie | 2.0 beta2 99 |
| Licentie | Commercieell |
| APIs | JDO 2.0 met proprietary uitbreidingen
JPA 2 |
| Gebruikte API | JDO 2.0 (enhanced classes) |
| Database B | |
| Versie | Versie beschikbaar op 20 mei 2010 |
| Licentie | Tweeledig: GPL en commercieel |
| APIs | Proprietary |
| Gebruikte API | Proprietary |
| Database C | |
| Versie | Stabiele versie beschikbaar op 20 mei 2010 |
| Licentie | LGPL |
| APIs | Proprietary |
| Gebruikte API | Proprietary |
| Database C | |
| Versie | Bètaversie beschikbaar op 20 mei 2010 |
| Licentie | LGPL |
| APIs | Proprietary |
| Gebruikte API | Proprietary |
De tests zijn gedraaid op de volgende hardware en software:
- Dell Inspiron 9400
- Intel Core2 T7200 2,00 GHz
- 2 GiB RAM
- Databaseopslagschijf: op USB aangesloten 2,5" Seagate Momentus 100 GB, 7200 rpm
- Databaseopslagpartitie snelgeformatteerd voor iedere test
- Geen netwerkkabel aangesloten en Wi-Fi uitgeschakeld
- Microsoft Windows XP Professional SP3
- Sun Java Runtime Environment 1.6.0_18-b07, Java HotSpot Client VM 16.0-b13 (mixed mode, sharing)
- De meeste applicaties afgesloten en de meeste Windows-services uitgeschakeld
Per objectdatabase zijn er negen tests gedraaid: drie hoeveelheden objecten en drie maximale groottes van de heap:
| 100.000 transacties
400.000 objecten |
64 MiB
128 MiB 256 MiB |
|---|---|
| 250.000 transacties
1.000.000 objecten |
64 MiB
192 MiB 576 MiB |
| 1.000.000 transacties
4.000.000 objecten |
64 MiB
256 MiB 1.024 MiB |
Er zijn te veel gegevens in de resultaten om ze in dit artikel op te nemen. Je kunt hier een Excel-werkblad met de gegevens downloaden:
Object database insertion speed test results 2010-05-22 (public).xls
Iedere database heeft twee kolommen in het werkblad. In de eerste kolom staan de gemeten waarden. Als een waarde groen en vet is, dan is dat de beste waarde voor die combinatie van hoeveelheid geheugen en de maximale grootte van de heap.
Het maximale geheugengebruik is gemeten door na iedere 1000 transacties het gebruikte geheugen op
te vragen met
Runtime.totalMemory()
.
Het CPU-gebruik is gemeten door de CPU-tijd, opgevraagd met
ThreadMXBean.getThreadCpuTime(long)
, op te tellen van de threads die aan het begin én aan het einde van de test actief waren.
Threads die tijdens de test eindigden of gestart werden zijn niet meegerekend.
De tweede kolom toont de relatieve prestaties ten opzichte van de beste waarde. De beste waarde (100%) is zwart. Waarden die maximaal 25% slechter zijn zijn donkergeel, en waarden die meer dan 25% verschillen van de beste waarde zijn rood. Des te zwarter en geler deze kolom is, des te beter is de database in deze test.
Uit de resultaten concludeer ik het volgende. ObjectDB 2.0 is een erg goed product. Het is snel, gebruikt weinig geheugen en er vindt geen degradatie plaats als de database groeit (in feite vindt het tegenovergestelde plaats). Database B is alleen bruikbaar voor hoeveelheden objecten die aanzienlijk lager liggen dan de hoeveelheden in deze test. In de Process Explorer was in de I/O-grafiek duidelijk te zien dat database B goed van start ging, maar dat het daarna snel achteruit ging. Database C doet het wat betreft snelheid op zich goed, maar heeft problemen met het geheugengebruik. In de bètaversie zijn de problemen alleen maar groter geworden.