Technical Considerations in Object-Oriented Database Systems
Performance plays a pivotal role in selecting a database system. Benchmarking with specific applications and hardware is crucial. The Pole Position benchmark provides valuable insights for object-oriented applications, while various tests evaluate behaviors with large data, objects, fields, and users. The suitability of db4o for embedded systems is also explored in depth.
Download Presentation
Please find below an Image/Link to download the presentation.
The content on the website is provided AS IS for your information and personal use only. It may not be sold, licensed, or shared on other websites without obtaining consent from the author.If you encounter any issues during the download, it is possible that the publisher has removed the file from their server.
You are allowed to download the files provided on this website for personal or commercial use, subject to the condition that they are used lawfully. All files are the property of their respective owners.
The content on the website is provided AS IS for your information and personal use only. It may not be sold, licensed, or shared on other websites without obtaining consent from the author.
E N D
Presentation Transcript
CSCI 5433 OBJECT ORIENTED DATABASE SYSTEMS Chapter 14 :Technical Considerations using db4o [393~ 399] Group 2 Singuru, Gowthami Venigandla, Ragini Kambhampati, Raghuram Murrarishetty, Saikiran Bolisetti, Hari Ram Kumar Gorantla, Varun Kumar Chowdary
Contents Performance. Pole Position benchmark. Tests Summarized. Behavior with a Large Quantity of Data Huge Objects Objects with Huge Fields Behavior with Large Numbers of Users Suitability of db4o for Specific System Types Embedded Systems
Performance Performance is a key factor in the choice of a database. A true test of performance requires benchmarking with your own type of application and hardware combinations. To get an initial indication of likely performance, however, general benchmarks are available that can give you a guide to the strengths and weaknesses of different persistence solutions. We must observe how it performs with huge objects or large numbers of objects, and how it performs in systems with large numbers of users.
Pole Position benchmark It provides some very useful information in the context of object-oriented applications. This benchmark project provides a set of benchmark tests and the results of running these tests against a variety of databases. The published results include a rich set of measurements and comparisons between databases, including MySQL, HSQLDB, and db4o. It s worth looking in detail at the published Pole Position results.
Tests that are summarized are as follows Write flat bulk: This is a simple test that writes 10,000 objects of a single kind without further dependencies into the database. Read/write/delete object tree This test writes/deletes and reads a complex object tree with depth 8 of simple objects into the database.
Tests that are summarized are as follows Query inheritance This test writes, reads, queries, and deletes object trees with a five level inheritance structure. Query indexed int This test shows how fast you can query a single object from the database by using an indexed (integer) field. Retrieve object by native ID In contrast to the previous test, here the objects are queried by their native ID.
How these tests worked Query string: This test shows how fast an object can be queried using a characteristic string value as identifier (selects: 900/objects: 1,000). Delete flat indiv: Deletes 1,000 objects individually by ID. The results from the two tables point to a simple rule of thumb: the flatter and simpler your data, the better performance you will get with SQL.
Behavior with a Large Quantity of Data Db4o in some extreme cases of object model design. Huge Objects: This kind of object is to be found in dynamically or script-created data models. Every DBMS should be capable of storing this kind of object. db4o has no problems storing huge objects with more than 1,000 fields. storage time is only linearly dependent on field count (and of course, limited by heap memory), so objects can get bigger without having exponential performance loss.
Objects with Huge Fields Large fields in objects are required for multimedia data such as pictures, documents, or simply files. It is crucial to know how this data can be accessed in the business logic. db4o provides functionality to store BLOBs (Binary Large Objects) independently of the main database file. Therefore, you can define and store additional metadata or wrapper data in terms of fields. Optionally, you can store the data to a local file system instead of stressing the network infrastructure.
Behavior with Large Numbers of Users db4o was not intended to work with extremely high user occurrences. Until you reach a usage level of 10 users per second, the server is very robust. With heavier loads than this, you will find a linearly increase in processing time depending on the number of users per second. The system does not break down abruptly, even when having extremely high query frequencies or users
Suitability of db4o for Specific System Types Embedded Systems The term embedded system is used in different ways throughout the world of informatics. There is one common factor an embedded system is one in which hardware as well as software establishes a single functional unit.
Embedded Systems The characteristics of such a unit can be narrowed down to the following: A clear definition exists of the systems properties and duties. Resources are limited (often without peripherals such as disks, display, or keyboard). Prices are low as a result of large production volumes. Once the application is deployed, it runs without the need for an administrator who maintains the system (in other words, it s maintenance-free). Because of the absence of an administrator, it has to be very secure and reliable. Systems often run in real-time mode.
