Download Odysseus: a High-Performance ORDBMS Tightly

Odysseus: a High-Performance ORDBMS Tightly-Coupled with
IR Features
Kyu-Young Whang, Min-Jae Lee, Jae-Gil Lee, Min-Soo Kim, and Wook-Shin Han
Department of Computer Science and
Advanced Information Technology Research Center (AITrc)
Korea Advanced Institute of Science and Technology (KAIST)
373-1 Guseong-dong, Yuseong-gu, Daejeon 305-701, Korea
e-mail: {kywhang, mjlee, jglee, mskim, wshan}@mozart.kaist.ac.kr; fax: +82-42-867-3562
Abstract
Conventional ORDBMS vendors provide extension mechanisms for adding user-defined types
and functions to their own DBMSs. Here, the extension mechanisms are implemented using a highlevel interface. We call this technique loose-coupling. The advantage of loose-coupling is that it
is easy to implement. However, it is not preferable for implementing new data types and operations in large databases when high performance is required. In this paper, we propose the notion
of tight-coupling [11] to satisfy this requirement. In tight-coupling, new data types and operations
are integrated into the core of the DBMS engine. Thus, they are supported in a consistent manner
with high performance. This tight-coupling architecture is being used to incorporate information
retrieval (IR) features and spatial database features into the Odysseus ORDBMS that has been under
development at KAIST/AITrc. In this paper, we introduce Odysseus and explain its tightly-coupled
IR features (U.S. patented). We then demonstrate a web search engine that is capable of managing
20 million web pages in a non-parallel configuration using Odysseus.
1
Introduction
The amount of data on the internet has been growing at a rate of 10 times for every 3∼4 years [9], and many
applications handling new data types have been emerging [1, 12]. They include information retrieval (IR), spatial
databases, data mining, and data streaming. Accordingly, DBMSs have been evolving to support these new
applications.
1
DBMS vendors provide extension mechanisms for adding new data types and operations to their own
DBMSs. Examples are the Cartridge [8] for Oracle and the Extender [6] for IBM DB2. In these mechanisms,
new data types are added by using user-defined types, and their operations by using user-defined functions. Here,
user-defined types and functions are implemented through the high-level interface provided by the DBMS. We
call this mechanism loose-coupling.
In the loose-coupling architecture, the high-level interface employed causes the following problems. First,
communication overhead is incurred because operations on new data types are performed outside the core DBMS
engine. Second, not all data types and operations can be implemented because the high-level interface provided is
not 100% general. Third, concurrency control and recovery in fine granularity are hard to perform because lowlevel functions of the DBMS engine cannot be fully utilized for new data types due to the high-level interface.
Therefore, the loose-coupling architecture is not preferable for implementing new data types and operations in
large databases when high performance is required.
In this paper, we propose the tight-coupling architecture [11] to solve these problems. In the tight-coupling
architecture, a new data type and its operations are implemented directly into the core of the DBMS engine.
This architecture has the following advantages over the loose-coupling architecture: communication overhead is
minimal; no limitation on data types and operations exists; concurrency control and recovery can be done in fine
granularity.
The tight-coupling architecture has been used to incorporate IR features into the Odysseus ORDBMS [12],
which has been under development at KAIST/AITrc for 14 years.1 It enables Odysseus to process IR queries
efficiently, perform fast immediate updates, and do fine-granularity concurrency control and recovery. We first
introduce Odysseus and the tightly-coupled IR features. We then demonstrate excellence of the tightly-coupled
IR features through a web search engine implemented using Odysseus. Our demonstration system (a non-parallel
configuration) stores and manages approximately 20 million web pages.2
The rest of this paper is organized as follows. Section 2 gives the overview of Odysseus. Section 3 describes
the IR features tightly-coupled with Odysseus. Finally, Section 4 presents our demonstration system.
1 The
Odysseus DBMS consists of approximately 450,000 lines of C and C++ codes.
a parallel configuration, we can increase it to 2 billion web pages with data partitioning in 100 Linux machines. A prototype using
five machines has been implemented and successfully tested.
2 With
2
2
Overview of Odysseus
Odysseus is an object-relational database management system (ORDBMS) designed to support new applications
such as large-scale multimedia, information retrieval, GIS, OLAP, and data mining. Odysseus has the following
features:
• an SQL standard query language
• support for large-scale databases
•
up to 8 TBytes per table (class)
•
up to 2 GBytes per record (object)
• fast bulk loading and bulk deleting
• concurrency control and crash recovery (fine or coarse granularity)
• a Web-to-DBMS gateway
• tight coupling of IR features
•
an SQL-based query language extended for tight coupling with IR features
•
fast immediate update capability
- no need to halt the system to perform updates on IR contents
•
fine or coarse granularity concurrency control and crash recovery on IR contents
• tight coupling of spatial features (under development)
•
an SQL-based query language extended for tight coupling with spatial features
•
using Multi-Level Grid File (MLGF)[7, 10] as the spatial index
•
fine or coarse granularity concurrency control and crash recovery on spatial data
Figure 1 shows the system architecture of Odysseus. Odysseus consists of a storage system (Odysseus/COSMOS) and a query processor (Odysseus/OOSQL). Odysseus/COSMOS is a sub-system that stores and manages
objects in the database. It consists of Disk Manager, Small Object Manager, Large Object Manager, Index Manager, Cursor Manager, Spatial DB Engine, Text IR Search Engine, Recovery Manager, and Transaction Manager.
Disk Manager controls raw disks independent of O/S files. Small Object Manager manages objects smaller than
one page, and Large Object Manager manages those larger than one page and up to 2 GBytes.3 Index Manager
3 These
are being extended to a 64-bit architecture allowing the size of a large object to be up to 263 bytes.
3
manages the B+ -tree index, Multilevel Grid File (MLGF) spatial index, and Text IR index. Cursor Manager processes sequential and index scan operations. Spatial DB Engine offers operations for handling spatial data. Text
IR Search Engine offers operations for handling text data at the storage system level. Recovery Manager manages
recovery functions, and Transaction Manager concurrency control functions and transactions. Odysseus/OOSQL
is a sub-system for processing SQL queries. It consists of Query Analyzer, Query Plan Generator and Optimizer,
and Query Plan Executor. Query Analyzer analyzes given SQL queries. Query Plan Generator and Optimizer
generate and optimize query plans. Query Plan Executor executes optimized query plans to return query results
using Odysseus/COSMOS.
Odysseus/OOSQL
Odysseus/OOSQL User Interface
Query Analyzer
Query Plan Generator and Optimizer
Query Plan Executor
Odysseus/COSMOS
Odysseus/COSMOS User Interface
Cursor Manager
Recovery
Manager
Small Object
Manager
Spatial DB
Engine
Large Object
Manager
Text IR Search
Engine
Index Manager
(B+-Tree, MLGF, Text IR)
Transaction
Manager
Disk Manager
Database
……… ……… ………
Database
Figure 1. The Architecture of the Odysseus DBMS.
Odysseus is tightly coupled with IR and spatial features. Tight coupling with the IR features has been
completed, and that with the spatial features is under development. In the next chapter, we explain the tightlycoupled IR features in detail.
4
3
Tightly-Coupled IR Features
Odysseus stores text documents such as web pages and find those that contain given keywords in support of
IR. Here, text documents are stored in the form of the text type, and text IR indexes are used for finding those
documents. Users can specify the database schema using these text types and text IR indexes at the same level of
specifying nontext types and their indexes. Figure 2 shows the physical structure of a data record for a schema
defined involving the text type, a text IR index, the integer type, and a B+ -tree index. As shown in the figure, the
text type is specified just in the same way as the integer type is specified. Likewise, a text IR index is specified in
the same way as is a B+ -tree index.
B+-Tree
Text IR Index
data record
Text
………
Integer
Figure 2. The structure of a data record involving the text type and a text IR index.
Through the tight-coupling architecture, Odysseus maintains a high level of consistency when updating
data of the text type and text IR indexes. At the same time, it offers an improved query processing performance.
Specifically, Odysseus provides fast processing of two interesting types of queries: 1) multiple-keyword queries
and 2) queries involving both keyword and attribute conditions. These are done by the IR index join and attribute
embedding techniques. We first explain updating capabilities involving text IR indexes in Section 3.1, and then,
querying capabilities in Section 3.2.
3.1
Fast Immediate Update Involving Text IR Indexes
Fast immediate update is the most important among the tightly-coupled IR features of Odysseus. Since the
traditional inverted indexes are too large and complex, immediately updating them has been regarded as an
infeasible or at best a very inefficient operation. Therefore, these indexes are hardly used in the environments
where updates are frequent. However, immediate updates are processed rapidly in Odysseus by exploiting the
inverted index structure using large objects [2] and subindexes. We will elaborate on this structure (patented [11])
below.
5
Figure 3 shows the structure of the text IR index that Odysseus uses. The text IR index is similar to the
traditional inverted index structure [3], but differs in using 1) large objects to store posting lists and 2) subindexes
to index postings in each posting list. We store a posting list as a large object and manage the storage space of the
posting list by using the large object tree proposed by Biliris for Exodus [2]. The advantage of this method is that
it is easy to insert a new posting into or remove it from a posting list. A subindex is a B+ -tree created on each
large object that stores a posting list. The subindex is used for locating a specific posting with a given document
identifier within a posting list. Using subindexes, we can quickly find the location of a new posting to be inserted
or an existing posting to be deleted or modified.
a subindex (for each large object)
B +-Tree
a posting list
Large Object
Large Object
Keyword
B +-Tree
Large Object
Large Object
a posting list
# of Postings docId # of occurences offset
……
……
a posting
Figure 3. The Text IR Index structure using large objects and subindexes.
Without large objects and subindexes, insertion and deletion of a posting would be very expensive: the entire
postings in the posting list after the posting to be inserted or deleted should be moved forward or backward. This
operation incurs huge amount of disk I/O’s, thus degrading the performance. Without subindexes, the entire
posting list must be read to identify the location of the posting to be inserted or deleted. This operation also
incurs excessive amount of disk I/O’s. Thus, to support fast immediate updates, large objects and subindexes are
indispensable.
6
The text IR index not only enhances the performance of immediate updates but also enhances the performance of query processing [11]. When posting lists are merge-joined to process a multiple-keyword query,
subindexes are used to identify parts of posting lists to be actually merged. We will discuss this technique in the
next section. This technique enhances the query performance significantly. Thus, the text IR index is beneficial
for both frequent immediate updates and fast query evaluation.
3.2
Fast Query Processing
Odysseus can efficiently evaluate 1) multiple-keyword queries and 2) queries involving both keyword and attribute conditions as well as single keyword queries. We propose the IR index join and attribute embedding
techniques for this purpose [12].
IR index join is a query processing technique used to speed up multiple-keyword queries. When a multiplekeyword query (having m keywords) is processed, corresponding posting lists are m-way merge-joined. Using
subindexes, the exact parts of posting lists that need to be merged can be identified. Since needless parts of
the posting lists are skipped, performance is enhanced. We call this optimization technique posting skipping.
Figure 4 shows the process of merging two posting lists to find documents containing two keywords ‘system’
and ‘database.’ The gray colored parts of the posting lists are those to be merged based on the docId value;
the white colored parts are those not to be merged. The posting lists are maintained in the order sorted by the
document identifier (docId). This can be done easily by assigning docId in the order of storing the documents in
the database. Using subindexes, we can find these gray-colored parts easily and read only these parts. Recent
works by Guo et al. [4] and by Halverson et al. [5] use similar techniques to speed up the processing of multiple
keyword queries in XML databases.
Attribute embedding is a query processing technique used to speed up queries involving both keyword and
attribute conditions. It evaluates keyword and attribute conditions together by reading a single posting list, in
which the values of the attributes of documents are embedded. This technique obviates the need for accessing
data records stored in the main database since attribute values can be obtained by accessing only text IR indexes.
Accessing the data records is very expensive since it incurs random disk accesses over a large amount of storage
7
Subindex
Posting List
Keyword
”
“system”
doc10
…
doc45
doc74
………
doc94
Posting List
Keyword
“database”
”
doc10
………………………
doc45
doc74
doc94
Subindex
Figure 4. Processing multiple-keyword queries using IR index join.
space. Thus, attribute embedding significantly enhances the performance. Figure 5 shows the process of finding
documents that have the keyword ‘system’ and that were generated in the year 2004. Since the values of the year
attribute are embedded in the posting list for the keyword ‘system,’ the query processor can test whether each
document was generated in the year 2004 while reading the posting list. The user can specify the attributes to
be embedded in a posting list when s/he defines the database schema, and the query processor can automatically
find the values of the embedded attributes when executing a query.
A posting
Keyword
“system”
”
doc1
Posting List
1999 ……… doc10
2004 doc12
2000 ……… doc90
2003
docId attribute
year
Figure 5. Processing queries involving both keyword and attribute conditions using attribute embedding.
4
Demonstration
We demonstrate a web search engine (ODYS) implemented using Odysseus to show excellence of tightly-coupled
IR features. ODYS stores approximately 20 million web pages in a SUN T3+ disk array with 450 GB and runs on
a SUN Enterprize 3500 server with 400 MHz CPU. We provide a web interface for querying Odysseus through
our Web-to-DBMS gateway (called Odysseus/Web).
8
Figure 6 shows a web page for specifying a query. A user can specify an arbitrary boolean expression of
multiple keywords for each query. When a query is specified, the user can limit the scope of the query to a single
site. We call this feature site-limited search. Odysseus offers two methods for processing site-limited search. The
first method handles site-limited search as a query involving both keyword and attribute conditions by embedding
site identifiers into the corresponding posting list. That is, we use the attribute embedding technique to check
whether each document is from a specific site while reading the posting list. The second method handles sitelimited search as a multiple-keyword query by declaring the site identifier attribute as type text and creating a text
IR index on it. Here, the posting list of a site identifier stores docId’s of the documents crawled from the specific
site. That is, we use the IR index join technique to perform a m-way merge-join among the posting lists of the
keywords and the posting list for the given site identifier. Since the size of the posting list of a site identifier is
typically small compared to that of a keyword, many skips occur, due to posting skipping, while doing the mway merge-join among the posting lists. Thus, the performance of the second method is enhanced significantly.
The choice between the two methods can be made by the system designer or can be automatically made by the
optimizer. In this demonstration, we use the second method to process site-limited search.
Figure 7 shows a web page for displaying query results. In Figure 7, our search engine has retrieved 2,967
results from the entire database limited to the Korea Herald site in 82 ms. This result indicates that utilizing the
tightly-coupled text IR indexes for query execution is indeed effective.
References
[1] Banerjee, S., Krishnamurthy, V., and Murthy, R., All Your Data: The Oracle Extensibility Architecture,
Oracle White Paper, Oracle Corp., Oracle Parkway, California, 1999.
[2] Biliris, A., “The Performance Three Database Storage Structures for Managing Large Objects,” In Proc.
Int’l Conf. on Management of Data, ACM SIGMOD, pp. 276–285, 1992.
[3] Faloutsos, C. and Oard, D. W., A Survey of Information Retrieval and Filtering Methods, Tech. Report
CS-TR-3514, Univ. Of Maryland, Aug. 1995.
[4] Guo, L., Shao, F., Botev, C., and Shanmugasundaram, J., “XRANK: Ranked Keyword Search over XML
Documents,” In Proc. Int’l Conf. on Management of Data, ACM SIGMOD, pp. 16–27, 2003.
9
Figure 6. A web page for specifying a query.
[5] Halverson, A., Burger, J., Galanis, L., Kini, A., Krishnamurthy, R., Rao, A. N., Tian, F., Viglas S., Wang,
Y., Naughton, J. F., and DeWitt, D. J., “Mixed Mode XML Query Processing,” In Proc. the 29th Int’l Conf.
on Very Large Data Bases, pp. 225–236, 2003.
[6] IBM, DB2 UDB Text Extender Administration and Programming, 2003.
[7] Lee, J., Lee, Y., Whang, K., and Song, I., “A Region Splitting Strategy for Physical Database Design of
Multidimensional File Organizations,” In Proc. the 23rd Int’l Conf. on Very Large Data Bases, pp. 416–
425, 1997.
[8] Oracle, Oracle9i Data Cartridge Developer’s Guide, 2002.
[9] Sandhya, S. M., Enterprise Storage: Answer to Backup & Recovery Blues, Cyber India Online Ltd., 2001.
[10] Whang, K. and Krishnamurthy, R., Multilevel Grid Files, IBM Research Report RC 11516, 1985.
[11] Whang, K., Park, B., Han, W., and Lee, Y., “An Inverted Index Storage Structure Using Subindexes and
Large Objects for Tight Coupling of Information Retrieval with Database Management Systems,” U.S.
Patent No. 6,349,308, Feb. 19, 2002, Appl. No. 09/250,487, Feb. 15, 1999.
[12] Whang, K., “Tight-Coupling: A Way of Building High-Performance Application Specific Engines,”
Presented at the panel session of Int’l Conf. on Database Systems for Advanced Applications (DAS-
10
Figure 7. A web page for displaying query results.
FAA), Japan, Mar. 2003, available on-line from http://db-www.aist-nara.ac.jp/dasfaa2003/file/Prof KyuYoung Whang 5.pdf.
11