Object Oriented Database Learning Center
Objectivity Home - Government - Objectivity/DB - Webinars - Download Software
|
|
Download a PDF version of this Article Table of contents: Dynamic Containers™: The Key To Superior Performance
Deployment Examples |
The COM21 Solution Com21 uses a variety of containers to store the objects and uses dedicated containers for each of the following classes of objects: Quality of Service group objects, Subscriber objects, HCX component objects and attached STUs (in a single HCX container), Alarm objects for each HCX, Polling Data and each Map (which maps Account number to Subscriber Map and STU to address). The container architecture provides for a division of objects based on function although alternative approaches of mixing and matching could easily have been performed. Customized Alarm containers (deriving from the container class ooContObj) themselves have references to Alarm summary information for that container. This is a proper logical division as the Alarm summary is for that container. The Objectivity/DB customizable container architecture easily enables good design. Each level in the Objectivity/DB architecture provides additional levels of resolution. For example, all containers could be queried for a summary of all Alarm summaries. This query should not be concerned with the details of individual Alarm objects, provided the container is keeping an accurate summary. A customized HCX container allows for both physical and logical containment of HCX components and attached STUs. This breaking down of the problem into these components simplifies the design and the application designer knows implicitly where to find the objects. It would be difficult to imagine a solution to this problem without the container architecture due to both the complexity of a cable modem network and the difficulty of mapping physical containment using only associations. When application polling is enabled, billing and performance data is periodically gathered in multiple containers within the polling database. Multiple containers allow multiple daemons to concurrently update information in the database. Using the MROW (multiple readers, one writer) feature on read transactions provides the highest level of concurrency allowing this data to be summarized without any interference from the updating processes. This COM21 solution is a good example of utilizing containers of different sizes and contents to provide variable concurrency and throughput appropriate for the application. Data Warehousing: Imagine a cellular phone company wanting to implement a data warehouse to analyze user behavior. In designing such a data warehouse, data is stored and generated to several levels of granularity. We can break down the levels as in the diagram below.
 At the finest granularity, every call description record (CDR) in a 30-day period for each customer is kept. At the next higher level, a lightly summarized history of the customer activity since inception is kept. This lightly summarized history may contain statistical information by month for that customer such as calls by hour of day, day of week, area codes of numbers called, average duration of calls, etc. At the next level of granularity, customer data in each zip code served by the wireless phone company are aggregated in order to provide gross numbers that are useful for statistical activities. These may include number of calls made from a zip code by all customers, roaming call activity, customer churn rate, etc. In implementing such a data warehouse in Objectivity/DB, we will use different databases and containers for the raw, lightly summarized and highly summarized data in a federated database. We can use a design such as that below.
 You can then use a hierarchical storage system (HSM) to move the databases containing the CDR records into nearline or offline storage such as optical disk and magnetic tape when analysis of the high granularity data is complete. The summarized data can be kept online on regular hard drives while the lightly summarized data on an optical disk jukebox (nearline) and finally the raw data can be offline on magnetic tape. Data can also be moved back from near line or offline storage on demand albeit with some delay. Objectivity/HPSS (High Performance Storage System) and the Objectivity Open Object File System make it easy to interface with industry standard (HPSS) or existing HSMs. Such a system with three different levels of data granularity would cause containers to be of different sizes. In terms of the concurrency-throughput graph, such an application would probably use a subset of the area on the graph that would consist of the right half of the shaded ellipse. Performance Monitoring: In many applications, it is necessary to capture large amounts of data for analysis and to retain some interval of data obtained. Utilizing our example on the wireless phone service above, we may have a requirement that we wish to record the following types of attributes of each call for the purposes of establishing quality of service:
Note that there is no requirement to store customer information - just raw call information. This data is then analyzed to assess whether there is a need to improve signal quality in particular locations. We may wish to keep 90 days worth of call data but no longer than that to establish quality of service trends. It is easy to store up to millions of calls per week for a regional wireless phone service provider. Since there is a requirement to delete data more than 90 days old, it could be necessary to delete hundreds of thousands of records each day. In a RDBMS, deleting such a number of records also means modifying huge index trees. This will typically take hours in an RDBMS. However, if we created containers to store the call record objects for a single day, we can just drop the containers in Objectivity/DB in seconds. In terms of visualizing this application on the concurrency-throughput graph, this would be represented as line C on the graph which is near the leftmost edge of the elliptical area. Data Warehousing usually requires that multiple servers be used to contain, manage and query the data. With Objectivity/DB, data distribution and management are very transparent and scalability is unmatched. OLAP Cubes: Online Application Processing uses a multidimensional database and is often viewed as a cube. The diagram below shows the classic OLAP cube with the three axes to represent time, product and market. By making graduations across each axis, we could break up the data into smaller pieces, called “cubelets”. We can picture queries as operations on rectangular slices cut in that cube. If we have a sale of Product X which was sold in the New York market in January 1999, that piece of data is then in the cubelet which is at the intersection of Product X, January 1999 and New York (see blackened area in diagram).
 If we wanted to analyze data in just these three dimensions, you can effectively store all data in cubelets and make each cubelet a container in actual implementation. This natural partitioning of data into a cubelets/containers simplifies searches as well as analysis since we do not have to scan through large tables as in a RDBMS. A new product means we have to create a new array of containers in which to put the data. A scan over the time history of a given product in a given market would mean that we would retrieve only the relevant containers for that product for a specific market. We would not be scanning through and filtering non-qualifying data at all much less bring them from disk to main memory. Of course, in reality we would use more dimensions and therefore the cubelet could be viewed as a cube in itself with its own dimensions and implement containers at that level or we could implement additional dimensions in terms of data structures within the container. Combine this with the fact that indexes can be created within a container for data only in that container and you have a fairly good query capability even if you did not design in a dimension initially. Objectivity/DB also excels at scanning data even if it is not indexed and this makes it a strong contender when you wish to perform OLAP or multidimensional database type work. In fact, the time it takes to scan a flat file and an Objectivity/DB container with the same data is not significantly different. Whatever the actual design or implementation, we have within Objectivity/DB a powerful architecture utilizing containers.
|
Copyright © Objectivity, Inc. 2000-2007. All Rights Reserved.