Desarrollo rural en Chile
2.3 DESARROLLO AGRÍCOLA EN CHILE
The systems size can be scaled from a default size. The default system size is 200 power stations and that is approximately one tenth of a large S.P.I.D.E.R. system.
The default system size is calculated from the power station model shown in Figure 5-1. When scaling the system it is the number of stations that is altered.
The Network, TTD Storage and Event Storage is not effected by the scaling in amount, since there is only one object each of these types in a system.
The system default size contains:
1 Network 1 TTD Storage 1 Event Storage
30*200 Stations = 6000 Switches 2*200 Stations = 400 BusBars
2*200 Stations = 400 TransmissionLines 22*200 Stations = 4400 Nodes
10*200 Stations = 2000 Measurements 5.2.2 Object Classes
5.2.2.1 Network
There is only one Network object in a simulator system, and it contains five sub-objects. The DNCNet Configdata contains the OIDs of all Node objects in the simulator system and the SEMatrix Configdata contains the Measurement OIDs.
The length of the arrays is determined by the system size, the calculated array length in the table below is for a default system size.
DNCNet Configdata 1 array with 6400 floats and 1 with 4400 OID:s DNCNet BusBranch 1 array with 200 floats
NMBNet Configdata 1 array with 6400 floats and 1 with 4400 floats NMBNet BusBranch 1 array with 200 floats
SEMatrix Configdata 1 array with 2000 OID:s
5.2.2.2 Measurement
The measurement objects have three sub-objects.
DAS Read 4 boolean, 1 char string, 2 int, 3 floats DAS Write 4 boolean, 1 char string, 2 int, 3 floats SEMeas 2 boolean, 1 int , 1 float
5.2.2.3 Node
DNCStatus 1 float
5.2.2.4 Event Storage
Event Storage contains an event list. In an S.P.I.D.E.R. system the event list is dynamic, but in the simulator the event list is implemented as wraparound. Since there is no need to save old events and reviewing them. There is only one Event Storage object in a simulator system.
Event vector 1 array with 100 entries, each entry containing, one 200 char string, 2 int, 7 boolean
5.2.2.5 TTD Storage
There is only one TTD Storage object in a simulator system. The elements of the array contain a struct of 4 floats.
TTD vector 1 array with 350 entries, each entry containing 4 floats
5.2.2.6 TransmissionLine
DNCStatus 1 float
5.2.2.7 Switch
DAS Read 4 boolean, 1 char string, 2 int, 3 floats DAS Write 4 boolean, 1 char string, 2 int, 3 floats
5.2.2.8 BusBar
DNCStatus 1 float
5.3 Application Design
The applications in the S.P.I.D.E.R. system have an incoming data flow from events in the power stations. The data is processed, calculated and stored into the database. The applications receive and send data through a message system build on queues. Events occur and are send to the applications, where they are queued.
In figure 4.8 a simplified application model is shown, it contains the basic applications of a S.P.I.D.E.R. system.
DAS and
High load data rates per second 350 changed analogs
100 limit violations & indication changes - 100 indication changes
- 1 DNC determining
- 1 topology determining per 10 minutes
DNC configuration run each 30 seconds TTD configuration 350 analogs/second Network model
2000 analogs (2+4*2)*Busses 6000 indications (6*5)*Busses
Figure 5-1 Application data flow
The high load rates of data, shown in figure 5.1, have been calculated for one tenth of a large S.P.I.D.E.R. system. If the database size is scaled from its default size, the high load rates must also be scaled. Which objects that should be
accessed are generally selected with a random operator. If all attributes of a type are read, the objects are read sequentially.
In the initial specification of the simulator there should be a multi-process version and a message system between the applications. When problems encountered with the database products, these features were never implemented, but the simulator design provides support for such features.
The DAS and E&A Processing application accesses 450 Measurement objects per second, the DAS Write attributes are read and updated. The random generator determines which objects that are read.
Read 450 objects times 20 attributes / second Write 450 objects times 10 attributes / second
DAS and E&A processing Measurement
DAS Read 10 attributes
DAS Write 10 attributes 2000 Measurement objects
Figure 5-2 DAS and E&A Processing High Load
Read 100 objects times 20 attributes / second Write 100 objects times 20 attributes / second
E&A Storage Measurement
DAS Read
10 attributes DAS Write 10 attributes 2000 Measurement objects
Event Storage Event Vector 1 Event Storage object
Figure 5-3 E&A Processing High Load
Read 350 objects times 10 attributes / second Write 350 objects times 4 attributes / second
TTD Storage Measurement
DAS Write 10 attributes 2000 Measurement objects
TTD Storage
TTD Vector 1 TTD Storage object
Figure 5-4 TDD Processing High Load
Write 200 attributes /second
Read 6400 + 4400 attributes / second
DNC Network
DNCNet Configdata
Node
DNCStatus 4400 Node objects 1 Network object
DNCNet BusBranch
Write 10 objects times 1 attributes /second
Figure 5-5 DNC Processing High Load
NMB DAS Read 10 attributes
Read 6400 + 4400 attributes / second Network
NMBNet Configdata
1 Network object
NMBNet BusBranch
Read / Write 200 attributes/ second
Figure 5-6 NMB high load
Write 2000 times 4 attributes Network
1 Network object
SE
DAS Read 10 attributes Measurement
SEMeas 2000 Measurement objects
SEMatrix Configdata
Read 2000 attributes Write 2000 attributes
Figure 5-7 SE high load
6. Evaluation
6.1 Functionality
6.1.1 Common database features
• Persistence
Objectivity/DB supports persistence through inheritance.
• Secondary storage
Database servers can be implemented as Advanced Multithreaded Servers (AMS) or as Network File Servers NFS. Objectivity/DB has mechanisms for indexing, clustering and caching. No query optimization mechanism is available, this is left for the application programmer.
• Concurrency control
Objectivity/DB supports locking mechanisms, deadlock detection and avoid starvation with queues to critical resources.
Feature Description
Flexible transaction model Supports transactions of any duration, including long transactions through checkout/checkin feature.
Multiple readers, one writer Improves concurrency by allowing multiple readers to read the most recent state of an object that is locked for update by another transaction.
Object-level versioning Allows an application to selectively operate on specific versions of objects.
Hierarchical locking Two-phase hierarchical locking controls read and update accesses to objects.
Lock waiting Allows transactions to wait for a user-defined period for access to locked objects.
Active deadlock detection across databases Warns against potential deadlock situations.
Table 6-1 Objectivity/DB concurrency mechanisms
• Recovery facilities
Objectivity/DB recovers transactions automatically when an applications process is interrupted or crashes. Automatic recovery application and network failures
including: application failures, local and remote server failures, lockserver host and process failures.
• Query facilities
Objectivity/SQL++ provides full support of ANSI SQL 1989 and entry level SQL 1992, and includes partial support of intermediate level SQL 1992.
• Database administration, security and access control Objectivity/DB has no database administration of users.
The applications cache size can be set in sizes of memory pages. There is no support for transaction optimizations. Objectivity/DB supports hash indexing of containers.
There is no manual lock release in Objectivity/DB. If a lockserver is running and has a lock on the federal database, it cannot be released. The lockserver must first be terminated. In a UNIX system this is not a problem since started processes from a user can be killed. In Windows NT this is cannot be done as user or as administrator. The problem leads to that the system has to be rebooted. The lockserver can be stopped from NT but this does not help, and of course uses Objectivity safety first here, if the lockserver is down and data still can be accessed, the database can enter an inconsistent state.
6.1.2 Object-oriented features
• Complex objects
Objects are created using the facilities of C and C++, Objectivity/DB also offers uni- and bi-directional associations between objects.
• Object identity
Objectivity/DB uses a 64 bits OID that contains information about the location of the object.
• Encapsulation
Attributes and methods are encapsulated through the class architecture of the different program languages that has an Objectivity/DB binding.
• Classes and inheritance
Objectivity/DB supports class architecture and inheritance through the bindings to object-oriented programming languages.
• Overriding, overloading and dynamic binding
Objectivity/DB supports overriding, overloading and dynamic binding through the bindings to object-oriented programming languages.
6.1.3 Realtime features
• Determinism
Objectivity/DB has support for blocking processes for a specified period of time.
If no answer is received during the period an error code is returned.
• Parallelism
In Objectivity/DB transactions are managed by a lockserver that grants or rejects access to database objects.
• Event handling
Event Notification Services in Objectivity/DB support event handling.
Objectivity/DB is developed for UNIX and is ported to the tested NT version. The product is row based, and thereby not integrated into the Windows environment.
6.1.4 User friendly 6.1.4.1 Documentation
Objectivity supplies documentation for delivered products.
In the documentation, is the fundamental rows of easy examples often left out, even if the source is only one row it is usually removed and replaced with a comment that says: Here the code should be, or here we set these variables. If you
want to know how these variables are set it is only shown once and is described in text, for example with handlers. Simple examples are an easy way to learn the product fast, by creating own simple examples and viewing the result. If the fundamental rows are not described in all chapters is acceptable but they should be written out in the first chapters, were inexperienced users that struggles with their first programs try to find answers.
Some important material, that effects design and implementation, can only be found in the supplement book. For example the non-support for unions is not mentioned in "user manual".
6.1.4.2 Support
During the work Objectivity has provided free support through their Swedish distributor Norsys Technology. Most of the support is managed through email, but also through telephone. A short introduction was also given from Norsys during installation of the product.
6.1.4.3 Tools
Objectivity/DB provides three browsing facilities:
• Type Browser
• Data Browser
• Query Browser
The oobrowser is an application program for viewing the database.
Table 6-1 Objectivity/DB Browser
When using oobrowse on large objects, there is a program needs to use a lot of the computers system resource, resulting in that the computer performance is the limiting cause for using the oobrowse tool. When viewing large objects on a computer that cannot provide the application with enough virtual memory and CPU power, the application will stall and has to be killed from the NT task manager, when doing this the locks in the lockserver is not released. Resulting in deadlocked lockserver.
The DDL-precompiler is not integrated into Visual Studio, so this has to be made manually through the command prompt. Makefiles may be used. But no scripts are provided by Objectivity, for example if the project contains a large number of source code files, it will take a long time to compile all source files. When updates are made to some files only these needs to be recompiled. If there is no support for update check, the user has to make sure that all changed files get recompiled. To write scripts for this is not very demanding and could easily be supplied by Objectivity.
Since Objectivity is not integrated in Visual Studio, this can be a problem for new Visual Studio users. There are project settings that needs to be set in the right way for running Objectivity thorough Visual Studio, like compiler options etc. No software support for this is available from Objectivity, only samples of projects all ready created, but if a new workspace and project are created new problems occur.
6.2 Performance
6.2.1 Test Cases with Objectivity
The executing program is a basic read program from the simulator database. The test is to determine how much each operation costs in time. The tests were performed on 166Mhz computer with 114 MB internal memory. The database size was set to default. The code that was executed is shown in Table 6-1.
1
Table 6-1 Program code
The program code was executed with different setups and time was measured so that the cost of each operation could be calculated. Especially in memory
references. Table 6-2 shows the test results for each test:
Code Cache Total Time Iterations Time
5 50 9.934 1000000 9.934E-6
5,4.0 50 8.362 1000000 8.362E-6
5,4.1 50 8.292 1000000 8.292E-6
5,4.0,3 50 112.332 1000000 1.12332E-4
5,4.0,3,2 50 116.358 1000000 1.16358E-4
5,4.0,3,2,1 50 226.176 1000000 2.26176E-4
Table 6-2 Execution times of different operations
As shown in Table 6-2 the execution time for the second and third tests are shorter than the first test. This seems incorrect since more code has to be executed and therefore the execution time would be longer. In the first test the object is open but it is not made inside the loop, the rows 1, 2, 3, 4.0 is executed outside the loop, before the time measurement has started. Which means that the object is brought from the database into the application cache for further use, the same object is then used during the loop and time measurement. Objectivity support has not been able to give an answer to why the execution time is shorter with greater number of operations.
6.2.2 Test Case with Objectivity cache
During the test the database size were set to default. The same code is executed several times but with different cache sizes, ranging from 10 to 500 pages. The results are displayed in Table 6-1.
Code Cache Total Time Iterations Time
5,4.0,3,2,1 10 722.719 1000000 7.22719E-4
5,4.0,3,2,1 20 530.953 1000000 5.30953E-4
5,4.0,3,2,1 30 327.161 1000000 3.27161E-4
5,4.0,3,2,1 40 219.615 1000000 2.19615E-4
5,4.0,3,2,1 50 226.176 1000000 2.26176E-4
5,4.0,3,2,1 60 222.259 1000000 2.22259E-4
5,4.0,3,2,1 70 223.041 1000000 2.23041E-4
5,4.0,3,2,1 80 223.872 1000000 2.23871E-4
5,4.0,3,2,1 90 221.408 1000000 2.21408E-4
5,4.0,3,2,1 100 223.632 1000000 2.23632E-4
5,4.0,3,2,1 150 219.646 1000000 2.19646E-4
5,4.0,3,2,1 200 225.023 1000000 2.25023E-4
5,4.0,3,2,1 250 225.855 1000000 2.25855E-4
5,4.0,3,2,1 300 223.922 1000000 2.23922E-4
5,4.0,3,2,1 350 223.662 1000000 2.23662E-4
5,4.0,3,2,1 400 224.432 1000000 2.24432E-4
5,4.0,3,2,1 450 222.029 1000000 2.22029E-4
5,4.0,3,2,1 500 226.726 1000000 2.26726E-4
Table 6-1 Execution times with different cache sizes
The diagram in Figure 6-1 shows that a too small cache gives bad execution times.
When reaching the point, were all data could be fitted into the cache the execution times stabilizes around 220 seconds. Since the execution times is so long the setup time for a larger cache is masked.
Figure 6-1 Diagram over execution time with different caches
6.2.3 Test Cases with C++
For comparing the results given in the test with Objectivity, fragments of the database structure were created in C++. The tests were executed in the same manner, with the same conditions and equipment.
Time to execute test loop with 1000000 iterations
0 100 200 300 400 500 600 700 800
0 100 200 300 400 500 600
Cache size
Time
Series1
1.
2.
3.
Meas = &spider[rand()%(int)(2000*scale)];
DasRead = (TestDASRead *)meas->GetAppl(0);
ReadVar.attrib1 = dasRead->attrib1;
ReadVar.attrib2 = dasRead->attrib2;
ReadVar.attrib3 = dasRead->attrib4;
ReadVar.attrib4 = dasRead->attrib4;
ReadVar.attrib6 = dasRead->attrib6;
ReadVar.attrib7 = dasRead->attrib7;
ReadVar.attrib8 = dasRead->attrib8;
ReadVar.attrib9 = dasRead->attrib9;
ReadVar.attrib10 = dasRead->attrib10;
Table 6-1 Program code
The results from the tests are shown in Table 6-2.
Code Total Time Iterations Time
Test Meas Case 0 38.004 100000000 3.8004E-7
Test Meas Case 1 157.287 100000000 1.57287E-6
Test Meas Case 2 310.146 100000000 3.10146E-6
Table 6-2 Execution times for C++ classes
The result shows the in memory reference time for the used equipment. It is more 20 times faster (~26) than with the Objectivity/DB application cache.
7. Conclusion
Object-oriented approach models the real world more completely than a relational approach. Complex objects are inefficient to model in a RDBMS. When
application behavior is separated from database behavior, mapping between the relational and the object world has to be made.
For simple data models there are no need to use an ODBMS, there is no
performance advantage, searching for requested data and optimizations of queries are supported by the products.
RDBMS has a dominating position on the market, their products have matured and contains all necessary tools. All major vendors use the SQL standard, which increases portability between different products. As long as no standard has been chosen for object-oriented database systems, they have a great disadvantage against the relational databases.
ODBMS and RDBMS will coexist and hold different niches of the market, since commercial relational database systems have collected more than a decade of business experience, are well established and do much better cope with the simple structured data they are designed for.
The thesis does not include a performance test for a relational database, time for these tests were not given. An object-oriented design is well suited for the S.P.I.D.E.R. database architecture and Objectivity/DB is a strong contender among the leading ODBMSs.
The access pattern of a S.P.I.D.E.R. system is with a large number of short transactions. Objectivity/DB is more suited for long transactions. To use Objectivity/DB with the S.P.I.D.E.R. access pattern a commit device has to be implemented, that gathers several short transactions before committing. This has not been implemented.
Objectivity/DB is best suited for distributed solutions. When using
Objectivity/DB as a S.P.I.D.E.R. database, it has lack of support of S.P.I.D.E.R.
features. The most important missing feature is shared memory. The S.P.I.D.E.R.
system uses a shared memory approach for retrieving a high performance system.
With no shared memory each application has to have its own application cache,
since there is no cache coherence between Objectivity/DB application caches all updates has to go through the database to be visible to other applications. This leads to very high rates of disk I/O, which results in very poor performance. As performance is the most important issue for the database in a S.P.I.D.E.R. system, Objectivity/DB is not very well suited for this task.
Objectivity/DB is well suited for a distributed and replicated environment. For achieving the best performance of an Objectivity/DB the database design should be adjusted to a distributed system. It is possible for a distributed system would outperform a shared memory approach, since it can add more nodes. Shared memory approach has a supported architecture by the parallel databases and a multiprocessor system is probably the most suited solution for S.P.I.D.E.R.
databases for example Oracle 8 has an object approach and supports parallel database architecture.
8. References
[Obj96] Objectivity Documentation
[Dar98] C.J. Date and Hugh Darwen, Foundation for Object/Relational Databases The Third Manifesto, ISBN 0-201-30978-5, 1998 [Bur98] Douglas K. Burleson, Inside the Database Object Model, ISBN
0-8493-1807-6, 1998
[Lar95] James A. Larson, Database Directions, ISBN 0-13-290867-0, 1995 [Con98] Thomas Connolly, Carolyn Begg and Anne Strachan, Database
Systems A Practical Approach to Design, Implementation, and Management, ISBN 0-201-34287-1,1998
[Cat00] R.G.G. Cattell, Douglas Barry, The Object Data Standard: ODMG 3.0, ISBN 1-55860-647-5, 2000
[Cat94] R.G.G. Cattell, The Object Database Standard: ODMG –93, ISBN 1-55860-302-6, 1994
[Kue94] Peter Kueng, Comparison of ten ooDBMS, 1994 [Vah10] Http://galaxy.uci.agh.edu.pl/~vahe/products.html [Vah20] Http://galaxy.uci.agh.edu.pl/~vahe/oodb3.html [Dat98] White Paper Relationsdatabaser, Datateknik, 1998
Http://www.et.se/datateknik/whitepaper/WP_relationsdatabaser.pdf
Http://flowwworks.com
Http://icslab.agh.edu.pl/~jasper/oodb/
Http://orient.freeservers.com Www.ardent.com
Www.bluestream.com Www.cai.com
Www.exceloncorp.com/objectstore/
Www.gemstone.com
Www.highway1.com.au/adsoftware/
Www.ibex.ch Www.intersys.com Www.jyd.com Www.mdbs.com Www.neologic.com Www.objectivity.com Www.odmg.org Www.ozone-db.org Www.persistent.com Www.poet.com
Www.sysra.com/eyedb/
Www.t-know.com Www.versant.com