Database Reference
In-Depth Information
B+-Tree or T-Tree; avoiding the overheads of complexity associated with these
storage structures. This approach ensures that using smallest suitable storage
structures, desired performance is achieved using minimal hardware resources
for small database management.
Storage capacity limitations for predictable performance.
ECOS im-
poses data storage capacity limitations for each storage structure. We enforce
this for more predictable performance and to ensure that storage structure per-
formance does not degrade because of unlimited data growth. In ECOS, once the
limited storage capacity of a storage structure is consumed, it evolves to a larger
more complex storage structure composed of multiple existing ones considering
the important factors, such as hardware, the data growth, and the workload.
For ordered read-optimized data storage, a sorted array is evolved into a sorted
list. For unordered write-optimized data storage, a heap array is evolved into the
heap list. The evolution of storage structure is an important event for assess-
ing the next suitable storage structure by analyzing the existing data and the
previously monitored workload. Similarly, each new storage structure also has
a definite data storage capacity limitation and, once again, as it is consumed,
ECOS further evolves and increases the hierarchy of the hierarchically-organized
storage structures.
API consistency to hide complexity and ensure ease of use.
To hide the
complexity of different storage structures over different levels of hierarchy, ECOS
keeps the interface for all storage structures consistent. We provide a standard
interface to access columns with simple, Put(), Get(), and Delete() functionality
with record as argument. It is invisible to an end-user, which storage structure
is currently in use for each column.
Automatic partitioning.
ECOS separates physical storage for each column
to reduce the I/O contention for storing large databases. For large columns,
it also separates the data for a column into multiple separate physical storage
units, which is similar to horizontal partitioning. In Figure 2, at a minimum
each column has its own separate physical storage. With the growth of data,
each column may spread over multiple physical storage units. For example, for
storage structures of Table 1, each sorted list or heap list will be stored in a
separate data file, whereas each B+-Tree or T-Tree will be stored in a separate
index file. These physical storage units may be stored on the single hard disk,
or they may spread across the network.
3.3 Evolution and Evolution Paths
By evolution, we mean the transformation of a storage structure from an exist-
ing form into another form such that the previous form becomes an integral and
atomic unit of the new form autonomically. Evolution path is the mechanism to
define how ECOS evolves a smallest simple storage structure into a large com-
plex storage structure. It consists of many storage structure/mutation rules pair
entries that ECOS uses to identify, how to evolve the storage structures. Each
