=Paper=
{{Paper
|id=None
|storemode=property
|title=None
|pdfUrl=https://ceur-ws.org/Vol-850/proceedings.pdf
|volume=Vol-850
}}
==None==
https://ceur-ws.org/Vol-850/proceedings.pdf
Proceedings
24. GI-Workshop Grundlagen von Datenbanken“
”
29.05.2012 – 01.06.2012
Lübbenau, Deutschland
Ingo Schmitt, Sascha Saretz, Marcel Zierenberg (Hrsg.)
{schmitt | sascha.saretz | zieremar}@tu-cottbus.de
Vorwort
Liebe Teilnehmerinnen und Teilnehmer,
der 24. Workshop Grundlagen von Datenbanken“ (GvD) 2012 fand in Lübbenau, Spree-
”
wald, statt. Dieser viertägige Workshop wird alljährlich vom GI-Arbeitskreis Grundlagen von
Informationssystemen im Fachbereich Datenbanken und Informationssysteme (DBIS) veran-
staltet und hat die theoretischen, konzeptionellen und methodischen Grundlagen von Da-
tenbanken und Informationssystemen zum Thema. Organisiert wurde der Workshop 2012
von der Forschungsgruppe Datenbank- und Informationssysteme am Institut für Informatik,
Informations- und Medientechnik an der Brandenburgischen Technischen Universität Cottbus.
Der Workshop soll die Kommunikation zwischen Wissenschaftlern/-innen im deutschspra-
chigen Raum fördern, die sich grundlagenorientiert mit Datenbanken und Informationssys-
temen beschäftigen. Er ist insbesondere als Forum für Nachwuchswissenschafter/-innen ge-
dacht, die ihre aktuellen Arbeiten in einem größeren Forum vorstellen wollen. Das Vattenfall-
Tagungshotel Lübbenau bot für eine erfolgreiche Diskussion optimale Rahmenbedingungen in
der landschaftlich sehr reizvollen Umgebung des Spreewaldes.
Insgesamt wurden für den Workshop 15 Arbeiten eingereicht und jeweils von drei Gutach-
tern bewertet. Die Einführung des Begutachtungsprozesses in den letzten Jahren sorgt schon
im Vorfeld des Workshops für eine hohe Qualität der Arbeiten. Die Einreichungen spannten
den Bogen von klassischen Themen wie Indexverwaltung über weitere Themen wie mobile Sys-
teme, räumliche Datenbanken, Data Warehousing und XML-Verwaltung bis hin zu aktuellen
Themen wie Self-Tuning, SaaS, Cloud Computing sowie probabilistische Datenbanken. Diese
große Bandbreite der Gebiete reflektiert die Bandbreite von Problemen in der Datenbankge-
meinde, wie sie auf großen Datenbankkonferenzen diskutiert werden. Dabei werden die Gren-
zen zwischen klassischen Datenbankthemen und benachbarten Bereichen immer durchlässiger.
Gerade diese thematische Bandbreite und die damit einher gehende Spezialisierung auf ein-
zelne Themen macht es für Doktoranden schwierig, die eigene Arbeit richtig einzuordnen und
interessante Querverweise zu benachbarten Bereichen zu sehen. Die zwanglose Diskussion in
einer offenen Atmosphäre des Workshop soll helfen, diese Lücke zu schließen.
Für die Keynote-Vorträge wurden Günther Specht, der Ausrichter des GvD-Workshops
vom letzten Jahr und Bernhard Thalheim eingeladen. Ihnen sei an dieser Stelle für ihre Be-
reitschaft und ihr Kommen gedankt.
Des Weiteren danken wir dem Programmkomitee und allen Gutachtern für ihre Arbeit.
Das Organisations-Komitee und dabei besonders Sandy Schneider, Marcel Zierenberg und
Sascha Saretz haben den Großteil der Arbeit geleistet. Ohne ihren Einsatz und Engagement
wäre der 24. Workshop nicht möglich gewesen. Herzlichen Dank. Besonderen Dank auch an
Eike Schallehn und Hagen Höpfner sowie dem GI-Arbeitskreis Grundlagen von Informati-
”
onssystemen“, welche die Organisation sehr konstruktiv begleitet haben. Zum Schluss möchte
ich allen Mitgliedern meines Lehrstuhl sowie den Autoren und Vortragenden für ihren Anteil
am Gelingen am Workshop herzlich danken.
Mit den besten Grüßen,
Ingo Schmitt
Cottbus am 01.06.2012
iii
iv
Komitee
Programm-Komitee
• Wolf-Tilo Balke, TU Braunschweig
• Stefan Brass, Universität Halle
• Stefan Conrad, Universität Düsseldorf
• Erik Buchmann, Karlsruher Institut für Technologie
• Torsten Grust, Universität Tübingen
• Andreas Henrich, Universität Bamberg
• Hagen Höpfner, Bauhaus-Universität Weimar
• Harald Kosch, Universität Passau
• Klaus Meyer-Wegener, Universität Erlangen
• Daniela Nicklas, Universität Oldenburg
• Gunter Saake, Universität Magdeburg
• Eike Schallehn, Universität Magdeburg
• Ingo Schmitt, BTU Cottbus
• Holger Schwarz, Universität Stuttgart
• Günther Specht, Universität Innsbruck
Organisations-Komitee
• Ingo Schmitt, BTU Cottbus
• Sascha Saretz, BTU Cottbus
• Marcel Zierenberg, BTU Cottbus
• Sandy Schneider, BTU Cottbus
Weitere Gutachter
• Alexander Schulze, BTU Cottbus
• Sascha Saretz, BTU Cottbus
• Marcel Zierenberg, BTU Cottbus
• Daniel Blank, Universität Bamberg
• Martin Schäler, Universität Magdeburg
• Maik Mory, Universität Magdeburg
• Norbert Siegmund, Universität Magdeburg
v
Inhaltsverzeichnis
Keynotes 1
Out of Africa?
Günther Specht . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
Privacy-Enhanced Information Systems
Bernhard Thalheim . . . . . . . . . . . . . . . . . . . . . . . . . . 3
Workshop-Beiträge 5
Towards Modeling Locations as Poly-Hierarchies
Hagen Höpfner und Maximilian Schirmer . . . . . . . . . . . . . 5
Towards Using Location Poly-Hierarchies for Energy-Efficient
Continuous Location Determination
Maximilian Schirmer und Hagen Höpfner . . . . . . . . . . . . . 11
Datenbank-Performance-Experimente in der Lehre
Max Flügel, Alexander Stein und Michael Höding . . . . . . . . . 17
Migration nicht-nativer XML-Strukturen in den nativen XML-
Datentyp am Beispiel von DB2 for z/OS V9.1
Christoph Koch . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
Evolution von XML-Schemata auf konzeptioneller Ebene -
Übersicht: Der CodeX-Ansatz zur Lösung des Gültig-
keitsproblems
Thomas Nösinger, Meike Klettke und Andreas Heuer . . . . . . . 29
Ein Partitionierungsdienst für Geographische Daten in Räum-
lichen Datenbanken
Hendrik Warneke und Udo W. Lipeck . . . . . . . . . . . . . . . 35
Cloud Data Management: A Short Overview and Comparison
of Current Approaches
Siba Mohammad, Sebastian Breß und Eike Schallehn . . . . . . . 41
Cloud-Services und effiziente Anfrageverarbeitung für Linked
Open Data
Heiko Betz und Kai-Uwe Sattler . . . . . . . . . . . . . . . . . . 47
SLO-basiertes Management in relationalen Datenbanksyste-
men mit nativer Multi-Tenancy-Unterstützung
Andreas Göbel . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
iETL: Flexibilisierung der Datenintegration in Data Ware-
houses
Sebastian Schick, Gregor Buchholz, Meike Klettke, Andreas Heu-
er und Peter Forbrig . . . . . . . . . . . . . . . . . . . . . . . . . 59
Ereignismuster für die Verwaltung von komplexen Tupeler-
eignissen in Probabilistischen Datenbanken
Sebastian Lehrack . . . . . . . . . . . . . . . . . . . . . . . . . . 65
Flexible Indexierung für Ähnlichkeitssuche mit logikbasierten
Multi-Feature-Anfragen
Marcel Zierenberg . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
Challenges in Finding an Appropriate Multi-Dimensional In-
dex Structure with Respect to Specific Use Cases
Alexander Grebhahn, David Broneske, Martin Schäler, Reimar
Schröter, Veit Köppen und Gunter Saake . . . . . . . . . . . . . 77
Minimal-Invasive Indexintegration - Transparente Datenbank-
beschleunigung
Alexander Adam, Sebastian Leuoth und Wolfgang Benn . . . . . 83
Self-Tuning Distribution of DB-Operations on Hybrid CPU/GPU
Platforms
Sebastian Breß, Siba Mohammad und Eike Schallehn . . . . . . . 89
vii
Out of Africa?
Günther Specht
Datenbanken und Informationssysteme
Institut für Informatik
Universität Innsbruck, Österreich
guenther.specht@uibk.ac.at
KURZFASSUNG
Woher? und Wohin? sind die bewegenden Fragen des Lebens, der For-
schung und der Wissenschaft. Auch der Datenbanktechnologie. Dieser
Vortrag gibt sich nicht mit der Antwort 42 zufrieden, sondern spannt
einen Bogen bis hin zur interdisziplinären Vernetzung der Datenbanken
und Informationssysteme mit der Genetik. Dort gelang es heuer in der
Haplogruppeneinteilung der Frage Out of Africa?“ mittels massivem
”
IT- und DB-Einsatz eine neue Antwort zu geben. . .
24th GI-Workshop on Foundations of Databases (Grundlagen von Daten-
banken), 29.05.2012 - 01.06.2012, Lübbenau, Germany.
Copyright is held by the author/owner(s).
1
2
Privacy-Enhanced Information Systems
Bernhard Thalheim
Lehrstuhl für Technologie der Informationssysteme
Institut für Informatik
Christian-Albrechts-Universität zu Kiel
thalheim@is.informatik.uni-kiel.de
KURZFASSUNG
Nach einem kurzen Überblick über den State-of-the-Art der Nut-
zung des Internets werden Prinzipien, Trends und Technologie für die
Wahrung der Privatsphäre dargestellt. Daraus lassen sich vielfältige
Modellierungs-, Infrastruktur-, Technologie-, Sozial- und Rechtsprojek-
te zur Unterstützung von Privatsphäre im Internet ableiten. Ziel ist die
Entwicklung einer erweiterten Infrastruktur, in der Privatheit auch im
Internet möglich ist. Im Detail stellen wir Ansätze vor, mit denen die
Privatheit an Daten gesichert werden kann. Dazu ist ein Sicherheits-
modell, ein Inhaltemodell und ein Sicherungsmodell notwendig. Darauf
kann ein Koordinationsmodell aufgesetzt werden. Techniken zur Stüt-
zung von Privatheit können darauf aufgesetzt werden. Dies wird anhand
von zwei Datenbank-Ansätzen gezeigt.
24th GI-Workshop on Foundations of Databases (Grundlagen von Daten-
banken), 29.05.2012 - 01.06.2012, Lübbenau, Germany.
Copyright is held by the author/owner(s).
3
4
Towards Modeling Locations as Poly-Hierarchies
Hagen Höpfner and Maximilian Schirmer
Bauhaus-Universität Weimar
Media Department / Mobile Media Group
Bauhausstraße 11, 99423 Weimar, Germany
hoepfner@acm.org, maximilian.schirmer@uni-weimar.de
Keywords the Bauhausstraße 11 in Weimar, Germany and the assumption be-
Location, Location Modeling, Poly-Hierarchies, Enclave Problem, ing that such information is usually more meaningful to the user.
Multiple Belonging Hence, we should use a service that maps positions to locations.
However, location-based applications differ in their required preci-
sion [10]. While the name of the city in which a user and/or a de-
ABSTRACT vice is currently located might be appropriate for handling location-
Location models are formal descriptions of locations (i. e., named aware data processing in an event information system, a navigation
sets of geographical positions) as well as of semantic relationships system demands for exact coordinates, or street names at least.
among locations. There exist various location models that vary in The aforementioned example also illustrates another issue that is
the considered location information, their level of detail, the kind common for locations. In many cases, semantic locations form hi-
of modelled relations and the used formal representation. In fact, erarchical structures. For example, in a hierarchical location model,
more complex location models cover more aspects required for im- earth is divided into continents, continents into countries, coun-
plementing location-aware or location-dependent systems, but also tries into states, states into cities, cities into streets and streets into
require more complex algorithms. As each application domain re- street numbers, and so on. However, modelling locations as mono-
quires only a limited set of features, limiting a model to those fea- hierarchies oversimplifies the reality and does not support multiple
tures helps to improve system performance. In this paper, we dis- belongings. While, e. g., Weimar is part of Germany, Germany of
cuss a novel location model called location poly-hierarchies that Europe, etc., Istanbul is part of Turkey, but also of Europe and Asia.
models the belonging of one location to one ore more other loca- Please note, we focus on geographic belongs-to-relationships (sub-
tions. Furthermore, we present an approach for creating location set and overlap) rather than on geopolitical ones. Location hierar-
poly-hierarchies from a given set of locations. chies benefit from the fact that determining low-level location in-
formation determines upper levels, too. Location poly-hierarchies
cure the mentioned model incompleteness while keeping the bene-
1. INTRODUCTION AND MOTIVATION fit of a “fast” lookup of the correct path within the poly-hierarchy
In February 2004, the authors of [5] stated: “The widespread de- (cf., [11]). The research question addressed in this paper is:
ployment of sensing technologies will make location-aware appli-
How can one algorithmically create location poly-hierarchies
cations part of every day life.” Nowadays, location-awareness has
from a given set of locations?
become a key feature in a broad range of mobile information sys-
tems. Navigation systems, social network apps, tourist information The remainder of this paper is structured as follows: Section 2
systems, event information systems, shop finders and many more surveys related work. Section 3 introduces the concept of loca-
heavily rely on position data of their users. Consequently, almost tion poly-hierarchies. Section 4 presents our approach for creating
all modern smartphones supply positioning techniques. However, them. Section 5 discusses implementation aspects. Section 6 sum-
a position determination, e.g, by the use of the Global Positioning marises the paper and gives an outlook on future research.
System (GPS), enables a smartphone to calculate coordinates and
accuracy, only. As, from the perspective of the user, a seman-
tic location is more understandable than coordinate information,
2. RELATED WORK
location-aware or location-based systems map position information There has been a lot of active research on suitable models and
to semantically meaningful locations. For example, the GPS coor- representations for location data in the field of location models.
dinates 50.972 797 and 11.329 18 are precise but likely not mean- Location models are a core component of location-based applica-
ingful for humans. They belong to the building which is placed in tions. They represent not only location information, but also spatial
(or even spatio-temporal [7]) relationships in the data, help to ex-
press relative locations, proximity, and allow users to determine
containment of locations or connectedness of relationships.
The authors of [13] present in great detail the broad variety of lo-
cation models that has been developed in recent years of active re-
search. A key factor for distinguishing and characterising location
models is their way of representing spatial relationships. Accord-
ing to [1], they can be categorised into set-based, hierarchical, and
24th GI-Workshop on Foundations of Databases (Grundlagen von Daten-
banken), 29.05.2012 - 01.06.2012, Lübbenau, Germany. graph-based models. Hybrid models that combine several aspects
Copyright is held by the author/owner(s). exist as well. Figure 1 presents an overview of the three main lo-
5
Towards Modeling Locations as Poly-Hierarchies
cation model concepts. In the illustrated examples, the set-based return only single points. However, we can interpret Tanja’s current
approach is the least expressive one, as it only models the fact GPS coordinate as a set of positions of cardinality 1. As discussed
that there are two distinct locations within a set of locations, and in Section 1 it is a common understanding that locations have a hi-
a set of coordinates is assigned to each location. The hierarchical erarchic nature. The train station is located within a city, the city is
model adds containment information, and the graph-based model located in a state, the state within a country, and so on. Using this
adds connectedness and distance in the form of edge weights. subset-based location interpretation, LTanja ⊂ Lts ⊂ LWeimar ⊂
LThuringia ⊂ LGermany ⊂ LEurope ⊂ LEarth represents the loca-
tion of Tanja as path in a location mono-hierarchy.
Location A World Location A However, there exist various real-world issues that require a poly-
(1,2)
(1,2) (1,3) (2,3) (2,4) (1,2) hierarchical representation of locations. For example, Istanbul as
50
25 the capital of Turkey, belongs to the continents Europe and Asia.
60
Hence, LIstanbul 6⊂ LEurope and LIstanbul 6⊂ LAsia hold. The
Location C
Location B Location A Location B
Location B
same issue holds for Russia, which is located in Europe and in
Asia, too. Another problem results from enclaves. Kaliningrad,
(2,4) (1,3)
(1,2) (1,3) (2,3) (2,4)
e.g., is part of Russia, but this information is insufficient to decide
(2,3)
25 100
Location D Location E
whether Kaliningrad is part of Europe or part of Asia. The solution
Location c
(2,3)
10 (2,5)
for these problems is the use of set overlaps in combination with
containment relationships that form a location poly-hierarchy.
(1,2)
(a) (b) (c)
earth
earth
Figure 1: Examples for set-based (a), hierarchical (b), and
graph-based (c) location models. The edge weights in the
graph-based model represent distance information.
Europe
Asia
Europe
Asia
Hierarchical location models as a special case of set-based mod-
Turkey
Russia
els represent containment relationships between different levels of
the model and are widely used as basis for location-based applica-
tions [6, 2, 4]. Hierarchical models cannot represent distance infor-
mation or directly encode proximity, but they have great advantages Istanbul
Kaliningrad
in traversal and for containment queries. They are also very close to
the common human understanding of locations. As already stated (a) (b)
in Section 1, the widely acknowledged segmentation of locations
into administrative regions (country, state, city, street, and so on) is Figure 2: Examples for the Poly-hierarchical nature of loca-
also a hierarchical model that heavily relies on containment infor- tions: Istanbul (a), and Kaliningrad (b).
mation. On a city level, a lot of implicit information can be derived
through the top-level relationship to a state or country (e.g., admin-
istrative language, local cuisine, prevalent religions). Figure 2 illustrates the simplified poly-hierarchies for Istanbul
and Kaliningrad. From the definition of poly-hierarchies, we know
3. LOCATION POLY-HIERARCHIES that they can be represented by a directed acyclic graph LP H =
(V, E). Each node v ∈ V is a location and each directed edge e =
The authors of [12] define the term “location” as follows: “Lo- (v1 , v2 ) with v1 , v2 ∈ V represents that the child node v2 belongs
cation of an object or a person is its geographical position on the (semantically) to the parent node v1 . Each location poly-hierarchy
earth with respect to a reference point.” From our point of view, has an unique root node vr ∈ V with ¬∃vx ∈ V |(vx , vr ), because
this definition is too restrictive, because geographic positions are the entire coordinate system is closed in case of locations (all con-
points within a reference system. In contrast to a point, a location siderable positions are elements of the set of all positions on earth).
has a spatial extent. Another definition is given in [3]: “Geographic Finally, for each leaf node vl ∈ V that must not have any child
location is the text description of an area in a special confine on the node ¬∃vx ∈ V |(vl , vx ) holds.
earth’s surface.”. From a more theoretical point of view, an area is From an implementation point of view, each node in the poly-
a set of geographical positions. So, we use a set-oriented definition: hierarchy graph has the structure (n, P, C) where n is the name of
A location is a named set of geographical positions on earth with the location Ln , P is a set of edges to the parent nodes and C is
respect to a reference point. a set of edges to child nodes. The root node r = (earth, P, C) is
For example, in a two-dimensional coordinate system1 , the loca- the only node in LP H for which P = ∅ ∧ C 6= ∅ must hold. For
tion of a building, lets say a train station (ts), is given as set Lts = leaf nodes P 6= ∅ ∧ C = ∅, and for inner nodes P 6= ∅ ∧ C 6= ∅
{(x1 , y1 ), . . . , (xn , yn )}, where each position (point) (xi , yi ), 1 ≤ hold. For the concept described in the remainder of this paper, it
i ≤ n belongs to the train station building’s area. We discuss the is required to know the level of each node within this graph. The
calculation of the point set in Section 5.1. Consequently, we can level level(m) of a node m is defined as the number of nodes on
characterise the location of an object or a person as a relationship the longest direct path from r to m, plus one. As illustrated in
between sets. A person, lets say Tanja, is located at the train station Figure 2(b), level(Russia) = 2 and level(Kaliningrad) = 3.
if LTanja ⊂ Lts holds. Recent positioning technologies like GPS In a location mono-hierarchy each edge between a parent node
1
For simplification purposes, we use two-dimensional coordinates and a child node represents the fact that all points of the location
in this paper. However, the formalism can easily be adapted to three that corresponds to the child node are also elements of the location
dimensions. that corresponds to the parent node. However, as discussed before,
6
Towards Modeling Locations as Poly-Hierarchies
it is not sufficient to use subset relationships only. The semantics
of edges in the poly-hierarchical graph representation is as follows. Algorithm 1 Creating a location poly-hierarchy from a location set
Given a (child) node c = (nc , Pc , Cc ) the following relations hold:
• For each parent node p ∈ V referenced in Pc having level(p) Input: L = {L1 , . . . , Lk } // location set
with ¬∃p0 ∈ Pc |p0 6= p ∧ level(p) = level(p0 ) the edge
(p, c) ∈ E represents the subset relationship Lnc ⊂ Lnp . Output: LP H = (V, E) // location poly-hierarchy
• For each (parent) node p ∈ V referenced in Pc having level(p) 01 def naive_lph_create(L):
with ∃p0 ∈ Pc |p0 6= p ∧ level(p) = level(p0 ) the edge 02 V ⊂ = ∅ // init of the node set for subset relations
(p, c) ∈ E represents the overlapping relationship Lnc ∩ 03 V ∩ = ∅ // init of the node set for overlap relations
Lnp 6= ∅. 04 E ⊂ = ∅ // init the edge set for subset relations
05 E ∩ = ∅ // init the edge set for overlap relations
In other words this means that per hierarchy level each edge be-
06 LV = ∅ // init set of already analysed locations
tween a single parent node and the child node means an subset rela-
— S TEP 1: FINDING OVERLAP AND SUBSET RELATIONSHIPS —
tionship. If a child node has more than only one parent node in the
07 for each Lname1 ∈ L do
same level, then those links represent an overlap relationship. Fur-
08 for each Lname2 ∈ L − {Lname1 } − LV do
thermore, we know that the in the latter case, due to the directed
09 if Lname2 ⊂ Lname1 then
nature of the edges, the child node must be a subset of the union
10 V ⊂ = V ⊂ ∪ {name1 , name2 }
of the respective parent nodes (i. e., the conjunction of the overlap
11 E ⊂ = E ⊂ ∪ {(name1 , name2 )}
relationships per level holds).
12 fi
13 elif Lname1 ⊂ Lname2 then
earth
earth
14 V ⊂ = V ⊂ ∪ {name1 , name2 }
level=0
level=0
15 E ⊂ = E ⊂ ∪ {(name2 , name1 )}
16 fi
Europe
Asia
Europe
Asia
17 elif Lname2 ∩ Lname1 6= ∅ then
level=1
level=1
level=1
level=1
18 V ∩ = V ∩ ∪ {name1 , name2 }
19 E ∩ = E ∩ ∪ {(name2 , name1 )}
20 E ∩ = E ∩ ∪ {(name1 , name2 )}
Turkey
Russia
level=2
level=2
21 fi
22 done
23 LV = LV ∪ {Lname1 }
Istanbul
Kaliningrad
24 done
level=3
level=3
25 if E ⊂ == ∅ then return(FALSE) fi // no root node found
(a) (b) — S TEP 2: CLEANING UP E ∩ ( REMOVING LOOPS ) —
26 for each name1 ∈ V ∩ do
Figure 3: Examples for the semantics of edges in LP H, solid 27 Lt = ∅; E t = ∅ // temporary location and edge sets
lines represent subset relationships and dashed lines overlaps. 28 for each e ∈ V ∩ do
29 if e == (name1 , x) then
30 Lt = Lt ∪ {Lx }; E t = E t ∪ {(name1 , x)}
Figure 3 illustrates the link semantics for the Istanbul and the 31 fi
Kaliningrad examples. As one can see in Subfigure 3(a), LIstanbul ⊂ 32 done
LTurkey as Turkey is the only parent node of Istanbul at level two. 33 if Lname1 ⊂ Lt then E ∩ = E ∩ − E t fi
Since Istanbul has two parent nodes on level one (i. e., Europe and 34 done
Asia), these links represent the overlaps LIstanbul ∩ LEurope 6= ∅ and — S TEP 3: CLEANING UP E ⊂ ( TRANSITIVITY ) —
LIstanbul ∩ LAsia 6= ∅. The facts that (in addition) LTurkey ∩ LEurope 6= 35 for each name1 ∈ V ⊂ do
∅ ∧ LTurkey ∩ LAsia 6= ∅ holds, also implies LIstanbul ⊂ LEurope ∩ LAsia . 36 if ∃x, y ∈ V ⊂ ↔ {(x, name1 ), (y, x)} ∩ E ⊂ 6= ∅ then
We could use this “transitive” conclusion in a similar way for the 37 V t = {z|z 6= Sx ∧ (z, name1 ) ∈ V ⊂ }
Kaliningrad example, too. However, as show in Subfigure 3(b) it 38 E ⊂ = E ⊂ − z∈V t {(z, name1 )}
would reduce the expressivity of this LP H. Kaliningrad is only 39 fi
part of Europe but not of Asia. Hence, the Europe node is the only 40 V t = {x|(x, name1 ) ∈ E ⊂ } // all parents of name1
parent node of the Kaliningrad node at level one. 41 for each x ∈ V t do
42 V c = {y|(x,Sy) ∈ E ⊂ ∧ y ∈ V t − {name1 }}
43 if Lname1 ⊂ c∈V c Lc then
4. LPH CREATION 44 E ⊂ = E ⊂ − {(x, name1 )}
As discussed in Section 3 one could create an LP H using over- 45 fi
lap relationships only. We already pointed out that, in order to be 46 done
as expressive as possible, an LP H must use as many subset rela- 47 done
tionships as possible. Algorithm 1 creates the LP H from a given — S TEP 4: MERGING E ∩ WITH E ⊂ AND V ∩ WITH V ⊂ —
set L = {L1 , . . . , Lk } of locations. For illustration purposes, we 48 V = V ∩ ∪ V ⊂; E = E∩ ∪ E⊂
assume that names of locations are unique. However, one could 49 return(V , E)
also use location IDs instead of the names to guarantee uniqueness.
Our algorithm uses four main steps. In the first step (lines 7-24),
it creates two subgraphs, one (V ⊂ , E ⊂ ) containing all subset re-
7
Towards Modeling Locations as Poly-Hierarchies
lationships and one (V ∩ , E ∩ ) for all (additional) overlap relation- The same procedure removes the edges Istanbul→Europe and
ships. Figure 4 illustrates these subgraphs for the Istanbul and the Istanbul→Asia.
Kaliningrad examples. Obviously, step 1 might generate redundant
edges (cf., Figure 4(c)) earth→Russia→Kaliningrad and a4er
checking
(1)
Europe,
(2)
Asia
a4er
checking
(3)
Turkey
a4er
checking
(4)
Istanbul
earth→Kaliningrad) or (later on) unnecessary edges (cf., Fig-
Europe
Asia
Europe
Asia
Europe
Asia
ure 4(a) earth→Turkey). Furthermore, it generates loops in the
overlap subgraph as overlap relations have a symmetric nature (cf., Turkey
Turkey
Turkey
Figure 4(b) and Figure 4(d)). We illustrated those needless edges
using dotted arrows. Istanbul
Istanbul
Istanbul
Figure 6: Step 2 for the Istanbul example.
earth
Step 3 (lines 35-47) cleans up the subset subgraph using the tran-
Europe
Asia
Europe
Asia
sitivity property of subset relationships. In contrast to many graph
optimisation approaches, we do not aim for reducing the number of
edges in general, but for finding the minimal number of edges nec-
Turkey
Turkey
essary for representing correct semantics (cf. Section 3). For the
first optimisation (lines 36-39), we first calculate for each node the
set of parent nodes having parent nodes themselves. Afterwards,
we remove all direct edges from grandparents nodes as they can
Istanbul
Istanbul
be reached through the parents. In our examples, this removes
(a) V ⊂ , E ⊂ (b) V ∩ , E ∩ the edges earth→Istanbul and earth→Kaliningrad. A
second optimisation (lines 40-46) checks whether a node is con-
tained in the union of its sibling locations. If this is the case,
earth
we can remove the edge from the parent node (in our examples
earth→Turkey and earth→Russia), even if this fragments
the subgraph (cf. Figure 7).
Europe
Asia
Europe
Asia
earth
earth
Russia
Russia
Europe
Asia
Europe
Asia
Kaliningrad
(c) V ⊂ , E ⊂ (d) V ∩ , E ∩ Turkey
Russia
Figure 4: Intermediate graph(s) after step 1; (a,b) Istanbul,
(c,d) Kaliningrad. Istanbul
Kaliningrad
(a) Istanbul (b) Kaliningrad
Step 2 (lines 26-34) of the algorithm cleans up the overlap sub-
graph, i. e., it breaks the loops. Therefore, each node of this sub-
Figure 7: Intermediate graphs (V ⊂ , E ⊂ ) after step 3.
graph is analysed (cf. Figure 5). If the location represented by a
node is a subset of the union of all its direct child nodes, then we
remove the outgoing edges. Joining the subset subgraph(s) with the overlap subgraph, as it is
checking
Europe
checking
Asia
checking
Russia
done in the final step 4 (line 48), results in a connected LP H. The
Europe
Asia
Europe
Asia
Europe
Asia
fragmentation, that might have happened in step 2, is cured as the
removed edges resulted from an overlap relationship between the
Russia
Russia
Russia
involved nodes. For our examples, Algorithm 1 therefore creates
the location poly-hierarchies shown in Figure 3.
Figure 5: Step 2 for the Kaliningrad example; bold arrows
highlight the edges analysed for currently handled node that
Limiting factors
is marked gray. Algorithm 1 requires a complete and closed set of locations. With-
out the location Asia, the Kaliningrad example graph would loose
the LP H properties discussed in Section 3 as removing the Asia
Figure 6 illustrates step 2 for the Istanbul example. After check- node also removes the edge Asia→Russia. Without this edge,
ing the nodes for Europe and Asia, the node for Turkey is checked. the relationship Europe→Russia would be semantically wrongly
So far, it has the child nodes Europe and Asia. As all points of interpreted as subset relationship. In fact, Algorithm 1 could be
Turkey belong to Europe or Asia, both must not be represented adapted in order to recognise this case through topologic sorting
by child nodes of the Turkey node. So, these edges are removed. as the condition in line 33 would evaluate to false. Consequently,
8
Towards Modeling Locations as Poly-Hierarchies
E ∩ would still contain loops after step 2. Furthermore, the algo- poly-hierarchy from a given (closed and complete) set of locations.
rithm does not support differently named locations with equal sets We discussed limitations of the algorithm and also pointed out po-
of position points (i. e., La ⊆ Lb ∧ Lb ⊆ La holds). Step 1 would tential solutions to handle them. Finally, we discussed some issues
missinterpret this case as overlap relationship. Consequently, step 2 that need to be considered for the implementation of our strategy.
would nondeterministically remove one of the edges. A solution to However, there are many open issues that lead to future research
this problem would be a cleanup phase that unifies those locations directions. First of all we plan to evaluate the algorithm with real
before starting Algorithm 1. world data. We expect that the algorithm works properly, but we
are aware of the huge amount of data that needs to be processed.
5. IMPLEMENTATION ASPECTS Hence, we will have to optimise the algorithm in order to avoid
unnecessary (database) operations. Furthermore, we will research
As the “towards” in the title of this paper denotes, the presented whether it would be better to explicitly keep the information about
results are subject to ongoing research. We were not able to fin- the type of the relationships. This extended graph model would, of
ish the import of the evaluation database before the deadline. In course, ease the interpretability of the final location poly-hierarchy,
fact, importing the OpenStreetMap database containing data about but it would also increase the complexity of the model.
Europe (http://download.geofabrik.de/osm) using an
slightly adapted version of the osm2postgresql_05rc4.sh
script, which can be downloaded from http://sourceforge.
7. REFERENCES
[1] C. Becker and F. Dürr. On Location Models for Ubiquitous
net/projects/osm2postgresql, is still in progress. So
Computing. Personal and Ubiquitous Computing,
far it took more than two weeks (PosgreSQL 9.1 [9] with Post-
9(1):20–31, 2005.
GIS 1.5.1 [8] running on an iMac Intel Core 2 Duo 3.06 GHz, 4 GB
1067 MHz RAM, OS X 10.7.3). However, there are certain imple- [2] M. Beigl, T. Zimmer, and C. Decker. A Location Model for
mentation issues that we find worthwhile to be discussed. Communicating and Processing of Context. Personal
Ubiquitous Computing, 6:341–357, Jan. 2002.
5.1 Point sets of locations [3] Z. Dongqing, L. Zhiping, and Z. Xiguang. Location and its
The formal definition of locations and location poly-hierarchies Semantics in Location-Based Services. Geo-spatial
as discussed in Section 3 is based on set theory. From a theoret- Information Science, 10(2):145–150, June 2007.
ical point of view, those sets are infinite. A common approach to [4] F. Dürr and K. Rothermel. On a Location Model for
handle this infinity problem is to decrease the precision of set el- Fine-Grained Geocast. In A. K. Dey, A. Schmidt, and J. F.
ements through quantisation. However, it would not be useful or McCarthy, editors, UbiComp ’03 Proceedings, volume 2864
even possible to physically store (materialise) all points of all loca- of LNCS, pages 18–35, Berlin / Heidelberg, 2003. Springer.
tions. Hence, for the implementation of our approach we decided [5] M. Hazas, J. Scott, and J. Krumm. Location-Aware
to use a polygon-based representation of locations, where a set of Computing Comes of Age. IEEE Computer, 37(2):95–97,
polygons describes the boundaries of the locations. In principal, all Feb. 2004.
points that are inside of one of these polygons belong to the loca- [6] C. Jiang and P. Steenkiste. A Hybrid Location Model with a
tion. The OpenStreetMap data model provides an additional multi- Computable Location Identifier for Ubiquitous Computing.
polygon relation (cf., http://wiki.openstreetmap.org/ In G. Borriello and L. E. Holmquist, editors, Ubicomp ’02
wiki/Multipolygon_relation) for representing more com- Proceedings, volume 2498 of LNCS, pages 246–263,
plex areas. It allows, e. g., for areas within a location that do not London, UK, 2002. Springer.
belong to this particular location. Hence, from an implementation [7] T. Kauppinen, R. Henriksson, R. Sinkkilä, R. Lindroos,
point of view, a location is represented as a database view. The J. Väätäinen, and E. Hyvönen. Ontology-based
location name corresponds to the name of the view and the point Disambiguation of Spatiotemporal Locations. In IRSW ’08
set is defined by a database query resulting in the location outline Proceedings. CEUR-WS.org, 2008.
(multi)polygon. [8] OSGeo Project. PostGIS 1.5.1 Manual.
http://postgis.refractions.net/download/
5.2 Set operations postgis-1.5.1.pdf.
Interpreting locations as (multi)polygons necessitates a differ- [9] The PostgreSQL Global Development Group. PostgreSQL
ent interpretation of the used set operations, too. As discussed in 9.1.3 Documentation. http://www.postgresql.org/
Section 4, Algorithm 1 has to check subset and set overlap rela- docs/9.1/static/index.html.
tionships. Remember, a location La contains another location Lb [10] B. N. Schilit, A. LaMarca, G. Borriello, W. G. Griswold,
if and only if Lb ⊂ La holds. Hence, La must contain all points D. McDonald, E. Lazowska, A. Balachandran, J. Hong, and
(xb , yb ) ∈ Lb . For the polygon-based locations, the subset relation V. Iverson. Challenge: ubiquitous location-aware computing
means that the (multi)polygon describing La must cover those of and the “place lab” initiative. In WMASH ’03 Proceedings,
Lb completely. Similarly, an overlap relation of two locations im- pages 29–35, New York, NY, USA, 2003. ACM.
plies that the boundary (multi)polygons overlap (and vice versa). [11] M. Schirmer and H. Höpfner. Towards Using Location
Most geographical information system extensions, such as Post- Poly-Hierarchies for Energy-Efficient Continuous Location
GIS, provide the corresponding operators (cf. [8]). Determination. In GvD ’12 Proceeding. CEUR-WS.org,
2012. forthcoming.
6. SUMMARY AND OUTLOOK [12] A. Y. Seydim, M. H. Dunham, and V. Kumar. Location
We presented a novel approach to model (geographical) relation- dependent query processing. In MobiDE ’01 Proceedings,
ships among locations. We extended the effective, but not complete pages 47–53, New York, NY, USA, 2001. ACM.
location hierarchy approach in order to support enclaves and over- [13] J. Ye, L. Coyle, S. Dobson, and P. Nixon. A Unified
lapping locations. We formally introduced the new location poly- Semantics Space Model. In LoCA ’07 Proceedings, LNCS,
hierarchy model and presented an algorithm for creating a location pages 103–120, Berlin / Heidelberg, 2007. Springer.
9
10
Towards Using Location Poly-Hierarchies for
Energy-Efficient Continuous Location Determination
Maximilian Schirmer and Hagen Höpfner
Bauhaus-Universität Weimar
Media Department / Mobile Media Group
Bauhausstraße 11, 99423 Weimar, Germany
maximilian.schirmer@uni-weimar.de, hoepfner@acm.org
Keywords other hand, indoor GPS positioning is almost impossible because of
Location Determination, Location Poly-Hierarchies, Energy Effi- the occlusion and shielding of satellite signals created by building
ciency structures.
Mobile devices are battery-driven. So, energy is one of the most
limiting factors for their uptime. Additionally, the user acceptance
ABSTRACT of location-based or context-aware mobile applications is nega-
Location awareness is a key feature of mobile information systems. tively influenced when the applications heavily strain the mobile
Typically, location is determined by interpreting a set of measured devices’ batteries. Furthermore, location-based applications differ
positions. Various approaches for position determination do exist. in their required precision [16]. While the name of the city a user
They vary greatly in their precision, applicability, and energy re- or a device is currently located in might be appropriate for an event
quirements. As mobile devices are battery-driven, energy is one of information system, a navigation system might demand for exact
the most limiting factors for the system’s uptime. Locations have coordinates or street names at least. A common representation of
a hierarchical nature and location-based applications differ in their locations follows their hierarchical nature. In a hierarchical model,
required precision. In this paper, we present three approaches that earth is divided into continents, continents into countries, countries
utilise location poly-hierarchies in order to reduce the energy de- into states, states into cities, cities into streets and streets into street
mand of continuous location determination: (1) We analyse the numbers, and so on. Consequently, determining low-level location
dependencies among the different hierarchy levels, (2) we incor- information in this hierarchy also determines upper levels and con-
porate an adaptive delay between measurements based on the hier- tains information that is connected to these levels. In addition to
archy level and the calculated minimal required time to change, and this, locations only change if the device is moving. While GPS
(3) we select appropriate positioning techniques for each hierarchy coordinates might change with each movement, city information is
level. We implemented and evaluated our approaches. stable until the device leaves the city. Hence, the system might wait
with the next energy-demanding location determination on the city
1. INTRODUCTION AND MOTIVATION level until the device possibly left the city. In this paper, we present
Navigation systems, social network apps, tourist information sys- three approaches that utilise location poly-hierarchies for reducing
tems, event information systems, shop finders and many more heav- the energy demand of continuous location determination:
ily rely on position data of their users. Consequently, almost all 1. We analyse dependencies among different hierarchy levels.
modern smartphones supply positioning techniques. The most pop-
ular positioning technique is the Global Positioning System (GPS). 2. We postpone position measurements based on a calculated
However, even devices that do not provide GPS hardware are able minimal time that is required for leaving the current location.
to locate themselves using alternative techniques such as geotagged
Wi-Fi hotspot and cell tower databases (db), wireless signal trian- 3. We select appropriate positioning techniques for each hierar-
gulation/lateration, or geotagging. Although all of them allow lo- chy level.
calisation of a mobile device, they vary dramatically in precision,
applicability, hardware requirements, and energy demands. A GPS Our preliminary experimental results show that there is a strong po-
request requires a GPS receiver with a much higher energy demand tential in these techniques to reduce the energy demand compared
compared to an on-device database lookup that is based on already to continuous GPS polling.
localised cell towers or Wi-Fi hotspots [4]. However, in an outdoor The remainder of the paper is structured as follows: Section 2
scenario, GPS is far more precise than the analysis of location in- discusses related work. Section 3 introduces the concept of loca-
formation of connected Wi-Fi hotspots or cell towers [22]. On the tion hierarchies. Section 4 presents the three aforementioned ap-
proaches. Section 5 describes the evaluation approach and the re-
sults. Section 6 summarises the paper.
2. RELATED WORK
Our work mainly overlaps with the research fields location mod-
els and energy-aware computing. Location models form the basis
for all high-level operations on location data. Consequently, the
24th GI-Workshop on Foundations of Databases (Grundlagen von Daten-
banken), 29.05.2012 - 01.06.2012, Lübbenau, Germany. frequent and enduring use of location data in mobile computing
Copyright is held by the author/owner(s). immediately raises the issue of the mobile devices’ limited energy
11
Towards Using Location Poly-Hierarchies for Energy-Efficient Continuous Location Determination
resources. The field of energy-aware computing presents a variety requires dedicated software engineering with new concepts and al-
of concepts and methods to compensate for these constraints. gorithms [9].
One concept of energy-aware computing is resource substitution
2.1 Location Models [3]. It is based on the observation that in most cases, alternative
Location models as core components of location-based appli- resources exist for a given resource. These alternatives often vary
cations represent location information and spatial (or even spatio- greatly in their costs (e.g., computing power, storage capacity, or
temporal [15]) relationships in data. They help to express relative energy demands), but also in their accuracy, granularity, and fre-
locations, proximity, and allow users to determine containment of quency of data updates. This directly influences their appropri-
locations or connectedness of relationships. ateness for substitution. In general, resource substitution favours
The authors of [21] present in great detail the broad variety of resources with a lower cost (energy requirements) over expensive
location models that have been developed in recent years of active (high-energy) alternatives. In many cases, a high-energy resource
research. A key factor for distinguishing and characterising loca- is not necessarily required and can be substituted without measur-
tion models is their way of representing spatial relationships. Ac- able impact on system performance or user acceptance [19].
cording to [1], they can be categorised into set-based, hierarchical, The authors of [17] utilise resource substitution in the form of
and graph-based models. Hybrid models that combine several as- sensor substitution. In a location-based context, data from a GPS
pects exist as well. Figure 1 presents an overview of the three main device is often substituted with triangulation or lateration data from
concepts. In the illustrated examples, the set-based approach is the cell towers or Wi-Fi stations. A comparable concept is sensor trig-
least expressive one, as it only models the fact that there are two gering, where logical dependencies between different sensors are
distinct locations within a set of locations, and a set of coordinates used. When low-energy sensors detect changes in the environment,
is assigned to each location. The hierarchical model adds contain- a detailed update with high-energy sensors is triggered. An exper-
ment information, and the graph-based model adds connectedness iment described in [17] shows that low-energy accelerometer data
as well as distance in the form of edge weights. can be used to trigger high-energy GPS sampling. This approach
greatly reduces the energy demand of location determination for
mobile applications that do not require a gap-less reconstruction of
Location A World Location A
routes. This triggering approach has also been applied in the area of
(1,2)
(1,2) (1,3) (2,3) (2,4) (1,2)
civil engineering, where it is critical that autonomous sensor nodes
50
60
25
in buildings gather highly detailed data when vibrations occur. In
Location B Location C the “Lucid Dreaming” system [13], a low-energy analogue circuit
Location B Location A Location B
(2,4) (1,3) is sufficient to watch for these environment changes. It triggers
(2,3)
(1,2) (1,3) (2,3) (2,4)
a high-energy microcontroller-based sensor to gather the required
25 100
fine-grained data.
Location D Location E
Location c
3. TERMS AND DEFINITIONS
(2,3)
10 (2,5)
(1,2)
(a) (b) (c) According to [18], “location of an object or a person is its geo-
graphical position on the earth with respect to a reference point.”
Figure 1: Examples for different popular location models: set- From our viewpoint, this definition is too restrictive, as geographic
based (a), hierarchical (b), and graph-based (c). The edge positions are points. In contrast to a point, a location has a spatial
weights in the graph-based model represent distance informa- extent. Due to [5], “geographic location is the text description of an
tion. area in a special confine on the earth’s surface.”. However, an area
is a set of geographical positions. So, we use a set-oriented defini-
tion: A location is a named set of geographical positions on earth
Hierarchical location models as a special case of set-based mod- with respect to a reference point. In a two-dimensional coordi-
els represent containment relationships between different levels of nate system, e.g., the location of a building is given as a set, where
the model and are widely used as basis for location-based appli- each position (point) belongs to the building’s area. We do not dis-
cations [14, 2, 6]. They cannot represent distance information or cuss the calculation of point sets here, but rather refer to techniques
directly encode proximity, but they have great advantages in traver- of geographical information systems (GIS) [7]. The location mod-
sal and for containment queries. They are very close to the com- els presented in Section 2.1 describe relationships among locations.
mon human understanding of locations. Almost everyone under- However, reality requires a more sophisticated location model. Is-
stands the widely acknowledged segmentation of locations into ad- tanbul, as the capital of Turkey, belongs to Europe and Asia. The
ministrative regions (country, state, city, street, etc.). At this, on same issue holds for Russia, which is located in Europe and in Asia,
a city level, a lot of implicit information can be derived through too. Another problem results from enclaves: Kaliningrad is part
the top-level relationship to a state or country (e.g., administrative of Russia, but this information is not sufficient to decide whether
language, local cuisine, prevalent religions). Kaliningrad belongs to Europe or Asia. The solution for these prob-
lems is to use set overlaps instead of containment relationships in
2.2 Energy-aware Computing combination with a poly-hierarchical location model [11].
Energy-aware computing recognises the need for energy as a Figure 2 illustrates the simplified poly-hierarchies for Istanbul
factor in modelling and implementing computing systems in or- and Kaliningrad, represented as directed acyclic graphs. Each node
der to manage and reduce their energy demand. This includes both is a location and each directed edge represents that the child node
hardware and software systems. While energy-aware hardware has belongs (semantically) to the parent node(s). Moreover, the location
been under active research for many years, energy-aware software poly-hierarchy LP H has a unique root node because the entire co-
is still a novel and underestimated field of research. Hardware solu- ordinate system is closed in case of locations (all considerable po-
tions such as sleep modes or performance scaling cannot be directly sitions are elements of the set of all positions on earth). We do not
transferred or adapted to software systems. Energy-aware software discuss the construction of LP H in this paper, but assume that an
12
Towards Using Location Poly-Hierarchies for Energy-Efficient Continuous Location Determination
and Asia. So, the number of comparisons depends on the structure
earth
earth
of the given poly-hierarchy. Our algorithm calculates the correct
path for a given location while minimising the number of compar-
isons. We assume that the names of the leaf and inner nodes in
Europe
Asia
Europe
Asia
LP H are unique and referenced within the GIS db.
earth
earth
earth
earth
earth
Russia
Russia
Europe
Asia
Europe
Asia
Europe
Asia
Europe
Asia
Europe
Asia
Russia
Russia
Russia
Russia
Russia
Istanbul
Istanbul
Istanbul
Istanbul
Istanbul
Istanbul
Kaliningrad
(a) (b) (c) (d) (e)
(a) (b)
Figure 3: Traversing the location poly-hierarchy in case of Is-
Figure 2: Poly-hierarchical example locations: Istanbul (a), tanbul.
Kaliningrad (b).
earth
earth
earth
earth
expert defined it in advance. Furthermore, we assume that the level Europe
Asia
Europe
Asia
Europe
Asia
Europe
Asia
of a node is defined as the number of nodes on the longest direct Russia
Russia
Russia
Russia
path from root to this node, plus one. As illustrated in Figure 2(b),
level(Russia) = 2 and level(Kaliningrad) = 3. Kaliningrad
Kaliningrad
Kaliningrad
Kaliningrad
(a) (b) (c) (d)
4. LOCATION DETERMINATION STRATE-
Figure 4: Traversing the location poly-hierarchy in case of
GIES Kaliningrad.
The research question addressed in this paper is twofold: we
want to continuously determine the location of an object while re-
ducing the energy requirements for positioning, and we want to The algorithm works as follows (cf. Figures 3 and 4): At first, the
offer location information that is appropriate for different applica- proper leaf node is selected using a db query (F. 3(a); F. 4(a)). We
tion scenarios. The two extrema are: GPS polling and not mea- then traverse the LP H bottom-up and mark nodes that belong to
suring at all. Polling is the most energy-intensive approach and the correct path: The direct (grand)parent node(s) with the lowest
not measuring is the most imprecise “solution”. We developed level are analysed. If the current node has only one (grand)parent
three approaches for calculating appropriate location information node in this level, this node is selected as path anchor (F. 4(b)).
with a minimal amount of energy. The first strategy reflects the If more than one (grand)parent node exists on the minimal level,
fact that memory-intensive computations require much more en- we check them with a db query (F. 3(b)), mark the correct one and
ergy than CPU-intensive ones [8] and reduces the number of re- select it as path anchor (F. 3(c)). We continue with the path anchor
quired database lookups. The other two strategies aim for reducing until we reach the root node (F. 3(d); F. 4(c)). The last step is to
the number of GPS request and lookup operations in order to find collect the nodes on the path from root to the leaf node including
the correct path from a detected node to the root of LP H. This all marked inner nodes (F. 3(e); F. 4(d)).
path correctly describes the different levels of detail for the current
location. 4.2 Postponed Measurements
The postponed measurements strategy predicts the time required
4.1 Level Dependencies for a person or object to leave the current location. This time de-
In LP H the point sets’ cardinalities of locations represented pends on the hierarchy level, the geographical model used for this
by higher-level nodes are smaller than those of locations repre- level and on the movement speed [20].
sented by the linked lower-level nodes. The assignment of a lo- For simplification purposes, the application specifies the veloc-
cation to a set of positions uses default GIS techniques. So, a db ity of the moving object as a movement profile (pedestrians: ≈
stores border polygons, and a db lookup fetches the proper location 6 km h−1 , cyclists: ≈ 11 km h−1 , car drivers: ≈ 60 km h−1 ). The
values from the db. Hence, one location lookup requires certain most obvious approach is to take the object’s current position Lc =
memory-intensive operations. Moreover, in case of continuous lo- (xc , yc ) and then calculate the minimal Euclidean distance d to all
cation determination, queries must be performed for each move- locations within the current path in LPp H. For each location L on
ment of the requesting object. However, if we know about the this path, we have to calculate: min( (xc − xl )2 + (yc − yl )2
(semantic) dependencies among certain levels within the location |∀(xl , yl ) ∈ L). With a simple calculation, we then compute the
poly-hierarchy, we can reduce the amount of energy-intensive db time the object would need to leave this location. If, e.g., a pedes-
lookups by traversing LP H. trian is 5 km away from the city limit, he or she would need at
m∗3600 s
Figure 2(b) shows that if an object is located within Kaliningrad, least 50 minutes ( 50006000 m
= 3000 s) to leave the city. So, we
it is in Russia and Europe and on earth, too. So, only one compar- postpone the next position measurement by 50 minutes if the appli-
ison of location sets is necessary. For the example in Figure 2(a), cation requires the location at a city level. The Euclidean distance
this is not as trivial. The requesting object is located in Istanbul and guarantees the calculation of the shortest distance. Hence, if the
in Turkey. However, requesting the continent information requires velocity is correct, the calculation always returns a time window
an additional set comparison as Istanbul belongs to both Europe the moving object must be in the current location.
13
Towards Using Location Poly-Hierarchies for Energy-Efficient Continuous Location Determination
This approach is used for area-like locations where no route in- tions on the city level might be used in a polling mode. Anyway,
formation exists. In case of a map-based location management, we position-based location determination such as cell tower triangula-
utilise crossroad data to get more precise predictions (cf. [10]). tion in combination with a GIS requires too much calculation effort,
Therefore, we maintain a db with all crossroads and calculate the if used in a polling manner. However, we will research a combina-
Euclidian distance between the current position and the closest cross- tion of polled and time-triggered updates of location information in
road. Of course, the prediction is more exact if we use the en- a location poly-hierarchy in the near future.
tire map information but storing the complete maps would require
much space (e.g., for the German state of Thuringia, we have to 5. EVALUATION
maintain 125,034 crossroads or to store and query 657 MB of Open-
Our prototype is still work in progress. Therefore, we present a
StreetMap data).
preliminary evaluation that enabled us to estimate the energy foot-
Besides the postponement calculation for the various levels, we
print of our proposed concept in an exemplary scenario.
have to consider the poly-hierarchy as well. Referring back to the
Istanbul-Example: if the moving object is located in Istanbul, it 5.1 Experimental Setup
may take one hour to leave the city, but only 10 minutes to leave
The evaluation system was implemented as a mobile application
the continent. The solution for this issue is to analyse the LP H in
on the Android 2.3.4 platform. We conducted our tests with the
the following way. Given the LP H, the current location and the
recently released HTC Sensation smartphone. As shown in Fig-
current velocity. First we calculate the correct location path using
ure 5(b), the application is mainly a data logger for location and
the algorithm discussed in Section 4.1. In the next step, we cal-
power management data. In order to gather location data, we im-
culate the postponement value for each location in this path using
plemented a cell tower lateration algorithm, and used the Android
the appropriate calculation (Euclidian distance, crossroad analysis).
SDK’s methods for obtaining GPS data. The application reads
The minimal value determines the time until the next measurement.
energy-related data (battery voltage and current) directly from the
4.3 Level Appropriateness device’s power management. It was implemented as an indepen-
dent background logging service that gathers data even when the
There exist various technologies to measure positions such as
device is locked. The experimental setup follows our data-based
geotagged Wi-Fi hotspot and cell tower databases, wireless sig-
energy measurement approach, as described in [12].
nal triangulation/lateration, or geotagging. They vary in their en-
ergy demand and their precision. While looking at the location
poly-hierarchy one can recognise that locations represented closely
to the root node mostly require less precise location techniques.
Country information can directly be read from the country code
provided by mobile telecommunications operators. The city infor-
mation can be harvested from cell tower information using a simple
db lookup. We have to use the most high-energy GPS only if pre-
cise location information are required. The approach discussed in
the following combines the techniques illustrated in Section 4.1 and
Section 4.2.
Hierarchy level Level Technique
Earth 0 known to be true
Continent 1 Country code + Cell tower ID lookup
Country 2 Country code
State 3 Cell tower ID lookup
City 4 Cell tower triangulation
Street 5 GPS
Table 1: Location determination lookup table. (a) (b)
For the postponed measurements, we adapted the cross-level post- Figure 5: Celludroid evaluation app running on an HTC Sen-
ponement value in a way that we calculate different postponement sation smartphone.
values for each level while alternating the measurement strategy
(cf. Table 1). Let’s say that the object is located in Istanbul, and All data was stored in an sqlite database that could later on easily
that the GPS-based measurement resulted in a postponement value be used for analysis. For convenience, the application also shows
of 10 minutes for the continent, and a postponement value of 1 hour the estimated location on a map (cf. Figure 5(a)) and allows to
for the city. After 10 minutes, we then check the appropriateness explore the properties of nearby cell towers.
of the continent location using energy-efficient cell tower triangu- The cell tower lateration uses a Google service1 to look the lo-
lation and calculate a new postponement value for this level on this cation of nearby cell towers up. Because all retrieved cell tower
basis. Hence, in best case (we do not leave the continent), we can locations are cached in an sqlite database, subsequent location re-
wait with the next GPS positioning for 50 more minutes. quests for previously discovered cell towers do not require addi-
A more trivial approach supported by this idea are applications tional (high-energy) network communication.
that do not need exact position information. As mentioned above, 1
Unfortunately, access to this service is not publicly documented,
requesting the country information does not need any positioning our implementation is based on the general process documented
as the information is provided by the service provider. Further- in this forum article: http://stackoverflow.com/a/
more, less energy-intensive cell ID lookups for determining loca- 3356956
14
Towards Using Location Poly-Hierarchies for Energy-Efficient Continuous Location Determination
Our test run consisted of a sequence of 30-minute city walks, one 1100 GPS
for each test condition: 1000
900
a) baseline, 800
b) cell tower lateration, and 700 Cell tower
lateration
Energy [J]
600 Baseline
c) GPS. 500
In the baseline condition, the display was turned off, Wi-Fi was on, 400
GPS
Bluetooth was off, and no background tasks except our logging ser- 300 Cell tower
lateration
vice were running. During each run, power management data and 200
Baseline
cell tower locations were logged every second. GPS was requested 100
every 5 s. However, the Android SDK cannot guarantee an exact 0
time between GPS location updates. In fact, our measured time is 10 minutes 30 minutes
slightly higher (7.2 s on average).
From the power management data, we derived electrical power Figure 7: Comparison of accumulated energy demand.
and electrical energy data. In order to assess the accuracy of the
gathered location data, additional processing was necessary. While
the GPS data already included accuracy information, we computed even showed an error of more than 800 m. These extreme differ-
accuracy information for the cell tower lateration by comparing the ences highlight the fact that the reduced energy requirements of cell
gathered coordinates to their counterparts from the GPS run. This tower lateration condition have an at least equally drastic influence
enabled us to give an estimate for the upper bound of the error. on accuracy.
5.2 Results and Discussion 5.3 Scenario
The gathered results provide insight into the areas of applica-
Energy tion where sufficient potential exists to reduce the energy require-
Our results indicate that cell tower triangulation has no significant ments for continuous location determination. In this subsection, we
impact on the device’s energy demand at all. The baseline con- sketch a scenario that relies on our three conceptual pillars:
dition shows a total of 181.07 J after 10 minutes and 565.5 J after a) using level dependencies,
30 minutes, while the test run with cell tower lateration resulted in a
slightly higher 183.76 J after 10 minutes and 583.28 J after 30 min- b) postponed measurements,
utes. This difference of 1.5 % is within the measuring tolerance of c) using appropriate positioning techniques.
our method. Far more interesting is the difference between baseline
This scenario-based evaluation surely cannot serve as a proof for
1000 our proposed concept, but it provides a glimpse on its possible im-
900
800
pact. Our scenario application is a mobile tourist information sys-
700 tem for smartphones. All data is stored on the mobile device and
Power [mW]
600
500 can be accessed using db queries. The application can access the
400 following device’s location sensors:
300
200
100
a) SIM card operator’s country code (country information),
0
5 min 10 min 15 min 20 min 25 min 30 min
b) Cell tower association (state information),
Time
c) Cell tower lateration (city part/street information),
Figure 6: Comparison of power consumption for GPS (red line, d) GPS (street number information).
top) and cell tower lateration (blue line, bottom) during contin-
uous position determination. In our scenario, a tourist from Japan is on a bus tour through Ger-
many and is currently visiting Thuringia. In Weimar, she decides
and GPS condition. Figure 6 documents the power consumption to start using the tourist information system.
progress during cell tower and GPS run. In the GPS run, the device
required 316.07 J after 10 minutes and 1057.8 J after 30 minutes. Using level dependencies
Compared to baseline, this is an increase of 74.56 % after 10 min- Upon first use, the system requires a single positioning with cell
utes, or 87.06 % after 30 minutes (cf. Figure 7). Remember, GPS tower lateration. With the gathered coordinates, the country, state,
data was gathered every 7.2 s on average. In these 7.2 s, our setup and city nodes of the location poly-hierarchy can be determined:
required 4896 mJ of energy on average (7.2 s · 680 mJ s−1 ). In the earth→Europe→Germany→Thuringia→Weimar. The system
baseline condition, 7.2 s of idling required 1296 mJ of energy on uses this data to switch to the tour mode for Thuringia.
average (7.2 s·180 mJ s−1 ), which is 26.5 % of the amount required
for GPS. Using appropriate techniques according to level
In this mode, a continuous perimeter search delivers points of in-
Accuracy terest, such as restaurant, museums, public places, or theaters. Be-
The results regarding accuracy of the position determination tech- cause this feature at this point only requires the general information
niques are very clear. While the GPS condition results show an about the presence of such points of interest (and not a detailed
average of 9.2 m, cell tower lateration performs drastically worse routing information on how to get there), it is appropriate to rely on
at 308.26 m (a difference of 3242.55 %). Some outliers in the data cell tower lateration.
15
Towards Using Location Poly-Hierarchies for Energy-Efficient Continuous Location Determination
Postponing unnecessary measurements [5] Z. Dongqing, L. Zhiping, and Z. Xiguang. Location and its
When the tourist finished exploring the city, she wants to find a nice Semantics in Location-Based Services. Geo-spatial
place to have lunch. After selecting one of the restaurants from the Information Science, 10(2):145–150, June 2007.
perimeter search result list, the tourist information system enters [6] F. Dürr and K. Rothermel. On a location model for
the navigation mode. In this mode, a database of intersections is fine-grained geocast. In UbiComp ’03 Proc., pages 18–35.
used in combination with a movement profile to estimate important Springer, 2003.
turning points along a route where it is necessary to activate the [7] I. Heywood, S. Cornelius, and S. Carver. An Introduction to
GPS technique. Geographical Information Systems. Prentice Hall, Upper
Saddle River, NJ, USA, 2nd edition, Nov. 2002.
Estimation of reduced energy requirements [8] H. Höpfner and C. Bunse. Towards an energy-consumption
Upon first use, at least one GPS request can be saved. As we based complexity classification for resource substitution
have shown in the previous subsection, each request requires about strategies. In GVDB ’10 Proc., volume 581. CEUR-WS.org,
4896 mJ. The continuous perimeter search for points of interest May 2010.
took 2 hours in our scenario. During these 2 hours, a continu- [9] H. Höpfner and C. Bunse. Energy Awareness Needs a
ous GPS polling would have required about 1000 GPS requests Rethinking in Software Development. In ICSOFT ’11 Proc.,
(4896 J). In contrast, the cell tower lateration used by the sys- volume 2, pages 294–297. SciTePress, 2011.
tem only required 1296 J. Giving an estimation of the reduction [10] H. Höpfner and M. Schirmer. Energy efficient continuous
achieved by the postponed measurements in the navigation mode location determination for pedestrian information systems. In
(using the intersection database) is very difficult, as it relies on a MobiDE ’12 Proceedings, 2012. accepted for publication.
multitude of factors (e.g., velocity, distance between intersections). [11] H. Höpfner and M. Schirmer. Towards modeling locations as
A conservative lower bound would be to assume that this method poly-hierarchies. In GVBD ’12 Proc., May 2012. accepted
reduces the amount of GPS requests to 50 %. for publication, forthcoming.
[12] H. Höpfner, M. Schirmer, and C. Bunse. On measuring
6. SUMMARY, CONCLUSIONS, AND OUT- smartphones’ software energy requirements. In ICSOFT ’12
LOOK Proc., 2012. accepted for publication, forthcoming.
We addressed two research questions in the area of continuous [13] S. Jevtic, M. Kotowsky, R. P. Dick, P. A. Dinda, and
location determination: We analysed precision appropriateness and C. Dowding. Lucid dreaming: Reliable analog event
discussed energy requirements. We utilised the poly-hierarchical detection for energy-constrained applications. In IPSN ’ß07
nature of locations to provide different levels of location informa- Proc., pages 350–359. ACM, 2007.
tion. We discussed three approaches: We reduced the amount of [14] C. Jiang and P. Steenkiste. A hybrid location model with a
location calculations within the location poly-hierarchy, we intro- computable location identifier for ubiquitous computing. In
duced the concept of postponed measurements, and we discussed Ubicomp ’02 Proc., pages 246–263. Springer, 2002.
appropriateness issues in location poly-hierarchy levels. [15] T. Kauppinen, R. Henriksson, R. Sinkkilä, R. Lindroos,
The overall goal behind our research is to realise a location frame- J. Väätäinen, and E. Hyvönen. Ontology-based
work that application developers can use to implement location- Disambiguation of Spatiotemporal Locations. In IRSW ’08
aware applications without the need to take care of the high en- Proc., volume 422. CEUR-WS.org, 2008.
ergy requirements of GPS. We know that various frameworks do [16] B. N. Schilit, A. LaMarca, G. Borriello, W. G. Griswold,
exist and address the same issue. However, our results show the D. McDonald, E. Lazowska, A. Balachandran, J. Hong, and
potential to reduce the required energy further. The paper opens V. Iverson. Challenge: ubiquitous location-aware computing
various research directions that we will follow on: The concept of and the “place lab” initiative. In WMASH ’03 Proc., pages
location poly-hierarchies requires a detailed and formal definition. 29–35. ACM, 2003.
While location hierarchies and ontology-based models are well re- [17] M. Schirmer and H. Höpfner. SenST: Approaches for
searched, poly-hierarchies are rather novel. Furthermore, more re- Reducing the Energy Consumption of Smartphone-Based
search needs to be done in the area of calculating the postponement Context Recognition. In CONTEXT ’11 Proc., pages
values, and the combination of polling and postponed updates must 250–263. Springer, 2011.
be addressed. [18] A. Y. Seydim, M. H. Dunham, and V. Kumar. Location
dependent query processing. In MobiDE ’01 Proc., pages
7. REFERENCES 47–53. ACM, 2001.
[1] C. Becker and F. Dürr. On location models for ubiquitous [19] J. P. Sousa, R. K. Balan, V. Poladian, D. Garlan, and
computing. Personal and Ubiquitous Computing, M. Satyanarayanan. User Guidance of Resource-Adaptive
9(1):20–31, 2005. Systems. In ICSOFT ’08 Proc., volume SE/GSDCA/MUSE,
[2] M. Beigl, T. Zimmer, and C. Decker. A location model for pages 36–44. INSTICC press, 2008.
communicating and processing of context. Personal [20] O. Wolfson, B. Xu, S. Chamberlain, and L. Jiang. Moving
Ubiquitous Computing, 6:341–357, Jan. 2002. Objects Databases: Issues and Solutions. In SSDBM ’98
[3] C. Bunse and H. Höpfner. Resource substitution with Proc., pages 111–122. IEEE CS, 1998.
components — optimizing energy consumption. In ICSOFT [21] J. Ye, L. Coyle, S. Dobson, and P. Nixon. A unified
’08 Proc., volume SE/GSDCA/MUSE, pages 28–35. semantics space model. In LoCA ’07 Proc., LNCS, pages
INSTICC press, July 2008. 103–120. Springer, 2007.
[4] I. Constandache, S. Gaonkar, M. Sayler, R. R. Choudhury, [22] P. A. Zandbergen. Accuracy of iPhone Locations: A
and L. P. Cox. Energy-Efficient Localization via Personal Comparison of Assisted GPS, WiFi and Cellular Positioning.
Mobility Profiling. In MobiCASE ’09 Proc., pages 203–222. Transactions in GIS, 13(s1):5–26, July 2009.
Springer, 209.
16
Datenbank-Performance-Experimente in der Lehre
Max Flügel, Alexander Stein, Michael Höding
FH Brandenburg
Magdeburger Straße 50
14770 Brandenburg/Havel
(+49)3381 355 243
[fluegel|steina|hoeding]@fh-brandenburg.de
ABSTRACT 1.1 Problem
In diesem Beitrag stellen wir unsere Idee und deren Ansätze vor, In Unternehmen, in denen leistungsstarke Datenbanken und
die die Ausbildung im Bereich Datenbank-Performance mittels ein gutes Antwortzeitverhalten eine Rolle spielen, kommt es vor,
eines Praktikums unterstützen sollen. Wichtiges Element des Er- dass bezüglich der Datenbank-Performance voreilige und einseiti-
kenntnisgewinns ist das eigene Erleben im Rahmen von Experi- ge Entscheidungen getroffen werden und somit die sorgfältige
menten. Im Bereich Datenbank-Performance müssen Experimente Betrachtung der Datenbank-Performance zu kurz kommt.
und Experimentierumgebung so gestaltet und aufgebaut sein, dass
In der Lehre wird oftmals zu wenig Aufschluss über dieses
den Erwartungen an Vergleichbarkeit und Wissenszuwachs ent-
Thema gegeben bzw. in Veranstaltungen lediglich darauf hinge-
sprochen wird.
wiesen, dass Datenbank-Performance unter anderem bei Unter-
nehmen eine große Rolle spielt oder spielen kann. Welche Beiträ-
Keywords ge, sprich welche Methoden und/oder Werkzeuge, für eine opti-
Database Performance, Praktikum, Experiment male Performance-Auslastung eingesetzt werden können und wie
mit potentiellen Leistungsdefiziten umgegangen werden kann,
1. Einführung und Motivation wird im Rahmen der Lehre viel zu selten betrachtet. Eine Vertie-
Datenbank-Performance ist in Forschung, Lehre und Praxis fung durch eigene Übungen findet zudem i.d.R. nicht statt.
ein zentraler Betrachtungsgegenstand. Betriebliche Anwendungs- Ein weiteres Problem, welches mit der zuvor genannten Sachlage
systeme müssen durch akzeptable Antwortzeiten einen reibungs- einher geht, ist, dass das Thema Datenbank-Performance als sehr
losen Betrieb ermöglichen. Datenbankforschung und Datenbank- abstrakt und wenig kalkulierbar bzw. greifbar von vielen Studen-
hersteller haben hierzu eine Vielzahl von Methoden und Mecha- ten eingeschätzt wird. Es ist nicht genau klar, wie die Performan-
nismen entwickelt und eingeführt. Eine Aufgabe der Lehre ist es, ce dargestellt und beeinflusst werden kann.
diese Methoden zu vermitteln, um ihre Anwendung zu unterstüt-
zen. Zwar gibt es zunehmend Self-Tuning-Mechanismen in Da-
tenbankmanagementsystemen (DBMS), jedoch ist der gut ausge- 1.2 Zielstellung
bildete Datenbankadministrator ein wichtiges Erfolgselement des Für die genannten Problemfelder sollen in der Lehre ein hö-
soziotechnischen Gesamtsystems. herer Stellenwert und die notwendige Akzeptanz erreicht werden.
Dabei soll nicht nur die Datenbank-Performance als solche be-
Um Studierende für ein Thema zu motivieren und auch zu begeis- leuchtet werden. Auch Wirtschaftlichkeitsbetrachtungen der Per-
tern, muss ihnen die Möglichkeit gegeben werden, Erkenntnisse formance sollen mit einfließen. Kernziel ist es, mögliche Um-
in der praktischen Arbeit zu erlangen. Hierzu können Experimen- gangsweisen mit der Performance von Datenbanken deutlich zu
te eingesetzt werden, welche sich unter anderem durch selbststän- machen.
diges Arbeiten auszeichnen. Der Student wird durch eine Aufga-
benstellung mit einem in der Theorie beschriebenen Problem Erreicht werden kann dieser Ansatz durch das praktische Ar-
bekannt gemacht. Das Experiment hat in seiner Struktur einen beiten mit Datenbank-Performance-Experimenten in der Lehre.
festen Rahmen. Dieser unterstützt den Studenten ein Thema me- In mehreren Übungsveranstaltungen sollen die Studenten ei-
thodisch zu betrachten (vgl. [2] S.239). Zusätzlich erlernt der genständig Praxiserfahrungen sammeln können, um Datenbank-
Student neben neuem Wissen auch soziale Kompetenzen (Team- Performance selbst zu erleben. Hierfür soll aufgezeigt werden,
fähigkeit, Konfliktlösung, usw.). wie die Performance gemessen und interpretiert werden kann. Im
Nachgang werden Methoden und Werkzeuge vorgestellt, mit
denen die Performance optimiert wird. Denkbar wäre auch, dass
die Studenten selbst nach geeigneten Möglichkeiten suchen und
diese dann anwenden müssen.
Ziele sind demnach:
Performance erleben
Performance-Messmethoden kennenlernen und einsetzen
24th GI-Workshop on Foundations of Databases (Grundlagen von Da-
tenbanken), 29.05.2012-01.06.2012, Lübbenau, Germany.
Copyright is held by the author/owner(s).
17
Datenbank-Performance-Experimente in der Lehre
Gesamtarchitektur betrachten (beispielsweise zugrundelie- Die jeweiligen Tests lassen sich dabei in die Phasen Vorberei-
gendes System) und analysieren, um „Flaschenhälse“ zu er- tung, Durchführung und Nachbereitung aufteilen (vgl. [6] S. 253).
kennen Die Tests werden entsprechend dokumentiert, um daraus Maß-
nahmen abzuleiten. In der Vergangenheit haben sich für System-
Optimieren der Performance
bzw. Softwaretests verschiedene Normen und Standards entwi-
Wirtschaftlichkeit von Performance-Lösungen betrachten ckelt. Hier ist unter anderem die DIN 66273 (Vorgehensmodell
für die Lastmessung) zu nennen.
Dabei werden fachliche als auch überfachliche Fähigkeiten aus-
geprägt.
2.2 Aufbau des Praktikums
Um Performance für die Studenten erlebbar zu machen, wird
2. Theoretische Grundlagen begleitend zur Vorlesung ein Praktikum durchgeführt. Dieses
Um Performance zu erleben, sollen Performance-Tests und die Praktikum teilt sich in einzelne Experimente auf. Die Experimen-
didaktische Methode Experiment miteinander verbunden werden. te bauen in der Folge aufeinander auf, so erhalten die einzelnen
Im folgenden Abschnitt wird auf Performance-Tests und ihre Experimente einen roten Faden. Es werden die wichtigsten Eck-
Rolle in den Systemtests eingegangen. Im Anschluss daran wer- punkte der Performance-Messung berücksichtigt. Innerhalb der
den das Experiment in seiner Methode und die wesentlichen Pha- einzelnen Experimente sollen bewusst die Stellschrauben an den
sen beschrieben. Abschließend sollen die Zusammenhänge zwi- Systemen geändert werden, um die Wirkung der einzelnen Va-
schen beiden Themenfeldern aufgezeigt werden. riablen auf das Verhalten des Systems zu erkennen und anschlie-
ßend zu bewerten. Der Student soll hierbei selbstständig die Wer-
2.1 Performance-Test te der Variablen ändern können.
„Die Performance oder Leistung in der Informatik ist die Fä- Das Experiment lässt sich gemäß K. Reich in drei Phasen auftei-
higkeit eines Systems, eine Aufgabe in einer bestimmten Zeit zu len (vgl. [3] S. 7):
erledigen“ ([4] S. 439). Dabei wird Performance durch den An- Am Beginn steht die Planungsphase. Hier wird die Vorbe-
wender wahrgenommen und muss entlang der Zielgruppen- trachtung umgesetzt. Zudem wird die Fragestellung formu-
Anforderungen betrachtet werden (vgl. [4] S. 439). So werden liert, auf deren Basis eine Hypothese aufgestellt werden
Wartezeiten bei Datenanalysen durch den Nutzer eher akzeptiert, kann. Weiterhin werden die Randbedingungen des Experi-
als die Wartezeit bei Internetsuchmaschinen. Die Performance ments beschrieben und der Versuchsaufbau geplant.
eines Systems lässt sich hingegen durch Tests systematisch nach-
weisen und im Anschluss gegebenenfalls an die Anforderungen Dann erfolgt die Durchführungsphase. In dieser Phase wird
anpassen. Dabei gehören die Performance-Tests zu den System- die Planung umgesetzt, indem der Praktikumsversuch durch-
tests. Systemtests werden nach H. Balzert in Funktionstest, Leis- geführt wird.
tungstest, Benutzbarkeitstest, Sicherheitstest und Interoperabili- Nach der Durchführung des Experiments erfolgt die Nachbe-
tätstest unterteilt. Diese Tests dienen zur Bestimmung der Pro- trachtung bzw. Auswertungsphase. Hier werden die Ergeb-
duktqualität eines Softwaresystems (vgl. [5] S. 503 ff.). Durch nisse überprüft und hinsichtlich der potentiellen Fehlerquel-
Leistungstests können zwei grundsätzliche Fragestellungen be- len analysiert.
antwortet werden:
Daraus wird für die praktische Umsetzung folgender Ablauf abge-
Wie viele Daten kann das System verarbeiten? leitet:
Wie lange braucht das System für die Datenverarbeitung? 1. Aufgabe stellen; durch den Lehrenden
Zusätzlich können hier auch die Dimensionen der Belastung ein- 2. Vorbetrachtung; durch den Studierenden
gegliedert werden. Hierzu zählen die Tests unter normalen Bedin- 3. Überprüfung; durch den Lehrenden
gungen des Regelbetriebs, das Testen im Grenzbereich durch 4. Praktikumsversuch; durch den Studierenden
Lasttests und das bewusste Überschreiten des Grenzbereichs
durch Stresstests. 5. Nachbetrachtung; durch den Studierenden
6. Evaluation des Experiments; durch den Lehrenden
Bei der Formulierung der Aufgabenstellung sind zwei Extreme
denkbar. Zum einen besteht die Möglichkeit, die Aufgabe völlig
offen und ohne Restriktionen zu stellen, z.B. „Untersuchen Sie
das System in Bezug auf CPU, Arbeitsspeicher und Storage!“.
Zum anderen kann durch eine geschlossene Aufgabenstellung die
Aufgabe so klar formuliert sein, dass der Student einen fest vor-
geschriebenen Weg beim Abarbeiten der Aufgabe einschlägt und
garantiert zum Ziel kommt. Beide Varianten haben nach Meinung
der Autoren ihre Vor- und Nachteile (siehe Tabelle „Vor- und
Nachteile bei der Aufgabenstellung“). Die zweckmäßigere Va-
riante soll im Rahmen des Projekts ermittelt werden.
Abbildung 1: Systemtest
18
Datenbank-Performance-Experimente in der Lehre
Tabelle 1: Vor- und Nachteile bei der Aufgabenstellung tlich der in der Vorbetrachtung getroffenen Hypothese. Hier soll
der Student durch eine ehrliche und realistische Einschätzung
Offene Aufgabenstellung Aufgabenstellung mit Rest- seiner ursprünglichen Annahme das Resultat seines Versuchs
riktionen bewerten. An dieser Stelle sollte auch eine Fehleranalyse mit
einfließen. Neben der technischen Beurteilung zählen auch die
+ Der Student kann sich frei + Ergebnis ist schnell über- Wirtschaftlichkeitsbetrachtungen (Verhältnis zwischen Nutzen
entfalten prüfbar und Aufwand/Kosten) zu den Erfordernissen dieser Phase.
Abschließend wird das Experiment vom Lehrenden evaluiert.
+ Neue Erkenntnisgewinne + Ergebnis ist nachvollziehbar Zum einen wird im Rahmen der Evaluation die Einhaltung der
formalen Vorgehensweise geprüft, hier die Phasen des Experi-
+ Vielfältige Ergebnisse sind + Ergebnisse sind vergleich- ments und die Dokumentation. Zum anderen wird die Plausibilität
möglich bar begutachtet. An dieser Stelle müssen die Vor- und Nachbetrach-
tung in einem logischen Zusammenhang stehen, d.h. wurde in der
- Ergebnis ist ungewiss - Erkenntnisgewinn ist vorge- Nachbetrachtung auch auf genau das eingegangen, was in der
schrieben Vorbetrachtung geplant wurde. Das setzt natürlich voraus, dass in
der Durchführungsphase auch das umgesetzt wurde, was in der
- Ergebnis und Experiment - Experiment lässt wenig Platz Vorbetrachtungsphase angesetzt wurde.
evtl. nicht nachvollziehbar für Eigeninitiative
Der Evaluationsaufwand steigt natürlich auch mit steigendem
Grad einer offenen Aufgabenstellung. Hier ist ganz besonders
- Ergebnisse eventuell schwer - Gänzlich neue Erkenntnis-
darauf zu achten, wie die Studierenden vorgegangen sind und wie
vergleichbar se/Lösungswege sind kaum
plausibel der eingeschlagene Lösungsweg ist. Näher betrachtet
möglich
werden muss an dieser Stelle der wissenschaftliche Anspruch des
Lösungswegs.
Folgende Themengebiete sind beispielsweise für das Praktikum
denkbar:
Erkundung der Systemeigenschaften
Einfluss der SQL-Statements
Nutzen und Wirkung von Indexen
Arbeiten mit Puffern
Die Experimente werden durch den Studenten vorbereitet. In
dieser ersten Phase müssen sich die Studenten die Aufgabenstel-
lung genau versinnbildlichen und eine Zielstellung definieren. Im
Anschluss daran gilt es den Lösungsweg zu planen. Dabei sollen
theoretische Grundkenntnisse und das spezifische Fachwissen aus
den Lehr- und Übungsveranstaltungen ebenso dienen, wie Kenn-
tnisse und Fähigkeiten, welche sich die Studenten für die Aufga-
benerfüllung selbstständig aneignen müssen. Desweiteren sollen
die Prämissen der Planungsphase laut K. Reich zum Tragen
kommen (siehe oben), d.h. die Studenten sollen mittels des er-
langten Wissens eine Hypothese parallel zur Aufgabenstellung
formulieren und diese Annahme dann durch ihren Praktikumsver-
such entweder bestätigen oder widerlegen. Wenn eine Aufgabe
beispielsweise verlangt eine bestimmte Datenmenge aus einer
Datenbank einerseits mit einem SQL-Statement und andererseits
mit Programm-Code (z.B. PHP, Java) abzufragen, dann könnten
die Studenten hier die Hypothese aufstellen, dass das Abfragen
mittels SQL performanter als das Abfragen mit Programm-Code
ist. Als Ergebnis der Vorbetrachtung entsteht der Protokollent-
wurf.
Erst bei ausreichender Vorbetrachtung des Experiments, wird die
Durchführung durch den Lehrenden möglich gemacht, hierzu
erfolgt eine Überprüfung. Während des Praktikumsversuchs wird
der Vorplanung entsprochen und die Aufgabenstellung praktisch
gelöst. Die Ergebnisse werden in einem (Mess-)Protokoll festge-
halten. Abbildung 2: Ablauf eines Experiments
Nach erfolgreicher Durchführung des Praktikumsversuchs, wer-
den die Ergebnisse in der Auswertungsphase (Nachbetrachtung)
zusammengefasst und beurteilt. Die Beurteilung erfolgt hinsich-
19
Datenbank-Performance-Experimente in der Lehre
Für die Durchführung der Praktikumsversuche soll ein im Vorfeld Tabelle 2: Aufteilung der Gruppen
festgelegter Wochentag, der Versuchstag, dienen. Die Festlegung Studierendenzahl
auf einen solchen Versuchstag und den übrigen „normalen“ Tagen
erfolgt einerseits aus lehrbedingten und andererseits aus techni- 40 60 80
schen Gründen. Die Studenten sollen Erfahrungen mit einem
2 20 30 40
technisch „großen“ Umfeld sammeln können. Das bedeutet, dass
sie die Performance von umfangreichen Datenbanken in leis- Gruppen- 3 12*3+1*4 20 24*3+2*4
tungsstarken Experimentierumgebungen (Servern) testen sollen. stärke
An den Versuchstagen stehen diese Experimentierumgebungen 4 10 15 20
zur Verfügung. An den übrigen Tagen haben die Studenten Zu- 5 8 12 16
griff auf wesentlich „kleinere“ Umgebungen, um ihre Prakti-
kumsversuche vorbereiten bzw. nach den Versuchen Nacharbei-
ten durchführen zu können. Genaueres zum Zusammenspiel der Es wird für die weitere Planung von einer maximalen Gruppen-
beiden Umgebungsarten ist im vierten Kapitel nachzulesen. zahl von 20 Gruppen ausgegangen, d.h. bei einer Studierenden-
zahl von 40-80 Studierenden eine Gruppenstärke von 2-4 Studie-
Die Zeit zwischen den Versuchstagen soll durch den Studenten rende je Gruppe. Innerhalb der einzelnen Gruppen müssen dann
für die Vorbereitung und Nachbereitung seines Versuchs dienen. die aus dem Einzelexperiment abgeleiteten Aufgaben entspre-
Die jeweiligen Schritte der Experimente werden durch den Stu- chend aufgeteilt werden. Ist die Studierendenzahl über 80, muss
denten dokumentiert und lassen sich zum Abschluss des Prakti- die Gruppengröße auf 5 erhöht werden, um die Gesamtgruppen-
kums als Basis für die Prüfungsnote nutzen. zahl von 20 nicht zu überschreiten.
2.3 Zusammenhang zwischen Performance- 3.2 Rolle des Studierenden
Test und Experimenten Der Studierende wird während der Experimente selbst aktiv.
In der Informatik kann man Performance-Tests zu den Experi- Durch entsprechende theoretische Vor- und Nachbetrachtungen
menten zählen (vgl. [7] S. 233 ff.). Wie in jedem Test folgen auch wird er ein optimales Verhältnis zwischen Theorie und Praxis
Performance-Tests einer bestimmten Abfolge. Tests werden ge- erhalten. Er schult neben den rein fachlichen Fähigkeiten auch
plant und im Anschluss durchgeführt. Die Ergebnisse des Tests andere Kompetenzen. So muss er gerade in der Zusammenarbeit
werden dokumentiert und ausgewertet. Genauso wie Experimente mit anderen Studierenden seine Kommunikationsfähigkeit schu-
müssen Tests auch vergleichbar und reproduzierbar sein. Wenn len und auch sich selbst und die Gruppe in der er arbeitet organi-
man diesem allgemeinen Vorgehen folgt, lassen sich hier Paralle- sieren. Bei der jeweiligen Gruppenorganisation wird vorausge-
len zum Experiment ziehen. Die Studenten sollen diese Parallelen setzt, dass sich die Studierenden eigenständig für die Aufgaben
erkennen und sie für den Aufbau der Experimente nutzen. einteilen, bei denen ihre fachlichen Stärken liegen (z.B. Doku-
mentation, Programmierung, System-Administration). Als primä-
3. Organisation der Lehre re Anforderung an den Studierenden muss dessen Interesse, neue
Nachdem die Begriffe Experiment und Performance-Test be- Sachverhalte zu entdecken, geweckt werden (vgl. [3] S. 12). Die
schrieben sind, soll nun gezeigt werden, wie das Experiment die Fähigkeit, eventuell auftretende Konflikte frühzeitig zu erkennen
Lehre beeinflusst. Es wird dabei auf die Aufteilung der in der und diese abzustellen, wird als sekundäre Anforderung angese-
Lehrveranstaltung teilnehmenden Studenten und die daraus resul- hen.
tierenden Gruppenstärken ebenso eingegangen, wie auf die Rolle
des Lehrenden und des Studenten bei dieser Form der praktischen 3.3 Rolle des Lehrenden
Übung Dem Lehrenden wird während des Experiments eher die passiv
unterstützende Rolle zu teil. Er führt in den Vorlesungen in die
3.1 Aufteilung der Lehrveranstaltung Thematik ein und vermittelt dabei die theoretischen Grundlagen
Für die Experimente sollen sich die Studierenden in Gruppen (vgl. [3] S. 11). Während der Experimente wird er beratend zur
zusammenfinden. Die Arbeit im Team wird erfahrungsgemäß Seite stehen und dem Studenten bei Bedarf Denkanstöße geben.
bessere Ergebnisse hervorbringen als Einzelarbeit, da sich die Er muss nach der Vorbereitungsphase eine erste Überprüfung des
Studenten mit ihren unterschiedlichen Wissensständen austau- Aufbaus und des Experiments durchführen, bevor er den Prakti-
schen und somit ergänzen können. Zudem ist die Bildung von kumsversuch durchführen lässt. Es wäre hier vorstellbar Lern-
Gruppen der Ressourcenplanung dienlich, wie in Kapitel vier plattformen wie Moodle [11] einzusetzen, um in einem kurzen
ersichtlich wird. Wissenstest die Vorbereitung zu überprüfen. Auch die Ergebnisse
des Praktikumsversuchs (z.B. das Messprotokoll) können via
In der Fachhochschule Brandenburg im Studiengang Wirtschafts- Moodle verwaltet und überprüft werden.
informatik wird pro Semester mit einer Studierendenzahl von bis
zu 80 Studenten ausgegangen. Dabei ist eine Aufteilung in maxi-
mal 20 Gruppen noch handhabbar. So können diese 20 Gruppen 4. Ressourcenplanung
ihre Praktikumsversuche (am Versuchstag) in maximal 4 Blöcken Um den Studentengruppen die Möglichkeit der praktischen Arbeit
á 90 Minuten durchführen. Es ergibt sich folgende Matrix der zu geben, sind Experimentierumgebungen auf und mit speziellen
Gruppenstärke und Aufteilung: Systemen (Hardware und Software) notwendig.
20
Datenbank-Performance-Experimente in der Lehre
4.1 Einsatz von Virtualisierung sind, bleiben die Versuchs-VMs inaktiv (siehe nachfolgende Ab-
Für die Lehre der Messung von Datenbank-Performance ist es bildung).
wichtig, dass in einem Umfeld gearbeitet wird, in dem keine oder Die eigentlichen Praktikumsversuche werden auf den Versuchs-
nur sehr wenige Leistungsschwankungen bzgl. der Hardware zu systemen mit großen VMs realisiert. Diese VMs besitzen eine
erwarten sind. Grundsätzlich kann es eine mögliche Lösung sein, große Datenbank und deutlich mehr Leistung und ermöglichen
in die bestehende Infrastruktur der Hochschule einen zusätzlichen Performance-Tests in großem Umfang. Zeitlich werden die Ver-
Server oder ein Server-Blade zu integrieren, welcher von anderen suchs-VMs so geschaltet, dass an den Versuchstagen die Entwick-
Servern zumindest Software-seitig abgekapselt wird. lungs-VMs der Gruppen abgeschaltet und die Versuchs-VMs
aktiviert werden.
Nun stellt das gleichzeitige Arbeiten der Studentengruppen auf
einem und demselben Server keine gute Lösung dar, da kaum Nach den Praktikumsversuchen, werden die Systeme entspre-
feststellbar ist, welche Server-Ressource oder Software gerade chend umgedreht wieder aktiviert bzw. deaktiviert.
von einer bestimmten Gruppe beansprucht wird. Hier sind ein In der nachfolgenden Abbildung sind die schematische Aufteilung
eindeutiges Messen der Performance und somit vergleichbare der unterschiedlichen VM-Gruppen und deren Aktivität ersich-
Experimente nicht möglich. tlich.
Die Lösung stellt hier die Server-Virtualisierung dar. „Die Virtua-
lisierung abstrahiert die physische Hardware vom Betriebssystem.
Die klassische 1:1-Verbindung von Hardware und Betriebssys-
tem, die man vor allem in der PC-Welt kennt, wird aufgehoben;
dazwischen wird eine neue Schicht gelegt, die diese Abstraktion
vornimmt, die Virtualisierungsschicht.“ ([10] S. 33) Die Aufgabe
des Virtualisierens für die Experimentierumgebung übernimmt
das VMware-Produkt vSphere mit seinem ESX Server (siehe
nachfolgende Abbildung).
Abbildung 4: Aufbau der Experimentierumgebung
Durch Anfertigen von Clones (Klone) der ersten angelegten VM
pro VM-Gruppe kann schnell die gewünschte VM-Anzahl er-
Abbildung 3: Konventioneller Server-Aufbau (links) versus reicht werden, ohne jede VM einzeln auf herkömmlichem Wege
Server-Virtualisierung (rechts) ([10] S. 33) anlegen zu müssen.
Durch die Virtualisierung können auf dem Server mehrere virtuel- Die zugrundeliegenden Ressourcen, sprich die physische Hardwa-
le Maschinen (VMs) eingerichtet werden, innerhalb derer die re des Servers, wird unter den jeweils aktiven VMs fest aufgeteilt.
Studenten dann ihre Experimente unter gleichen Rahmenbedin-
gungen (Vereinheitlichung der Hardware bzw. virtuellen Hardwa- Mit der Virtualisierungs-Lösung können folgende positive Nebe-
re) durchführen können. Jede VM erhält dann ihr eigene Soft- neffekte für das Praktikum erreicht werden:
wareumgebung, wie Betriebssystem (engl.: Operating System
oder kurz: OS), Datenbank und weitere Applikationen (App), wie Performance-Steigerung der Systeme
beispielsweise Performance-Tools. Dies ist in der obigen Abbil- Berücksichtigung von Aspekten der Green-IT (Einsparung
dung durch die kleinen Würfel dargestellt. von Hardware, Verringerung des Stromverbrauchs und
Die zum Einsatz kommenden VMs lassen sich in Entwicklungs- Kühlaufwands)
systeme und Versuchssysteme unterteilen. Die Systeme unter- Gute Administrierbarkeit der Experimentierumgebung (Än-
scheiden sich im Wesentlichen durch ihr Leistungsspektrum und derungen an den VMs, Zurücksetzen der VMs durch Snaps-
ihre Benutzung. hots) ([10] S. 34 ff.)
Für die Planung des Versuchsaufbaus kommen Entwick- Die genannten Nebeneffekte können den Studenten in der Lehre
lungssysteme zum Einsatz. Das sind kleine VMs, sprich VMs mit kommuniziert bzw. selbst von ihnen erfahren werden.
einer geringeren Leistung und Konfiguration. Jede Gruppe erhält Zudem kann als positiv angesehen werden, dass bei eventuellen
eine solche Entwicklungs-VM an der sie Änderungen vornehmen Schäden am System lediglich eine VM betroffen sein wird und
kann bzw. bestimmte Teilaufgaben bereits im Vorfeld testen nicht der Server bzw. die Hardware direkt. Die beschädigte VM
kann. Diese Systeme stehen den Gruppen zwischen den einzelnen kann dann wieder in den Urzustand zurückgesetzt werden.
Versuchstagen zur Verfügung. Die Entwicklungssysteme erhalten
eine kleine Datenbank. Während die Entwicklungs-VMs aktiv
21
Datenbank-Performance-Experimente in der Lehre
4.2 Konfiguration der virtuellen Maschinen werden, so dass in der Vorlesung ein Pool an Methoden und
Ausgehend von der Gruppenplanung aus dem Abschnitt 3.1 kann Werkzeugen vorgestellt wird und der Student entscheidet im
die nachfolgende Konfiguration für die VMs abgeleitet werden. Rahmen des Experiments, wie er vorgehen möchte. In der weite-
Hierbei wird lediglich auf die Zusicherungen von Arbeitsspeicher ren Arbeit muss geprüft werden, welche der beiden Methoden den
und Festplattenkapazität eingegangen. Studenten am besten beim Lernprozess unterstützt.
Den Entwicklungs-VMs wird während der Entwicklungszeit 4 GB
Arbeitsspeicher zugesichert. Daraus resultiert ein Arbeitsspei-
5. Fazit und Ausblick
Performance ist wichtig. Das ist jedem, der mit Daten-
cherbedarf von 80 GB. Wird an dieser Stelle mit einer Reserve
banksystemen zu tun hat, klar. Den Studierenden ein Gefühl für
kalkuliert, kommt man, in Anbetracht der gängigen Konfiguration
diese Thematik zu geben, dass ist eine der Herausforderungen der
von RAM-Modulen, auf einen erforderlichen Arbeitsspeicher von
Lehre. Um diese Herausforderung zu meistern, bieten sich Expe-
96 GB. Mit den 16 GB Reservespeicher kann unter anderem die
rimente an. Dadurch kann der Student praktische Erfahrungen im
Gruppenzahl bei Bedarf erhöht werden (4 Gruppen mehr mit wie-
Bereich Datenbank-Performance erlangen. Damit den Studenten
derum jeweils 4 GB RAM). Die Entwicklungs-VMs werden mit
einheitliche Umgebungen zum Experimentieren zur Verfügung
einer kleinen Datenbank mit max. 4 GB Datenvolumen ausgestat-
gestellt werden, bieten sich virtualisierte Systeme an. Dieser
tet (für vorbereitende Tests). Weiterhin wird zusätzlicher Storage
Rahmen ist bekannt und darüber sind sich die Autoren einig. In
von 6 GB für das Betriebssystem, das DBMS und weitere Tools
Zukunft muss gezeigt werden, wie die Aufgabenstellungen für die
(Performance-Tools) beansprucht. Eine Reserve von 2 GB Spei-
Studenten zu formulieren sind und wie die Performance konkret
cher wird ebenfalls eingeplant. Daraus folgt für jede Entwick-
zu messen ist. Im Studiengang Wirtschaftsinformatik muss neben
lungs-VM ein Storage-Bedarf von 12 GB. Bei 20 Gruppen bedeu-
den technischen Details der Systeme auch immer die Wirtschaft-
tet das einen Storage von 240 GB. Rechnet man die 4 potentiellen
lichkeit betrachtetet werden. Auch dieser Bereich muss in Zukunft
Entwicklungssysteme aus der Reserve hinzu, führt dies zu einem
genauer betrachtet werden.
Speicherbedarf von 288 GB für die Entwicklungs-VMs.
Für die Versuchs-VMs sollen, wie in Abbildung 4 erkenntlich ist,
5 Systeme zur Verfügung stehen. Da zu den Versuchstagen sämt- 6. REFERENCES
liche Ressourcen den Versuchs-VMs zur Verfügung stehen sollen, [1] Euler D.; Hahn A., Wirtschaftsdidaktik, 2004, 1. Auflage,
kann der gesamte Arbeitsspeicher (96 GB) entsprechend aufge- Haupt Verlag, Bern
teilt werden. Das führt zu einem Arbeitsspeicher pro Versuchs- [2] Schubert S.; Schwill 1., Didaktik der Informatik, 2004, 1.
VM von rund 19 GB. In Sachen Storage-Kapazität sollen je Ver- Auflage, Spektrum Akademischer Verlag, München
suchssystem 80 GB vorgehalten werden (für Betriebssystem, DB, [3] Reich K., Experiment, 2008, http://methodenpool.uni-
DBMS und Tools). Das führt zu einem Storage-Bedarf von 400 koeln.de/download/experiment.pdf Abruf: 28.03.2012
GB für die Versuchssysteme.
[4] Faustmann; Höding; Klein; Zimmermann, Oracle- Da-
tenbankadministration für SAP, 2007, 1. Auflage, Galileo
4.3 Server-Hardware Press, Bonn
Nachfolgend werden Eckpunkte der Server-Hardware genannt.
[5] Balzert H.; Lehrbuch der Software- Technik, 1998 Spektrum
Für das Praktikum kommt ein Server-Blade zum Einsatz. Dieses
Akademischer Verlag GmbH, Heidelberg; Berlin
Blade besteht aus zwei Prozessoren (CPUs) mit jeweils 6 Kernen
und 3.46 GHz. Desweiteren besitzt der Server, wie aus der Kalku- [6] Schlimm N.; Novakovic M.; Spielmann R.; Knierim T., Per-
lation hervorgeht, 96 GB RAM. Der Gesamt-Storage, welcher in formance-Analyse und -Optimierung in der Software-
den Berechnungen bestimmt wurde, beträgt ca. 700 GB. Hierfür entwicklung, 2007, Informatik Spektrum, Springer-Verlag
stehen Hardware-seitig drei 450 GB Fibre Channel Festplatten zur [7] Claus V.; Schwill A., Duden der Informatik, 2001, 3. Aufla-
Verfügung. Die großzügige Reserve soll eventuellen späteren ge, Duden Verlag, Mannheim
Anforderungen gerecht werden.
[8] Müller T., Leistungsmessung und -bewertung, 2004,
Seminararbeit, Westfälische Wilhelms-Universität Münster,
4.4 Werkzeuge der Performance-Messung http://www.wi.uni-muenster.de/pi/lehre/ss04/SeminarTesten/
Die Performance-Messung hat verschiedene Aspekte. Es müssen Leistungsmessung.pdf Abruf: 28.03.2012
hier Methoden und Werkzeuge für die Umsetzung voneinander
abgegrenzt werden. So werden durch die Methoden einzelne Ver- [9] Barrett D., Linux kurz und gut, 2004, 1. Auflage, O’Reilly
fahrensansätze für die Tests beschrieben. Mit „Werkzeuge“ sind Verlag, Köln
hier die Tools zur Messung der entsprechenden Werte zusam- [10] Zimmer D.; Wöhrmann B.; Schäfer C.; Baumgart G.; Wi-
mengefasst. Es gibt ein weites Spektrum an Tools, wobei immer scher S.; Kügow O., VMware vSphere 4 - Das umfassende
die Aktualität und Verwendbarkeit der Werkzeuge geprüft werden Handbuch, 2010, 1. Auflage, Galileo Press, Bonn
sollte. Auf der einen Seite können Tools genutzt werden, welche
[11] http://moodle.de/ Abruf: 18.05.2012
in den jeweiligen Systemen, wie beispielsweise im Betriebssys-
tem oder im DBMS, vorhanden sind oder es können zusätzliche [12] Barth; Schneemann; Oestreicher, Nagios: System- und
Werkzeuge zum Einsatz kommen, wie z.B. Nagios [12]. Für die Netzwerk-Monitoring, 2012, 3. Auflage, Open Source Press
Wahl der Methoden und Werkzeuge bestehen mehrere Möglich-
keiten, zum einen können feste Vorgaben durch den Lehrenden
gemacht werden und zum anderen kann der Einsatz freigestellt
22
Migration nicht-nativer XML-Strukturen
in den nativen XML-Datentyp
am Beispiel von DB2 for z/OS V9.1
Christoph Koch
Friedrich-Schiller-Universität Jena
Lehrstuhl für Datenbanken und DATEV eG
Informationssysteme Datenbanken
Ernst-Abbe-Platz 2 Paumgartnerstr. 6-14
07743 Jena 90429 Nürnberg
Christoph.Koch@uni-jena.de Christoph.Koch@datev.de
KURZFASSUNG
Mit der Einführung der pureXML-Technologie [4] bietet das von
1. EINLEITUNG
Seit die Extensible Markup Language (XML) im Jahr 1998 vom
IBM entwickelte Datenbankmanagementsystem (DBMS) DB2 for
World Wide Web Consortium (W3C) verabschiedet wurde,
z/OS die Möglichkeit, XML-Daten nativ zu speichern und XML-
entwickelte sie sich fortlaufend weiter zum De-facto-Standard für
spezifisch zu verarbeiten. Die native Art der XML-Ablage
den Austausch von (semi-)strukturierten Daten. Damit einher ging
verspricht gegenüber der nicht-nativen XML-Speicherung zahl-
auch der verstärkte Einzug von XML in den Datenbanksektor [6],
reiche Vorzüge, die es sinnvoll werden lassen, im Unternehmen
sodass sich sowohl dedizierte XML-DBMS herausbildeten, als
vorhandene nicht-native XML-Daten in die native Struktur zu
auch herkömmliche relationale Systeme um XML-Strukturen
überführen. Der vorliegende Beitrag setzt genau an dieser
erweitert wurden.
Migrationsthematik auf und zielt darauf ab, sowohl die einzelnen
für eine solche Migration notwendigen Schritte aufzuzeigen, als Die einfachste und älteste Form, XML-Daten in relationalen
auch deren Performance in Relation zum Gesamtaufwand der DBMSen zu speichern, ist die nicht-native XML-Speicherung, die
Überführung nicht-nativer XML-Dokumente in die native XML- die datenbankseitige Ablage von XML-Daten als Binär- oder
Speicherform zu evaluieren. Character-Strings vorsieht [7]. Demgegenüber existieren seit
jüngerer Zeit auch native XML-Speichermöglichkeiten, wie
Die Ergebnisse dieses Beitrags basieren auf der Grundlage der
beispielsweise die hier betrachtete in DB2 implementierte
Arbeiten [1] und [2], die im Rahmen einer umfassenden
pureXML-Technologie und der damit verbundene native XML-
Untersuchung der XML-Unterstützung von DB2 for z/OS V9.1
Datentyp.
seit 2010 in der DATEV eG angefertigt wurden und richten sich
daher insbesondere an den dortigen Anforderungen aus. Da die native XML-Speicherung verglichen mit den verschie-
denen nicht-nativen Ablageformen diverse Vorteile hinsichtlich
Kategorien und Themenbeschreibung Performance, Flexibilität und Kosteneffizienz verspricht [4],
Database Performance and Benchmarks besteht auf langfristige Sicht das Ziel darin, „alte“ nicht-native
Datenbestände in die „neue“ native Form der XML-Speicherung
zu überführen. Die dazu notwendige Migration charakterisiert
Allgemeine Bestimmungen sich im Kontext von DB2 for z/OS durch den in den folgenden
Management, Measurement, Performance, Design, Languages Abschnitten beschriebenen Ausgangs- und Zielzustand.
Schlüsselwörter 1.1 Ausgangszustand
XML, nicht-nativ, nativ, Migration, Methodik, Performance Den Ausgangszustand der hier betrachteten Migrationsthematik
bilden nicht-native XML-Dokumente, die im Fall der DATEV eG
vorrangig in Form des VARCHAR- oder CLOB-Datentyps als
Character-String und noch spezieller in bestimmten Kontexten
über mehrere Tupel verteilt gespeichert sind. Solche Dokumente
sind in unserem Kontext zum Beispiel von einer OCR-Software
ins XML-Format digitalisierte Belege. Auf die genannten Beson-
derheiten der nicht-nativen Speicherformen wird nun konkreter
eingegangen.
24th GI-Workshop on Foundations of Databases (Grundlagen von
Datenbanken), 29.05.2012-01.06.2012, Lübbenau, Germany.
Copyright is held by the author/owner(s).
23
Migration nicht-nativer XML-Strukturen in den nativen XML-Datentyp am Beispiel von DB2 for z/OS V9.1
„Nicht-nativ“ bedeutet der Wortherkunft nach „nicht natürlich“. nicht-natives XML
Bezogen auf die nicht-native oder auch XML-enabled genannte Tupel Mustermann
Tupel name>408-555-1358
nötigen [5]. Beispiele für nicht-native XML-Speicherformen sind Tupel e>
3
die Ablage von XML-Dokumenten als Binär- oder Character-
String (siehe Abbildung 1) oder auch das Konzept der XML-
Abbildung 2: Verteilung über mehrere Tupel
Dekomposition. Letzteres basiert auf der Zerlegung von XML-
Dokumenten in relationale Strukturen. DB2 stellt hierzu die 1.2 Zielzustand
XMLTABLE-Funktion [11] bereit.
Entgegen dem zuvor beschriebenen Ausgangszustand erfordert
Die weiteren Ausführungen dieses Beitrags konzentrieren sich der native Zielzustand der in diesem Beitrag betrachteten XML-
aber wegen ihrer höheren Relevanz für die DATEV eG aus- Migration keine Variationen. Dies begründet sich durch die eine
schließlich auf die nicht-native XML-Speicherform als Character- in DB2 implementierte, optimierte und sich implizit selbst ver-
String und betrachten dabei speziell die Verwendung des CLOB- waltende native XML-Speicherform, die auf speziell angepassten,
Datentyps. In diesem Fall wird für die betrachtete Migration als aus der relationalen Welt bereits bekannten Strukturen basiert
Mapping die zentrale Funktionalität des XML-Parsens benötigt. (siehe Abbildung 3). Hierzu zählen, ähnlich zur LOB-Speicher-
Dabei werden nicht-native XML-Daten in die native Speicher- ung, in XML-Tablespaces befindliche XML-Auxiliary-Tabellen,
form transformiert. Nähere Details dazu folgen in Abschnitt 2.4. die über DocIDs und NodeIDs mit den Ausgangstabellen
verknüpft sind. Die gesamten XML-Strukturen sind aber so
nicht-native
gestaltet, dass sie aufgrund ihrer impliziten Verwaltung durch
XML-Speicherformen DB2 dem Nutzer gegenüber transparent bleiben und ihm somit
nur als „normale“ Spalte vom Datentyp XML sichtbar werden.
Dadurch hat er allerdings auf der anderen Seite unter anderem
Binary-String Character-String keinen auch Einfluss auf den verwendeten Zeichensatz, sodass der
native XML-Datentyp in DB2 stets die Unicode-Codepage UTF-8
nutzt [10].
CHAR VARCHAR CLOB
XML-
Abbildung 1: nicht-native XML-Speicherformen (Auswahl) Tablespace
In der DATEV eG werden XML-Daten zum aktuellen Zeitpunkt (1:1)
nicht-nativ in der EBCDIC-Codepage gespeichert. Dabei handelt
XML-
es sich um einen seit langem etablierten Single-Byte-Zeichensatz, Auxiliary-
der zur Repräsentation von Character-Daten genutzt wird und nur Tabelle
einen verglichen mit heutigen Standards wie Unicode geringen
Zeichenvorrat abdeckt.
min_
Für die hier betrachtete nicht-native XML-Speicherform des DocID XMLData
NodeID
CLOB-Datentyps gelten diverse Einschränkungen hinsichtlich
seiner Länge. Zwar kann ein CLOB-Dokument DB2-seitig Abbildung 3: implizite XML-Verwaltungsobjekte (nach [10])
prinzipiell eine maximale Länge von 2 GB besitzen. Diese lässt
sich jedoch durch die DB2-Subsystem-Parameter LOBVALA [8]
und LOBVALS [9] weiter einschränken, sodass per Default zur 2. MIGRATIONSSCHRITTE
Ressourceneinsparung bei der (Haupt-)Speicheradressierung ma- Ziel einer Datenmigration ist es, Informationen aus bestehenden
ximal 10 MB große LOB-Dokumente in DB2 verarbeitet werden Ausgangsstrukturen in spezielle Zielstrukturen zu transformieren.
können. In der DATEV eG wird von diesem Standardwert gering- Die dazu notwendigen Teilschritte sind daher die direkte Kon-
fügig nach oben abgewichen (aktuell 30 MB). Somit fällt die sequenz der Differenzen beider Strukturen. Übertragen auf die
tatsächlich mögliche Maximallänge eines CLOB-Dokuments in hier betrachtete Migration leitet sich auf diese Weise die in
unserem Kontext wesentlich kleiner als die genannten 2 GB aus. Abbildung 4 dargestellte Folge von Migrationsschritten ab, auf die
in den kommenden Abschnitten näher eingegangen wird.
Nicht zuletzt infolge dieser praktizierten Einschränkungen hat
sich zur DB2-seitigen Speicherung großer XML-Dokumente in (2.2) (2.4)
der DATEV eG das nachfolgend beschriebene Verfahren etabliert. Konkatenation XML-Parsen
VARCHAR/
Derartige Dokumente werden anwendungsseitig, wie in Abbil- XML
CLOB
dung 2 beispielhaft dargestellt, nötigenfalls in kleine, in der Regel Unicode-
Konvertierung
nicht wohlgeformte Teile „zerschnitten“ und diese über mehrere
(2.3)
(CLOB-)Tupel hinweg datenbankseitig abgelegt. Eine ähnliche Vorverarbeitung
Diskussion wird in [1] und [2] auch für die nicht-native XML- (2.1)
Speicherung als VARCHAR geführt.
Abbildung 4: Ablauf der Migration
24
Migration nicht-nativer XML-Strukturen in den nativen XML-Datentyp am Beispiel von DB2 for z/OS V9.1
2.1 Vorverarbeitung ursprünglichen EBCDIC-Inhalte im Rahmen einer Migration in
Der Schritt der Vorverarbeitung nimmt eine besondere Rolle in den Unicode-Zeichensatz überführt werden. Hierzu dient der
der Abfolge der Migration ein, da seine Bedeutung zum einen Migrationsschritt der Unicode-Konvertierung.
nicht direkt aus der geschilderten Zustandsdifferenz deutlich wird.
Zum anderen lässt sich eine Vorverarbeitung aber auch von der
2.4 XML-Parsen
Der wesentlichste Teil bei der Überführung von nicht-nativen
eigentlichen Migrationsfolge (siehe Abbildung 4) losgelöst durch-
XML-Dokumenten in den nativen XML-Datentyp besteht in dem
führen. Dies erklärt sich durch den funktionalen Zweck des dabei
Schritt des XML-Parsens. Dieser dient dazu, die textual (oder
stattfindenden Vorgangs, der im Wesentlichen darin besteht, die
binär) repräsentierten Ausgangsdokumente auf ihre Gültigkeit zu
Ausgangsdaten zu bereinigen.
überprüfen und in die hierarchische native XML-Struktur zu
Ein derartiger Bereinigungsvorgang ist in unserem Szenario nötig, überführen. Nähere Details zu dieser speziellen (nativen) Spei-
da aufgrund des beschränkten Zeichenvorrats der EBCDIC- cherform sind bereits in Abschnitt 2.2 angedeutet worden, sollen
Codepage bestimmte Zeichen nicht dargestellt und infolgedessen hier aber nicht weiter vertieft werden. Eine ausführliche Dar-
als Substitution-Character (HEX: 3F) substituiert werden. Dieser stellung dazu liefert [1].
Substitution-Character ist jedoch ein ungültiges Zeichen und wird
Aus theoretischer Sicht lässt sich hinsichtlich der erwähnten
vom XML-Parser in DB2 nicht akzeptiert. Damit nicht-native
Gültigkeitsprüfung nicht ausschließen, dass es unter bestimmten
XML-Dokumente mit enthaltenen ungültigen Zeichen aber
Bedingungen – beispielsweise bei dem Vorhandensein ungültiger
dennoch migriert werden können, ist es notwendig, durch eine
Zeichen im Ausgangsdokument (siehe Abschnitt 2.1) – beim
Vorverarbeitung diese ungültigen Zeichen durch gültige zu
XML-Parsen zu Fehlersituationen kommt. Für den speziellen, hier
ersetzen. Ein solcher Ersetzungsvorgang kann bereits auf dem
betrachteten Kontext der Migration gilt dies allerdings nur
Ausgangsdatenbestand durchgeführt werden und ist somit für den
bedingt. Zum einen werden aktuell sämtliche XML-Dokumente in
direkten Migrationsablauf unkritisch. Eine genauere Unter-
der DATEV eG bereits vor ihrem Einfügen in DB2 anwendungs-
suchung der Performance dieses Vorverarbeitungsschritts erfolgt
seitig geparst und zum anderen dient bereits der in Abschnitt 2.1
daher in Abschnitt 3.2 nicht.
angesprochene Migrationsschritt dazu, verbleibende Fehler in den
2.2 Konkatenation Ausgangsdaten zu bereinigen. Sollten dennoch Probleme während
Während beliebig große XML-Dokumente nicht-nativ durch das der Migration auftreten, sieht das in [1] diskutierte Konzept zur
in Abbildung 2 dargestellte Aufteilen DB2-seitig abgelegt werden, Migration auch für diesen Fall gezielte Fehlerbehandlungsmaß-
gilt diese Einschränkung für die XML-Speicherung unter Ver- nahmen vor. Nähere Details dazu sollen hier nicht angefügt
wendung des nativen XML-Datentyps nicht. Zwar werden native werden, sodass für die weitere Abhandlung die Korrektheit der
XML-Dokumente intern auch auf verschiedene Tupel verteilt Ausgangsdaten angenommen wird.
gespeichert, dies aber erfolgt implizit knotenabhängig und gestal- DB2 nutzt zum XML-Parsen die gleichnamige XMLPARSE-
tet sich dem Nutzer gegenüber somit vollständig transparent [1]. Funktion [11], die neben einer spezifizierbaren Option zur unter-
Für die betrachtete Migration resultiert daher folgende Kon- schiedlichen WHITESPACE-Handhabung (siehe Abbildung 5)
sequenz: „zerteilte“ nicht-native XML-Dokumente müssen zur auch zur XML-Schemavalidierung herangezogen werden kann. In
Überführung in den nativen XML-Datentyp wieder konkateniert der Nachfolgeversion 10 des hier betrachteten DB2 for z/OS V9.1
werden. existieren zusätzlich auch andere Möglichkeiten, XML-Dokumen-
Um diesen Vorgang der Konkatenation möglichst performant zu te gegen ein XML-Schema zu validieren. Weitere Informationen
gestalten, sind in [1] und [2] die datenbankseitigen Vorgehens- dazu und zur XML-Schemavalidierung allgemein finden sich in
weisen Konkatenation per Stored Procedure und Konkatenation [2]. Die hier diskutierte XMLPARSE-Funktion nutzt intern die
per Recursive SQL untersucht worden. Dabei hat sich erstere klar z/OS-XML-System-Services [12] und ermöglicht auf diese Weise
als die effizientere Variante herausgestellt, wobei sich bereits mit das effiziente XML-Parsen nicht-nativer XML-Dokumente.
Blick auf Abschnitt 3.2 vorwegnehmen lässt, dass auch diese
Form der Konkatenation einen erheblichen Anteil am Gesamt-
aufwand der Migration einnimmt. Wesentlich effizienter als die
Ich bin ein Text!
hier betrachteten Verfahren der expliziten Konkatenation wäre die
direkte Unterstützung einer iterativen Eingabe von nicht-nativen
Dokumentteilen durch den XML-Parser. Hierzu stellt DB2 stellt
allerdings keine Mechanismen bereit. Insgesamt sei aber noch- WHITESPACE beibehalten
mals darauf hingewiesen, dass die in Abbildung 2 gezeigte (PRESERVE WHITESPACE)
Zerteilung und damit auch die Konkatenation eher eine Art
Sonderform darstellt, die nur in verhältnismäßig wenigen Fällen
WHITESPACE abschneiden
(sehr große XML-Dokumente) anzutreffen ist.
(STRIP WHITESPACE)
2.3 Unicode-Konvertierung
Zum aktuellen Zeitpunkt überwiegt in unserer Arbeitsumgebung Ich bin ei
in DB2 deutlich der Anteil von EBCDIC- gegenüber Unicode- n Text!
Daten. Demzufolge sind auch nicht-native XML-Dokumente
wie in Abschnitt 1.1 beschrieben in der EBCDIC-Codepage
codiert abgelegt. Da aber für den nativen XML-Datentyp in DB2
Abbildung 5: WHITESPACE-Handhabung
strikt die Unicode-Codepage UTF-8 vorgegeben ist, müssen die
25
Migration nicht-nativer XML-Strukturen in den nativen XML-Datentyp am Beispiel von DB2 for z/OS V9.1
3. PERFORMANCE 3.2 Analyse der Migrationskosten
Die Ermittlung von Performance-Kennzahlen zu der in diesem Gemäß der eingangs angedeuteten Vorgehensweise erfolgt die
Beitrag betrachteten Migration basiert auf einer Differenzbildung Ermittlung der Performance der einzelnen Migrationsschritte
der Kosten verschiedener Folgen einzelner INSERT-Statements durch die sukzessive Aufschlüsselung der Gesamtkosten der
von CLOB-Daten bezogen auf das in Abschnitt 3.1 beschriebene Migration in einzelne (Teil-)Prozessketten. Die anschließenden
Vergleichskriterium. Zur Interpretation der dabei gewonnenen Ausführungen betrachten daher die folgenden Messreihen.
Resultate ist es wichtig, einen groben Überblick über die aktuell
in der DATEV eG eingesetzte DB2-Infrastruktur geben. Hierzu CLOB-INSERT (Basiskosten)
seien die folgenden Daten angeführt. CLOB-INSERT (inklusive Unicode-Konvertierung)
zSeries = z196 (neueste Generation) XML-INSERT (inklusive Unicode-Konvertierung und
Betriebssystemversion = z/OS 1.12 [IBM10b] XML-Parsen)
Storage-System = Hitachi Data Systems (HDS) – XML-INSERT (inklusive Konkatenation, Unicode-
Virtual Storage Platform (VSP) Konvertierung und XML-Parsen)
Die anschließenden Ausführungen beschäftigen sich mit der Die Performance des Vorverarbeitungsschritts wird aus den in
Darstellung und Analyse der unterschiedlichen, teils unerwarteten Abschnitt 2.1 genannten Gründen nicht weiter untersucht. Die an-
Performance-Resultate. Diese finden sich in ausgeweitetem schließend präsentierten Resultate zeigen die bei den Messreihen
Umfang in [2] wieder und werden dort durch zusätzliche, für ermittelten CPU-Zeiten. Neben diesen sind bei der Performance-
diesen Beitrag aber irrelevante Informationen zur Ergebnis- Analyse in DB2 auch diverse Elapsed-Zeiten (inklusive I/O-
deutung, zum Hintergrund der Messdatenerhebung sowie zur Zeiten, Lock/Latch-Waits, etc.) von Bedeutung, die aber aufgrund
Betrachtung weiterer Kriterien ergänzt. ihrer starken Schwankungen in Abhängigkeit zur aktuellen Last
auf dem DB2-Entwicklungssystem der DATEV eG in diesem
Generell liegt bei der fortan beschriebenen Erhebung von Perfor- Beitrag vernachlässigt werden. Eine Gesamtaufgliederung der
mance-Messdaten die Zielstellung darin begründet, den gesamten relevanten Zeiten findet sich in [2]. In den weiteren Ausführungen
Migrationsablauf innerhalb von DB2 durchzuführen. Dies werden für die genannten Messreihen die Resultate aufgezeigt und
schränkt zwar die Möglichkeiten zur Überführung der XML- teilweise andiskutiert. Umfangreichere Informationen dazu finden
Daten auf die Verwendung von DB2-Bordmitteln ein – demge- sich ebenfalls in [2].
genüber „mächtigere“ Anwendungsbibliotheken werden somit
nicht verwendet –, bietet aber die größtmögliche Effizienz, da nur Zuerst sei der Fokus auf die Zusatzkosten gerichtet, den die
auf diese Weise zusätzlicher Kommunikationsaufwand der zu Schritte Unicode-Konvertierung und XML-Parsen verursachen.
migrierenden XML-Daten zwischen Anwendung und DB2 Hier zeigt sich in Abbildung 6 eine mit zunehmender Größe der
eingespart werden kann. zu migrierenden XML-Dokumente generell fallende CPU-Zeit.
Während die Zusatzkosten für die Unicode-Konvertierung ver-
3.1 Vergleichskriterium – Größe und Anzahl hältnismäßig gering ausfallen, resultiert für den zusätzlichen
Während [2] die Performance der Migrationsschritte hinsichtlich Anteil, den das XML-Parsen verursacht, ein wesentlich höherer
drei verschiedener Vergleichskriterien analysiert, soll für die Aufwand. Dieser ist jedoch der Komplexität des XML-Parse-
Ausführungen dieses Beitrags die Betrachtung des Kriteriums der Vorgangs geschuldet, bei dem neben der Überführung der
Größe und Anzahl genügen. Dieses zielt neben einer Gegen- Ausgangsdaten in die native Speicherform unter anderem auch
überstellung der Kosten der einzelnen Migrationsschritte auch deren Struktur geprüft wird.
darauf ab, den Einfluss der Größe der zu migrierenden XML-
12
Dokumente zu untersuchen. Dazu wird ein konstantes Gesamt-
datenvolumen vorausgesetzt, das sich durch eine entsprechende 10
Dokumentanzahl reguliert und für die in Abschnitt 3.2 angefügten
8
Messresultate konstant 100 MB beträgt. Dieses Gesamtdaten-
Sekunden
volumen repräsentiert in seinem Umfang natürlich nicht die realen 6
Mengenverhältnisse der zu migrierenden Datenbestände der 4
DATEV eG. Da sich aber bei den Analysen zu [2] eine relativ
gute Skalierbarkeit bezogen auf die ermittelten Performance- 2
Ergebnisse zeigte, genügt bereits eine derartige Datenmenge zur 0
Grundlage für die Exploration der real zu erwartenden Migra- 1 KB x 10 KB x 100 KB x 1 MB x 10 MB x
tionskosten. Die angesprochene Regulierung der Gesamtdaten- 100.000 10.000 1.000 100 10
menge erfolgt für die abgebildeten Messresultate ausgehend von Größe und Anzahl
der Merkmalsausprägung „1 KB x 100.000“ – also der Migration
von 100.000 je 1 KB großen XML-Dokumenten – bis hin zur CLOB-INSERT
Ausprägung „10 MB x 10“
CLOB-INSERT (inklusive Unicode-Konvertierung)
XML-INSERT (inklusive Unicode-Konvertierung und XML-Parsen)
Abbildung 6: Performance der Migrationsschritte
26
Migration nicht-nativer XML-Strukturen in den nativen XML-Datentyp am Beispiel von DB2 for z/OS V9.1
Überraschenderweise sind die Grundkosten für einen einzelnen 4. ZUSAMMENFASSUNG
(komplexen) XML-Parse-Vorgang (unter anderem für das Laden Der vorliegende Beitrag hat einen Einblick in den Themen-
und Initialisieren des XML-Parsers) jedoch kaum merklich, schwerpunkt der Migration von nicht-nativen XML-Dokumenten
sodass sich die Messresultate ab der Merkmalsausprägung 10 KB in den nativen XML-Datentyp in DB2 gegeben. Dabei erfolgte die
x 10.000 trotz der kontinuierlich abnehmenden Anzahl von Doku- Herleitung und Erarbeitung von zwingend erforderlichen und
menten und somit auch XML-Parse-Vorgängen nur unwesentlich bedingt notwendigen Migrationsschritten sowie die Analyse deren
verändern. Mit anderen Worten formuliert bedeutet dies: Die Performance bezogen auf eine beispielhafte explorative Migration
relativ konstanten Gesamtkosten in Abbildung 6 (jeweils circa 5 von CLOB-Daten mittels INSERT-Statements. Im Ergebnis dieser
Sekunden CPU-Zeit für die "vier rechten hohen Balken") zeigen, exemplarischen Auswertung zeigte sich, wie unterschiedlich die
dass der Kostenaufwand primär in den insgesamt zu parsenden einzelnen Schritte die Gesamtkosten einer Migration beeinflussen
Megabytes liegt, nicht aber in deren Aufteilung auf viele oder auf und wo dabei die Hauptkostenfaktoren zu vermuten sind.
wenige XML-Dokumente.
Neben dem fachlichen Aspekt soll dieser Beitrag aber ebenso
Noch kostenintensiver als das XML-Parsen ist – eine gewisse dazu dienen, den wissenschaftlichen Charme eines praxisorien-
Anzahl von Dokumentteilen vorausgesetzt – unerwarteterweise tierten Anwendungsszenarios aufzuzeigen. Insbesondere wenn
nur der Migrationsschritt der Konkatenation. Um dessen Einfluss man wie in dem vorliegenden Beitrag angedeutet ins Detail einer
geeignet zu visualisieren, sind die durch ihn bei der Datener- konkreten Migrationslösung einsteigt, ergeben sich zahlreiche
hebung zur Messreihe „XML-INSERT (inklusive Konkatenation, Parallelen zu anderen DBMS-Themengebieten wie Archivierung
Unicode-Konvertierung und XML-Parsen)“ verursachten Kosten oder Aktive Datenbanken. Für den interessierten Leser seien
anteilig am Gesamtaufwand einer Migration in einer separaten daher zur vertieften Auseinandersetzung mit der hier diskutierten
Abbildung 7 dargestellt. Thematik nochmals die Arbeiten [1] und [2] empfohlen. Insbe-
sondere in [2] werden zudem auch weiterführende Untersuchun-
100%
gen zu den Themenschwerpunkten XML-Schema-Management
90%
(siehe auch [3]) und Query Performance angestellt.
80%
Sekunden (in Prozent)
70%
60%
5. LITERATUR
[1] C. Koch. XML-Speicherstrukturen in DB2 for z/OS Version
50%
9.1 und Überführungskonzepte für nicht-native XML-
40%
Speicherformen, Studienarbeit, Fakultät für Mathematik und
30%
Informatik, Friedrich-Schiller-Universität Jena und DATEV
20% eG, 08.2011.
10%
[2] C. Koch. Der Datentyp XML in DB2 for z/OS aus
0%
1x 10 x 100 x 1.000 x 10.000 x
Performance-Perspektive, Diplomarbeit, Fakultät für
1 KB x 1 KB x 1 KB x 1 KB x 1 KB x Mathematik und Informatik, Friedrich-Schiller-Universität
100.000 10.000 1.000 100 10 Jena und DATEV eG, 01.2012.
Zusatzkosten für Konkatenation (per Stored Procedure)
[3] C. Koch. Möglichkeiten und Konzepte zum XML-Schema-
Management am Beispiel von DB2 for z/OS V9.1, Fakultät
XML-INSERT (inklusive Unicode-Konvertierung und XML-Parsen) für Mathematik und Informatik, Friedrich-Schiller-
Universität Jena und DATEV eG, 06.2012.
Abbildung 7: Kostenanteil der Konkatenation
[4] IBM Corporation. DB2 pureXML – Intelligent XML
Hier sei angenommen, dass stets 1 KB große Dokumentteile zu database management, Produkt-Homepage, 2012.
einem Gesamtdokument konkateniert und anschließend weiter- http://www-01.ibm.com/software/data/db2/xml
migriert werden. Daher variiert bei den zu den abgebildeten Re-
[5] M. Päßler. Datenbanken und XML – Passt das?, 04.07.2007.
sultaten gehörenden Messreihen nicht mehr die Dokumentgröße
http://inka.htw-berlin.de/datenverwaltung/docs/Paessler.pdf
in Abhängigkeit eines konstanten Gesamtdatenvolumens, sondern
die Anzahl an, zu einem Dokument zu konkatenierenden Teile. [6] G. Lausen. Datenbanken: Grundlagen und XML-
Beispielweise werden bei der Merkmalsausprägung „10 x 1 KB x Technologien, Spektrum Akademischer Verlag, 1. Auflage,
10.000“ genau 10 je 1 KB große Dokumentteile zu einem 2005.
10 KB großen XML-Dokument zusammengefügt und anschlie- [7] H. Schöning. XML und Datenbanken: Konzepte und
ßend wie ein „herkömmliches“ 10 KB großes nicht-natives XML- Systeme, Carl Hanser Verlag GmbH & Co. KG, 1. Auflage,
Dokument weitermigriert. 2002.
Auffällig ist hier, dass trotz der simplen Logik der Konkatenation [8] IBM Corporation. DB2 Version 9.1 for z/OS – USER LOB
mittels der CONCAT-Funktion dennoch ein erheblicher Aufwand VALUE STG field (LOBVALA subsystem parameter),
entsteht, der ab einer Anzahl von 100 zu konkatenierenden Doku- 03.2011.
mentteilen den Hauptanteil der Gesamtkosten einer Migration http://publib.boulder.ibm.com/infocenter/dzichelp/v2r2/inde
einnimmt. An dieser Stelle lässt sich aber zumindest für die x.jsp?topic=/com.ibm.db2z9.doc.inst/src/tpc/db2z_ipf_lobval
betrachteten Datenbestände der DATEV eG Entwarnung geben, a.htm
da Konkatenationen mit derartig vielen Dokumentteilen im Rah-
men der untersuchten Migration nicht vorzunehmen sind.
27
Migration nicht-nativer XML-Strukturen in den nativen XML-Datentyp am Beispiel von DB2 for z/OS V9.1
[9] IBM Corporation. DB2 Version 9.1 for z/OS – SYSTEM LOB [11] IBM Corporation. DB2 Version 9.1 for z/OS – SQL
VAL STG field (LOBVALS subsystem parameter), 03.2011. Reference, 03.2011.
http://publib.boulder.ibm.com/infocenter/dzichelp/v2r2/inde http://publib.boulder.ibm.com/epubs/pdf/dsnsqk1a.pdf
x.jsp?topic=/com.ibm.db2z9.doc.inst/src/tpc/db2z_ipf_lobval [12] IBM Corporation. z/OS – XML System Services User's
s.htm Guide and Reference, 01.2012.
[10] IBM Corporation. DB2 Version 9.1 for z/OS – XML Guide, http://www-03.ibm.com/systems/resources/gxlza151.pdf
12.2010.
http://publibfp.dhe.ibm.com/epubs/pdf/dsnxgk16.pdf
28
Evolution von XML-Schemata auf konzeptioneller Ebene
Übersicht: Der CodeX-Ansatz zur Lösung des Gültigkeitsproblems
Thomas Nösinger, Meike Klettke, Andreas Heuer
Lehrstuhl Datenbank- und Informationssysteme
Institut für Informatik
Universität Rostock
(tn, meike, ah)@informatik.uni-rostock.de
ABSTRACT die Gültigkeit bereits vorhandener XML-Dokumente verlet-
If new requirements arise models have to be adapted to zen und macht eine Adaption dieser notwendig (siehe Ab-
them. Additionally, the instances based on these models ha- bildung 1).
ve to be adapted as well otherwise they might not be valid
anymore. The same applies to the XML schema as a model XML-Schema
Änderungen
XML-Schema‘
and widely accepted description for XML documents. One
solution for solving the occurring validity problem is the Gültigkeit Bestimmung der
Änderungen
Gültigkeit
here described XML schema evolution. On the basis of a
conceptual model the user interaction is analyzed and trans- XML-Dokumente Adaption XML-Dokumente‘
lated into transformation steps for the adaption of XML in-
stances. The user interaction contains the use of predefined
change operations on the conceptual model, a representation
of the corresponding XML schema Figure 1: Das Gültigkeitsproblem nach [14]
Categories and Subject Descriptors Der Vorgang der XML-Schemaänderung und der darauf
folgenden Anpassung der XML-Dokumente wird als XML-
I.7.1 [Document and Text Editing]; H.3.2 [Information Schemaevolution bezeichnet. Es existieren unterschiedli-
Storage]; H.3.3 [Information Search and Retrieval]; che Ansätze zur Durchführung der XML-Schemaevolution
D.2.8 [Metrics] [13]:
Keywords 1. Die Anwendung einer expliziten Evolutionssprache.
XML-Schemaevolution, konzeptionelle Modellierung, Gültig-
2. Der Vergleich zweier Versionen eines Modells und die
keitsproblem, Instanzanpassung
Ableitung von Transformationsschritten.
1. EINLEITUNG 3. Die Beobachtung und Auswertung der Nutzerinterak-
Die dynamische Anpassung von Modellen an aktuelle Ge- tion, aus der dann Transformationsschritte abgeleitet
gebenheiten birgt die Notwendigkeit, vorhandene Instanzen werden. Dieser Ansatz wird hier thematisiert.
und Anwendungen an die neuen, eventuell veränderten Um-
stände anzupassen. Ändert sich somit die strukturelle Be- Der erste Ansatz ist die Anwendung einer Evolutions-
schreibung einer Datenbasis, muss zwangsläufig auch die Da- sprache zur XML-Schemaevolution. Dies entspricht im Da-
tenbasis angepasst werden, damit die Gültigkeit bezüglich tenbankbereich dem Alter-Befehl der Data Definition Lan-
des neuen Modells gewährleistet wird. Diese Problematik ist guage SQL. Zur Zeit ist dieser Ansatz aufgrund der feh-
Kernpunkt des Gültigkeitsproblems, d.h. sind Instanzen lenden, standardisierten Evolutionssprache für XML-Sche-
eines Modells nach dessen Änderung noch gültig? mata nicht anwendbar. Des Weiteren wird vom Anwender
Die Veränderung der Struktur eines XML-Schemas bspw. an dieser Stelle ein tiefes Verständnis bzw. Expertenwissen
durch das Umsortieren von Inhaltsmodellen, das Erhöhen der möglichen Sprachkonstrukte und deren Anwendung ver-
des minimalen Vorkommens eines Elementes, das Einfügen langt.
oder auch Umbenennen nicht-optionaler Elemente etc. kann Der zweite Ansatz ist die Versionierung von Modellen.
Sind verschiedene Modelle vorhanden, dann können Trans-
formationsschritte aus dem Vergleich beider Modelle erzeugt
werden. Es müssen an dieser Stelle allerdings unterschiedli-
che, eventuell nicht vergleichbare Versionen vorgehalten wer-
den. Des Weiteren wird normalerweise bei syntaktischen und
/oder semantischen Konflikten eine automatische Lösung
basierend auf Heuristiken vorgeschlagen oder aber der An-
wender zur Lösung benötigt. Dieses Vorgehen erfordert wie-
24th GI-Workshop on Foundations of Databases (Grundlagen von Daten-
banken), 29.05.2012 - 01.06.2012, Lübbenau, Germany. derum ein tieferes Verständnis bzw. Expertenwissen der be-
Copyright is held by the author/owner(s). teiligten XML-Schemaversionen.
29
Evolution von XML-Schemata auf konzeptioneller Ebene
Der dritte Ansatz nutzt die Interaktion eines Anwenders erleichtern soll. PRISM++ ermöglicht keine XML-Schema-
aus, indem von diesem getätigte Änderungen an einer kon- evolution, thematisiert allerdings die Notwendigkeit, auch
zeptionellen Repräsentation eines XML-Schemas analysiert Integritätsänderungen vollziehen zu können.
werden. Die Nutzeränderungen sind dabei die Anwendung In [9] wird das GEA Framework (Generic Evolution Archi-
vordefinierter Operationen auf einem konzeptionellen Mo- tecture) vorgestellt, in dem XML-Schemata als UML-Klas-
dell. Das somit erlangte Wissen wird für eine automatische sendiagramme mit Stereotypen beschrieben werden. Unter
Erzeugung von Transformationsschritten zur Anpassung der Verwendung von elementaren Transformationsregeln werden
XML-Dokumente und Anwendungen verwendet. Es wird im Änderungen in UML auf XML propagiert.
Vergleich zu den ersten beiden Ansätzen weder vom Nutzer XCase [15] ist eine Implementierung von XSEM (kon-
Expertenwissen bezüglich einer Evolutionssprache benötigt, zeptionelles Modell: Xml SEmantics Modeling), welches un-
noch müssen unterschiedliche Versionen eines XML-Schemas ter Verwendung einer MDA (Model-Driven Architecture)
vorgehalten, ausgewählt und verwendet werden. die XML-Schemaevolution durchführt. Es existieren unter-
schiedliche Abstraktionslevel (u.a. PIM als Platform-Inde-
2. STAND DER FORSCHUNG pendent Model und PSM als Platform-Specific Model) die
Änderungen auf abstrakterem Niveau ermöglichen und diese
Die XML-Schemaevolution wird sowohl von den großen
dann zwischen den verschiedenen Ebenen propagieren (ein
Datenbank- und Softwareherstellern (u.a. Microsoft [4], IBM
XML-Schema ist ein PSM). Dieser Ansatz ist dem hier vor-
[3], Oracle [5], Altova [2]) als auch in Forschungsprototypen
gestellten am ähnlichsten, unterscheidet sich aber grundle-
(u.a. XCase [15], PRISM++ [8], X-Evolution [11], EXup [7]
gend in der Herangehensweise der Erfassung von Änderun-
und GEA [9]) thematisch behandelt und auch teilweise um-
gen, deren Auswertung, Kategorisierung und dem Umfang
gesetzt.
möglicher Änderungen bezüglich eines XML-Schemas.
Microsoft unterstützt den XML-Datentyp, lässt den Nut-
Eine automatische Erzeugung von Transformationsschrit-
zer in Collections XML-Schemata sammeln und danach mit-
ten und die damit verbundene Anpassung von XML-Doku-
tels einer Typisierung die Spalten einer Relation einem Sche-
menten sind in den hier vorgestellten Forschungsprototypen
ma zuordnen. XML-Instanzen typisierter Spalten können
nicht möglich bzw. die umsetzbaren Änderungen sind nicht
bezüglich ihres XML-Schemas auf Gültigkeit geprüft wer-
umfangreich genug. Des Weiteren wird bei keinem der Pro-
den, ändert sich allerdings ein XML-Schema, muss dieses
totypen der hier vorgestellte Ansatz der XML-Schemaevo-
unter einer neuen Version erneut eingefügt werden. Micro-
lution verfolgt, es besteht somit weiterhin Forschungsbedarf
soft unterstützt die hier angestrebte XML-Schemaevolution
in dieser Thematik.
nicht, sondern nutzt die Versionierung von XML-Schemata.
IBM DB2 ermöglicht die Registrierung von XML-Schemata
in einem XML-Schema-Repository (XSR) und eine anschlie- 3. FORMALE GRUNDLAGEN
ßende Erweiterung dieser unter Beachtung von zehn stren- Eine Grundlage der XML-Schemaevolution ist das an der
gen Kompatibilitätsanforderungen. In Oracle können Sche- Universität Rostock entwickelte, konzeptionelle EMX Mo-
mata ebenfalls registriert und anschließend mittels der Me- dell (Entity Model for XML-Schema), das zur grafischen
thoden copyEvolve und inPlaceEvolve evolutioniert werden. Modellierung von XML-Schemata im Forschungsprototypen
Sowohl bei IBM als auch Oracle sind restriktive Anforderun- CodeX (Conceptual Design and Evolution for XML-Sche-
gen gestellt, die nur eine Generalisierung des alten Schemas ma [12]) implementiert wurde. Die folgende Formalisierung
ermöglichen und somit nur teilweise die angestrebte XML- des konzeptionellen Modells ist notwendig, um die bereits
Schemaevolution unterstützen. erwähnten Änderungsoperationen auf dem EMX Modell de-
Altova bietet mit Diffdog eine Erweiterung ihres Editors finieren zu können.
an, mit dem zwei Schemata miteinander verglichen werden
können, um nachfolgend XSLT-Skripte zur Transformation 3.1 Konzeptionelles Modell
der Instanzen zu erzeugen. Treten bei dem Vergleich Kon- Das konzeptionelle Modell (MM ) ist ein Tripel, das aus
flikte auf, d.h. es kann keine eindeutige Zuordnung zwischen Knoten (NM ), gerichteten Kanten zwischen Knoten (EM )
den unterschiedlichen Strukturen der XML-Schemata herge- und zusätzlichen Eigenschaften (FM ) besteht.
leitet werden, dann wird vom Anwender eine manuelle Zu-
MM = (NM , EM , FM ) (1)
ordnung verlangt. Eine Automatisierung ist nicht möglich,
eine Nutzerinteraktion und somit Expertenwissen bezüglich Die Knoten sind Elemente (elementsM ), Attributgruppen
der XML-Schemata ist erforderlich. (attributegroupsM ), Inhaltsmodelle (groupsM ), Typen (ein-
Die Prototypen X-Evolution [11] und EXup [7] nutzen eine fache (simple-typesM ), komplexe (complex-typesM )), Module
grafische Oberfläche zur Spezifikation, Ausführung und Ve- (modulesM , u.a. externe XML-Schemata), Integritätsbedin-
rifikation von Schemaänderungen (beschrieben durch Primi- gungen (integrity-constraintsM ) oder Annotationen (anno-
tive), wobei die Updatesprache XSchemaUpdate für die Be- tationsM ). Die Knotenarten werden näher charakterisiert
schreibung der Änderungen und die Dokumentadaption ver- (z.B. elements M = {elementM }, elementM = (ID, name, na-
wendet wird. Eine Grundlage dieser Systeme ist ein DBMS, mespace, geometry, minoccur, maxoccur)), was auf Grund
welches XMLTYPE unterstützt. EXup und X-Evolution ver- von Platzbeschränkungen an dieser Stelle und bei den fol-
wenden darüber hinaus XSUpdate als Evolutionssprache, genden Modellen nicht vertieft werden soll. Die gerichteten
welches XSPath nutzt (eine Teilmenge von XPath). Kanten werden jeweils zwischen Knoten definiert, wobei die
PRISM++ [8] bietet einen fein-granularen Evolutionsme- Richtung die Zugehörigkeit (Enthalten-sein Beziehung) um-
chanismus zur Evolution von Datenbankschemata, welcher setzt und gemäß der Möglichkeiten von XML-Schema fest-
Datenbankadministratoren unter Verwendung von SMO-IC- gelegt wurden.
MO (Evolutionssprache: Schema Modification Operators - Die zusätzlich zu definierenden Eigenschaften ermöglichen
Integrity Constraints Modification Operators) die Evolution die Nutzer-spezifische Anpassung eines konzeptionellen Mo-
30
Evolution von XML-Schemata auf konzeptioneller Ebene
dells, insofern dies erwünscht ist. Dazu zählen u.a. CodeX- von anderen Operationen. Eine Operation wird auf den oben
Standardwerte zur Konfiguration des Editors, Angaben zur definierten Modellen ausgeführt.
Pragmatik, Kosten, Namen und zur Version eines EMX Mo- Operation
dells. Die Pragmatik (Pragmatik ∈ {kapazitätserhaltend, ka- Mx −−−−−−−→ Mx0 , x ∈ {M, S, D} (4)
pazitätserhöhend, kapazitätsreduzierend}) ist im Zusammen- Operationen sind zum Beispiel: changeElementType (Um-
hang mit den Änderungsoperationen notwendig, um den In- sortieren vom Inhaltsmodell), changeElementMinOccur (Er-
formationsverlust durch nicht beabsichtige Modellanpassun- höhen des minimalen Vorkommens eines Elementes), add-
gen zu verhindern. Die Kosten sollen die Steuerung von Än- ElementToComplexElement (Einfügen nicht-optionaler Ele-
derungsoperationen ermöglichen, damit zu komplexe und so- mente) oder renameElement (Umbenennen eines Elemen-
mit eventuell zu teure Transformationen verhindert werden tes).
können. Kosten werden verwendet, um den Aufwand der Eine Übersicht über die Zusammenhänge zwischen den
Änderungen zu bestimmen und gegebenenfalls eine Versio- Modellen und den Operationen ist in Abbildung 2 darge-
nierung vorzuschlagen. stellt. Die renameElement-Operation soll exemplarisch auf
3.2 XML-Schema und XML-Instanzen den oben definierten Modellen betrachtet werden. Dies ist
eine einfache Operation, kompliziertere Evolutionsoperatio-
XML-Schema (XSD) als strukturelle Beschreibung von nen werden analog ausgeführt.
XML-Instanzen ist formal durch das W3C definiert [6]. Ein
XML-Schema (MS ) ist in unserem Kontext ein Tupel aus
Knoten (NS ) und zusätzlichen Eigenschaften (FS ). Bezie-
hungen zwischen den Knoten (z.B. gerichtete Kanten) sind
implizit in den Knoten enthalten, die zusätzlichen Eigen-
schaften sind Informationen zum Namen und der Version.
MS = (NS , FS ) (2)
Knoten sind laut abstraktem Datenmodell Definitionen
(type-definitionsS ), Deklarationen (declarationsS ), Modell-
gruppen (model-group-componentsS ), Gruppendefinitionen
(group-definitionsS ), Annotationen (annotationsS ) oder Be-
dingungen (constraintsS ). Neben der abstrakten Definition
von Knoten existiert die Element-Informationseinheit, die Figure 2: EMX, XML-Schema und XML-Instanzen
für jeden Knoten die Realisierung innerhalb eines XML-
Schemas definiert, d.h. welche Inhalte und Attribute kön-
nen verwendet werden oder nicht. A: renameElementM (IDValue, oldValue, newValue)
XML-Instanzen (MD ) sind analog zum XML-Schema Tu-
pel aus Knoten (ND ) und zusätzlichen Eigenschaften (FD ), ∀ n ∈ NM ∧ n.ID = IDValue:
wobei die Beziehungen zwischen den Knoten wieder implizit if n ∈ elementsM
in diesen enthalten sind.
then n.name := newValue
MD = (ND , FD ) (3)
Wenn ein Nutzer die grafische Repräsentation eines Ele-
Die Knoten einer XML-Instanz sind Dokumente (docu- mentes selektiert und das Attribut Name ändert, dann wird
mentsD ), Attribute (attributesD ), Prozessanweisungen (pro- dieses in CodeX erkannt und als renameElementM Opera-
cessing-instructionsD ), Namensräume (namespacesD ), Tex- tion geloggt. Regeln garantieren dabei, dass nur sinnvolle
te (textsD ) oder Kommentare (commentsD ) [1]. Operationen geloggt werden (z.B. Voraussetzung für rena-
Zusätzlichen Eigenschaften sind der Name, die Version, meElement-Operation: oldValue 6= newValue). Die Identi-
Änderungseigenschaften und Signifikanz eines Dokumentes. fikation des selektierten Elements wird im konzeptionellen
Die Änderungseigenschaften (changeable ∈ {true, false}) sol- Modell durch eine eindeutige ID gewährleistet. Neben der
len bei XML-Instanzen den ungewollten Informationsverlust ausgeführten Operation, den beteiligten Werten und der ID
verhindern (z.B. Entfernen von Elementen). Die Signifikanz müssen Informationen zum Kontext gespeichert werden. Da-
(significance) ist ein normierter Wert, um bei Auswertungen zu zählen u.a. Angaben zum Gültigkeitsbereich, zu vorhan-
von Dokumentkollektionen zum Finden von Standardwerten denen Referenzen und zum direkten Knotenumfeld (Positi-
Dokumente priorisieren bzw. gewichten zu können. on in einem Inhaltsmodell etc.). Diese Kontextinformationen
3.3 Operationen sollen bei den nachfolgenden Operationen (renameElementS
und renameElementD ) die Identifizierung des betroffenen
Auf dem konzeptionellen Modell (EMX) werden vordefi- Elementes ermöglichen und die Verarbeitung erleichtern.
nierte Änderungsoperationen vom Nutzer durchgeführt. Die
anwendbaren Operationen lassen sich gemäß der Kategori- C: renameElementS (oldValue, newValue, context)
sierung von Änderungsoperationen herleiten und charakte-
risieren (siehe [10]). Charakteristika sind u.a. die Kapazi- ∀ n, m, k ∈ NS ∧ n 6= m ∧ n 6= k ∧ m 6= k ∧ context(n):
tätsänderung (kapazitätserhaltend, kapazitätserhöhend oder
// Globales Element mit neuem Namen existiert?
kapazitätsreduzierend), der XML-Instanzeinfluss (Instanz-
anpassung bei EMX-Änderung notwendig, nicht notwendig if n, m ∈ elementsS ∧ n.scope.variety = 0 global 0 ∧
oder abhängig vom Parameter), die herleitbaren bzw. ab- m.scope.variety = 0 global 0 ∧ n.name = oldValue
schätzbaren Kosten einer Operation und die Abhängigkeiten ∧ m.name = newValue
31
Evolution von XML-Schemata auf konzeptioneller Ebene
then newValue := uniqueName(newValue) ∧ 3.4 Zusammenhänge
n.name := newValue Die Beschreibung der Operationen macht deutlich, dass es
if ∃ k ∈ elementsS ∧ k .scope.variety = 0 local 0 ∧ Abhängigkeiten sowohl zwischen den Modellen als auch zwi-
k .ref = oldValue schen den Operationen gibt. Zum Beispiel sind die Kontext-
then ∀ k: k .ref := newValue informationen des konzeptionellen Modells für die Identifika-
// Lokales Element mit neuem Namen, aber anderem Typ existiert?
tion von Knoten im XML-Schema und/oder XML-Instanzen
notwendig, zeitgleich lässt die Element-Informationseinheit
elseif n, m ∈ elementsS ∧ n.scope.variety = 0 local 0 ∧ des XML-Schemas u.a. Aussagen über notwendige oder nicht
m.scope.variety = 0 local 0 ∧ n.name = oldValue ∧ notwendige Anpassungen von XML-Instanzen zu (minOc-
m.name = newValue ∧ n.type 6= m.type ∧ curs, maxOccurs). Diese Zusammenhänge wurden in der Ab-
n.parent.name = m.parent.name bildung 2 dargestellt und führen zu folgenden Theoremen:
then newValue := uniqueName(newValue) ∧
n.name := newValue Theorem 1. Ein konzeptionelles Modell MM wird durch
0
// Lokales Element, kein Namen-Typ-Konflikt?
die Operation A eines Nutzers verändert zu MM . Sei B eine
Beschreibungsvorschrift zur Abbildung (Korrespondenz) des
elseif n ∈ elementsS ∧ n.scope.variety = 0 local 0 ∧
konzeptionellen Modells MM auf ein XML-Schema MS . C
n.name = oldValue
sei die Änderungsoperation zur Überführung von MS zu MS0 .
then n.name := newValue Dann gilt:
// Globales Element, kein Namen-Konflikt?
A + B⇒C
elseif n ∈ elementsS ∧ n.scope.variety = 0 global 0 ∧
n.name = oldValue Das Theorem 1 besagt: Sind die Operation des Nutzers auf
then n.name := newValue dem EMX Modell und die Korrespondenzen zwischen dem
if ∃ k ∈ elementsS ∧ k .scope.variety = 0 local 0 ∧ konzeptionellen Modell und dem XML-Schema bekannt, so
k .ref = oldValue kann die Operation zum Anpassen des XML-Schemas her-
then ∀ k: k .ref := newValue geleitet werden.
Nachdem der Nutzer das konzeptionelle Modell verändert Theorem 2. Ein konzeptionelles Modell MM wird durch
0
hat, muss das entsprechende XML-Schema ebenfalls ange- die Operation A eines Nutzers verändert zu MM . Sei B ei-
passt werden. Dafür wird das Log von CodeX geladen und ne Korrespondenz zwischen dem konzeptionellen Modell MM
analysiert. Durch dieses Vorgehen sind die auszuführende und einem XML-Schema MS und sei D eine Korrespondenz
Operation, die veränderten Werte und der entsprechende zwischen dem XML-Schema MS und MD . E sei die Ände-
Knoten bekannt (Kontextinformationen). Durch die darauf- rungsoperation zur Überführung von XML-Instanzen MD zu
0
folgende Umbenennung eines Elementes im XML-Schema, XML-Instanzen MD , die bezüglich MS0 gültig sind. Dann gilt:
müssen je nach Gültigkeitsbereich, umgebenen Knotenum- A + B + D⇒E
feld und vorhandenen Referenzen weitere Anpassungen am
XML-Schema vorgenommen werden. Zum Beispiel muss ge- Das Theorem 2 besagt: Sind die Operation des Nutzers auf
prüft werden, ob eventuell gleich benannte, globale Elemente dem EMX Modell und die Korrespondenzen zwischen dem
schon vorhanden sind oder ob Referenzen angepasst werden konzeptionellen Modell, dem XML-Schema und den XML-
müssen. Die im konzeptionellen Modell gesammelten und im Instanzen bekannt, so kann die Operation zum Anpassen der
Log gespeicherten Kontextinformationen erleichtern dies. XML-Instanzen hergeleitet werden.
E: renameElementD (oldValue, newValue, context) Es können somit aus der Auswertung der Nutzerinterak-
tion mit dem konzeptionellen Modell automatisch entspre-
∀ n ∈ ND ∧ FD .changeable: chende Transformationsschritte hergeleitet werden.
if n ∈ elementsD ∧ n.node-name = oldValue ∧
context(n) 4. BEISPIEL
then n.node-name := newValue Die vorgestellte renameElement-Operation wird nachfol-
gend an einem durchgängigen Beispiel auf den unterschied-
Der letzte Schritt in der XML-Schemaevolution ist die lichen Modellen angewendet.
automatische Erzeugung von Transformationsschritten aus Der Knoten mit dem Namen ’nummer’ wird vom Nutzer
den Änderungen des Nutzers am konzeptionellen Modell. ausgewählt und im konzeptionellen Modell verändert (siehe
Nachdem das XML-Schema angepasst wurde, sind vorhan- Abbildung 3). Es sind keine Einschränkungen bezüglich der
dene XML-Instanzen eventuell nicht mehr gültig (Gültig- Modellpragmatik oder der nicht zu überschreitenden Kosten
keitsproblem). Dies kann aus den Charakteristika der Ope- gemacht worden (siehe FM ). CodeX erkennt, dass der aus-
rationen, den gespeicherten Informationen des Logs und den gewählte Knoten eine spezifische ID (hier z.B. ’1’) hat und
Anpassungen des XML-Schemas hergeleitet werden. Sind entsprechend ein Element ist. Wird nun das Attribut Name
Instanzen betroffen (der XML-Instanzeinfluss der Opera- verändert, d.h. dieses Attribut bekommt den neuen Wert
tion) und XML-Instanzen sollen verändert werden können ’ID’ (’nummer’ 6= ’ID’), dann wird dies in das Log geschrie-
(FD .changeable), dann muss ein entsprechendes Transfor- ben. Im Log steht, dass die Operation renameElement(’1’,
mationsskript erzeugt werden, das die Instanzen anpasst. ’nummer’, ’ID’) ausgeführt wurde. Des Weiteren werden an-
In CodeX wird aktuell ein XSLT Skript (XML Stylesheet hand der eindeutigen Knoten-ID Kontextinformationen ge-
Language Transformation) erzeugt, welches auf XML-Do- speichert, zum Beispiel die Gültigkeit (’lokal’), eventuelle
kumente angewendet werden kann. Referenzen (ist in dem Fall aufgrund der Gültigkeit nicht
32
Evolution von XML-Schemata auf konzeptioneller Ebene
ma und XML-Instanz ein zwingendes Element in einer Se-
quenz war (minOccurs = ’1’), falls das globale Vaterelement
’event’ als Dokumentenwurzel ausgewählt wurde. Das be-
deutet, dass alle XML-Instanzen die gültig bezüglich des
alten XML-Schemas waren und die verändert werden sol-
len (FD .changeable), entsprechend an das neue XML-Sche-
ma angepasst werden müssen.
Durch die Anwendung einer Operation auf dem konzep-
tionellen Modell und der bekannten Korrespondenzen zwi-
schen EMX Modell, XML-Schema und XML-Instanz, kann
die Operation zum Anpassen der XML-Instanzen hergeleitet
werden (siehe Theorem 2).
Diese Operation bzw. die notwendigen Transformations-
Figure 3: Konzeptionelles EMX Modell schritte sind in einem XSLT-Skript realisiert, welches für das
Beispiel in Abbildung 5 dargestellt ist.
möglich) und das Knotenumfeld (Vaterknoten ist gemäß der
Kanteninformationen EM ’event’, Inhaltsmodell ist eine Se-
quenz, zweite Position in Sequenz).
Figure 5: XSLT-Skript zur XML-Instanzanpassung
Figure 4: XML-Schema zum EMX Modell
5. UMSETZUNG
Abbildung 4 ist das zum obigen EMX Modell gehören-
Der CodeX-Editor bietet unterschiedliche Funktionalitä-
de XML-Schema. Die Korrespondenzen zwischen dem kon-
ten zur Durchführung und Unterstützung der XML-Sche-
zeptionellem Modell und dem XML-Schema sind definiert,
maevolution (siehe Abbildung 6). Unter anderem kann das
d.h. es ist aufgrund der Abbildungsvorschriften möglich, das
eine Modell in das andere zu überführen. Durch das Log
ist bekannt, dass die renameElement-Operation ausgeführt Ergebnis
wurde, diese Operation muss demnach auch auf dem XML- GUI Schemaänderung Datenbereitstellung
Schema nachvollzogen werden. Es gibt dem Log folgend ein Visualisierung Import Export
lokales Element ohne Referenzen im XML-Schema, welches
den Namen ’nummer’ hat, in einer Sequenz an zweiter Stelle Evolutionsengine XSD Config
XSD
XML XSLT XSD Config
steht und den Vater ’event’ besitzt. Dieses Element soll um-
benannt werden, das Attribut ’name’ soll den neuen Wert
’ID’ erhalten. In dem überschaubaren Beispiel ist dies nur
ein Knoten, der den entsprechenden Kontext hat und mittels Modell
Mapping
Spezifikation
Operationen
Konfiguration Dokument
Instanzen
Updateskripte &
der renameElement-Operation umbenannt wird. Modell Daten Evolutionsspezifische Daten Evolutionsergebnisse
Aufgrund der Anwendung einer Operation auf dem kon- Transformation
Wissensbasis Log
zeptionellen Modell (Operation und Kontextinformationen
CodeX
werden geloggt) und der bekannten Korrespondenzen, kann
demnach die Operation zum Anpassen des XML-Schemas
hergeleitet werden (siehe Theorem 1). Figure 6: Komponentenmodell von CodeX
Durch die Umbenennung eines Elementes kann die Gültig-
keit von XML-Instanzen betroffen sein. Es wurde die rena- konzeptionelle Modell bzw. dessen grafische Repräsentation
meElement-Operation ausgeführt, welche laut Operations- von einem Nutzer verändert werden, was entsprechend in ei-
spezifikation eine kapazitätserhaltende Operation ist. Des nem Log gespeichert wird. Welche Änderungen bzw. vordefi-
Weiteren kann die Operation je nach Parametern (d.h. die nierten Operationen anwendbar sind, wird durch Operations-
Kontextinformationen) einen Einfluss auf die Gültigkeit von spezifikationen beschrieben (siehe Kategorisierung in [10]).
XML-Instanzen haben. Es muss zunächst der entsprechen- Das konzeptionelle Modell wird aus einem gegebenen XML-
de Elementknoten im XML-Schema durch die Kontextinfor- Schema unter Verwendung vom Modell-Mapping Informa-
mationen ermittelt werden. Es ist bekannt, dass das Ele- tionen (Korrespondenzen) extrahiert oder neu angelegt. Das
ment ’nummer’ laut Korrespondenz zwischen XML-Sche- Log kann nach einer entsprechenden Analyse zur Erzeugung
33
Evolution von XML-Schemata auf konzeptioneller Ebene
von XSLT-Skripten verwendet werden, welche die aus den 8. REFERENCES
Nutzeraktionen hergeleiteten Transformationsschritte um- [1] XQuery 1.0 and XPath 2.0 Data Model (XDM)
setzen. Diese Transformation nutzt die evolutionsspezifischen (Second Edition). http://www.w3.org/TR/2010/
Daten, u.a. erneut die Operationsspezifikation, XML-Sche- REC-xpath-datamodel-20101214/, December 2010.
mainformationen, gegebene Konfigurationen oder auch Do- Online; accessed 01-March-2012.
kumentkollektionen. Konfigurationen sind die zusätzlichen [2] Altova Produkt diffdog: XML-Schemavergleich.
Eigenschaften (FM ) des konzeptionellen Modells, während http://www.altova.com/de/diffdog/
die Dokumentinstanzen zur Kostenabschätzung und gege- xml-schema-diff-tool.html, 2011. Online; accessed
benenfalls zur Wertfindung verwendet werden können. Die 15-December-2011.
Datenbereitstellung und Extraktion von Ergebnissen wer-
[3] IBM DB2 LUW V9R7 Online Documentation.
den entsprechend durch Import und Export-Komponenten
http://publib.boulder.ibm.com/infocenter/
realisiert.
db2luw/v9r7/index.jsp, 2011. Online; accessed
15-December-2011.
6. ZUSAMMENFASSUNG [4] Microsoft technet: Verwenden von xml in sql server.
Die XML-Schemaevolution behandelt das Gültigkeitspro- http://technet.microsoft.com/de-de/library/
blem. Wenn sich XML-Schemata ändern und somit an neue ms190936(SQL.90).aspx, 2011. Online; accessed
Gegebenheiten bzw. Anforderungen angepasst werden, müs- 15-December-2011.
sen deren Instanzen zur Wahrung der Gültigkeit ebenfalls [5] Oracle XML DB Developer’s Guide 11g Release 2
adaptiert werden. Dies sollte weitestgehend automatisch er- (11.2). http://docs.oracle.com/cd/E11882_01/
folgen. Im präsentierten Ansatz wird ein konzeptionelles Mo- appdev.112/e23094/xdb07evo.htm, 2011. Online;
dell verwendet, welches eine vereinfachte, grafische Reprä- accessed 12-December-2011.
sentation eines XML-Schemas ist. Wird das konzeptionelle [6] W3C XML Schema Definition Language (XSD) 1.1
Modell durch vordefinierte Operationen von einem Nutzer Part 1: Structures. http://www.w3.org/TR/2012/
verändert, dann wird das damit gewonnene Wissen entspre- PR-xmlschema11-1-20120119/, January 2012. Online;
chend geloggt und danach für die Anpassung des XML-Sche- accessed 01-March-2012.
mas und der XML-Instanzen angewendet. In diesem Zusam- [7] F. Cavalieri. EXup: an engine for the evolution of
menhang sind Kontextinformationen und Korrespondenzen XML schemas and associated documents. In
zwischen den Modellen entscheidend, denn nur durch diese Proceedings of the 2010 EDBT/ICDT Workshops,
Informationen können automatisiert Transformationsschrit- EDBT ’10, pages 21:1–21:10, New York, NY, USA,
te aus der Nutzerinteraktion hergeleitet werden. 2010. ACM.
Die einzelnen Modelle wurden kurz vorgestellt, bevor die [8] C. Curino, H. J. Moon, A. Deutsch, and C. Zaniolo.
renameElement-Operation formal beschrieben wurden. Die Update Rewriting and Integrity Constraint
Zusammenhänge der einzelnen Modelle und die Anwendung Maintenance in a Schema Evolution Support System:
der renameElement-Operation wurde ebenfalls thematisiert. PRISM++. PVLDB, 4(2):117–128, 2010.
An einem durchgängigen Beispiel wurde darüber hinaus dar- [9] E. Domı́nguez, J. Lloret, B. Pérez, Á. Rodrı́guez,
gestellt, wie diese Operation auf den einzelnen Modellen an- A. L. Rubio, and M. A. Zapata. Evolution of XML
gewendet wird. Des Weiteren wurde CodeX als Forschungs- schemas and documents from stereotyped UML class
prototyp präsentiert, der zur Realisierung und Durchfüh- models: A traceable approach. Information & Software
rung der XML-Schemaevolution unerlässlich ist. Technology, 53(1):34–50, 2011.
Ein hier nicht ausführlich, aber dennoch in CodeX bereits
[10] H. Grunert. XML-Schema Evolution: Kategorisierung
vorhandener Aspekt ist die Berücksichtigung von Kosten-
und Bewertung. Bachelor Thesis, Universität
funktionen bei der XML-Schemaevolution. Aktuell werden
Rostock, 2011.
die möglichen Kosten einer Evolution anhand der durchzu-
führenden Änderungsoperation abgeschätzt und mit einem [11] G. Guerrini and M. Mesiti. X-Evolution: A
Nutzer-spezifischen Grenzwert verglichen. CodeX kann so Comprehensive Approach for XML Schema Evolution.
konfiguriert werden, dass bei Überschreitung dieses Wertes In DEXA Workshops, pages 251–255, 2008.
Änderungsoperationen abgelehnt werden und stattdessen ei- [12] M. Klettke. Conceptual XML Schema Evolution - the
ne Versionierung vorgeschlagen wird. CoDEX Approach for Design and Redesign. In BTW
Workshops, pages 53–63, 2007.
[13] M. Klettke. Modellierung, Bewertung und Evolution
7. AUSBLICK von XML-Dokumentkollektionen. Habilitation,
CodeX bietet derzeit Basisfunktionalitäten zur Modellie- Fakultät für Informatik und Elektrotechnik,
rung von XML-Schema und zur XML-Schemaevolution an. Universität Rostock, 2007.
Momentan fehlen allerdings die Behandlung von Integritäts- [14] M. Klettke, H. Meyer, and B. Hänsel. Evolution —
bedingungen, Namensräume, die Beachtung von Dokument- The Other Side of the XML Update Coin. In 2nd
kollektionen und die Auswertung und Speicherung der Kon- International Workshop on XML Schema and Data
textinformationen. In Zuge der Anpassung und Erweiterung Management (XSDM), Tokyo, April 2005.
soll CodeX als Webapplikation freigeschaltet werden, damit [15] J. Klı́mek, L. Kopenec, P. Loupal, and J. Malý. XCase
der Prototyp von anderen Anwendern zur XML-Schemaevo- - A Tool for Conceptual XML Data Modeling. In
lution verwendet werden kann. ADBIS (Workshops), pages 96–103, 2009.
Des Weiteren werden die bisher vorhandenen Beschrei-
bungen der Änderungsoperationen gemäß der Kategorisie-
rung von [10] erweitert, formal beschrieben und integriert.
34
Ein Partitionierungsdienst für Geographische Daten in
Räumlichen Datenbanken
Hendrik Warneke und Udo W. Lipeck
Institut für Praktische Informatik, FG Datenbanken und Informationssysteme
Leibniz Universität Hannover, Welfengarten 1, 30159 Hannover
{hwa,ul}@dbs.uni-hannover.de
ZUSAMMENFASSUNG tenproduzenten, Dienstleister und Nutzer über Netzwerke,
Da in der computergestützten Geographie mit zum Teil sehr in der Regel das Internet, miteinander verknüpft sind und
großen Mengen von räumlichen Daten gearbeitet werden geographische Informationen mit standardisierten Verfahren
muss, hat sich mittlerweile die Überzeugung durchgesetzt, austauschen und verarbeiten [4]. Diese Strukturen sehen vor,
solche Datensätze in räumlichen Datenbanken zu speichern. dass geographische Daten blattschnittfrei in räumlichen Da-
Allerdings wird bei der Entwicklung von geographischen Pro- tenbanken gespeichert werden, wozu man häufig objektrela-
grammen dem Aspekt der Skalierbarkeit oftmals wenig Be- tionale Systeme mit Erweiterungen um räumliche Datenty-
achtung geschenkt. So enthalten verbreitete Programme für pen, Operatoren und Indexe einsetzt.
Geoinformationssysteme wenig bis keine sogenannten exter- Aus den grundlegenden, mit den Techniken der Landes-
nen Algorithmen, die den Geschwindigkeitsunterschied zwi- vermessung hergestellten Daten, den sogenannten Geobasis-
schen internem (RAM) und externem Speicher (Festplatte) daten, können durch vielfältige Prozesse neue Datensätze
berücksichtigen und versuchen, die Anzahl der I/O-Zugriffe abgeleitet werden, die man für kartographische Darstellun-
auf letzteren zu minimieren. Diese Programme arbeiten da- gen von Informationen aus Fachbereichen wie z.B. Verkehr,
her nur dann effizient, wenn genug interner Speicher für die Umwelt und Ökonomie verwendet. Die folgende Auflistung
zu bearbeitenden Geodaten zur Verfügung steht. Wir stel- enthält einige Beispiele für Klassen solcher Prozesse, die heu-
len in diesem Beitrag einen auf Partitionierung basierenden te meistens automatisiert durch Computerprogramme, im
Ansatz vor, der den Aufwand für die Entwicklung von auf folgenden Geoprogramme genannt, durchgeführt werden.
großen Geodatenmengen skalierenden Programmen stark re- Generalisierung: Um eine lesbare Kartendarstellung aus
duziert. Dazu werden Zugriffe auf externe Speicher in eine den Geobasisdaten zu erzeugen, müssen diese durch
vorgelagerte Partitionierungs- und eine nachgelagerte Re- Operationen wie z.B. das Weglassen von Objekten so-
kompositionsphase verschoben und für diese Phasen flexible wie Vereinfachen, Zusammenfassen oder Verdrängen
Operationen, die ein breites Spektrum an geographischen von Geometrien verändert werden. Dabei besitzen die
Problemstellungen unterstützen, als Partitionierungsdienst Basisdaten meist eine höhere Auflösung als für die be-
für räumliche Datenbanksysteme angeboten. absichtigte Darstellung benötigt wird.
Transformation: Erfordert eine Anwendung ein bestimm-
1. EINLEITUNG tes Datenmodell, das sich von dem der Geobasisdaten
Lange Zeit verwendete man für die Arbeit mit geogra- unterscheidet, müssen diese zunächst in das beabsich-
phischen Informationen größtenteils auf Papier gedruckte tigte Modell transformiert werden.
Landkarten. Diese wurden in handliche Kartenblätter unter-
teilt, um die zur Beschreibung der Erdoberfläche in hoher Integration: Um Informationen aus verschiedenen Daten-
Auflösung benötigten Datenmengen besser handhaben zu sätzen gemeinsam nutzen zu können, werden diese zu
können. Der Übergang zu computergestützten Geoinforma- einem Datensatz integriert. Dies erfordert z.B. Verfah-
tionssystemen erlaubte es, Geodaten mit Hilfe unabhängig ren wie die Identifikation korrespondierender geogra-
vom Maßstab in Form von Geometrien zu modellieren. Da- phischer Objekte (Matching) sowie die Anpassung von
bei behielt man häufig die Aufteilung in Kartenblätter auf Geometrien für die gemeinsame Darstellung.
Dateiebene bei, da die verarbeitbare Datenmenge für vie-
le Systeme und Datenformate beschränkt war. Heute baut Geoprogramme, die diese Prozesse implementieren, müssen
man sogenannte Geodateninfrastrukturen auf, in denen Da- aufgrund des beträchtlichen Umfangs von Geobasisdaten-
sätzen in der Lage sein, den begrenzten Hauptspeicher ei-
nes Rechners effizient zu verwalten, um Performanceproble-
me aufgrund von Swapping oder Programmabstürze wegen
Speichermangels zu vermeiden. Dazu würde es sich anbie-
ten, diese Programme als Datenbankanwendungen zu im-
plementieren, die sämtliche Datenzugriffe über SQL-Befehle
abwickeln. Dieses Vorgehen ist jedoch mit einigen Nachtei-
len verbunden. Zunächst ist man auf die von dem räumli-
24th GI-Workshop on Foundations of Databases (Grundlagen von Daten-
banken), 29.05.2012 - 01.06.2012, Lübbenau, Germany. chen Datenbanksystem angebotene Funktionalität für geo-
Copyright is held by the author/owner(s). metrische und geographische Berechnungen beschränkt. Die
35
Ein Partitionierungsdienst für Geographische Daten in Räumlichen Datenbanken
freie Auswahl aus spezialisierten und optimierten Software- Repräsentationen der Daten weitergegeben werden. Für un-
Bibliotheken entfällt. Weiterhin hängt die Performance von seren Partitionierungsdienst sind wir hingegen an flexiblen
SQL-basierten Anwendungen entscheidend von der Quali- Partitionierungs- bzw. Rekompositionsoperationen interes-
tät der Anfrageoptimierung ab. Aufgrund der inhärenten siert, die für die Entwicklung der Geoprogramme keine ein-
Schwierigkeit der Kostenschätzung für geometrische Opera- schränkenden Vorgaben machen.
tionen stellt dies insbesondere bei räumlichen Datenbanken Aufgrund seiner Wichtigkeit bei der Berechnung räum-
ein Problem dar. Schließlich müssten die Algorithmen für licher Verbunde ist das Problem der Bestimmung von sich
Geoprogramme in eine relationale Formulierung umgewan- überschneidenden achsenparallelen Rechtecken besonders in-
delt werden, was aufgrund von deren Komplexität i.A. auf- tensiv untersucht worden. Während für interne Algorithmen
wändig und fehleranfällig ist. Hinzu kommt noch, dass die das Plane-Sweep-Paradigma [1] favorisiert wird, verwenden
Entwickler geographischer Anwendungen oftmals keine Da- externe oder parallele Algorithmen häufig Partitionierung,
tenbankspezialisten sind. wie z.B. Patel und DeWitt [5]. Der Einfluss von Redundanz
Wir stellen in diesem Beitrag einen Ansatz vor, der die- auf die Laufzeit von partitionierungsbasierten Algorithmen
se Probleme durch Partitionierung der Geobasisdaten um- für dieses Problem wird beispielsweise von Zhou et.al. [8] un-
geht. Statt ein Geoprogramm auf den gesamten Datensatz tersucht. In einer ähnlichen Untersuchung [2] kommen Dit-
anzuwenden, wird jede Datenpartition für sich allein bear- trich und Seeger u.a. zu dem auf den ersten Blick überra-
beitet, wobei diese so klein gewählt wird, dass der verfüg- schenden Ergebnis, dass man durch mehr Redundanz in den
bare Hauptspeicher nicht überfüllt wird. Die für die ein- Berechnungen sogar die Laufzeit verbessern kann.
zelnen Partitionen berechneten Ergebnisdatensätze müssen
anschließend wieder zu einem Gesamtdatensatz zusammen- 3. ENTWURF DES PARTITIONIERUNGS-
gesetzt werden, was wir als Rekomposition bezeichnen. Da
unterschiedliche Prozesse auch unterschiedliche Strategien DIENSTES
für die Partitionierung und Rekomposition erfordern, bieten
wir eine Sammlung solcher Operationen als Dienst auf einem 3.1 Architektur
räumlichen Datenbanksystem an. Die Entwickler von Geo- Wir implementieren Partitionierungs- und Rekompositi-
programmen können diesen über eine einfache Schnittstelle onsoperationen als Stored Procedures auf einem räumlichen
ansprechen, wodurch die Notwendigkeit entfällt, innerhalb Datenbanksystem. Diese können über eine Datenbankschnitt-
der Programme selbst den Austausch der Daten zwischen stelle von einem Steuerprogramm außerhalb der Datenbank
Haupt- und sekundärem Speicher zu berücksichtigen. aufgerufen werden, um in der Datenbank gespeicherte Da-
Für geographische Daten bietet es sich an, zur Partitio- ten für ein Geoprogramm aufzuteilen und wieder zusammen-
nierung die räumliche Lage zu verwenden und Datenobjek- zusetzen (Abbildung 1). Das Steuerprogramm liest jeweils
te aus einem zusammenhängenden Gebiet in eine Partition
einzuteilen. Dieser Ansatz ist allgemein für Geoprogramme
anwendbar, die sich lokal verhalten. Dies bedeutet, dass für
die Berechnung von Ergebnissen an einer Position nur Da-
ten aus einer begrenzten Umgebung benötigt werden und
diese Umgebung klein gegenüber einer Partition ist. In die-
sem Fall lassen sich Fehler, die insbesondere am Rand einer
Partition entstehen, weil dem Geoprogramm nicht alle Da-
ten zur Verfügung stehen, reduzieren oder ganz vermeiden,
indem man sich überlappende Partitionen erzeugt [6].
Der Rest des Beitrags ist wie folgt strukturiert: In Ab-
schnitt 2 nennen wir Arbeiten, die mit unserem Ansatz ver-
wandt sind. Abschnitt 3 beschreibt die Architektur und das
Funktionsprinzip des Partitionierungsdienstes. In Abschnitt
4 verwenden wir die Liniensegmentierung als konkretes An-
wendungsbeispiel und geben für diesen Prozess alternative
Partitionierungs- und Rekompositionsoperationen an. Ab-
schnitt 5 beschreibt die Ergebnisse von Experimenten mit
diesen Operationen auf realen geographischen Daten. Schließ-
lich liefert Abschnitt 6 ein Fazit über den in diesem Beitrag Abb. 1: Geoprogramm (Ablauf ) mit Partitionierung
vorgestellten Ansatz und einen Ausblick auf Folgearbeiten.
einen Eintrag aus dem Partitionierungsschema (Abschnitt
2. VERWANDTE ARBEITEN 3.2), das die Geometrien der Partitionen enthält. Damit wird
Das Prinzip, Datensätze zuerst aufzuteilen, Teilergebnis- eine geeignete Partitionierungsoperation aufgerufen und ei-
se zu berechnen und später aus den Teilergebnissen ein Ge- ne Partition der Ausgangsdaten berechnet. Diese muss in ein
samtergebnis zu generieren, ist in der Informatik unter dem von dem Geoprogramm verwendetes Dateiformat exportiert
Namen Divide-and-Conquer bekannt. Auch für geometrische werden, bevor dieses vom Steuerprogramm aufgerufen wird,
Probleme gibt es eine Reihe von Vorschlägen, beispielsweise um für die Datenpartition ein Ergebnis zu berechnen, das
von Güting und Schilling [3], die externe Algorithmen nach zunächst ebenfalls im Dateisystem abgelegt wird. Nachdem
diesem Prinzip entwickeln. Um eine optimale asymptotische dieses Ergebnis wieder in die Datenbank importiert worden
Laufzeit zu erreichen, werden die drei Teilschritte stark auf- ist, ruft das Steuerprogramm eine geeignete Rekompositi-
einander abgestimmt, indem z.B. Sortierungen oder spezielle onsoperation auf, die die Daten mit den bereits rekompo-
36
Ein Partitionierungsdienst für Geographische Daten in Räumlichen Datenbanken
nierten Daten aus anderen Partitionen zusammensetzt und
Konflikte auflöst. Anschließend kann das Steuerprogramm Pufferpolygon
mit der nächsten Partition aus dem Partitionierungsschema
fortfahren bis der komplette Datensatz bearbeitet ist.
Für Zugriffe auf die möglicherweise großen Datensätze in- Kontext Datenobjekt
nerhalb der Partitionierungs- und Rekompositionsoperatio-
Partitionspolygon
nen verwenden wir konsequent SQL-Anweisungen. Dadurch
machen wir implizit von den im räumlichen Datenbanksys-
tem implementierten externen Algorithmen Gebrauch, so
dass innerhalb dieser Operationen eine effiziente Abfolge von Abb. 2: Kontext, Partitions- und Pufferpolygon
I/O-Zugriffen erfolgt. Da innerhalb des Geoprogramms nur
noch auf die Daten aus einer Partition zugegriffen wird, sind
dort keine externen Algorithmen mehr nötig. lokale Berechnungen ausführen, und das in diesem Beitrag
vorgestellte Konzept ist für solche Anwendungen einsetzbar.
3.2 Redundanz Redundanz führt dazu, dass für einige Datenobjekte meh-
Um vorzugeben, wie geographische Daten bei der Parti- rere Ergebnisse in unterschiedlichen Partitionen berechnet
tionierung aufgeteilt werden, verwenden wir ein sogenanntes werden. Wir bezeichnen solche Situationen als Rekomposi-
Partitionierungsschema. Dieses besteht aus einer schnittfrei- tionskonflikte. Bei der Rekomposition müssen diese aufge-
en und lückenlosen Menge von Polygonen (Partitionspoly- löst und die Ergebnisse wieder zu einem Gesamtdatensatz
gone), denen jeweils eine eindeutige Partitionsnummer zu- zusammengesetzt werden, der keine Spuren der Partitionie-
geordnet ist. Es ist möglich, ein vordefiniertes Partitionie- rung mehr enthält. Dabei sollen aus den Ergebnisdaten der
rungsschema (z.B. eine Unterteilung in Verwaltungsbezir- Berechnung für eine Partition möglichst immer die Objekte
ke), das in der Datenbank gespeichert ist, zu verwenden, übernommen werden, die sich innerhalb des Partitionspoly-
oder den Partitionierungsdienst ein geeignetes Schema (z.B. gons befinden, da wir diese Ergebnisse als korrekt ansehen.
ein Gitter aus gleich großen Rechtecken) erzeugen zu lassen. Die aufgrund von fehlendem Kontext möglicherweise fehler-
Berechnungen in Geoprogrammen weisen oft eine mehr behafteten Ergebnisdaten außerhalb des Polygons sind zu
oder weniger starke Abhängigkeit vom räumlichen Kontext verwerfen und aus dem Ergebnis der Partition zu überneh-
der Datenobjekte auf. Dies bedeutet, dass nur dann korrekte men, die diese Daten im Inneren enthält. Unterschiedliche
Ergebnisse in einem bestimmten Gebiet erzeugt werden kön- Rekompositionsoperationen werden insbesondere benötigt,
nen, wenn auch die Objekte aus einer lokalen Umgebung die- um verschiedene Konflikte zwischen ausgedehnten Objekten
ses Gebiets in der Partition enthalten sind. Bei einer streng aufzulösen, die die Grenze zwischen benachbarten Partitio-
disjunkten Aufteilung der geographischen Daten, wie durch nen überlappen. Beispiele passender Partitionierungs- und
das Partitionierungsschema vorgegeben, steht insbesondere Rekompositionsoperationen für eine geographische Anwen-
für Objekte am Rand der Partition möglicherweise nicht ge- dung werden wir in Abschnitt 4 vorstellen.
nug Kontext zur Verfügung, da Objekte von außerhalb des
Partitionspolygons beim Aufruf des Geoprogramms nicht in 3.3 Repräsentationsmodelle
den Daten enthalten sind. Um diesen Nachteil zu kompen- Ein wesentliches Ziel beim Entwurf des Partitionierungs-
sieren, erlauben es die von uns entwickelten Operationen, dienstes ist Flexibilität. Die von diesem Dienst angebotenen
dass dieselben Datenobjekte in mehreren Partitionen ent- Operationen zur Partitionierung und Rekomposition sollen
halten sind, was wir als Redundanz bezeichnen. Das Ziel für eine möglichst große Vielfalt von Geoprogrammen an-
dabei ist es, dass beim Aufruf des Geoprogramms für eine wendbar sein, um Berechnungen auf großen Datensätzen zu
Partition genug Daten in dieser enthalten sind, um korrek- ermöglichen. Geographische Daten können jedoch auf viele
te Ergebnisse zumindest für alle Positionen innerhalb des verschiedene Arten strukturiert sein. Das Datenbankschema
Partitionspolygons zu berechnen. für einen geographischen Datensatz bezeichnen wir im Fol-
Die Erzeugung von Redundanz in den partitionierten Da- genden als Repräsentationsmodell dieser Daten. Um trotz
ten lässt sich auf verschiedene Arten erreichen. Eine Mög- der Heterogenität unterschiedlicher Repräsentationsmodelle
lichkeit ist, die Partitionspolygone um einen festen Abstand nicht für jede Anwendung eigene Operationen anbieten zu
zu vergrößern, so dass sich benachbarte Polygone am Rand müssen, identifizieren wir typische Strukturen bzw. Teilsche-
überlappen. Diese Operation, die auch in Abbildung 2 dar- mata, die in vielen Modellen auftreten. Sind die für eine An-
gestellt ist, bezeichnet man als Pufferbildung. In Abschnitt wendung relevanten Informationen in einer solchen Struktur
4 geben wir weitere Möglichkeiten an, bei denen redundant modelliert oder lassen sich in diese transformieren, können
zu repräsentierende Daten über die Beziehungen zwischen wir Operationen zur Partitionierung und Rekomposition ein-
den Objekten bestimmt werden. Zu beachten ist dabei, dass setzen, die für ein solches Teilschema implementiert sind.
sich in Abhängigkeit davon, wieviel Redundanz man für eine Der zentrale Teil des Schemas für einen geographischen
bestimmte Anwendung benötigt, das Datenvolumen für ein- Datensatz bildet häufig die in Abbildung 3 dargestellte Struk-
zelne Partitionen vergrößert. Im schlimmsten Fall kann eine tur. Die zu beschreibenden Merkmale der Erdoberfläche sind
Partition dann mit dem zur Verfügung stehenden Hauptspei- in den Daten durch Objekte dargestellt, die neben der räum-
cher nicht mehr bearbeitet werden, wodurch das eigentliche lichen Beschreibung durch eine Geometrie noch einen inner-
Ziel der Partitionierung verfehlt wird. Häufig kann man für halb des Datensatzes eindeutigen Identifikator und eine Ob-
Geoprogramme nachweisen oder experimentell belegen, dass jektart besitzen. Letztere legt fest, um was für einen Typ
die Abhängigkeit vom Kontext auf Umgebungen mit kleiner (z.B. Straße oder Ackerfläche) von Objekt es sich handelt.
räumlicher Ausdehnung beschränkt bleibt (siehe z.B. [6]). Zur feineren Charakterisierung der Objekte können weitere
In diesen Fällen sprechen wir davon, dass diese Programme Attribute verwendet werden, wobei die erlaubten Typen von
37
Ein Partitionierungsdienst für Geographische Daten in Räumlichen Datenbanken
folglich im Gegensatz zum Spaghetti-Modell nur einmal ab-
gespeichert werden muss. Ein weiterer Unterschied besteht
darin, dass im TDM die topologischen Beziehungen der Ele-
mente zueinander explizit gespeichert werden. Dadurch kön-
nen z.B. benachbarte Flächen bestimmt werden, ohne dass
Abb. 3: Objekte, Attribute und Beziehungen man geometrische Berechnungen durchführen muss.
Weitere typische Schemata werden bei der Integration von
Daten verwendet, um Zuordnungen von Objekten aus unter-
Attributen häufig von der Objektart abhängen (z.B. Brei- schiedlichen Datensätzen zu modellieren [7]. Wir verzichten
te der Fahrbahn für Straßen). Weiterhin benötigt man Be- aus Platzgründen auf eine detaillierte Beschreibung.
ziehungen zwischen den Objekten, die ebenfalls von unter-
schiedlichem Typ sein können, um z.B. Über- und Unterfüh-
rungen an Straßenkreuzungen zu modellieren. 4. ANWENDUNGSBEISPIEL
Durch ein Repräsentationsmodell können für die Geome- Als anschauliches Beispiel für die Verwendung unterschied-
trien der Objekte verschiedene Einschränkungen festgelegt licher Partitionierungs- und Rekompositionsoperationen be-
sein, die es beim Partitionieren und Rekomponieren zu be- trachten wir in diesem Abschnitt das geometrische Problem
rücksichtigen gilt. Eine häufige Einschränkung betrifft z.B. der Liniensegmentierung. Dieses besteht darin, eine Men-
den Geometrietyp, wenn nur Punkte, Linien oder Flächen in ge von Linienobjekten, die sich beliebig überschneiden dür-
einem Datensatz enthalten sind. Weitere gebräuchliche Ein- fen, in eine schnittfreie Menge von Linien zu transformie-
schränkungen sind die Forderung der Schnittfreiheit, d.h. ren. Es gibt eine Reihe von nützlichen Anwendungen, wie
Geometrien verschiedener Objekte dürfen sich nur an den z.B. zur Erzeugung der Menge von Kanten bei der Trans-
Rändern überschneiden, oder das Verbot von Lücken, so formation von Spaghetti-Daten in ein topologisches Daten-
dass der komplette Datenraum durch Flächenobjekte über- modell. Die hier verwendete Implementierung besteht aus
deckt sein muss. Ein Beispiel für Repräsentationsmodelle zwei Schritten. Zuerst werden mit Hilfe eines Plane-Sweep-
mit solchen Einschränkungen sind Landbedeckungsdaten [6]. Verfahrens [1] alle Paare sich schneidender Linien bestimmt.
Diese bestehen aus einer schnittfreien und lückenlosen Men- Anschließend wird jede Linie an allen Schnittpunkten unter-
ge von Flächenobjekten, denen als Objektart jeweils eine teilt, so dass diese im Ergebnis durch mehrere Linien darge-
Landbedeckungsklasse (z.B. Nadelwald) zugeordnet ist. stellt wird, die sich mit anderen Linien nur noch an den End-
Repräsentationsmodelle mit linien- oder flächenhaften Geo- punkten überschneiden. Liegen dabei zwei Linien auf einem
metrien, die nicht schnittfrei sind, werden ein wenig abwer- längeren Abschnitt übereinander, wird für diesen Abschnitt
tend auch als Spaghetti-Datenmodelle bezeichnet [4]. Wäh- nur eine einzelne Linie ins Ergebnis übernommen.
rend sie für die Herstellung von Karten gut geeignet sind, Im Folgenden stellen wir für die Liniensegmentierung drei
bevorzugt man für raumbezogene Analysen sogenannte to- Strategien zur Partitionierung und Rekomposition aus dem
pologische Datenmodelle (TDM). Die grundlegende Struktur in Abschnitt 3 beschriebenen Partitionierungsdienst vor. Es
eines topologischen Datenmodells ist in Abbildung 4 darge- sei angemerkt, dass die für diese Strategien angebotenen Da-
stellt. Knoten bilden punktförmige Objekte in einem TDM tenbankprozeduren in der Anwendbarkeit nicht auf dieses
eine Problem eingeschränkt sind, sondern sich auch für viele
weitere Geoprogramme einsetzen lassen. Beispielsweise wur-
de Variante 1 bereits in [6] erfolgreich für die Generalisierung
von Flächendaten angewendet.
4.1 Clipping & Vereinigung
Wir wählen in dieser Variante für eine Partition alle Ob-
jekte aus, deren Geometrien sich mit dem Partitionspolygon
überschneiden. Zusätzlich schneiden wir bei Objekten am
Rand der Partition den Teil der Geometrie ab, der über das
Partitionspolygon herausragt. Folglich verbleibt nur der in-
nerhalb des Partitionspolygons liegende Anteil als geometri-
sche Repräsentation des Objekts in der Partition. Dies wird
allgemein auch als Clipping bezeichnet. Durch diese Art von
Abb. 4: Datenstruktur eines TDMs Aufteilung kann ein Linienobjekt ggf. in mehreren Partitio-
nen auftreten, allerdings jeweils mit einem unterschiedlichen
ab und können außerdem die Endpunkte von Kanten dar- Teil seiner Geometrie, weshalb wir die Partitionierung als
stellen. Kanten wiederum repräsentieren linienhafte Objek- disjunkt bezeichnen können. Bei der Liniensegmentierung
te und bilden die Ränder von Maschen. Und solche Ma- für eine Partition werden alle Schnitte von Objekten gefun-
schen entsprechen Teilen von flächenhaften Objekten. Die den, die innerhalb des Partitionspolygons liegen, und die
drei Mengen verschiedenartiger TDM-Elemente sind jeweils Geometrien entsprechend aufgeteilt.
schnittfrei, allerdings können ein Knoten oder eine Kante in Betrachtet man die Ergebnisse der Liniensegmentierung
einer Masche enthalten sein. Ein geographisches Objekt ist für die einzelnen Partitionen gemeinsam, fällt auf, dass ne-
durch die TDM-Elemente repräsentiert, durch deren Aggre- ben den korrekten Unterteilungen an den Linienschnittpunk-
gation man die Geometrie des Objekts rekonstruieren kann. ten zusätzlich Unterteilungen an den Schnittpunkten mit
Dabei kann dasselbe Element (z.B. eine Kante) zu mehre- den Rändern der Partitionen auftreten, was auf das Clip-
ren Objekten gehören und repräsentiert in diesem Fall einen ping zurückzuführen ist. Man betrachte z.B. die Situation
gemeinsamen Bestandteil der Geometrien der Objekte, der in Abbildung 5, in der aus drei Linienobjekten a, b und c
38
Ein Partitionierungsdienst für Geographische Daten in Räumlichen Datenbanken
c1 c1
b1 b1
a2 a4 a2 a4
a1 a3 a1 a3
b2 c2 b2 c2
Abb. 5: Überflüssige Segmentierung Abb. 6: Überlappende Linien
insgesamt acht segmentierte Linien erzeugt wurden. Bei der weder bereits im Ergebnis enthalten oder werden beim Re-
Unterteilung zwischen a2 und a3 liegt allerdings kein echter komponieren einer der nächsten Partitionen eingefügt. Für
Schnitt vor. Da derartige Situationen ohne Partitionierung Situationen wie in Abbildung 6 bestimmen wir für die sich
nicht auftreten würden, liegen hier Rekompositionskonflik- überlappenden Linien den gemeinsamen Teil durch eine geo-
te vor und müssen durch eine geeignete Operation bereinigt metrische Durchschnittsoperation. Z.B. fügen wir anstelle
werden. Dazu bestimmen wir, welche Linien aus dem bereits der zu langen Linien a2 und a3 nur deren Durchschnitt ins
zusammengesetzten Ergebnis welche anderen Linien aus der Gesamtergebnis ein.
aktuellen Partition an der Partitionsgrenze berühren und fü-
gen diese durch eine Vereinigung zu einer Linie zusammen. 4.3 Objektüberschneidung & Duplikate
Wir müssen allerdings auch berücksichtigen, dass ein Li- Im Vergleich zur vorigen Variante können wir die Elimi-
nienobjekt aus dem Ausgangsdatensatz mehrmals den Rand nierung der Duplikate bei der Rekomposition weiter verein-
der Partition schneiden kann, weshalb wir ggf. auch Grup- fachen, wenn wir bei der Partitionierung noch mehr Red-
pen von mehr als zwei Linien zu einem Objekt vereinigen undanz hinzufügen. Wir bezeichnen dazu die Linienobjekte,
müssen. Ein weiterer Sonderfall liegt vor, wenn sich zwei die das Polygon der Partition p schneiden, als p-Objekte.
Linien aus dem Ausgangsdatensatz genau auf dem Rand Um alle p-Objekte bei der Berechnung für diese Partition
eines Partitionspolygons überschneiden, weil es sich dann korrekt zu segmentieren, müssen wir bei der Partitionierung
bei dem nach obiger Vorschrift ermittelten Berührungspunkt noch Linien von außerhalb der Partition hinzunehmen, die
um einen echten Schnittpunkt handelt und somit keine Ver- sich mit einem p-Objekt überschneiden.
einigung stattfinden darf. Wir können diese Situationen da- Dadurch, dass bei der Partitionierung mehr Objekte re-
durch erkennen, dass sich zwei segmentierte Linien aus der- dundant für mehrere Partitionen ausgewählt werden, ent-
selben Partition an einem solchen Punkt berühren. stehen auch mehr Duplikate, die bei der Rekomposition ent-
fernt werden müssen (siehe Abbildung 7). Die meisten dieser
4.2 Partitionsüberschneidung & Durchschnitt Duplikate werden wir wieder los, indem wir (wie bei Variante
Wie in der ersten Variante wählen wir alle Objekte aus, die 2) Linien außerhalb des Partitionspolygons verwerfen (z.B.
das Partitionspolygon schneiden, verzichten aber auf Clip- a′1 /a′4 ). Bei allen Linien im Ergebnis einer Partition, die den
ping. Die Intention dabei ist es, aufwändige Berechnungen Rand des Partitionspolygons schneiden, können allerdings in
zum Abschneiden und Vereinigen der Geometrien einzuspa- dieser Variante nur echt übereinstimmende Duplikate auftre-
ren. Dafür nehmen wir etwas Redundanz in Kauf, denn Lini- ten, denn diese Linien wurden vollständig segmentiert. An-
en aus dem Ausgangsdatensatz, die über den Rand der Par- statt Durchschnitte zu berechnen, reicht es somit aus, von
tition hinausragen, werden in mehreren Partitionen mit ih- den am Rand der Partition auftretenden Duplikaten (hier
rer vollständigen Geometrie repräsentiert, so dass eine nicht a2 /a3 ) jeweils ein Objekt ins Ergebnis zu übernehmen.
disjunkte Partitionierung vorliegt. Schnitte zwischen solchen
Objekten werden demnach bei der Segmentierung mehrfach
in unterschiedlichen Partitionen berechnet.
Beim Rekomponieren einer Partition müssen Duplikate c1
c'1 a'4
b1
aus den Ergebnissen entfernt werden, da die aus den mehr- b'1 a2 a4
fach repräsentierten Objekten gebildeten Linien auch mehr- a1 a3
fach in den Ergebnissen auftreten. Allerdings stimmen diese a'1 c'2 c2
Duplikate in Bezug auf die Segmentierung nicht zwingend b2
b'2
überein, denn der Schnitt einer über den Rand der Partiti-
on hinausragenden Linie mit einer Linie, die komplett außer-
halb der Partition liegt, wird bei der Berechnung in dieser
Partition nicht gefunden. Man betrachte z.B. die Situation Abb. 7: Doppelte Linien
in Abbildung 6. Während im Ergebnis der linken Partition
(cyan) die Linie a am Schnittpunkt mit b in a1 und a2 unter-
teilt wurde, fehlt die Unterteilung am Schnittpunkt mit c.
Für das Ergebnis der rechten Partition (magenta) hingegen 5. ERGEBNISSE
ist die Situation genau umgekehrt. Um die Anwendbarkeit der in Abschnitt 4 vorgestellten
Um Duplikate zu entfernen, verwerfen wir beim Rekom- Partitionierungs- und Rekompositionsoperationen zu demon-
ponieren einer Partition zunächst alle Linien, die komplett strieren und die Varianten miteinander zu vergleichen, füh-
außerhalb des Partitionspolygons liegen, denn diese sind ent- ren wir Tests mit einem ca. 7,2GB großen kommerziell pro-
39
Ein Partitionierungsdienst für Geographische Daten in Räumlichen Datenbanken
duzierten Datensatz durch, der das gesamte Bundesland Hes- kale Algorithmen gelöst werden können, so dass die benötig-
sen umfasst. Diese Daten enthalten Informationen über Stra- te Redundanz bei der Partitionierung nicht zu groß wird.
ßen und weitere für den Kraftfahrzeugverkehr relevante geo- Während für die in diesem Beitrag vorgestellten Expe-
graphische Objekte in Form von Liniengeometrien, die für rimente die Größe der Partitionen fest vorgegeben wurde,
die kartographische Darstellung optimiert und insbesonde- ist es für einen Anwender des Partitionierungsdienstes wün-
re nicht schnittfrei sind. Partitionierung und Rekomposition schenswert, stattdessen die Größe des verfügbaren Speichers
sind in einer Datenbank (Oracle 11g) mit räumlicher Er- angeben zu können, für die der Dienst dann ein geeignetes
weiterung (Oracle Spatial) implementiert. Zur Segmentie- Partitionierungsschema berechnet. Daher arbeiten wir dar-
rung verwenden wir ein Programm aus einer Java-Bibliothek an, Modelle aus der Literatur zum Schätzen der Partitions-
für geometrische Berechnungen (JTS Topology Suite), das größe für räumliche Verbunde zu verallgemeinern, um diese
durch zahlreiche Optimierungen auf Kosten eines hohen Spei- auch auf andere Geoprogramme anwenden zu können. Da-
cherverbrauchs sehr effizient arbeitet. bei muss auch berücksichtigt werden, dass reale geographi-
Wir führen für diesen Datensatz mit jeder der drei Va- sche Daten nicht gleichmäßig verteilt sind, und somit auch
rianten eine Segmentierung durch, wobei wir ein Partitio- die Partitionsgröße innerhalb eines Partitionierungsschemas
nierungsschema aus 129 Quadraten mit jeweils 25km Kan- abhängig von der Datendichte variieren sollte.
tenlänge verwenden. Wir messen und summieren dabei je- Um das Spektrum von möglichen Anwendungen für den
weils separat die Laufzeiten, die bei der Partitionierung, Seg- Partitionierungsdienst zu vergrößern, muss dieser um weite-
mentierung und Rekomposition für alle Partitionen benötigt re Operationen und insbesondere weitere Repräsentations-
werden. Diese Laufzeiten sind in Abbildung 8 dargestellt. modelle erweitert werden. Außerdem werden wir genauer
Die Laufzeit für die Segmentierung ist erwartungsgemäß in untersuchen, wie sich dieser Dienst möglichst gewinnbrin-
gend für die Fortführung von abgeleiteten Datensätzen ein-
setzen lässt. Dieser Ansatz basiert auf der Idee, bei Updates
für Geobasisdaten zunächst möglichst kleine, aber räumlich
zusammenhängende Gebiete zu identifizieren, in denen Än-
derungen stattgefunden haben. Für die Aktualisierung von
abgeleiteten Datensätzen müssen dann unter Verwendung
von Partitionierung und Rekomposition nur diese Gebiete
an Stelle des kompletten Datensatzes neu berechnet werden.
7. DANKSAGUNG
Diese Arbeit wurde vom Bundesamt für Kartographie und
Geodäsie im Rahmen des Projekts Wissensbasierter Photo-
grammetrisch-Kartographischer Arbeitsplatz (WiPKA) ge-
fördert.
Abb. 8: Laufzeiten (in Sek.) der Prozessphasen
8. LITERATUR
[1] Berg, M. de ; Cheong, O. ; Kreveld, M. van ;
Overmars, M. : Computational Geometry: Algorithms
der ersten Variante am geringsten und steigt durch das Hin-
and Applications. 3.Aufl. Springer-Verlag, 2008
zufügen von mehr Redundanz in Variante 2 und 3 jeweils
leicht an. Am meisten Zeit benötigt in allen Varianten die [2] Dittrich, J.-P. ; Seeger, B. : Data Redundancy and
Rekomposition. Während diese in Variante 3 die geringste Duplicate Detection in Spatial Join Processing. In:
Laufzeit benötigt, ist dabei jedoch eine vergleichsweise auf- Proc. ICDE 2000, San Diego, S. 535–546
wändige Partitionierung nötig. Die beste Gesamtlaufzeit hat [3] Güting, R. H. ; Schilling, W. : A Practical
somit Variante 2, bei der die Partitionierung am schnellsten Divide-and-Conquer Algorithm for the Rectangle
geht und die Zeiten für Segmentierung und Rekomposition Intersection Problem. In: Information Sciences 42
jeweils in der Mitte liegen. (1987), Nr. 2, S. 95–112
[4] Hake, G. ; Grünreich, D. ; Meng, L. : Kartographie.
6. FAZIT 8.Aufl. Walter de Gruyter & Co., 2002
[5] Patel, J. M. ; DeWitt, D. J.: Partition Based
Der in diesem Beitrag vorgestellte Partitionierungsdienst
Spatial-Merge Join. In: Proc. SIGMOD 1996, Montreal,
für geographische Daten in räumlichen Datenbanken besteht
S. 259–270
im Wesentlichen aus einer Sammlung von flexibel anwendba-
ren Partitionierungs- und Rekompositionsoperationen. Die- [6] Thiemann, F. ; Warneke, H. ; Sester, M. ; Lipeck,
se erlauben es, Geoprogramme mit sehr geringem Entwick- U. : A Scalable Approach for Generalization of Land
lungsaufwand fit für die Bearbeitung großer Datenmengen Cover Data. In: Proc. 14th AGILE Intl.Conf. on Geo-
zu machen. Dabei bleibt die Freiheit der Wahl einer Pro- graphic Information Systems. Utrecht, 2011, S. 399–420
grammiersprache und von Software-Bibliotheken sowie die [7] Warneke, H. ; Schäfers, M. ; Lipeck, U. ; Bobrich,
gute Wartbarkeit der Geoprogramme erhalten, da Zugriffe J. : Matching-Based Map Generalization by
auf extern gespeicherte Daten nur während der Partitionie- Transferring Geometric Representations. In: Proc.
rung und Rekomposition erfolgen müssen. Neben dem an Geoinformatik 2011, Münster, S. 71–77
dieser Stelle vorgestellten Anwendungsbeispiel eignet sich [8] Zhou, X. ; Abel, D. J. ; Truffet, D. : Data
diese Vorgehensweise für eine Vielzahl weiterer geographi- Partitioning for Parallel Spatial Join Processing. In:
scher Problemstellungen, sofern diese durch hinreichend lo- GeoInformatica 2 (1998), Nr. 2, S. 175–204
40
Cloud Data Management: A Short Overview and
Comparison of Current Approaches
Siba Mohammad Sebastian Breß Eike Schallehn
Otto-von-Guericke University Otto-von-Guericke University Otto-von-Guericke University
Magdeburg Magdeburg Magdeburg
siba.mohammad@iti.uni- sebastian.bress@st.ovgu.de eike@iti.cs.uni-magdeburg.de
magdeburg.de
ABSTRACT
Users / Applications Users / Applications
To meet the storage needs of current cloud applications,
new data management systems were developed. Design de-
cisions were made by analyzing the applications workloads
Query Language Relational Cloud Storage Service
and technical environment. It was realized that traditional
Relational Database Management Systems (RDBMSs) with
their centralized architecture, strong consistency, and rela-
tional model do not fit the elasticity and scalability require- Relational DBMS
ments of the Distributed Processing
cloud. Different System with a variety
architectures
of data partitioning schemes and replica placement strate-
gies were developed. As for the data model, the key-value
pairs with its variations were adopted for cloud storage. The Figure 1: RDBMS as a service
Structured Data System
contribution of this paper is to provide a comprehensible
overview of key-characteristics of current solutions and out-
line the problems they do and do not address. This paper across heterogeneous hardware and software platforms. It
should serve as an Storage
entry point for orientation of future re- will store tera bytes of data, thus parameters of I/O opera-
Distributed System
search regarding new applications in cloud computing and tions and block sizes must be adapted to large sizes. Based
advanced requirements for data management. on these assumptions the requirements for a cloud DBMS
are: elasticity, scalability, fault tolerance and self manage-
ability [11]. The rest of the paper is organized as follows.
1. INTRODUCTION First, we provide an overview of the architecture and the
Data management used within the cloud or offered as a family tree of the cloud storage systems. Then, we discuss
service from the cloud is an important current research field. how different systems deal with the trade-off in the Con-
However, there are only few publications that provide a sur- sistency, Availability, Partition tolerance (CAP) theorem.
vey and compare the different approaches. The contribution After that, we discuss different schemes used for data parti-
of this paper is to provide a starting point for researchers and tioning and replication. Then, we provide a list of the cloud
developers who want to work on cloud data management. data models.
Cloud computing is a new technology that provides resources
as an elastic pool of services in a pay-as-you-go model [5].
Whether it is storage space, computational power, or soft-
2. ARCHITECTURE OVERVIEW
ware, customers can get it over the internet from one of the There are two main approaches to provide data manage-
cloud service providers. Big players in the market, such as ment systems for the cloud. In the first approach, each
Google [8], Amazon [13], Yahoo! [9], and Hadoop [7], defined customer gets an own instance of a Database Management
the assumptions for cloud storage systems based on analyz- System (DBMS), which runs on virtual machines of the ser-
ing the technical environment and applications workload. vice provider [10] as illustrated in Figure 1. The DBMS
First, a data management system will work on a cluster of supports full ACID requirements with the disadvantage of
storage nodes where components failure is the normal situ- loosing scalability. If an application requires more comput-
ation rather than the exception. Thus, fault tolerance and ing or storage resources than the maximum allocated for an
recovery must be built in. The system must be portable instance, the customer must implement partitioning on the
application level using a different database instance for each
partition [1]. Another solution is on demand assignment of
resources to instances. Amazon RDS is an example of rela-
tional database services, that supports MySQL, Oracle, and
SQL Server.
In the second approach, data management is not provided
as a conventional DBMS on a virtualized platform, but as
a combination of interconnected systems and services that
24th GI-Workshop on Foundations of Databases (Grundlagen von Daten-
banken), 29.05.2012 - 01.06.2012, Lübbenau, Germany. can be combined according to application needs. Figure 2
Copyright is held by the author/owner(s). illustrates this architecture. The essential part is the dis-
41
Cloud Data Management: A Short Overview and Comparison of Current Approaches
Users / Applications 2010 Users / Applications
RDS
HadoopDB
Hive
Query Language Relational Cloud Storage Service
2009 Cassandra
Relational DBMS
Distributed Processing System 2008
Hadoop MR HBase
HDFS Dynamo SimpleDB
Structured Data System 2007
S3
2006
Distributed Storage System
2005 Google MR
Figure 2: Cloud data management architecture
Bigtable
2004
tributed storage system. It is usually internally used by the
cloud services provider and not provided as a public service. GFS
use the system
It is responsible for providing availability, scalability, fault 2003
use concepts
tolerance, and performance for data access. Systems in this
layer are divided in three categories: File system DBMS
• Distributed File Systems (DFS), such as Google’s File
System (GFS). Figure 3: Family tree of cloud data management
• Cloud based file services, such as Amazon’s Simple systems
Storage Service (S3).
• Peer to peer file systems, such as Amazon’s Dynamo. tree of cloud storage systems as illustrated in Figure 3. We
use a solid arrow to illustrate that a system uses another one
The second layer consists of structured data systems and such as Hive using HDFS. We use a dotted arrow to illus-
provides simple data models such as key-value pairs, which trate that a system uses some aspects of another system like
we discuss in Section 6. These systems support various APIs the data model or the processing paradigm. An example of
for data access, such as SOAP and HTTP. Examples of sys- this is Cassandra using the data model of Bigtable. In this
tems in this layer are Google’s Bigtable, Cassandra, and family tree, we cover a range of commercial systems, open
SimpleDB. The third layer includes distributed processing source projects, and academic research as well. We start
systems, which are responsible for more complex data pro- on the left side with distributed storage systems GFS and
cessing, e.g, analytical processing, mass data transforma- HDFS. Then, we have the structured storage systems with
tion, or DBMS-style operations like joins and aggregations. API support such as Bigtable. Furthermore, there are sys-
MapReduce [12] is the main processing paradigm used in tems that support a simple QL such as SimpleDB. Next, we
this layer. have structured storage systems with support of MapReduce
The final layer includes query languages. SQL is not sup- and simple QL such as Cassandra and HBase. Finally, we
ported. However, developers try to mimic SQL syntax for have systems with sophisticated QL and MapReduce sup-
simplicity. Most query languages of cloud data management port such as Hive and HadoopDB. We compare and classify
systems support access to one domain, key space, or table, these systems based on other criteria in the coming sections.
i.e., do not support joins [4, 2]. Other functionalities, such An overview is presented in Figure 4.
as controlling privileges and user groups, schema creation,
and meta data access are supported. Examples of query
languages for cloud data are HiveQL, JAQL, and CQL. The 3. CONSISTENCY, AVAILABILITY, PARTI-
previous components complement each other and work to- TION TOLERANCE (CAP) THEOREM
gether to provide different sets of functionalities. One im- Tightly related to key features of cloud data management
portant design decision that was made for most cloud data systems are discussions on the CAP theorem [14]. It states
query languages is not supporting joins or aggregations. In- that consistency, availability, and partition tolerance are sys-
stead, the MapReduce framework is used to perform these tematic requirements for designing and deploying applica-
operations to take advantage of parallel processing on differ- tions for distributed environments. In the cloud data man-
ent nodes within a cluster. Google pioneered this by provid- agement context these requirements are:
ing a MapReduce framework that inspired other systems.
For more insight into connections and dependencies be- • Consistency: includes all modifications on data that
tween these systems and components, we provide a family must be visible to all clients once they are committed.
42
Cloud Data Management: A Short Overview and Comparison of Current Approaches
System
Analytical RDBMS
Distributed Storage/File System Structured Data Systems Processing as
Systems service
Amazon S3
HadoopDB
Cassandra
SimpleDB
CouchDB
Dynamo
Bigtable
PNUTS
HBase
HDFS
Hive
RDS
GFS
Property
Consistency Model
ACID X X
BASE X X X X
SCLA X X X
Tunable
X X
Consistency
Partitioning Scheme
Hash X X
Range X X X
List X X
Composite X X
Partition Key
file file table table table table table
Level space
set of set of
Partition chunk chunk tablet region tablet bucket chunk
items items
Data Models
Key Value X X X X X X X X
Row
X
Oriented
Wide
X X X X
Column
Document
X
Oriented
Relational X X X
Replication
Rack aware X X X X X X
Rack
X X X
unaware
Datacenter
X X X X
aware
Replication DB DB DB
item chunk block item domain tablet record DB chunk DB
Level file file file
Map/Reduce
Internally X X
Input for X X X X X X X X
Interface
Query Lang X X X X X X
API X X X X X X X X X X X
Figure 4: Overview and classification of cloud data management systems(Gray field begins a new category of
properties. Dark gray field means that the property is not applicable on a system) 43
Cloud Data Management: A Short Overview and Comparison of Current Approaches
At any given point in time, all clients can read the C
same data.
• Availability: means that all operations on data, whether
read or write, must end with a response within a spec-
ified time.
• Partition tolerance: means that even in the case of HBase
HadoopDB
components’ failures, operations on the database must Hive
RDS
continue. Bigtable
The CAP theorem also states that developers must make
trade-off decisions between the three conflicting requirements
to achieve high scalability. For example, if we want a data
storage system that is both strongly consistent and partition
tolerant, the system has to make sure that write operations Tunable
return a success message only if data has been committed BASE
to all nodes, which is not always possible because of net- A Consistency P
work or node failures. This means that its availability will CouchDB Cassandra
be sacrificed. SimpleDB PNUTS
In the cloud, there are basically four approaches for DBMSs Dynamo
in dealing with CAP: S3
Atomicity, Consistency, Isolation, Durability (ACID):
With ACID, users have the same consistent view of Figure 5: Classification of cloud data management
data before and after transactions. A transaction is systems based on CAP
atomic, i.e., when one part fails, the whole transaction
fails and the state of data is left unchanged. Once a
transaction is committed, it is protected against crashes high consistency or high availability and other degrees
and errors. Data is locked while being modified by in between. An example of a system supporting tun-
a transaction. When another transaction tries to ac- able consistency is Cassandra [15] where the user de-
cess locked data, it has to wait until data is unlocked. termines the number of replicas that the system should
Systems that support ACID are used by applications update/read. Another example is PNUTS [9], which
that require strong consistency and can tolerate its af- provides per record time-line consistency. The user de-
fects on the scalability of the application as already termines the version number to query at several points
discussed in Section 2. in the consistency time-line. In Figure 5, we classify
different cloud data management systems based on the
Basically Available, Soft-state, Eventual consistency
consistency model they provide.
(BASE):
The system does not guarantee that all users see the
same version of a data item, but guarantees that all 4. PARTITIONING TECHNIQUES
of them get a response from the systems even if it Partitioning, also known as sharding, is used by cloud
means getting a stale version. Soft-state refers refers data management systems to achieve scalability. There is a
to the fact, that the current status of a managed ob- variety of partitioning schemes used by different systems on
ject can be ambiguous, e.g. because there are several different levels. Some systems partition data on the file level
temporarily inconsistent replicas of it stored. Even- while others horizontally partition the key space or table.
tually consistent means that updates will propagate Examples of systems partitioning data on the file level are
through all replicas of a data item in a distributed the DFSs such as GFS and HDFS which partition each file
system, but this takes time. Eventually, all replicas into fixed sized chunks of data. The second class of systems
are updated. BASE is used by applications that can which partition tables or key space uses one of the following
tolerate weaker consistency to have higher availability. partitioning schemes [18, 6] :
Examples of systems supporting BASE are SimpleDB
and CouchDB. List Partitioning A partition is assigned a list of discrete
values. If the key of the inserted tuple has one of these
Strongly Consistent, Loosely Available (SCLA): This values, the specified partition is selected . An example
approach provides stronger consistency than BASE. of a system using list as the partitioning scheme is
The scalability of systems supporting SCLA in the Hive [20].
cloud is higher compared to those supporting ACID.
It is used by systems that choose higher consistency Range Partitioning The range of values belonging to one
and sacrifice availability to a small extent. Examples key is divided into intervals. Each partition is assigned
of systems supporting SCLA are HBase and Bigtable. one interval. A partition is selected if the key value of
the inserted tuple is inside a certain range. An example
Tunable consistency: In this approach, consistency is con- of a system using range partitioning is HBase.
figurable. For each read and write request, the user de-
cides the level of consistency in balance with the level Hash Partitioning The output of a hash function is as-
of availability. This means that the system can work in signed to different partitions. The hash function is
44
Cloud Data Management: A Short Overview and Comparison of Current Approaches
applied on key values to determine the partition. This not reach all replicas or a specified number of them within
scheme is used when data does not lend itself to list a specific time. Example of that is the WRITE ALL opera-
and range partitioning. An example of a system using tion in Cassandra, where the write fails if the system could
hash as the partitioning scheme is PNUTS. not reach all replicas of data. However, some systems in the
cloud choose to be always writeable and push conflict res-
There are some systems that use a composite partitioning olution to read operations. An example of that is Dynamo
scheme. An example is Dynamo, which uses a composite of which is used by many Amazon services like the shopping
hash and list schemes (consistent hashing). Some systems cart service where customer updates should not be rejected.
allow partitioning data several times using different parti-
tioning schemes each time. An example is Hive, where each
table is partitioned based on column values. Then, each par- 6. DATA MODEL
tition can be hash partitioned into buckets, which are stored Just as different requirements compared to conventional
in HDFS. DBMS-based applications led to the previously described
One important design consideration to make is whether different architectures and implementation details, they also
to choose an order-preserving partitioning technique or not. led to different data models typically being used in cloud
Order preserving partitioning has an advantage of better data management. The main data models used by cloud
performance when it comes to range queries. Examples of systems are:
systems using order preserving partitioning techniques are
Bigtable and Cassandra. Since most partitioning methods Key-value pairs It is the most common data model for
depend on random position assignment of storage nodes, cloud storage. It has three subcategories:
the need for load balancing to avoid non uniform distribu-
tion of data and workloads is raised. Dynamo [13] focuses on • Row oriented: Data is organized as containers
achieving a uniform distribution of keys among nodes assum- of rows that represent objects with different at-
ing that the distribution of data access is not very skewed, tributes. Access control lists are applied on the
whereas Cassandra [17] provides a load balancer that an- object (row) or container (set of rows) level [19].
alyzes load information to lighten the burden on heavily An example is SimpleDB.
loaded nodes. • Document Oriented: Data is organized as a col-
lection of self described JSON documents. Docu-
5. REPLICATION TECHNIQUES ment is the primarily unit of data which is iden-
tified by a unique ID. Documents are the unit
Replication is used by data management systems in the
for access control [16]. Example of a cloud data
cloud to achieve high availability. Replication means storing
management system with document oriented data
replicas of data on more than one storage node and probably
model is CouchDB.
more than one data center. The replica placement strategy
affects the efficiency of the system [15]. In the following we • Wide column: In this model, attributes are grouped
describe the replication strategies used by cloud systems: together to form a column family. Column family
information can be used for query optimization.
Rack Aware Strategy: Also known as the Old Network Some systems perform access control and both
Topology Strategy. It places replicas in more than one disk and memory accounting at the column fam-
data center on different racks within each data center. ily level [8, 17, 3]. An example of that is Bigtable.
Data Center Aware Strategy: Also known as the New Systems of wide column data model should not be
Network Topology Strategy. In this strategy, clients mistaken with column oriented DB systems. The
specify in their applications how replicas are placed former deals with data as column families on the
across different data centers. conceptual level only. The latter is more on the
physical level and stores data by column rather
Rack Unaware Strategy: Also known as the Simple Strat- than by row.
egy. It places replicas within one data center using a
method that does not configure replica placement on Relational Model (RM) The most common data model
certain racks. for traditional DBMS is less often used in the cloud.
Nevertheless, Amazon’s RDS supports this data model
Replication improves system robustness against node fail- and PNUTS a simplified version of it.
ures. When a node fails, the system can transparently read
data from other replicas. Another gain of replication is in-
creasing read performance using a load balancer that directs 7. SUMMARY AND CONCLUSION
requests to a data center close to the user. Replication has a The cloud with its elasticity and pay-as-you-go model is
disadvantage when it comes to updating data. The system an attractive choice for outsourcing data management ap-
has to update all replicas. This leads to very important de- plications. Cloud service providers, such as Amazon and
sign considerations that impact availability and consistency Microsoft, provide relational DBMSs instances on virtual
of data. The first one is to decide whether to make repli- machines. However, the cloud technical environment, work-
cas available during updates or wait until data is consistent loads, and elasticity requirements lead to the development
across all of them. Most systems in the cloud choose avail- of new breed of storage systems. These systems range from
ability over consistency. The second design consideration is highly scalable and available distributed storage systems
to decide when to perform replica conflicts resolution, i.e., with simple interfaces for data access to fully equipped DBMSs
during writes or reads. If conflict resolution is done during that support sophisticated interfaces, data models, and query
write operations, writes could be rejected if the system can languages.
45
Cloud Data Management: A Short Overview and Comparison of Current Approaches
Cloud data management systems faced with the CAP the- [5] M. Armbrust, A. Fox, R. Griffith, A. D. Joseph, R. H.
orem trade-off provide different levels of consistency ranging Katz, A. Konwinski, G. Lee, D. A. Patterson,
from eventual consistency to strict consistency. Some sys- A. Rabkin, I. Stoica, and M. Zaharia. Above the
tems allow users to determine the level of consistency for clouds: A berkeley view of cloud computing. Technical
each data input/output request by determining the number report, EECS Department, University of California,
of replicas to work with or the version number of the data Berkeley, 2009.
item. List, range, hash, and composite partitioning schemes [6] S. S. Avi Silberschatz, Henry F. Korth. Database
are used to partition data to achieve scalability. With par- System Concepts Fifth Edition. McGraw-Hill, 2010.
titioning comes the need for load balancing with two ba- [7] D. Borthakur. The Hadoop Distributed File System:
sic methods: uniform distribution of data and workloads, Architecture and Design. The Apache Software
and analyzing load information. With data partitioned and Foundation, 2007.
distributed over many nodes, taking into consideration the [8] F. Chang, J. Dean, S. Ghemawat, W. C. Hsieh, D. A.
possibility of node and network failures, comes the need for Wallach, M. Burrows, T. Chandra, A. Fikes, and R. E.
replication to achieve availability. Replication is done on Gruber. Bigtable: A distributed storage system for
the partition level using rack aware, data center aware, and structured data. In In Proceedingss of the 7th
rack unaware placement strategies. Cloud data management Conference on Usenix Symposium on Operating
systems support relational data model, and key-value pairs Systems Design and Implementation - Volume 7,
data model. The key-value pairs is widely used with differ- pages 205–218, 2006.
ent variations: document oriented, wide column, and row [9] B. F. Cooper, R. Ramakrishnan, U. Srivastava,
oriented. A. Silberstein, P. Bohannon, H.-A. Jacobsen, N. Puz,
As outlined throughout this paper, several typical proper- D. Weaver, and R. Yerneni. Pnuts: Yahoo!’s hosted
ties of traditional DBMS, such as advanced query languages, data serving platform. Proc VLDB Endow., 2008.
transaction processing, and complex data models, are mostly
[10] C. Curino, E. Jones, R. A. Popa, N. Malviya, E. Wu,
not supported by cloud data management systems. Some
S. Madden, H. Balakrishnan, and N. Zeldovich.
of them, because they are simply not required for current
Relational Cloud: A Database Service for the Cloud.
cloud applications. Others, because their implementation
In 5th Biennial Conference on Innovative Data
would lead to losing some of the important advantages, e.g.,
Systems Research, 2011.
scalability and availability, of current cloud data manage-
ment approaches. On the one hand, providing features of [11] S. Das, S. Agarwal, D. Agrawal, and A. E. Abbadi.
conventional DBMS appears to lead toward worthwhile re- ElasTraS: An Elastic, Scalable, and Self Managing
search directions and is currently addressed in ongoing re- Transactional Database for the Cloud. Technical
search. On the other hand, advanced requirements, which report, 2010.
are completely different may arise from future cloud appli- [12] J. Dean and S. Ghemawat. Mapreduce: simplified data
cations, e.g., interactive entertainment, on-line role playing processing on large clusters. Commun. ACM, 2008.
games, and virtual realities, have interesting characteristics [13] G. DeCandia, D. Hastorun, M. Jampani,
of continuous, collaborative, and interactive access patterns, G. Kakulapati, A. Lakshman, A. Pilchin,
sometimes under real-time constraints. In a similar way, S. Sivasubramanian, P. Vosshall, and W. Vogels.
new ways of human-computer interaction in real-world en- Dynamo: Amazon’s highly available key-value store.
vironments addressed, for instance, in ubiquitous comput- SIGOPS Oper. Syst. Rev., 2007.
ing and augmented reality are often very data-intensive and [14] A. Fox, S. D. Gribble, Y. Chawathe, E. A. Brewer,
sometimes require expensive processing, which could be sup- and P. Gauthier. Cluster-based scalable network
ported by cloud paradigms. Nevertheless, neither traditional services. SIGOPS Oper. Syst. Rev., 1997.
DBMS nor cloud data management can currently sufficiently [15] E. Hewitt. Cassandra The Definitive Guide. O Reilly
support those applications. Media, Inc, 2010.
[16] J. L. J. Chris Anderson and N. Slater. CouchDB The
8. ACKNOWLEDGMENTS Definitive Guide. OReilly Media, Inc, 2010.
We would like to thank the Syrian ministry of higher ed- [17] A. Lakshman and P. Malik. Cassandra: a
ucation for partially funding this research. decentralized structured storage system. SIGOPS
Oper. Syst. Rev., 2010.
[18] S. B. e. a. Lance Ashdown, Cathy Baird. Oracle9i
9. REFERENCES Database Concepts. Oracle Corporation., 2002.
[1] Amazon RDS FAQ. [19] R. H. Prabhakar Chaganti. Amazon SimpleDB
http://aws.amazon.com/rds/faqs/. [online; accessed Developer Guide Scale your application’s database on
10-March-2012]. the cloud using Amazon SimpleDB. Packt Publishing
[2] Cassandra Query Language Documentation. Ltd, 2010.
http://caqel.deadcafe.org/cql-doc. [online; accessed [20] A. Thusoo, J. S. Sarma, N. Jain, Z. Shao, P. Chakka,
25-July-2011]. S. Anthony, H. Liu, P. Wyckoff, and R. Murthy. Hive:
[3] HBase: Bigtable-like structured storage for Hadoop a warehousing solution over a map-reduce framework.
HDFS. http://wiki.apache.org/hadoop/hbase. [online; Proc. VLDB Endow., 2009.
accessed 01-March-2012].
[4] Jaql Overview.
http://www.almaden.ibm.com/cs/projects/jaql/.
[online; accessed 31-August-2011].
46
Cloud-Services und effiziente Anfrageverarbeitung für
Linked Open Data
[Work in Progress]
Heiko Betz, Kai-Uwe Sattler
Department of Computer Science and Automation
TU Ilmenau, Germany
{first.last}@tu-ilmenau.de
ABSTRACT QL [2] auf. Dies ist eine graph-basierte Anfragesprache für
Der Verbreitungsgrad von Linked Open Data hat in den RDF-Daten. Sie definiert neben der Möglichkeit Daten abzu-
letzten Jahren massiv zugenommen. Stetig erscheinen neue fragen, ähnlich dem SQL aus der Datenbankwelt, ein Trans-
Quellen, die RDF-Daten frei zur Verfügung stellen. Aktu- portprotokoll zwischen verschiedenen SPARQL-Endpoints.
ell diskutiert die Bundesregierung über ein neues Gesetz, In SPARQL selbst werden Basic Graph Patterns (BGP) für
welches zur Offenlegung von Daten der öffentlichen Hand die Abfrage von Daten verwendet, die aus einem oder meh-
verpflichtet. Durch diese Maßnahme, steigt u. a. die Menge reren Tripeln bestehen. Hierdurch ergeben sich joinintensive
an Linked Open Data sehr schnell an. Es werden neue Ver- Abfragen, die eine weitere detaillierte Betrachtung benöti-
fahren benötigt, die mit sehr vielen RDF-Daten gleichzeitig gen.
eine effiziente, skalierbare und mit Garantien versehene Ab-
frage von Daten mittels SPARQL gewährleistet. In dieser Fallunterscheidung.
Arbeit wird ein reines In-Memory Shared-Nothing-System Für die Beantwortung von (komplexen) quellenübergrei-
vorgestellt, das die genannten Anforderungen in effizienter fenden Anfragen müssen nun zwei Fälle unterschieden wer-
Weise erfüllt. Hierfür werden verschiedenste Optimierungs- den [7]:
maßnahmen ergriffen, die das Potenzial moderner Hardware
umfassend ausnutzen. 1. Verteilter Ansatz: Daten bleiben in den Quellen. An-
fragen werden von einem Koordinator entgegengenom-
men, in Subanfragen aufgesplittet, den entsprechenden
1. EINFÜHRUNG Quellen zugesandt, von diesen bearbeitet und das Re-
Die Anzahl an verfügbaren Quellen für Linked Open Data sultat vom Koordinator entgegengenommen.
(LOD) wächst stetig an1 . Unter anderem wurde vor kurzem
von der Bundesregierung die Open Data-Initiative gestartet. 2. Data Warehouse Ansatz: Daten werden von verschie-
Es sollen Daten, die durch Steuergelder finanziert wurden, denen Quellen geladen, vorverarbeitet und lokal abge-
der Öffentlichkeit frei zur Verfügung stehen2 . Insgesamt geht legt (materialisiert). Anfragen können direkt durchge-
die Anzahl an verfügbaren LOD-Quellen in diesem hochver- führt werden. Die Quellen bleiben gleichzeitig erhalten.
teilten System in die Hunderttausende bzw. Millionen über.
Es werden disjunkte bzw. teils überlappende Daten bereit- Punkt 1 besitzt mehrere potenzielle Vorteile. Durch die Ver-
gestellt, die häufig untereinander verlinkt sind, jedoch nicht teilung wird ein Single Point of Failure (SPOF) vermieden.
immer einem gemeinsamen Qualitätsstandard entsprechen. Der Koordinator muss keine Daten speichern, da sie alle
Die innere Struktur von LOD entspricht dem Ressource in den Quellen vorliegen. Er muss nur einen geringen Spei-
Description Framework [1] (RDF) Aufbau. In diesem wer- cherplatz und nur eine geringe Rechenkapazität zur Verfü-
den Daten als Tripel repräsentiert (Subjekt, Prädikat und gung stellen. Ein wichtiger Punkt, der für eine Verteilung der
Objekt). Hierauf baut wiederum die Abfragesprache SPAR- Quellen spricht, ist, dass die Daten nicht an andere Unter-
1
nehmen herausgegeben werden müssen. Es können ’Firmen-
Die LOD-Cloud, welche nur einen minimalen Ausschnitt geheimnisse’ bewahrt werden. Als Nachteile ergeben sich je-
darstellt und unter http://www4.wiwiss.fu-berlin.de/ doch einige Punkte. Die Zerlegung von Anfragen in Subque-
lodcloud/state/ zu finden ist, umfasst mittlerweile ca. 31
Milliarden Einträge. ries und alle daraus folgenden Schritte sind ein hoch komple-
2
http://heise.de/-1429179 xes Problem (Parsing, Normalisierung, eingebettete Anfra-
gen ’herausdrücken’, Vereinfachung, Datenlokalisation, Op-
timierung). Zwei weiter nicht zu unterschätzende Nachtei-
le sind die fehlenden Kontroll- und Überwachungsmechanis-
men der Quellen. Die Antwortzeit in einem solchen Szenario
ist nach oben unbeschränkt. Es ergibt sich, dass keinerlei Ga-
rantien abgegeben werden können. Weiterhin ist durch die
Verteilung das verwendete Schema dem Koordinator gänz-
lich unbekannt. Viele Quellen sind zudem nicht in der Lage,
24th GI-Workshop on Foundations of Databases (Grundlagen von Daten-
banken), 29.05.2012 - 01.06.2012, Lübbenau, Germany. SPARQL-Anfragen zu verarbeiten. Sie liefern nur die Quel-
Copyright is held by the author/owner(s). len über einen Webserver aus. Wären SPARQL-Anfragen
47
Cloud-Services und effiziente Anfrageverarbeitung für Linked Open Data
möglich, wären Analyseanfragen à la Data Warehouse-Anfragen hierbei als Framework und nicht als reine Datenablage an-
auch nur bedingt möglich. gesehen werden. Neben SPARQL-Anfragen soll es den Be-
Die zentralen Nachteile des Punktes 2 sind die (i.) benötig- nutzer im gesamten Workflow unterstützen. Unter Work-
te Zeit zum Einsammeln aller Daten, die (ii.) Durchführung flow werden die Folgenden Operationen verstanden: Einfü-
einer Vorberechnung und das Problem, dass niemals gewähr- gen/Löschen/Ändern von Tripeln sowie die Abfrage/Analy-
leistet werden kann, dass (iii.) alle Daten aktuell sind. Zu- se von Daten. Unter dem Stichpunkt Analyse fallen sämtli-
dem wird (iv.) ein SPOF, sowie ein (v.) extrem hoher Spei- che Data-Mining-Aufgaben, die in einem Data-Warehouse-
cherplatz an einer einzigen zentralen Instanz in Kauf genom- Szenario möglich sind. Ein weiteres Ziel ist die Unterstüt-
men. Ein weiterer Nachteil beider Fälle ist das (vi.) unbe- zung von SLAs. Neben dem Garantieren von maximalen
kannte Schema und die (vii.) geringe Datenqualität. Im zen- Antwortzeiten sollen auch Garantien bezüglich der Verfüg-
tralisierten Fall kann jedoch auf die letzten beiden Probleme barkeit und der Aktualität von Daten, sowie einige ande-
effizient reagiert werden, indem entsprechende Indizes ange- re mehr beachtete werden. Letztendlich soll das System als
legt und/oder verschiedenste Optimierungen durchgeführt ein Cloud-Service für LOD-Daten propagiert werden. Das
werden. Eine entsprechende Datenvorverarbeitung kann zu- Ziel hierbei ist, Kosten für den Endbenutzer einzusparen.
dem davor gestartet werden, um die Datenqualität zu ver- Er möchte nur für den von ihm selbst verursachten Aufwand
bessern. Beides wird durch die einheitliche Form der Daten bezahlen (Service on Demand). Im alternativen Fall müsste
als reine Tripel unterstützt. Der große Vorteil, der sich aus eine eigene Infrastruktur aufgebaut werden, was häufig zu
dem zentralisierten Ansatz ergibt, ist die Möglichkeit, An- viel höheren Kosten führt.
fragezeiten zu einem bestimmten Prozentsatz zu gewährleis- Diese Arbeit beschäftigt sich mit einem Teil aus dem so-
ten, da sich das gesamte System unter der Kontrolle einer eben beschriebenen Zieles. Es soll ein erster Ansatz für einen
Instanz befindet. Weiterhin kann ein Scale-Out (Erhöhung Datenspeicher für Linked Open Data aufgezeigt werden, der
der Speicherkapazität (v.), Verbesserung der Antwortzeiten) mit sehr großen Datenmengen eine effiziente Anfrageverar-
und eine Replikation (Beseitigung SPOF (iv.), Verbesserung beitung ermöglicht. Hierfür ist ein zuverlässiges Scale-Out-
der Antwortzeiten) angestrebt werden. Zur Verringerung der Verfahren notwendig, welches vorgestellt wird. Des Weiteren
Speicherkapazität (v.) können effiziente Kompressionstech- soll das gewählte Verfahren auf eine wechselnde Anfragelast
niken verwendet werden, die zugleich lese- und schreibopti- reagieren können.
miert sind, was zu einer weiteren Verringerung des benötig-
ten Speicherplatzes führt. Durch die Verwendung von push 2. STATE-OF-THE-ART
und Bulk Load-Techniken zur Datenintegration anstelle von
Für die Verarbeitung von LOD existieren bereits viele
reinen pull-Techniken kann garantiert werden, dass die abge-
verschiedene Systeme, die RDF-Daten entgegennehmen und
fragten Daten aktuell (iii.) sind. Das Einsammeln von Daten
SPARQL-Queries ausführen. Einige bekanntere System sind
ist nur zu Beginn einmal nötig, wenn eine neue Datenquelle
Virtuoso [5], MonetDB [3], Hexastore [14], Jena [15] und
erschlossen wird (i. und ii.).
RDF-3X [11]. Virtuoso ist ein weitverbreitetes relationales
Der Mechanismus des Scale-Outs und der Replikation be-
Datenbanksystem, das aus allen Kombinationen des Subjek-
dingen jedoch, dass eine Zerlegung der Anfrage durchgeführt
tes, Prädikates und Objektes Indizes erzeugt. Somit kann
werden muss. Wobei dieser eine Nachteil durch die oben ge-
sehr schnell auf Daten zugegriffen werden. MonetDB ist ein
nannten Vorteile aufgewogen wird. Insgesamt sprechen viele
OpenSource Column-Store, der eine Menge von Zwischen-
Faktoren für die Verwendung eines zentralisierten Ansatzes.
ergebnissen im Speicher hält, um neue und ähnliche An-
Garantien bezüglich den soeben erwähnten Antwortzei-
fragen schneller bearbeiten zu können. Hexastore ist eine
ten sind äußerst komplex in ihrer Umsetzung und benötigen
In-Memory-Lösung. Es erzeugt aus allen möglichen Kom-
im extremen Fall viele vorallokierte Kapazitäten, die wäh-
binationen von Tripeln Indizes, die daraufhin in einer Lis-
rend normaler Nutzung brachliegen und hohe Kosten ver-
te abgelegt werden. Für die Vermeidung von Dopplungen
ursachen. Stattdessen werden sie nur während Lastspitzen
und zur Kompression werden Strings in einem Wörterbuch
benötigt. Folglich werden aus diesem Grund häufig prozen-
abgelegt. Jena ein bekanntes OpenSource-Projekt kann ver-
tuale Werte angegeben. Es sollen beispielsweiße 99,99 % aller
schiedene Datenspeicher verwenden. Einerseits können die
Anfragen in der maximal erlaubten Zeitspanne beantwortet
Daten in einem eigenen Format abgelegt werden, anderer-
werden. Erst ein solches Vorgehen erlaubt es, dass während
seits in einer relationalen Datenbank. Auch Jena verwendet
einer Lastspitze neue Kapazitäten hinzugenommen werden
ein Wörterbuch zur Kompression. RDF-3X verwendet auch
können (automatisierter Scale-Out). Das Ziel hierbei ist, zu-
mehrere Indizes, um alle möglichen Kombinationen abzu-
künftige Anfragen wieder innerhalb der gesetzten Antwort-
speichern und legt diese in B+-Bäumen ab. Zudem enthält
zeit beantworten zu können. Am Ende der Lastspitze wer-
es eine ausgeklügelte Anfrageoptimierung, die speziell auf
den die zusätzlich allokierten Ressourcen wieder freigege-
die Besonderheiten von RDF abgestimmt ist.
ben. Letztendlich werden hierdurch Kosten für den Betrei-
Werden alle vorgestellten Systeme genauer betrachtet, stellt
ber des Services eingespart. Wichtig zu erwähnen ist, dass
man fest, dass diese einige Nachteile besitzen. Entweder sind
die Garantie bezüglich der Antwortzeit nicht für jede belie-
diese auf bestimmte Operationen (lesen, ändern) und/oder
bige SPARQL-Anfrage garantiert werden kann. Stattdessen
Domänen getrimmt und/oder sind nicht skalierbar im Sinne
soll dies nur für gewöhnliche“ Anfragen gelten.
” eines Scale-Outs und somit ungeeignet für sehr große Da-
tenmengen. Stattdessen setzten sie auf die Leistung einer
Projektziel. einzigen Maschine, was zu einem erheblichen Performance-
Das Ziel dieses Projektes ist es, ein hochverfügbares, - , Speicherplatz- und Verfügbarkeitsproblem werden kann.
skalierbares und -effizientes System aufzubauen, welches meh- Weiterhin unterstützt keines der erwähnten Systeme Garan-
rere hundert Milliarden bzw. mehrere Billionen Tripel von tien bezüglich Antwortzeiten. Sie setzen zudem auf einen
RDF-Daten in einer materialisierten Form vorhält. Es soll Permanentspeicher, welcher I/O-Zugriffe erfordert. Dies er-
48
Cloud-Services und effiziente Anfrageverarbeitung für Linked Open Data
Query geführt werden. Die Verwendung einer reinen In-Memory
Pull Lösung basiert auf der Grundlage, zukünftig Antwortzeiten
... garantieren zu können.
Linked Open Data bestehen ausschließlich aus Tripeln, die
Datenquellen wiederum aus Strings bestehen. Werden die darin abgespei-
cherten Werte genauer untersucht, stellt man fest, dass die-
Push selben Stringwerte mehrmals auftreten. Hier ist eine Kom-
pression nützlich, um Speicherplatz einzusparen. Dies fällt
Innere Aufbau umso mehr ins Gewicht, da der Data-Warehouse Ansatz an-
gestrebt wird. Die naheliegenste Technik, ist der Einsatz ei-
nes rein lokalen Wörterbuches. In einem solchen wird jeder
Figure 1: Aufbau des Systems mit mehreren un- Stringwert auf eine eindeutige ID gemappt. Hierfür ist wie-
abhängigen Knoten, die untereinander verbunden derum eine effiziente Anfrageverarbeitung von Nöten, die im
sind. Annahme einer Query und Weitergabe an ei- folgenden Abschnitt beschrieben wird.
nem beliebigen Knoten. Einspielen von neuen Da-
tenquellen durch Push und Pull.
Kombinierte Row- und Column-Store.
Ein Chunk besteht intern aus einer Kombination von Row-
und Column-Store [9]. Jede logische Zeile enthält drei Spal-
höht wiederum sehr schnell die Antwortzeit. Eine Gewäh-
ten für Subjekt, Prädikat und Objekt, wobei in einem je-
rung von Garantien wird erschwert. Einige dieser Ansätze
den Feld nur ein einzelner Integerwerte abgelegt ist. Werden
sind zudem bereits mit wenigen Milliarden Tripeln über-
nun alle einzelnen Integerwerte eines Tripels mittels Shift-
fordert (Jena). Andere verwenden alte Konzepte für neuere
Operationen disjunkt zu einem Wert vereint, ergibt sich ein
Probleme (Virtuoso), was nicht immer zu einer optimalen
Wort mit 96 Bit Breite, wenn jeweils 32 Bit für Subjekt,
Lösung beiträgt.
Prädikat und Objekt angenommen werden. Somit wird die
Bezüglich den Garantien von Antwortzeiten, beschreiben
Datenzeile aus drei logischen Spalten zu einer physischen
die Autoren in [12] und [9] ein Verfahren zur Beantwortung
Spalte vereint, die in einem theoretischen Drittel der Zeit
von Anfragen in einem konstanten Zeitintervall. Dies wird
überprüft werden kann.
durch verschiedenste Optimierungen erreicht. Unter ande-
Moderne CPUs besitzen interne SIMD3 -Register die ei-
rem wird beschrieben, wie ein Row- und Column-Store mit-
ne Breite von 256-Bit besitzen. Diese wurde mit dem neu-
einander verschmolzen wird und trotzdem eine effiziente An-
en AVX4 -Befehlsatz von Intel eingeführt. In einem solchen
frageverarbeitung ermöglicht wird.
Register werden mehrere logisch getrennte Einheiten zu ei-
ner physischen Einheit verbunden, die in einer Instruktion
3. ARCHITEKTUR gleichzeitig bearbeitet werden können. Hierfür müssen die
Die Architektur des Gesamtsystems ist in Abbildung 1 einzulesenden Daten auf eine volle 2-er Potenz ergänzt und
aufgezeigt. Sie folgt dem typischen Scale-Out-Paradigma mit die Wortgrenze bekannt sein.
verschiedenen Shared-Nothing-Systemen (Kreise in der Mit- Werden die Fakten vereint, muss zuerst das 96 Bit Wort
te), die alle gleichberechtigt sind. Anfragen können von be- auf 128 Bit, ergänzt werden. Mit Hilfe der verfügbaren 256-
liebigen Knoten entgegengenommen werden. Im nächsten Bit können nun zwei logische Datenzeilen mit jeweils 128-
Schritt wird ein Queryrewriting durchgeführt und an die ent- Bit gleichzeitig überprüft werden. Theoretisch ergibt sich
sprechenden Knoten weitergegeben. Die Empfänger nehmen eine bis zu sechsfache Performancesteigerung. Mittels der
die umgeschriebenen Anfragen entgegen, bearbeiten diese Vermeidung von Sprung- und sonstigen Befehlen, die Leer-
und senden letztendlich das Ergebnis zurück. Nachdem alle lauf produzieren, ist dieses Verfahren sehr Cache freundlich.
Einzelergebnisse eingetroffen sind werden diese mittels ver- Einmal verwendete Daten können stur linear abgearbeitet
schiedener Join-Operationen zu einem Ergebnis verknüpft. werden. Zugriffe auf dem langsamen RAM werden damit
Dieses wird letztlich an den ursprünglich anfragenden Cli- vermieden. Insgesamt wird die Struktur moderner Hardware
ent als Ergebnis zurück gesandt. Auf der rechten Seite der sehr gut ausgenutzt und eine Performancesteigerung ergibt
Grafik ist ersichtlich, dass neue Daten mittels push- oder sich.
pull-Techniken eingespielt werden können und dies während Wie oben erwähnt, muss in diesem Fall eine Ergänzung
der Laufzeit, mit Einhaltung der Antwortzeitgarantien. von 96-Bit auf 128-Bit durchgeführt werden. Es verbleiben
32 ungenützte Bit. Diese können für eine weitere Spalte ver-
3.1 Lokale Verarbeitung wendet werden. In dieser kann die Sprache bzw. der Daten-
Die lokale Verarbeitungseinheit liegt auf einem Knoten typ des (Literal)Objektes vermerkt werden [1]. Sollten ent-
und besteht aus einem Java-Programm, sowie vorwiegend sprechende Filterbedingungen auftreten, können diese direkt
aus einer C++ In-Memory-Datenhaltung und Datenabfra- mit übernommen werden, was zu einer weiteren Performan-
gemöglichkeit, die LODCache genannt wird. Dies ist eine cesteigerung beiträgt. Andererseits können die 32-Bit pro
hochperformante, reine In-Memory Lösung für LOD, die den Spalte zu gering sein und entsprechend erweitert werden. Es
L2-, wenn vorhanden L3-Cache und die RAM-Struktur mo- ist auch eine Kombination aus beiden möglich (z. B. 40 Bit
derner Hardware effizient ausnutzt. Allokierte Datenfelder, pro Spalte und 8 Bit für Sprache und Datentyp).
sogenannte Chunks, entsprechen genau der Größe des L2- Durch die Verwendung von Integerwerten, die eine feste
Caches. Dies ermöglicht es sehr effizient auf Daten zuzugrei- Bitbreite besitzen, wird auf einen expliziten und unvorher-
fen, diese zu Bearbeiten und Berechnungen auf diesen durch-
3
zuführen. Des Weiteren können Anfragen an den LODCache Single instruction, multiple data
4
gestellt, sowie Änderungen und Einfügeoperationen durch- Advanced Vector Extensions
49
Cloud-Services und effiziente Anfrageverarbeitung für Linked Open Data
sehbar langen Stringvergleich verzichtet. Dies erhöht weiter 0 1 2
die Performance und verbessert die Antwortzeit. A
Wie zu erkennen ist, wird auf eine Erzeugung von zusätz- 0 1 2
lichen Indixes verzichtet. Dies ergibt sich aus der Speicherre- 0 2
B
1
striktion und dem nötigen Wartungsaufwand, der während
jeder Änderung anfällt. Hierdurch können Operationen un-
AB
201
vorhersehbar lange blockiert werden. Es sind keine Garan-
tien mehr möglich. Anstelle werden wie in einem gewöhn-
lichen Column-Store alle Elemente stetig geprüft. Dies ist Figure 2: Aufbau des Baumes nach dem Einfügen
durch moderne Hardware und der ständig steigenden Paral- von ’AB’ (Rechteck), welches über den Pfad 201 er-
lelisierung problemlos möglich. Sind c Cores gegeben, muss reichbar ist.
jeder Core nur maximal d cC c
e Elemente überprüfen, wobei
cC die Anzahl der Chunks angibt.
gleichzeitig effizient durchgeführt werden kann. Dies könnte
Lokale Anfrageverarbeitung. naiv erreicht werden, indem jeder nachfolgende Mapping-
Der LODCache besitzt keinerlei Logik für die Optimie- wert einige Zahlen zu seinem Vorgänger überspringt. Treten
rung von Anfragen. Aus diesem Grund ist eine vorgelagerte nun neue Einträge auf, können diese solange eingefügt wer-
Java-Applikation vorhanden. Diese nimmt SPARQL-Anfragen den, wie freie Plätze existieren. Ein Problem dieses Ansat-
entgegen, zerlegt diese, optimiert sie (lokale Optimierung) zes ist jedoch, dass nicht bekannt ist, in welcher Reihenfolge
und überführt sie in die Sprache des LODCaches. Dieser Strings auftreten und es ist gänzlich unbekannt an welcher
führt die entsprechende Operation durch und übergibt das freien Position ein Element eingefügt werden muss/soll (in
Ergebnis dem Java-Programm mittels JNI5 , dass die ermit- der Mitte, an der ersten oder letzten freien Position?). Eine
telten Daten an den Aufrufer sendet. falsche Position bedingt eine schnellere Reorganisation. Aus
Wird eine exakt Match Anfrage mit Subjekt1 , Objekt1 diesem Grund muss ein besser geeignetes Verfahren verwen-
und einem freien Prädikat ?p an den LODCache gesandt, det werden.
werden zuerst die Integerwerte der fest definierten Strings Ein solches wird für XML-Daten in [8] beschrieben. Die
gesucht und in ein Wort mittels Shift und logischen OR- Autoren zeigen ein rekursives Verfahren, um Daten in ei-
Operationen zu einer Maske (m) ergänzt. Dies wird mit- nem Baum abzulegen und eine eindeutige ID zu generie-
tels vier CPU-Operationen durchgeführt werden (COPY, ren. Hierfür wird auf jeder Ebene jede mögliche Verzweigung
SHIFT, OR, SHIFT). Die Operationen zum Filtern der Da- durchnummeriert6 . Nun wird zwischen geraden und ungera-
ten aus einem Chunk beschränken sich daraufhin nur noch den Elementen unterschieden. Die ungeraden Elemente sind
auf ein logisches AND und einen Vergleich (CMP), je Ein- vorhanden, um darin Werte sortiert aufzunehmen (durchge-
trag und Chunk. Die genaue Berechnung ist im Folgenden zogene Linie). Im Gegensatz zu den Ungeraden, denn die-
nochmals dargestellt. Wobei e das zu überprüfende Element se spannen einen neuen Unterbaum auf (gestrichelte Linie).
ist, m die Maske und r das Ergebnis als boolescher Wert. Soll ein neuer Wert eingefügt werden, wird dieser auf der
höchsten Ebene (sortiert) hinzugefügt, die (i.) mindestens
r = (e AND m) CMP m einen freien Platz besitzt und (ii.) lexikografisch den String
korrekt einordnet. Das neue Element kann nun über die Kon-
Werden Bereichsanfragen betrachtet, muss das Mapping katenation aller traversierten Baumverzweigungen eindeutig
der Strings auf Integerwerte eindeutig und ordnungserhal- identifiziert werden und wird sinnvollerweise in einem String
tend sein, da sonst immer das Wörterbuch zu Rate gezo- überführt. In Abbildung 2 ist ein Beispiel mit den Elementen
gen werden müsste. Dies bedeutet, jeder Integerwert muss ’A’, ’B’ und dem neuen Element ’AB’ gegeben. Durch die-
mit der lexikografischen Ordnung seines gegenüberliegenden sen Ansatz ist gewährleistet, dass sich neue Elemente immer
Strings übereinstimmen. Nur so können die in [9] aufge- zwischen zwei bereits bestehenden Elementen einsortieren
führten Operationen angewandt und die Performance von lassen. Problematisch an diesem Ansatz ist jedoch, dass be-
SIMD-Befehlen ausgenutzt werden. Hierfür muss zuerst der liebig viele Unterbäume generiert werden können, der Baum
minimale und maximale Integerwert der Bereichsanfrage er- zu einer Liste entartet und somit die Pfadlänge zu einem
mittelt werden. Daraufhin werden zwei Masken erstellt und Element sehr lang werden kann. Dies widerspricht jedoch
die Daten in den Chunks mit diesen, durch verschiedene lo- der oben genannten Forderung, nach einer festen Breite für
gische Operationen, verglichen. Elemente, sowie der Verwendung eines Integerwertes. Aus
diesem Grund muss eine Modifikation dieses Ansatzes ver-
Ordnungserhaltender Baum. wendet werden.
Ein Problem tritt jedoch beim Einfügen von neuen String- Anstelle eines Strings, um den Pfad eindeutig zu identifi-
werten auf. Diese werden meist lexikografisch zwischen zwei zieren, werden nun beispielsweise 32 Bit Werte verwendet.
bereits bestehenden Elementen eingeordnet. Somit müssten Im Folgenden werden weiterhin jeweils 2 Bit pro Ebene ver-
sich in einem naiven Ansatz alle IDs aller nachfolgenden wendet. Wobei für jede neue Ebene, die neu hinzukommen-
Stringwerte ändern. Das Wörterbuch und alle bestehenden den Bits an den bereits bestehenden Bits dahinter gehan-
Chunks müssen daraufhin überprüft und ggf. abgeändert gen werden (von der größten zur kleinsten Wertigkeit). Es
werden. ergeben sich insgesamt maximal 16 Ebenen. Von den mög-
Dies ist ein sehr großes und äußerst schwerwiegendes Pro- lichen vier (2b = 22 ) Werten pro Ebene können nur drei
blem, welches sich nicht vermeiden lässt. Es kann nur ver- verwendet werden (00, 01, 10). Dies ergibt sich daraus, da
sucht werden, dass die Reorganisation möglichst selten und der Wert 11 ungerade ist. In einem solchen müsste nach der
5 6
Java Native Interface In den weiteren Ausführungen wird von 0 gestartet.
50
Cloud-Services und effiziente Anfrageverarbeitung für Linked Open Data
00 01 10 Eingabe von Daten einen Hashwert, der genau einem Knoten
A 00 10
im Chord-Ring zugeordnet ist. Eine einfache Datenlokalisa-
01 tionsfunktion ist hierdurch gegeben. Der Vorteil, der hieraus
00 01 10 B entsteht ist ein globaler und flüchtiger Index, der keinerlei
Wartung benötigt und auf allen n Elementen gleichermaßen
AB
zur Verfügung steht.
100001 Für die Indizierung von RDF-Tripeln werden alle einstel-
ligen Kombinationen aus Subjekt, Prädikat und Objekt er-
Figure 3: Aufbau des Baumes nach dem Einfügen zeugt (s→op, p→so, o→sp). Diese werden nun mittels h(x)
von ’AB’ (Rechteck), welches über den Pfad 100001 auf den Ring verteilt, indem das zu indizierende Element in
erreichbar ist. h(x) gegeben wird und der entsprechende Knoten bestimmt
wird. Für dasselbe Literal ergibt sich immer derselbe Hash
und somit ist immer derselbe Knoten zuständig.
oben genannten Definition ein Element ablegt werden. Je-
doch existiert nach diesem kein weiteres gerades Element, Globale Anfrageverarbeitung.
womit nach einem falsch einsortierten Element kein weite- Im ersten Schritt wird eine beliebige SPARQL-Anfrage
res lexikografisch dahinter liegendes Element eingefügt wer- einem Client an einem beliebigen Knotenelement gesandt.
den kann. Dies würde eine frühere Reorganisation erzwingen, Der Empfänger wird zum Koordinator dieser Anfrage. Nun
was zu vermeiden ist. In Abbildung 3 ist das bereits weiter zerlegt er die SPARQL-Anfrage und überprüft, ob er alle
oben gezeigte Beispiel nochmals auf diesen Sachverhalt ab- Daten lokal besitzt. Ist dies der Fall, liest er die Daten aus
gebildet. und führt die gesamte Berechnung durch. Ansonsten leitet er
die umgeschriebenen Subanfragen an die zuständigen Kno-
Bewertung. ten weiter. Hierfür wird die Hashfunktion h(x) benötigt, in
Ein großes Problem dieses Ansatzes ist jedoch die geringe dem der nicht variable Teil einer jeden WHERE-Bedingung
Auslastung. So werden höchstens 50 % der möglichen Werte eingetragen wird. Während des Rewriting-Vorganges werden
verwendet und auch nur genau dann, wenn keine zusätzli- FILTER-Statements beachtet und in die Subqueries einbe-
chen Ebenen vorhanden sind. Somit treten wiederum sehr zogen, falls dies möglich ist (globale Optimierung). Durch
schnelle Reorganisationen auf. Auf der anderen Seite kann diese Technik arbeiten mehrere Knoten parallel an derselben
eine Reorganisation sehr schnell durchgeführt werden. Sie Ausgangsquery. Als Nebeneffekt wird die Datenmenge ver-
ist auf wenige logische Operationen pro Wörterbuch- und kleinert. Nach dem Erhalt der Subqueries arbeiten die Kno-
Chunk-Eintrag beschränkt (SHIFT- und OR-Operationen). ten diese ab (lokale Anfrageverarbeitung; siehe Kapitel 3.1)
Gleichzeitig kann durch eine Reorganisation die Ebenenan- und senden das Ergebnis an den Koordinator zurück. Die-
zahl verringert und somit die Anzahl an Bits pro Ebene ver- ser führt die benötigten Joins und die restlichen FILTER-,
größert werden. Die theoretisch mögliche Auslastungsgrenze GROUP BY-, HAVING-, ORDER BY-, LIMIT-, OFFSET-
steigt automatisch an. , Projektions-, usw. Operationen durch. Zum Schluss wird
das Ergebnis an den Client gesandt.
3.2 Globale Verarbeitung
Die globale Architektur besteht aus der Zusammenfassung Bewertung.
aller lokalen Verarbeitungseinheiten zu einer globalen Ein- Ein Problem dieses Ansatzes ist die mehrfache redundante
heit. Diese sind mittels der Technik eines Chord-Ringes [13] Datenhaltung derselben Daten in maximal drei verschiede-
miteinander verbunden. Er besteht aus n unabhängigen und nen Knoten und die dafür zweimal höhere Speicherkapazi-
gleichwertigen Elementen, die in einem geschlossenen Ring tät. Dies ist jedoch nur bedingt ein Nachteil. Durch den au-
angeordnet sind. Wobei jedes Element einen Vorgänger und tomatisierten Scale-Out-Mechanismus kann ein lokales Ele-
einen Nachfolger besitzt (siehe Abbildung 1; Doppeltpfeile ment entlastet werden, indem ein neuer Knoten einen Teil-
mit durchgehender Linie). Neben diesen Verbindungen exis- bereich der Hashwerte und die darin abgebildeten Daten für
tieren noch sogenannte Finger (siehe Abbildung 1; einfacher sich beansprucht. Ein weiterer Vorteil ist die Möglichkeit
Pfeil mit gestrichelter Linie). Dies sind zusätzliche unidirek- auf sehr große Anfragelasten dynamisch reagieren zu kön-
tionale Verbindungen, die mehrere Nachfolger überspringen nen. Es können automatisch neue Knoten hinzugefügt wer-
und somit für eine schnellere Kontaktaufnahme mit einem den, die einen Teil der Anfragelast übernehmen. Die Auftei-
beliebigen Element vorhanden sind. Wären diese nicht vor- lung des Speicherplatzes und Anfragelast, wird jeweils durch
handen, müsste eine Anfrage von einem Element zum an- die konsistente Hash-Funktion h(x) garantiert [10]. Durch
deren solange weitergereicht werden, bis der Empfänger er- den beschriebenen Scale-Out, wächst die maximale Pfad-
reicht ist (O(n)). Dies wird durch die Finger auf O(log2 n) länge nur bedingt an, da diese durch O(log2 n) definiert ist
verkürzt. (was einem Vorteil entspricht). Ein weiterer Vorteil ist, dass
zu jeder WHERE-Bedingung maximal ein Knoten involviert
Fragmentierungsfunktion. ist. Es müssen keine knotenübergreifenden Daten für bspw.
Für die Umsetzung eines Scale-Outs wird eine Fragmen- Bereichsanfrage gesammelt werden. Dies ist nur zwischen
tierungs- und Allokationsfunktion benötigt. Erstere definiert verschiedenen WHERE-Bedingungen nötig, die mittels Join
wie welche Daten aufgeteilt werden, letztere auf welchen verknüpft werden.
Knoten welches Element abgelegt wird. Beide sollten mög-
lichst einfach zu berechnen sein, da sie für jede Anfrage be-
nötigt werden (Datenlokalisation). Der Chord-Ring definiert 4. ZUSAMMENFASSUNG
hier bereits eine Hashfunktion h(x). Diese erzeugt durch die In dieser Arbeit wurde ein Ansatz vorgestellt, der mehre-
51
Cloud-Services und effiziente Anfrageverarbeitung für Linked Open Data
re Hundert Milliarden bzw. mehrere Billionen RDF-Tripel ge SPARQL-Anfragen ermittelt, die sich in Äquivalenzklas-
Linked Open Data effizient verwalten kann. Es wurde eine sen einteilen lassen. Den einfachen SPARQL-Anfragen, den
Unterscheidung in lokaler und globaler Verarbeitung durch- Anfragen, die eine Datenmanipulation erfordern sowie den
geführt. Die lokale Verarbeitungseinheit besteht aus einem analytischen SPARQL-Anfragen.
hochoptimierten In-Memory C++-Programm zur Datenhal-
tung und -abfrage, das die Strukturen moderner Hardware 6. REFERENCES
effizient ausnutzt. Im selben Abschnitt wurde eine Möglich- [1] Rdf - semantic web standards.
keit aufgezeigt, Bereichsanfragen effizient zu verarbeiten, in- http://www.w3.org/RDF.
dem ein ordnungserhaltendes Mapping von Strings auf In- [2] Sparql query language for rdf.
tegerwerten dargestellt wurde. Dies wird durch einen ord- http://www.w3.org/TR/rdf-sparql-query.
nungserhaltenden und updatefreundlichen Baum garantiert. [3] P. A. Boncz, M. L. Kersten, and S. Manegold.
Die globale Verarbeitungseinheit besteht aus dem Zusam- Breaking the memory wall in monetdb. Commun.
menschluss mehrerer lokaler Komponenten und verwendet ACM, 51(12):77–85, 2008.
hierzu die Technik des Chord-Ringes. Jedes Element ist gleich- [4] G. DeCandia, D. Hastorun, M. Jampani,
berechtigt, es existiert somit kein zentraler Koordinator. Für G. Kakulapati, A. Lakshman, A. Pilchin,
die Verbindung untereinander existieren Finger, die eine ma- S. Sivasubramanian, P. Vosshall, and W. Vogels.
ximale Anzahl an Weiterleitungen garantieren. Zur Verar- Dynamo: Amazon’s highly available key-value store.
beitung von beliebigen SPARQL-Anfragen werden diese von SIGOPS Oper. Syst. Rev., 41(6):205–220, 2007.
einem Knoten entgegengenommen, optimiert und an den be- [5] O. Erling and I. Mikhailov. RDF support in the
treffenden Knoten gesandt. Zur Datenlokalisation wird ei- virtuoso DBMS. In S. Auer, C. Bizer, C. Müller, and
ne einfache Hashfunktion und kein global zu pflegender In- A. V. Zhdanova, editors, CSSW, volume 113 of LNI,
dex benötig. Des Weiteren ist dieses Verfahren unabhän- pages 59–68. GI, 2007.
gig gegenüber der Anzahl an Tripeln und dem benötigten
[6] FU-Berlin. Berlin sparql benchmark.
Speicherplatz, da ein automatischer Scale-Out-Mechanismus
http://www4.wiwiss.fu-
existiert.
berlin.de/bizer/berlinsparqlbenchmark.
[7] A. Harth, K. Hose, M. Karnstedt, A. Polleres, K.-U.
5. AUSBLICK Sattler, and J. Umbrich. Data summaries for
In der weiteren Forschung müssen einige Punkte näher be- on-demand queries over linked data. In WWW, pages
trachtet werden, die als Motivation zu diesem Ansatz dienen. 411–420, 2010.
Hierunter fällt die Einhaltung der garantierten Antwortzeit [8] M. P. Haustein, T. Härder, C. Mathis, and M. W.
aller Anfragen bis zu einem vorher definierten Prozentsatz. 0002. Deweyids - the key to fine-grained management
Zur Unterstützung dieser Forderung ist eine Replikation der of xml documents. JIDM, 1(1):147–160, 2010.
Daten denkbar. [9] R. Johnson, V. Raman, R. Sidle, and G. Swart.
Dies führt zum nächsten Problem, der effizienten Replika- Row-wise parallel predicate evaluation. PVLDB,
tion. Bis zu diesem Zeitpunkt werden alle Daten nur auf ei- 1(1):622–634, 2008.
nem Knoten vorgehalten. Stürzt dieser ab, sind all seine Da- [10] D. R. Karger, E. Lehman, F. T. Leighton,
ten verloren und nachfolgende Anfragen können nicht mehr R. Panigrahy, M. S. Levine, and D. Lewin. Consistent
beantwortet werden. Als Ausweg bestünde die Möglichkeit, hashing and random trees: Distributed caching
ein ähnliches Vorgehen umzusetzen, wie es in Amazons Dy- protocols for relieving hot spots on the world wide
namo [4] implementiert ist. web. In F. T. Leighton and P. W. Shor, editors,
Zur weiteren Performancesteigerung ist es notwendig den STOC, pages 654–663. ACM, 1997.
LODCache weiter zu optimieren. Es existiert zum Beispiel
[11] T. Neumann and G. Weikum. RDF-3X: A RISC-Style
die Möglichkeit auf einer SandyBridge-CPU eine Schleife di-
Engine for RDF. In VLDB, Auckland, New Zealand,
rekt im CPU eigenen Loop-Cache abzulegen. Eine Perfor-
2008.
mancesteigerung von über 100 % soll möglich sein. Jedoch
[12] V. Raman, G. Swart, L. Qiao, F. Reiss, V. Dialani,
ist die Bedingung hierfür, dass alle Instruktionen höchstens
D. Kossmann, I. Narang, and R. Sidle. Constant-time
28 µ-Operationen lang sind.
query processing. In G. Alonso, J. A. Blakeley, and
Der oben beschriebene Ansatz zum Mapping von Strings
A. L. P. Chen, editors, ICDE, pages 60–69. IEEE,
auf ordnungserhaltende Integerwerte muss weiter erforscht
2008.
werden. Es ist u. a. notwendig, die Operationen zur Reor-
ganisation effizienter anzuordnen. Eine Möglichkeit zur Er- [13] I. Stoica, R. Morris, D. Liben-Nowell, D. R. Karger,
höhung der Auslastung wird außerdem angestrebt. In die- M. F. Kaashoek, F. Dabek, and H. Balakrishnan.
sem Zusammenhang soll gleichzeitig ein Verfahren entwi- Chord: a scalable peer-to-peer lookup protocol for
ckelt werden, um Updates auf bestehende Daten möglichst internet applications. IEEE/ACM Trans. Netw.,
effizient durchzuführen. 11(1):17–32, 2003.
Für die weitere Entwicklung und Evaluierung des Systems [14] C. Weiss, P. Karras, and A. Bernstein. Hexastore:
wird zukünftig ein Benchmark eingesetzt. Es wurde der Ber- Sextuple Indexing for Semantic Web Data
lin SPARQL Benchmark [6] ausgewählt. Dieser erzeugt ak- Management. In VLDB, Auckland, New Zealand,
zeptierte Resultate und ist für das Testen von beliebigen 2008.
SPARQL-Systemen entwickelt worden. Für Skalierungstests [15] K. Wilkinson, C. Sayers, H. Kuno, and D. Reynolds.
kann ein Skalierungsfaktor angepasst werden, der die Anzahl Efficient RDF storage and retrieval in Jena2. In Proc.
an automatisch erzeugten Tripeln vergrößert. First International Workshop on Semantic Web and
Die Performanz des Systems wird durch verschiedenarti- Databases, 2003.
52
SLO-basiertes Management in relationalen
Datenbanksystemen mit nativer
Multi-Tenancy-Unterstützung
Andreas Göbel
Lehrstuhl für Datenbanken und Informationssysteme
Fakultät für Mathematik und Informatik
Friedrich-Schiller-Universität Jena
Ernst-Abbe-Platz 2, 07743 Jena
andreas.goebel@uni-jena.de
KURZFASSUNG 1. EINLEITUNG
Das an Bedeutung und Akzeptanz gewinnende Geschäfts- Software as a Service (SaaS) bezeichnet ein Geschäftsmo-
modell Software as a Service ermöglicht Unternehmen die dell, bei dem Unternehmen von einem Drittanbieter Anwen-
Konzentration auf ihr Kerngeschäft durch das Beziehen von dungen in Form von Services über das Internet beziehen.
Dienstleistungen über das Internet. Die Festlegung von Ser- Der Ansatz steht dem herkömmlichen On-Premise-Modell
vice Level Agreements gewährleistet eine hohe Qualität des gegenüber, bei dem Unternehmen die Lizenzen für Software
Dienstes. Um die operationalen Kosten des Service Providers käuflich erwerben und die Anwendungen anschließend auf
gering zu halten, bedarf es des Einsatzes einer Multi-Tenancy- eigener Hardware betreiben. Durch das Betreiben und War-
Architektur, die zu neuen Herausforderungen für den Einsatz ten der Anwendung sowie der notwendigen Hardware durch
von Datenbankverwaltungssystemen führt. den Drittanbieter (SaaS-Anbieter) können die als Mandanten
In diesem Beitrag werden die Problemstellungen der Rea- bezeichneten Unternehmen auf den Erwerb und die Wartung
lisierung von Multi Tenancy in heutigen Datenbankverwal- der Hardware verzichten. Service Level Agreements (SLAs)
tungssystemen aufgezeigt und eine native Unterstützung legen dabei als Bestandteil der Dienstleistungsverträge durch
von Multi Tenancy in jenen Systemen motiviert. Es wird die Definition verschiedener Service Level Objects (SLOs)
hervorgehoben, dass die Integration von mandantenspezi- die Qualität der Services fest.
fischen Service Level Agreements zur Steigerung der Qua- Laut Studien renommierter Marktanalyseunternehmen
lität des Dienstes beiträgt. Hierzu wird die Verwendung wird die Bedeutung von SaaS in den nächsten Jahren wei-
dieser bereitgestellten Daten zur Ressourcenverwaltung und ter zunehmen. So prognostiziert Pierre Audoin Consultants
-überwachung sowie der Lastverteilung von Mandanten ver- SaaS für das Jahr 2015 einen Umsatzanteil am Software-
deutlicht. Markt in Höhe von zehn Prozent und begründet die zu-
nehmende Bedeutung u.a. mit entsprechenden Anpassungen
Kategorien und Themenbeschreibung der Produktportfolios sowie Akquisitionen von bedeutenden
Software-Anbietern wie Oracle, SAP und Microsoft [18].
H.2.7 [Database Management]: Database Administrati- SaaS-Angebote sind aktuell insbesondere in den Bereichen
on—Data dictionary/directory; H.2.1 [Database Manage- E-Commerce, Kundenbeziehungsmanagement und bei kolla-
ment]: Logical Design—Schema and subschema borativen Aufgaben wie E-Mail zu finden. Zunehmend werden
Produkte in den Bereichen Humankapital-Management und
Allgemeine Begriffe Unternehmensressourcenplanung angeboten. Um einen mög-
lichst großen Markt ansprechen zu können, ermöglichen SaaS-
Design, Management, Measurement
Anbieter eine individuelle Anpassung des Services. Die Ange-
bote richten sich auch an kleine und mittlere Unternehmen
Stichworte (KMU), denen aufgrund begrenzter finanzieller Möglichkeiten
Relational Database, Multi Tenancy, Service Level Agree- die Mittel für den Erwerb und Support einer vergleichbaren
ment On-Premise-Lösung fehlen. Dieser so genannte Long Tail [3]
kann durch Preisvorteile gegenüber On-Premise-Angeboten
und entfallende Kosten der Mandanten für die Beschaffung
und Wartung von Hardware bedient werden [10]. Es bedarf
hierzu einer hohen Wirtschaftlichkeit des Services durch eine
Konsolidierung von Mandanten auf physischen Ressourcen
in Form von Multi-Tenancy-Anwendungen.
2. MULTI TENANCY
Die Architektur von SaaS-Angeboten ist in großem Ma-
24th GI-Workshop on Foundations of Databases (Grundlagen von Daten-
banken), 29.05.2012 - 01.06.2012, Lübbenau, Germany. ße vom Geschäftsmodell des Anbieters abhängig. Sie wird
Copyright is held by the author/owner(s). beispielsweise beeinflusst durch das zur Verfügung stehende
53
SLO-basiertes Management in relationalen Datenbanksystemen mit nativer Multi-Tenancy-Unterstützung
Virtuelle Betriebssys- Datenbank- Schema /
Isolation Hardware Datenbank Zeile
Maschine temnutzer instanz Tablespace
niedrig Komplexität, Ressourcenausnutzung, max. Mandantenanzahl, Skalierbarkeit hoch
Bewertung
hoch Kosten je Mandant, Sicherheit, Wartungsaufwand niedrig
Abbildung 1: Ansätze zur Mandantenisolation im DB-Layer, angelehnt an [19]
Entwicklungskapital, den Zielmarkt sowie die Anzahl und ten sowie mandantenspezifische Schemaänderungen bedürfen
Charakteristika der Mandanten. Zu den Charakteristika ge- bei diesem Ansatz das Absetzen von DDL-Statements, die bei
hören u.a. die benötigte Datenmenge, die voraussichtliche einigen DBMS zu Problemen mit dem fortlaufenden Betrieb
Workload und die Anforderungen der Mandanten bezüglich führen können. Die hohe Anzahl an Tabellen führt zudem
Verfügbarkeit, Performance, Datenisolation und Individuali- zu einem hohen Hauptspeicherbedarf sowie partiell gefüllten
sierung der Anwendung. Seiten des Datenbankpuffers. [6, 12]
Um die in der Einleitung motivierte hohe Wirtschaft- Bei dem Ansatz Shared Table werden Objekte der Da-
lichkeit eines SaaS-Angebots zu erzielen, werden vermehrt tenbank von Mandanten gemeinsam genutzt. Tabellen ent-
Multi-Tenancy-Architekturen eingesetzt. Diese erlauben allen halten somit Tupel verschiedener Mandanten, weshalb die
Service-Nutzern die gemeinsame Verwendung von Hardware- Verwendung einer zeilenbasierten Zugriffskontrolle nötig ist.
Ressourcen durch das Anbieten einer gemeinsamen Anwen- Eine zusätzliche Tabellenspalte legt hierbei die Zugehörig-
dungsinstanz [9]. Sowohl auf der Applikations- als auch der keit des Tupels zum entsprechenden Mandanten fest. Durch
Datenbankseite sind verschiedene Ansätze zur Separierung den Verzicht auf mandantenspezifische Datenbankobjekte ist
von Mandanten denkbar. die Größe des Datenbankkatalogs nahezu unabhängig von
der Mandantenanzahl. Die maximale Anzahl unterstützter
2.1 Multi Tenancy in DBMS Mandanten ist somit laut [12] lediglich durch die maxima-
Es existiert ein breites Realisierungspektrum für Multi le Anzahl unterstützter Tabellenzeilen beschränkt, was den
Tenancy in einem Datenbankserver. In Abbildung 1 werden Ansatz für das Bedienen des im Abschnitt 1 angesprochenen
die wichtigsten Ansätze zusammengefasst sowie Vorteile und Long Tails prädestiniert. Durch die hohe Ressourcenaus-
Herausforderungen aufgezeigt. Neben der Möglichkeit, auf nutzung reduziert sich der Overhead bezüglich Fest- und
eine Mandantenkonsolidierung zu verzichten (Separate Hard- Hauptspeicherbedarf pro Mandant auf ein Minimum. Admi-
ware), können Mandanten beispielsweise durch die Zuweisung nistrative Operationen und Updates der Anwendung werden
separater virtueller Maschinen (Shared HW ), durch die Nut- bei diesem Ansatz in der Regel für alle Mandanten ausge-
zerverwaltung des Betriebssystems (Shared VM ) oder durch führt, was den Wartungsaufwand des Anbieters reduziert,
die Verwendung getrennter Datenbankinstanzen (Shared OS die Individualität des Services jedoch einschränkt. So können
Level ) bzw. Datenbanken (Shared DB Instance) voneinander die in [11] angesprochenen individuellen Anforderungen von
isoliert und dennoch auf einem Datenbankserver verwaltet Mandanten in Bezug auf Aspekte der Datenbankadministra-
werden. Aufgrund des initialen Ressourcenbedarfs und der tion und -konfiguration wie Backup-Strategien und Archi-
gesonderten Administration dedizierter Datenbanken, Daten- vierungsintervalle, die Replikationsart und Replikatanzahl
bankinstanzen, Betriebssysteme oder virtueller Maschinen oder Vorgaben zur Arbeitsweise des Datenbankoptimierers
führen diese Ansätze für den SasS-Anbieter zu hohen Kosten nicht erfüllt werden. Aufgrund der Konsolidierung von vielen
je Mandant. Sie sollten daher nur bei zwingender Notwendig- Mandantendaten innerhalb einer Tabelle liegen die größten
keit eines hohen Isolations- bzw. Sicherheitslevels oder bei Herausforderungen dieses Ansatzes in der Gewährleistung
einer geringen Anzahl von Mandanten verwendet werden. der Isolation der Mandantendaten und -Performance sowie
Der Ansatz Shared Database erlaubt durch die Mandanten- der Erarbeitung eines Datenbankschemas, welches den Man-
konsolidierung in einer Datenbank die gemeinsame Nutzung danten die Anpassung der vom SaaS-Anbieter zur Verfügung
von Datenbankprozessen und Hauptspeicherinhalten. Die gestellten Anwendungen erlaubt.
Zuweisung zu eigenen Datenbankobjekten wie Tabellen und
Indizes führt bei Nutzung der Datenbankzugriffskontrollen 2.2 Schemaflexibilität
zu einer logischen Isolation der Mandanten. Durch die Zuwei- Um seinen Service einer möglichst breiten Zielgruppe an-
sung der mandantenspezifischen Objekte zu separaten Spei- bieten zu können, sind SaaS-Anbieter bemüht, Mandanten
cherorten (Tablespaces) kann zudem eine physische Trennung weitreichende Anpassungsmöglichkeiten zu bieten. Diese um-
erreicht werden. Das Hinzufügen und Löschen von Mandan- fassen laut [10] unter anderem eine Anpassung der Benutzer-
54
SLO-basiertes Management in relationalen Datenbanksystemen mit nativer Multi-Tenancy-Unterstützung
oberfläche im Sinne eines Corporate Identity, die Anpassung paralleler Basisschema-Versionen einen verzögerten Wech-
an Geschäftsabläufe durch Modifikation von Geschäftsregeln, sel auf eine neue Version der SaaS-Applikation und dessen
individuelle Regelungen bezüglich der Zugangskontrollen so- Erweiterungen erlaubt.
wie die Möglichkeit zur Erweiterung des Datenbankschemas
durch zusätzliche Tabellenspalten oder komplette Tabellen. 3. SLO-BASIERTE VERWALTUNG
Diese Anforderung stellt sich aufgrund des notwendigen Zu-
sammenführens individueller Datenbankschemata der Man- Ein bisher kaum betrachtetes, jedoch nicht minder bedeut-
danten auf ein Gesamtschema der Datenbank insbesondere sames Forschungsgebiet im Zusammenhang mit der nativen
beim Ansatz Shared Table als Herausforderung dar. Aulbach Unterstützung von Multi Tenancy in Datenbanksystemen
et al. stellen in [4, 5] eine Reihe von Ansätzen vor, die in ist die Integration von abgeleiteten Richtlinien aus den Ser-
folgende Kategorien eingeteilt werden können: vice Level Agreements (SLAs) der Mandanten sowie die
Verwaltung der Mandantendaten auf Basis jener Richtlinien.
Vertikale Speicherung: Dieser Ansatz basiert auf dem Durch die zentrale Haltung der Richtlinien als Bestandteil
Entity-Attribute-Value-Modell [17], welches beispiels- des Datenbankkatalogs können sie von verschiedenen DBMS-
weise im medizinischen Bereich Anwendung findet. Je- Komponenten und externen Werkzeugen zur Verbesserung
der Attributwert eines mandantenspezifischen Daten- der Dienstqualität verwendet werden.
satzes wird auf einen Datensatz des Gesamtschemas SLO-basiertes Management kann mittels automatisiertem
abgebildet, der zur Identifizierung neben dem Attri- und proaktivem Agieren den Administrationsaufwand für den
butwert den zugehörigen Mandanten-, Tabellen- und SaaS-Anbieter reduzieren. Zudem kann es die Lastverteilung
Spaltenname sowie die Zeilennummer enthält. Ein man- und Migration von Mandanten unterstützen, um Mandan-
dantenspezifischer Datensatz muss hierbei zur Laufzeit ten stets die Ressourcen zur Verfügung zu stellen, die ihren
durch Verbundoperationen erzeugt werden, um die At- Anforderungen genügen. Die Priorisierung von Mandanten
tributwerte zu einem Datensatz zusammenzufügen. bei der Verarbeitung ihrer Systemanfragen kann durch eine
SLO-basierte Ressourcenverwaltung und -überwachung rea-
Horizontale Speicherung: Ein mandantenspezifischer Da- lisiert werden. Das SLO-basierte Management ist somit ein
tensatz wird direkt auf Datensätze des Gesamtschemas essentielles Mittel, um auf der einen Seite die Betriebskosten
abgebildet. Flexibilität kann beispielsweise durch die der SaaS-Anbieter durch eine hohe Ressourcenausnutzung
Nutzung einer universellen Tabelle geboten werden, gering zu halten und auf der anderen Seite den Mandanten
welche durch eine Vielzahl von generischen Spalten mit eine möglichst hohe Service-Qualität zu bieten.
flexiblen Datentypen die Speicherung beliebiger Daten- Die Einsetzbarkeit in verschiedenen Aufgabenfeldern so-
sätze erlaubt und die Verwaltung des Schemas in die wie die damit verbundenen Vorzüge für Administratoren
Anwendung verschiebt. und Mandanten begründen intensive Forschung in folgenden
XML: Heutige Datenbankmanagementsysteme bieten zu- Themengebieten:
nehmend native Unterstützung des XML-Datentyps zur
• Ableitung von geeigneten mandantenspezifischen Richt-
Speicherung semistrukturierter Daten. Durch dessen
linien aus Dienstleistungsverträgen,
Verwendung können verschiedene mandantenspezifische
Schemata innerhalb einer Tabelle verwaltet werden. • Repräsentation der Richtlinien im Katalog des Daten-
bankverwaltungssystems,
Hybride Speicherung: Die vorherigen Speicherformen kön-
nen miteinander verbunden werden, um ihre Stärken • Omnipräsentes Monitoring der Einhaltung von Richtli-
zu kombinieren. nien,
2.3 Native Unterstützung durch DBMS • Entwicklung und Realisierung geeigneter Algorithmen
Die in Abschnitt 2.2 vorgestellten Ansätze zur Unterstüt- zur Sicherstellung der Richtlinien.
zung individueller Mandantenschemata können bei heutigen
Datenbanksystemen nur mit Hilfe einer überhalb des DBMS 3.1 Service Level Objects
liegenden Schicht zur Transformation der mandantenspe- Als Bestandteil des Dienstleistungsvertrags zwischen dem
zifischen Datenbankanfragen und vom DBMS erhaltenen SaaS-Anbieter und den Mandanten legen Service Level Agree-
Ergebnisse realisiert werden. Diese Schicht regelt die Zugriffs- ments die zugesicherte Qualität des SaaS-Angebots fest. Hier-
kontrolle und verwaltet die Schemata der Mandanten, sodass zu spezifizieren sie beispielsweise Kennzahlen oder Abstufun-
die Schemainformationen vom DBMS nicht zur Optimie- gen bezüglich der folgenden Anforderungen an den Services
rung genutzt werden können. Zudem führt sie zu erhöhten in Form von Richtlinien, welche als Service Level Objects
Wartungsaufwand und beeinflusst unter Umständen die Ska- (SLOs) bezeichnet werden.
lierbarkeit des Systems. [6, 20]
Bisherige Konzepte und prototypische Implementierungen • Verfügbarkeit: Systemzugänglichkeit, Wartungsfenster,
[6, 20] zur nativen Unterstützung von Mandanten in rela- Wiederherstellungszeiten in Fehlerfällen
tionalen Datenbanksystemen verlagern im Wesentlichen die
• Performance: Geschwindigkeit der Datenverarbeitung,
Transformationsschicht inklusive der benötigten Metadaten
Reaktionszeiten der Schnittstellen
ins Datenbanksystem. Sie verfolgen hiermit das Ziel einer
effizienten Mandantenkonsolidierung sowie der Abbildung • Sicherheit: Datenschutz, Datensicherheit, Art der Iso-
mandantenspezifischer Schemata auf ein Gesamtschema, um lation von anderen Mandanten
die oben aufgezeigten Nachteile einer externen Transformati-
on anzugehen. Des Weiteren wird in [7] ein Konzept vorge- Die SLOs sollten u.a. aussagekräftig, erreichbar, messbar und
stellt, welches Mandanten durch die Unterstützung mehrerer verständlich sein [22]. Bestandteil der SLAs sind neben den
55
SLO-basiertes Management in relationalen Datenbanksystemen mit nativer Multi-Tenancy-Unterstützung
DBMS
DBMS Core
Tenant Query
SaaS-Workload
Assignment Transformation
Execution Engine
SLO-based Management Performance
Data Dictionary Monitor
Extension
Workload Manager
Tenants
Resource Manager
SLOs
Load Balancer
Replication
Manager
Abbildung 2: Integration von SLO-basiertem Management ins DBMS
SLOs entsprechende Regelungen für den Fall, dass der SaaS- wiederum einer Erweiterung des Katalogs um die SLOs jedes
Anbieter die zugesicherten SLOs nicht erfüllen kann. In der Mandanten sowie seiner zugewiesenen Bedeutsamkeit bzw.
Regel erfolgt dies über gestaffelte Strafzahlungen oder ledig- Priorität. Durch die Zuordnung eines Mandanten zu einer
lich über die Verminderung der anfallenden Grundgebühren SLO-Kategorie wie ’Standard’, ’Premium’ oder ’Individuell’
für Mandanten. kann bei der SLO-Zuweisung der Overhead bezüglich des
Fest- und Hauptspeicherbedarfs je Mandant reduziert werden.
3.2 SLO-Repräsentation Abbildung 2 verdeutlicht diese Erweiterung und kennzeichnet,
Nach der Einigung der SaaS-Anbieter und Mandanten über dass Katalogerweiterungen beispielsweise für die Zuweisung
zu gewährleistende SLOs und dem Vertragsabschluss erfolgt von Mandanten zu Anfragen (Tenant Assignment) und die
die Überführung der finalen Bestimmungen in Anforderun- in Abschnitt 2.3 angesprochene Transformationskomponente
gen an die zugrunde liegende Technologie und Hardware des (Query Transformation) benötigt wird.
Anbieters. SLOs werden vorrangig technologieunabhängig
definiert und gelten in der Folge für den gesamten Service,
3.3 Workload Management
weshalb eine adäquate Ableitung von mandantenspezifischen Einige Datenbankverwaltungssysteme bieten mittels Work-
Richtlinien für die einzelnen Systemkomponenten wie dem load Management die Möglichkeit zur Überwachung von
Datenbanksystem eine bedeutsame und komplexe Aufgabe Abfragen und den von ihnen benötigten Ressourcen. IBM
darstellt. Zudem verdeutlicht dieser Sachverhalt, dass die DB2 for Linux, UNIX and Windows stellt hierfür beispiels-
Einhaltung jener Richtlinien, analog zu Multi Tenancy, in weise den DB2 Workload Manager [1] und Oracle den Oracle
allen Schichten des Gesamtsystems von Bedeutung ist. Mit Database Resource Manager und Oracle Scheduler [2] bereit.
zunehmender Mandantenkonsolidierung auf den zur Verfü- Diese Anwendungen bieten ein breites Spektrum an Mitteln
gung stehenden Systemressourcen nimmt die Beeinflussung zur Überwachung von Anfragen, welches u.a. das Aufteilen
unter Mandanten bezüglich der Performance zu, was die von Systemressourcen zwischen Abfragen, die Priorisierung,
Erstellung passender Richtlinien weiter erschwert. Ab- und Unterbrechung von Abfragen sowie eine Zeitplanung
Die resultierenden Richtlinien sollten entsprechend einem von Abfragen enthalten kann.
adäquaten Modell erstellt werden. Sie bestehen aus einer Das DBMS muss fortwährend den Auslastungszustand der
Kombination aus Anforderungen, beispielsweise bezüglich Ressourcen messen und für das Workload Management bereit-
der Performance, Verfügbarkeit oder Sicherheit sowie einer stellen. Abbildung 2 verdeutlicht, mit welchen Komponenten
Priorität. Diese spiegelt die Bedeutsamkeit des Mandanten des DBMS-Kerns der Workload Manager typischerweise kom-
für das Unternehmen wider und basiert typischerweise auf muniziert, um die Verarbeitung von Abfragen zu steuern und
der Größenordnung der entsprechenden Vertragsstrafen eines zu überwachen [14]:
Mandanten [14]. Unter Umständen können hierbei jedoch • Execution Engine (Verwaltung der Ausführung von
Aspekte eine Rolle spielen, die nicht direkt aus dem Dienst- Abfragen),
leistungsvertrag abgeleitet werden können wie die Reputation
des Mandanten oder seine Bedeutung als strategischer Part- • Performance Monitor (Überwachung der Verarbeitung
ner des SaaS-Anbieters. von Abfragen),
Die native Unterstützung von Multi Tenancy im DBMS
• Resource Monitor (Regelung der Ressourcenallokation
bringt in der Regel eine Katalogerweiterung [20] um Tabellen
der Abfragen).
zur Repräsentation der Mandanten und der zugehörigen
Datenbankobjekte wie Tabellen oder Indizes mit sich. Die Die Erweiterung des Datenbankkatalogs um Mandanten
Definition und anschließende Überwachung der SLOs bedarf und SLOs stellt dem Datenbankverwaltungssystem die nöti-
56
SLO-basiertes Management in relationalen Datenbanksystemen mit nativer Multi-Tenancy-Unterstützung
gen Mittel zur Verfügung, um neben der korrekten Ausfüh- lung der Mandanten durch einen Load Balancer kann zudem
rung nebenläufiger Transaktionen eine auf SLOs basierende gemäß Abschnitt 3.3 zur Abfederung von Lastspitzen genutzt
Parallelisierung von Mandanten zu erzielen. Verschiedene werden. Entgegen statischer Ansätze [15] zur Berechnung
Nutzungsprofile und -zeiträume der Mandanten sowie üb- einer optimalen Verteilung von Mandantendaten auf eine
liche Nutzungsschwankungen erlauben eine Überbuchung Menge von Datenbankknoten sollte die Lastverteilung analog
der zur Verfügung stehenden physischen Systemressourcen zum Workflow Management dynamisch agieren.
wie der CPU, dem Hauptspeicher oder der Bandbreite zum Um unnötige Kommunikation zwischen Datenbankknoten
Festspeicher. Dies ermöglicht eine ausgezeichnete Auslastung zu vermeiden, sind die Daten eines Mandanten nicht über
der Ressourcen und hält somit die operativen Kosten des mehrere Knoten zu verteilen. Dies sollte nur möglich sein,
SaaS-Anbieters gering. Im (Ausnahme-)Fall hoher Lastspit- wenn die Anforderungen des Mandanten die zur Verfügung
zen durch einen parallelen intensiven Zugriff einer Großzahl stehenden Ressourcen des Rechners übersteigen.
von Mandanten, welche die Ressourcen gemeinsam nutzen, Die Mandanten legen durch die Nutzung einer SaaS-An-
kann die Einhaltung aller offerierten SLOs nicht gewährleis- wendung ihre Daten in die Hände des Anbieters und dessen
tet werden. Lastspitzen können aufgrund von regelmäßigen auf Sicherheit spezialisierte IT-Abteilung [11]. Durch die Ver-
Vorgängen wie Gehaltsbuchungen oder beispielsweise auf- teilung von Mandanten auf verschiedene Rechner ist neben
grund von unvorhergesehenen Nutzungsschwankungen unre- dem verringerten Einfluss der Mandanten bezüglich ihrer Per-
gelmäßig auftreten [6]. Um die Häufigkeit dieser Situation zu formance (Performance-Isolation zwischen Mandanten [8])
reduzieren und beim Auftreten adäquat zu reagieren, bedarf ein höherer Isolationsgrad der auf dem Festspeicher abgeleg-
es geeigneter Strategien zur Ablaufplanung der Abfragen ten Mandantendaten erreichbar bis hin zu einer physischen
sowie der Ressourcenzuteilung. Aus ökonomischer Sicht des Isolation. Der Isolationsgrad spiegelt sich zum Teil in ent-
Anbieters gilt es hierbei, die Summe der zu zahlenden Ver- sprechenden SLOs der Dienstverträge wider. Er kann durch
tragsstrafen zu minimieren. In [13] wird dieses Ziel durch die in Abbildung 2 dargestellte SLO-Katalogerweiterung im
einen dynamischen Controller und der Zuhilfenahme zwei- DBMS hinterlegt und vom Lastbalancierer bei der Verteilung
er Kostenfunktionen verfolgt, womit zudem eine dauerhafte der Mandanten auf Rechner berücksichtigt werden.
Übererfüllung der SLOs von Mandanten mit hoher Priorität
auf Kosten von Mandanten mit geringer Priorität vermieden Kosten
wird.
Häufig wird in diesen Modellen lediglich die Minimierung Mögliche
von Strafzahlen bezüglich der aktuellen Überauslastung be- Zielstellung
trachtet und die Korrelation von Entscheidungen bei verschie-
denen Lastspitzen außer Acht gelassen. So ist es möglich, dass
die SLOs eines Mandant mit geringer Priorisierung bei Last-
spitzen wiederholt nicht erreicht werden können. Aus ökono- Performance Verfügbarkeit
mischer Sicht ist dies für den SaaS-Anbieter augenscheinlich
eine optimale Strategie, sie kann jedoch zur Verärgerung Abbildung 3: Zielkonflikte des SaaS-Anbieters
oder gar Kündigung des Mandanten führen. Folglich gilt es,
frühere Entscheidungen in die Priorisierung von Mandanten
Verfügbarkeit besitzt gemäß Abschnitt 3.1 eine außeror-
und Ressourcenzuweisung bei Lastspitzen einzubeziehen. Die-
dentliche Bedeutsamkeit bei Dienstleistungsverträgen im
ses Ziel kann nur mit Hilfe einer dynamischen Priorisierung
SaaS-Umfeld. Ist der Dienst für die Mandanten nicht er-
erreicht werden.
reichbar, so kann dies schwerwiegende Folgen haben, die von
Neben der Ablaufsteuerung und Überwachung von Abfra-
einer Verzögerung der Arbeitsprozesse bei Mandanten bis
gen sowie dem Eingreifen im Falle einer Überlastung besteht
hin zu finanziellen Einbußen reichen. Entsprechend werden
eine wesentliche Aufgabe des SLO-basierten Managements
in den Dienstleistungsverträgen nur geringe (geplante und
in dem Verhindern von häufigen Überlastungen eines Sys-
ungeplante) Ausfallzeiten des Services zugelassen, bei deren
tems. Hierzu sind die Ressource sowie der Schweregrad, die
Verletzung der SaaS-Anbieter mit erheblichen Strafzahlungen
Häufigkeit und eine gegebenenfalls existierende Regelmäßig-
rechnen muss. Entsprechend liegt es im Interesse des An-
keit der Überlastungen zu beobachten. Durch ein proaktives
bieters, eine hohe Verfügbarkeit des Dienstes sicherzustellen.
Vorgehen kann zukünftigen Überlastungen vorgebeugt wer-
Abbildung 3 verdeutlicht, dass die Erreichung eines hohen
den, indem Maßnahmen autonom ergriffen werden oder der
Verfügbarkeitsniveaus auf der einen Seite zu zusätzlichen
Administrator in Form von Hinweisen bei seiner Tätigkeit
Kosten für den Anbieter führt und auf der anderen Seite die
unterstützt wird. Ein mögliches Vorgehen ist die Zuweisung
Performance des Services einschränkt. Eine hohe Verfügbar-
von Mandanten zu anderen physischen Ressourcen durch
keit fordert das Vermeiden von Single Points of Failures und
das Verschieben auf einen anderen Server mit dem Ziel einer
kann beispielsweise durch verschiedene Formen der Replika-
Lastverteilung.
tion erreicht werden. Der SaaS-Anbieter könnte durch einen
Replication Manager die Art und den Umfang der Replikati-
3.4 Verteilung von Mandantendaten on von Mandantendaten aufgrund von verschiedenen SLOs
Ein SaaS-Anwendung sollte die maximale Anzahl an un- der Mandanten variieren, um individuelle Anforderungen zu
terstützten Mandanten möglichst nicht beschränken. Um unterstützen.
auch bei vielen Mandanten eine ausreichende Performan-
ce zu erreichen, müssen die Daten der Mandanten mittels 3.5 SLA-Management in DaaS
Tabellen- und Indexpartitionierung auf verschiedene Fest- Die Verwendung von Datenbanksystemen zur Datenver-
speicher oder gemäß eines verteilten Datenbanksystems auf waltung einer SaaS-Anwendung stellt nur eine Möglichkeit
verschiedene Datenbankknoten verteilt werden. Die Vertei- zur Bereitstellung von Datenbanksystemen als Dienst inner-
57
SLO-basiertes Management in relationalen Datenbanksystemen mit nativer Multi-Tenancy-Unterstützung
halb einer Cloud dar, was als Database as a Service (kurz [3] C. Anderson. The Long Tail: Why the Future of
DaaS oder DbaaS [21]) betitelt wird. Sowohl in kommerziel- Business Is Selling Less of More. Hyperion, 2006.
len DaaS-Angeboten als auch in der DaaS-Forschung spielt [4] S. Aulbach, T. Grust, D. Jacobs, A. Kemper, and
Multi Tenancy eine bedeutende Rolle, um die operationalen J. Rittinger. Multi-tenant databases for software as a
Kosten von DaaS-Anbietern zu senken. Die Bereitstellung service: schema-mapping techniques. In SIGMOD,
von Daten für eine SaaS-Anwendung unterscheidet sich je- pages 1195–1206. ACM, 2008.
doch im Zusammenhang mit Multi Tenancy erheblich von [5] S. Aulbach, D. Jacobs, A. Kemper, and M. Seibold. A
anderen Dienstmodellen. comparison of flexible schemas for software as a service.
In SIGMOD, pages 881–888. ACM, 2009.
• Mandanten in einer SaaS-Anwendung besitzen und
[6] S. Aulbach, D. Jacobs, J. Primsch, and A. Kemper.
erweitern ein gemeinsames Basisschema und greifen zu-
Anforderungen an Datenbanksysteme für
dem in der Regel lesend auf gemeinsame Anwendungs-
Multi-Tenancy- und Software-as-a-Service-
daten zu. Bei anderen DaaS-Dienstmodellen existieren
Applikationen. In BTW, pages 544–555. GI, 2009.
meist keine mandantenübergreifenden Daten und keine
oder vernachlässigbare Ähnlichkeit der Datenbanksche- [7] S. Aulbach, M. Seibold, D. Jacobs, and A. Kemper.
mata von Mandanten. Dies wirkt sich auf die Kon- Extensibility and Data Sharing in evolving multi-tenant
solidierungsmöglichkeiten innerhalb einer Datenbank databases. In ICDE, pages 99–110, 2011.
aus. [8] D. Banks, J. Erickson, M. Rhodes, and J. S. Erickson.
Multi-tenancy in Cloud-based Collaboration Services.
• SaaS-Anwendungen bestimmen die Art der Workload Information Systems Journal, 2009.
für das verwendete Datenbanksystem, was sich das [9] C.-P. Bezemer, A. Zaidman, B. Platzbeecker,
SLO-basiertes Management zu Nutze machen kann. T. Hurkmans, and A. ’t Hart. Enabling multi-tenancy:
Bei anderen DaaS-Dienstmodellen ist die Workload An industrial experience report. In ICSM, pages 1–8,
hingegen mandantenspezifisch und unvorhersehbar. 2010.
[10] F. Chong and G. Carraro. Architecture Strategies for
• SLOs sind bei SaaS-Angeboten mit der kompletten An- Catching the Long Tail. 2006.
wendung verknüpft, während bei anderen DaaS-Dienst- [11] A. Göbel. Anforderungen von Cloud-Anwendungen an
modellen meist konkrete Vorgaben für das DBMS defi- Datenbanksysteme. In Workshop Database as a Service,
niert sind. 2010.
[12] D. Jacobs and S. Aulbach. Ruminations on
Diese Punkte verdeutlichen, dass Ergebnisse aktueller For- Multi-Tenant Databases. In BTW, pages 514–521, 2007.
schung im Bereich SLO-basierter Hardware-Provisionierung [13] S. Krompass, D. Gmach, A. Scholz, S. Seltzsam, and
und Steuerung der Abfrageverarbeitung für DaaS [16] nur A. Kemper. Quality of Service Enabled Database
sehr eingeschränkt auf Datenbankdienste für SaaS-Anwen- Applications. In ICSOC, pages 215–226, 2006.
dungen übertragen werden können und gesonderte Forschung
[14] S. Krompass, A. Scholz, M.-C. Albutiu, H. A. Kuno,
für jenen Bereich vonnöten ist.
J. L. Wiener, U. Dayal, and A. Kemper. Quality of
Service-enabled Management of Database Workloads.
4. ZUSAMMENFASSUNG UND NÄCHSTE IEEE Data Eng. Bull., 31(1):20–27, 2008.
SCHRITTE [15] T. Kwok and A. Mohindra. Resource Calculations with
Constraints, and Placement of Tenants and Instances
In diesem Beitrag wurde gezeigt, dass eine Integration von
for Multi-tenant SaaS Applications. In ICSOC, pages
Service Level Objects in ein Multi-Tenancy-Datenbanksystem
633–648. Springer-Verlag, 2008.
in Form einer Erweiterung des Datenbankkatalogs von ver-
schiedenen DBMS-Komponenten verwendet werden kann, [16] W. Lang, S. Shankar, J. Patel, and A. Kalhan. Towards
um die Überwachung der SLOs während des Betriebs zu Multi-Tenant Performance SLOs. In ICDE ’12, 2012.
gewährleisten. Als mögliche Verwendungsbeispiele wurden [17] P. M. Nadkarni and C. Brandt. Data extraction and ad
das Workload Management, die Lastverteilung und eine in- hoc query of an entity–attribute–value database.
dividuelle Replikationssteuerung aufgeführt. Journal of American Medical Informatics Association,
In den weiteren Arbeiten soll der Entwurf der SLO-Integra- 5(6):511–527, 1998.
tion konkretisiert, verschiedene Implementierungsvarianten [18] Pierre Audoin Consultants. Entry of the global players
verglichen und die Realisierbarkeit anhand eines Prototyps confirms Global SaaS Trends. 2012.
gezeigt werden. Anschließende Performance-Tests sollen Auf- [19] B. Reinwald. Database support for multi-tenant
schluss darüber geben, ob der zusätzliche Overhead durch applications. IEEE Workshop on Information and
die mandantenspezifischen Metadaten und das SLO-basierte Software as Services, 1:2, 2010.
Management die Skalierbarkeit und den laufenden Betrieb [20] O. Schiller, B. Schiller, A. Brodt, and B. Mitschang.
des Datenbanksystems beeinträchtigen. Native support of multi-tenancy in RDBMS for
software as a service. In EDBT/ICDT, pages 117–128.
ACM, 2011.
5. LITERATUR [21] M. Seibold and A. Kemper. Database as a Service.
[1] DB2 Workload Manager for Linux, Unix, and Windows. Datenbank-Spektrum, 12(1):59–62, 2012.
IBM Corp., 2008. [22] R. Sturm, W. Morris, and M. Jander. Foundations of
[2] Oracle�R Database Administrator’s Guide 11g Release Service Level Management. SAMS Publishing, Apr.
2. Oracle, 2011. 2000.
58
i ETL: Flexibilisierung der Datenintegration
in Data Warehouses
Sebastian Schick1 , Gregor Buchholz2 , Meike Klettke3 , Andreas Heuer1 , Peter Forbrig2
1
Lehrstuhl für Datenbank- und Informationssysteme; 2 Lehrstuhl für Softwaretechnik
3
Institut für Informatik
Universität Rostock, 18051 Rostock
vorname.nachname@uni-rostock.de
ABSTRACT
Data Warehouses bestehen aus zwei Hauptkomponenten: ei- neu identifiziert OLAP-‐Anfragen
f
Quellen-‐ e
Anfrageergebnisse
ner flexiblen Anfrageschnittstelle zur Datenanalyse (OLAP) identifikation
und einer relativ starren ETL-Komponente zum Laden der Data Mart
Daten ins Data Warehouse. In diesem Artikel soll vorgestellt Anpassung
werden, wie die Datenintegration bedarfsabhängig zu flexi-
bilisieren ist, welche Vorteile sich daraus ergeben und welche bereits erschlossen
Herausforderungen bei der Entwicklung eines solchen inter- Datenintegration
aktiven ETL (iETL)-Prozesses bestehen. Datenbereinigung
Selection
Categories and Subject Descriptors
Datenbanken,
D.2.2 [Software Engineering]: Design Tools and Tech- CSV-‐ und Excel-‐Dateien Data Warehouse
niques—User interfaces; H.2.7 [Database Management]:
Database Administration—data warehouse and repository; Abbildung 1: Interaktiver ETL-Prozess eines DW
H.3.3 [Information Storage and Retrieval]: Informati-
on Search and Retrieval—query formulation, search process
formationsfülle spiegelt sich in der Heterogenität der vor-
General Terms zuhaltenden Lösungen, der Vielfalt der Schnittstellen zum
Informationsaustausch sowie der Menge vorzufindender Da-
Data Warehouse
tenbanklösungen und Datenablagen in Excel und ähnlichen
Formaten wider. Dem gegenüber steht der zunehmende Be-
Keywords darf an zentralen Beobachtungs- und Steuerungsinstrumen-
Data Warehouse, ETL-Prozess, Szenario, Datenintegration ten der Bereiche Business- und Geo-Intelligence. Der Ver-
breitung fachübergreifender Systeme steht oft der sehr ho-
he Datenbeschaffungsaufwand (sowohl initial als auch pro-
1. MOTIVATION zessbegleitend) im Weg. Insbesondere die Erschließung neu-
Institutionen des öffentlichen Sektors sehen sich mehr noch er Datenquellen bei der Ausweitung von Kennzahlensyste-
als industrielle Verwaltungen einer Vielzahl von Softwarelö- men auf neue Fachgebiete oder bei Auftreten tagesaktuel-
sungen zur Unterstützung ihrer Prozesse gegenüber. Wäh- ler ad-hoc-Abfragen mit teils exotischen“ Fragestellungen
rend in Industrien wie dem Automobilbau oder dem Ban- ”
geht stets mit großem manuellen Aufwand bei der Informa-
kenbereich fünf bis zehn Kernkompetenzen in der IT darge- tionssuche und -transformation einher. Es geht also um eine
stellt werden, finden sich im Kerngeschäft öffentlicher Ver- Lösung zur Identifizierung und Integration heterogener Da-
waltungen leicht zwischen 100 und 150 Prozesse verschiede- tenquellen im Data Warehouse (DW)-Umfeld, die den An-
ner Dienstleistungskomplexe [11]. Diese Aufgaben- und In- wender in verschiedensten Datenquellen enthaltene Informa-
∗Die Arbeit dieser Autoren wird durch das BMWi im ZIM- tionen finden und in seinen Bestand übernehmen lässt. Nicht
Projekt KF2604606LF1 der GeoWare GmbH und der Uni- im Fokus stehen von technischem Personal eingerichtete tur-
versität Rostock gefördert. nusmäßige Beladungen oder Real-Time-Data-Warehousing
sondern die zunächst einmalige Integration aus Quellen mit
überwiegend statischem Inhalt und geringer Komplexität
durch den Anwender. Kapitel 2 illustriert dies anhand zwei-
er Szenarien aus der Anforderungsanalyse. Abb. 1 zeigt in
durchgezogenen Pfeilen bestehende Daten- und Kontrollflüs-
se und in unterbrochenen Linien die zu entwickelnden Ver-
bindungen. Interessant dabei ist, wie der Prozess aus Nut-
zersicht verlaufen kann und mehr noch, mittels welcher Ar-
24th GI-Workshop on Foundations of Databases (Grundlagen von Daten-
banken), 29.05.2012 - 01.06.2012, Lübbenau, Germany. chitekturen und Datenstrukturen die daraus ermittelten An-
Copyright is held by the author/owner(s). forderungen am besten umzusetzen sind.
59
iETL: Flexibilisierung der Datenintegration in Data Warehouses
Abbildung 2: Eingabemaske Szenario 1 Abbildung 3: Ergebnisliste Szenario 1
2. ANWENDUNGSSZENARIEN damit nicht relevant. Herr B. wählt also den zweiten Tref-
fer und betrachtet ihn in der Voransicht. Er erkennt, dass
In der Anforderungsanalyse dieses Projektes sind Szenari-
die gesuchten Daten (eine Auflistung der Auszubildenen mit
en ([3], S. 52) zur Veranschaulichung der gewünschten Funk-
Wohn- und Ausbildungsadresse) in dem Suchergebnis ent-
tionalität entstanden, die beim Entwickeln einer Lösung hel-
halten sind und wechselt via Importieren“ zum Import-Mo-
fen sollen. Die folgende Wiedergabe dieser Beispielanwen- ”
dul für Excel-Dateien. Dort kann er einzelne Spalten und
dungen beginnt nach dem Skizzieren des technischen Kon-
Bereiche der Excel-Tabelle als Werte der drei Dimensionen
textes jeweils mit der Beschreibung einer Bedarfssituation,
markieren und den Import in sein DW-Systems anstoßen.
an die sich eine mögliche Lösung aus Anwendersicht an-
Anschließend widmet er sich der Aufbereitung der Statisti-
schließt. Das folgende Kapitel 3 schlägt dann ein Konzept
ken.
zur Umsetzung dieser Anforderung vor.
Szenario 2 – Kontext: Die Konfiguration entspricht der
Szenario 1 – Kontext: Die Klassifikationshierarchie des
von Szenario 1. Hier wird jedoch die Anfrage nicht vom DW-
DW mit ihren Attributen ist dem System bekannt. Ebenso
System vorbelegt.
wurden die möglichen Datenquellen (Web-Services, Suchpfa-
de im Dateisystem) bereits konfiguriert. Die drei Dimensio- Situation: Vor dem Beitritt zu einem Verband zur Förde-
nen der Daten im DW sind: Zeitraum, Geo-Objekte (Hier- rung von Solarenergieanlagen an privaten Immobilien sollen
archie geographischer Bezugselemente) und Kenngrößen. für 2010 Anzahl, Verteilung und Höhe der Landesförderung
von Anlagen ermittelt werden. Frau B. ist damit beauftragt
Situation: Wenige Tage vor der Jahresversammlung des
und stellt fest, dass zu den Förderungen bislang keine Daten
Gaststätten- und Hotelverbandes wird Herr B. im Amt für
im DW existieren, jedoch hat sie kürzlich davon gehört, dass
Ausbildungsförderung mit dem Zusammenstellen einer Sta-
ein Mitarbeiter einem anderen per Mail eine solche Übersicht
tistik beauftragt. Sie soll die Entwicklung der Auszubilden-
schicken wollte.
denzahlen der vergangenen Jahre in diesem Bereich aufzei-
gen. Dazu fragt er die dafür relevanten Informationen in ei- Lösungsausblick: Sie startet das Suchsystem und spezi-
nem DW-System an und erkennt an der grauen Einfärbung fiziert ihre Anfrage: solaranlagen 2010 +förderung +privat
”
des entsprechenden Knotens in seiner DW-Anwendung, dass -gewerblich“ (siehe Abb. 4). Der Begriff solaranlagen“ und
”
die Daten zur Kenngröße Auszubildende in der Hauswirt- das Jahr 2010“ sollen im Ergebnis enthalten sein. Ebenso
” ”
schaft“ für den Stadtteil Nordstadt“ im Jahr 2008 fehlen. förderung“ und privat“, die ihr besonders wichtig sind und
” ” ”
Dass sie nicht wie sonst automatisch übermittelt wurden, für die das +“ eine erhöhte Priorität der Fundstellen be-
”
liegt seiner Meinung nach an der Umbenennung des Stadt- wirken soll. Kommt hingegen gewerblich“ in der Fundstelle
”
teils (früher: Neustadt“) im Vorjahr. vor, soll die Priorität des Ergebnisses sinken. Als Suchort
”
schließt Frau B. die Datenquelle StarDepot“ aus, dann star-
Lösungsausblick: Über einen Rechtsklick auf den ausge- ”
tet sie die Suche. In einer Ansicht ähnlich zu Abb. 3 nutzt
grauten Knoten lässt Herr B. eine Anfrage an das Suchsys-
sie die Vorschau, um die Datei mit den gesuchten Informa-
tem generieren, was ihn zur Eingabemaske (Abb. 2) führt.
tionen zu identifizieren. Anschließend bereitet sie die Daten
Die Suchfelder für die drei Dimensionen sind schon vorbe-
für den Import vor und übernimmt sie in den eigenen Da-
legt; per direkter Texteingabe oder über die Schaltflächen
tenbestand.
Variablen auswählen“ und Objekte auswählen“ könnte Herr
” ”
B. die Suchkriterien verändern; die jeweiligen Dialoge stellen
die möglichen Werte der jeweiligen Dimension zur Auswahl. 3. LÖSUNGSKONZEPT
Er tippt in das Suchfeld der Ortsbezeichnungen Neustadt“ In Abschnitt 2 wurden Anwendungsszenarien und mög-
”
ein und bekommt nach Abschluss der Suche als Ergebnis liche Lösungsausblicke vorgestellt, die eine Anpassung des
eine Liste von Datenquellen zu sehen (Abb. 3). Das erste ETL-Prozesses notwendig machen. In diesem Abschnitt stel-
Ergebnis ist offenbar ein Bericht eines konkreten Hotels und len wir dafür eine erweiterte DW-Architektur vor.
60
iETL: Flexibilisierung der Datenintegration in Data Warehouses
• Wissensbasis: Sämtliche Komponenten sollen zur Fle-
xibilisierung um semantische und ontologische Kon-
zepte erweitert werden.
Wir schlagen deshalb vor, das Referenzmodell für die Ar-
chitektur von DW aus [2] derart zu erweitern, dass der An-
wender bei der Identifikation passender Datenquellen un-
terstützt, der Integrationsprozess heterogener Datenquellen
erleichtert und die Flexibilisierung der Datenextraktion mit
geeigneten Konzepten ermöglicht wird. Die Architektur ist
in Abbildung 5 dargestellt. Datenflüsse zwischen den Kom-
ponenten sind als durchgezogene Pfeile umgesetzt, der Kon-
trollfluss wird mit unterbrochenen Linien markiert.
3.2 Die Wissenskomponente
Die zentrale Komponente in der vorgestellten Architektur
Abbildung 4: Eingabemaske Szenario 2 bildet der Data Warehouse Manager (DWM) (siehe Abb. 5).
Der DWM steuert in einem klassischen DW nach [2] alle
Komponenten, die zur Anfrage und Darstellung der Daten
3.1 Ausgangspunkt notwendig sind: Monitore, Extraktoren, Ladekomponenten
Der Anwender soll bei der Quellenidentifikation und Da- und Analysekomponenten. Zusätzlich erhält der DWM in
tenintegration im ETL-Prozess in einem DW unterstützt der hier vorgestellten Architektur Schnittstellen
werden. Dafür müssen die verfügbaren Datenquellen so auf-
• zur zentralen Wissenskomponente, die für die Planung
bereitet werden, dass eine Recherche und eine anschließen-
und Ausführung der Quellenidentifikation und Daten-
de Auswahl von geeigneten Datenquellen möglich ist. Die
transformation im ETL-Prozess benötigt wird und
Heterogenität der Datenquellen erschwert die automatische
Integration in das DW. In föderierten Datenbanken gab es • zur Search Engine zwecks Quellenidentifikation.
umfangreiche Untersuchungen zu Heterogenitäten der ein-
zelnen Datenquellen bzgl. Syntax und Semantik von Werten,
Attributen, Relationen und Modellen [6]. Die Transformati- Konzept.
on von Daten aus heterogenen Formaten in eine einheitli- Die Wissenskomponente (knowledge component) stellt
che Repräsentationsform stellt das Hauptproblem bei der Informationen über Klassifikations- und Dimensionshiera-
Integration dar. Der Anwender muss deshalb bei der Daten- chien, semantische Verknüpfungen und die Typisierung so-
integration und insbesondere bei der Datentransformation wie Metadaten einzelner Attribute bereit (siehe Abb. 5).
unterstützt werden. Angepasste Nutzerinterfaces sollen den Das domänenspezifische Wissen wird durch Quellenanga-
technikunerfahrenen Anwender unterstützen. ben, Synonyme und Muster (Format- bzw. Modell-Pattern)
Der Prozess des Füllens eines DW mit Daten wird als ergänzt. Die Wissenskomponente ist für die Prozesse der
ETL-Prozess bezeichnet, ETL steht hierbei für Extract, Trans- Quellenidentifikation und Datenintegration neuer Datenquel-
form und Load. Die Basisdaten in den meisten Anwendun- len unabdingbar.
gen sind heterogene Daten, die in ein einheitliches Format, • Der Metadata Manager stellt eine Schnittstelle be-
das multidimensionale Modell des DW integriert werden sol- reit, über die andere Komponenten Anfragen an die
len. Bei diesem Prozess werden die neuen oder veränderten Wissensbasis und das Metadaten-Repository stellen und
Daten aus den Basisdatenquellen ausgewählt (Extraction), Antworten anfordern können.
in eine einheitliche Darstellung umgewandelt (Transformati-
on), dabei vervollständigt, Duplikate bereinigt und eventuell • Die Knowledge Base beinhaltet ein Wissensmodell
voraggregiert. Anschließend erfolgt das Laden in die Daten- für die Speicherung und Verwaltung der semantischen
bank (Load) [5]. Im vorgestellten Ansatz soll eine Wissens- und ontologischen Informationen.
komponente den ETL-Prozess unterstützen, indem einzelne • Das Metadata Repository beinhaltet alle weiteren
Komponenten um semantische und ontologische Konzepte Metadaten, die vom DWM benötigt werden.
erweitert werden. Wir schlagen deshalb eine Erweiterung des
klassischen ETL-Prozesses in folgenden Bereichen vor:
Herausforderungen.
• Quellenidentifikation: Methoden des Information- Die Umsetzung einer Wissenskomponente erfordert den
Retrieval sollen den Anwender bei der Identifikation Aufbau einer Wissensbasis zum Anwendungsgebiet des DW,
und Vorauswahl von Datenquellen unterstützen. womit je nach Anwendungsszenario ein hoher manueller Auf-
wand verbunden ist. Ein Teil der Wissensbasis kann aus
• Datenintegration: Die flexible Integration heteroge- den hierarchischen Klassifikationsattributen der Dimensio-
ner Datenquellen soll durch semiautomatische Techni- nen des DW übernommen werden.
ken gefördert werden. Zusätzlich zu diesen hierarchischen Informationen werden
Wörterbücher benötigt, die die Verbindung zwischen Kon-
• Datenextraktion (als Teil der Datenintegration): Der zepten der Wissensbasis und Suchbegriffen herstellen. Die-
Anwender soll durch geeignete Nutzerinterfaces die Ab- se Wörterbücher sind initial zur erstellen und sollen beim
bildungs- und Transformationsvorschriften effizient be- Einsatz des iETL-Tools von einer lernenden Komponente
stimmen können. erweitert und anpasst werden.
61
iETL: Flexibilisierung der Datenintegration in Data Warehouses
analysis
knowledge component
BI-Tool Metadata
Repository Metadata Knowledge
Manager
Repository Base
load
Base Response Query
Data Warehouse Manager
Repository Manager Manager
load
Staging Ǧ Search Engine
Area
Index
extraction
data integration source identification
Integration Layer
applications documents databases portable disks
control flow data flow
Abbildung 5: Architektur für den flexiblen ETL-Prozess
3.3 Quellenidentifikation – Wann: Datumsangaben und Zeitbereiche.
Liegt in einem klassischen DW die Auswahl der Daten-
quellen bzw. der Quelldaten vorrangig bei den zuständigen • Das Query Processing beschreibt eine Vorverarbei-
Administratoren, so soll in diesem Ansatz der Anwender des tung der Anfrage unter Verwendung der Wissensbasis.
DW in die Quellenidentifikation einbezogen und dabei un- Dabei soll eine Anpassung der Anfrage hinsichtlich der
terstützt werden. Struktur (Ort, Zeit, Schlüsselwörter), die Expansion
der Anfrage mit Hilfe der Wissensbasis sowie ein Vo-
kabularmapping und weitere Vorverarbeitungsschritte
Konzept. wie eine lexikografische Analyse oder Stoppwortelemi-
Eine Suchkomponente soll bei der Quellenidentifikation im
nierung stattfinden.
ETL-Prozess dem Anwender die Auswahl weiterer Daten-
quellen erleichtern. Dafür soll ein Index über alle verfügba- • Die Search Engine soll die Indizierung von Daten-
ren Datenquelle aufgebaut werden, die über den Integra- quellen, eine Anfrageverarbeitung und die Bereitstel-
tion Layer verfügbar sind. Der Prozess der Quelleniden- lung von Ergebnislisten übernehmen. Die Indizierung
tifikation (source identification) ist in Abbildung 5 rechts (mit gleichen Methoden wie bei der Anfrageverarbei-
dargestellt. Die Komponenten sind an die Architektur ei- tung) soll durch eine Strukturanalyse auf Basis von
ner Web-Suchmaschine angelehnt, wie sie beispielsweise in Mapping-Mustern (die während der Datenintegration
[1] (Seite 460) vorgeschlagen wird. Sie werden im Folgenden erzeugt werden) umgesetzt werden. Neben dem Bereit-
vorgestellt. stellen von Anfrageergebnissen aus heterogenen Daten-
• Der Query Manager stellt über eine Schnittstelle quellen sollen Suchergebnisse mit Informationen über
einfache oder erweiterte Suchmasken bereit. Für die den Fundort innerhalb der Datenquellen angereichert
Suche werden vorerst die existierenden Dimensionen werden, wofür domänenspezifische Informationen und
aus dem DW als Suchparameter verwendet: Musteranalysen aus der Wissensbasis zum Einsatz kom-
men sollen.
– Was: Kenngrößen, die in einer Datenquelle ent-
halten sein müssen. • Das Crawling beschreibt den Schritt, in dem verfüg-
– Wo: Geo-Objekte, die durch die Werte beschrie- bare Datenquellen durchsucht und für die Indizierung
ben werden. bereitgestellt werden. In diesem Schritt ist die Nut-
62
iETL: Flexibilisierung der Datenintegration in Data Warehouses
zung vorhandener Mapping-Muster zu Strukturanaly- Konzept.
sen und semantischen Auswertungen geplant.
• Mit extraction wird die Übertragung von Daten aus
• Der Response Manager wird für die Präsentation externen Quellen in den Arbeitsbereich (staging area)
der Anfrageergebnisse genutzt. Dem Nutzer soll eine beschrieben. Die Auswahl der Datenquellen wurde im
Vorauswahl von Datenquellen durch eine vereinfachte Vorfeld durch den Anwender (Quellenidentifikation)
Datenvorschau ermöglicht werden, eine semiautomati- durchgeführt. Der Prozess muss um semiautomatische
sche Identifizierung möglicher Indikatoren, Variablen Methoden des Schema Matchings und Mappings erwei-
und Zeiträume in den Anfrageergebnissen soll dabei tert werden (pattern matching).
erfolgen (siehe Abb. 3). Die ausgewählten Quellen wer- Die bei der Datenextraktion und -transformation er-
den hier an den DWM übergeben, der in einem nächs- zeugten Mapping-Mustern sollen für eine spätere Wie-
ten Schritt die Datenintegration anstoßen kann. derverwendung in der Wissensbasis vorgehalten wer-
den und bei jeder Datenintegration auf ihre Anwend-
Herausforderung. barkeit hin überprüft werden. Passende Muster für die
Eine Herausforderung ist das Design des Anfrageinterfa- Extraktion einer Datenquellen werden dem Anwender
ces und der Ergebnisdarstellung. Hierfür müssen die Anfor- angeboten. Die Schritte der Extraktion und Transfor-
derungen der Anwender bestimmt werden. mation müssen durch angepasste, graphische Tools un-
terstützt werden.
• Anfrageinterfaces: Wie können Suchanfragen auf Ord-
• Mit transformation wird die Abbildung der Daten
ner, Datenquellen oder Dateitypen eingegrenzt werden
hinsichtlich struktureller und inhaltlicher Aspekte be-
und welche der Anfragetypen Context (Phrase, Boo-
schrieben. Neben der Datentransformation (z. B. Kon-
lean, etc.), Pattern Matching oder strukturierte An-
vertierung von Kodierungen, Vereinheitlichung von Da-
fragen (formularbasiert) können genutzt werden. Au-
tumsangaben, etc.) sollen hier auch eine Datenbereini-
ßerdem ist zu klären, ob die Klassifizierung der An-
gung, Duplikaterkennung und eine Datenfusion statt-
frage durch vorhandene Kategorien der Wissensbasis
finden (siehe auch [2]). Für diesen Schritt sind ebenfalls
möglich und sinnvoll ist.
Informationen aus der Wissensbasis notwendig. Vor-
• Ergebnisdarstellung: Wie muss eine zielgerichtete schläge für Transformationsvorschriften können aus der
Präsentation der Anfrageergebnisse unter Verwendung Wissensbasis abgeleitet werden.
der Wissensbasis umgesetzt werden und wie ist dabei
• Mit load wird die Übertragung der Daten aus dem
eine semiautomatische Identifizierung potentieller In-
Arbeitsbereich in das Base Repository beschrieben.
dikatoren, Variablen und Zeiträume möglich. Daneben
Die Daten stehen dann für die weitere Verarbeitung
sollen relevante Elemente der Ergebnismenge hervor-
durch unterschiedliche BI-Tools (Business Intelligence
gehoben und die Identifizierung von Strukturen inner-
Tools) zur Verfügung. Durch ein erneutes Laden wer-
halb eines Treffers durch Anwendung von Mapping-
den die Daten in ein externes BI-Tool Repository
Mustern möglich sein.
geladen (grau hinterlegt) und stehen so in DW-Anwen-
• Query Processing (basierend auf der Wissensbasis): dungen für weitere OLAP-Analysen zur Verfügung.
Wie kann die Wissensbasis für die Anfrageerweiterung
in Form einer facettierten Suche genutzt und wie kön-
nen Methoden des Relevance Feedback zur Verbesse- Herausforderungen.
rung der Qualität der Ergebnisse genutzt werden. Die Herausforderungen bei der Datenintegration liegen
bei der Tool-Unterstützung des Anwenders, sowie bei der
• Search Engine: Wie kann die Integration externer semantischen Unterstützung des Transformationsprozesses.
Anwendungen (Enterprise Search, ERP, CRM, etc.) Das Schema einer Datenquelle ist in der Regel unbekannt,
umgesetzt werden, wenn die bereitgestellte Anfrage- weshalb es mit Hilfe geeigneter Werkzeuge extrahiert werden
schnittstellen nur Teilergebnisse liefern oder der Um- muss.
fang der Datenbasen zu groß ist. Die Integration un-
terschiedlicher Datenformate soll ebenso unterstützt • Transformation: Die Datentransformation aus dem
werden, wie die Duplikaterkennung, wenn Inhalte und Format der Basisdatenquelle ins Zielformat kann nicht
Daten aus unterschiedlichen Quellen genutzt werden. vollständig automatisiert werden. Herausforderung ist
Weiterhin sollen Mapping-Muster für den Prozess der hier die Entwicklung von Nutzerinterfaces zur Einga-
Indizierung und Extraktion genutzt werden und Klas- be der benötigten Informationen durch den Fachan-
sifikation durch die Mapping-Muster unterstützt wer- wender. Die dabei entstehenden Transformationsmus-
den. ter sollen gespeichert werden, damit sie für andere Da-
tenquellen verwendet werden können.
3.4 Datenintegration Welche vorhandenen Ansätze der Datenintegration kön-
Die Datenintegration muss bedarfsabhängig und flexibel nen für die Datenbereinigung, Duplikaterkennung und
angepasst werden, wenn durch die Quellenidentifikation neue Datenfusion angewendet werden und wie kann eine
Datenquellen zu integrieren sind. Die Flexibilisierung soll Plausibilitätsprüfung der Daten unterstützt werden.
durch Anwendung von semantischen und ontologischen Kon- Für eine Plausibilitätsprüfung können z. B. Regeln de-
zepten erreicht werden, wodurch domänenspezifisches Wis- finiert werden, die die Wissensbasis einbeziehen. Ein
sen ausgenutzt wird. Die Architektur in Abbildung 5 ist da- möglicher Ansatzpunkt ist hier die Angabe von check-
bei an die Referenzarchitektur angelehnt. constraints.
63
iETL: Flexibilisierung der Datenintegration in Data Warehouses
3.5 Einsatz des Verfahrens Wissensbasis gebildet werden, die um Wörterbücher ergänzt
Das im Projekt zu entwickelnde Verfahren wird sich nicht wird.
auf alle DW anwenden lassen. Voraussetzung ist, dass es ei-
ne Wissensbasis zu dem Anwendungsgebiet des DW gibt. Da
diese Wissensbasis eine zentrale Rolle beim Finden der rele- 5. ZUSAMMENFASSUNG, AUSBLICK
vanten Datenquellen und bei der Transformation der Daten Die flexible, durch situativ entstandenen Datenbedarf in-
ins DW spielt, muss eine solche Wissensbasis für einen fle- itiierte Integration bislang unerschlossener Datenquellen in
xiblen ETL-Prozess vorhanden sein. Teile der Wissensbasis ein Data Warehouse erfordert eine Anreicherung des ETL-
lassen sich aus den Klassifikationsattributen der Dimensio- Prozesses um interaktive Schritte. Um diesen Prozess für
nen des DW generieren; die Zuordnung dieser Klassifikati- den Fachanwender handhabbar zu halten, bedarf es zusätz-
onshierarchie zu den korrespondierenden Suchbegriffen für licher Komponenten zur Speicherung und Nutzung von do-
die Datenquellen muss für das jeweilige Anwendungsgebiet mänenspezifischem Wissen (knowledge component), die das
ergänzt werden. Finden (source identification) und Integrieren (data integra-
tion) neuer Daten erleichtern bzw. erst ermöglichen.
4. RELATED WORK / Geleitet von Anwendungsszenarien wurde ein Konzept zur
Architektur eines solchen Systems vorgestellt. Die Heraus-
STAND DER TECHNIK arbeitung technischer Herausforderungen zeigt den zu ge-
henden Weg: Die Details der einzelnen Komponenten sind
4.1 Datenintegration zu konkretisieren, bislang nicht kombinierte Techniken zu
Jede Datenintegration bewirkt das Zusammenführen von verbinden und eine angemessene Nutzerschnittstelle zu ent-
Daten aus heterogenen Datenbanken und Informationssys- wickeln.
temen. Es gibt Klassifikationen, die die Heterogenitäten der
einzelnen Datenquellen systematisieren. Heterogenitäten kön- 6. REFERENCES
nen bzgl. Syntax und Semantik von Werten, Attributen, Re-
lationen, Modellen existieren ([6]). Eine Standardarchitek- [1] Baeza-Yates, R. und B. Ribeiro-Neto: Modern
tur, die das Zusammenführen von heterogenen Formaten in information retrieval: the concepts and technology
heterogenen Datenbanken vornimmt, wurde bereits im Jahr behind search. Addison-Wesley, Pearson, Harlow [u.a.],
1990 in [10] vorgeschlagen. 2. Aufl., 2011.
Eine dabei bestehende Aufgabe ist Matching und Map- [2] Bauer, A. und H. Günzel:
ping heterogener Datenbanken. Es gibt mehrere Mapping- Data-Warehouse-Systeme: Architektur, Entwicklung,
Tools, die eine intuitiv bedienbare Oberfläche anbieten, um Anwendung. dpunkt-Verl., Heidelberg, 2. überarb. und
dem Benutzer das Entwickeln von Datentransformations- aktualisierte Aufl., 2004. Literatur- und URL-Verz. S.
komponenten zu erleichtern (wie Altova MapForce1 , oder 545–576.
IBM Data Integrator), dieser Prozess ist jedoch nicht au- [3] Courage, C. und K. Baxter: Understanding Your
tomatisierbar. Einen Überblick über Forschungsansätze in Users: A Practical Guide to User Requirements
dieser Richtung findet man in [9]. Dabei spielen vor allem Methods, Tools, and Techniques. Morgan Kaufmann,
Ontologie-basierte Ansätze eine große Rolle (vgl. [7] und [4]). 1. Aufl., 2005.
[4] Doan, A. und A. Y. Halevy: Semantic Integration
4.2 ETL Research in the Database Community: A Brief Survey.
Beim ETL-Prozess in einem DW werden die Basisdaten AI Magazine, 26(1):83–94, 2005.
(meist heterogene Daten) in ein einheitliches Format, das [5] Inmon, W.: Building the data warehouse. Wiley, 2005.
multidimensionale Modell des DW integriert [5]. Man kann [6] Kim, W. und J. Seo: Classifying Schematic and Data
den ETL-Prozess eines DW als Spezialfall föderierter Daten- Heterogeneity in Multidatabase Systems. Computer,
banken sehen. Für neue Datenquellen bedeutet der ETL- 24(12):12–18, Dez. 1991.
Prozess also manuellen Aufwand, der eine Interaktion mit [7] Noy, N. F.: Semantic integration: a survey of
einem Benutzer erfordert; im laufenden Prozess kann das ontology-based approaches. SIGMOD Rec.,
Laden neuer Daten dann automatisch ausgeführt werden. 33(4):65–70, Dez. 2004.
Es stehen Tools zur Vereinfachung dieses Prozesses für die [8] Pardillo, J. und J.-N. Mazón: Using Ontologies for
Anwender zur Verfügung, Beispiele dafür sind Talend2 und the Design of Data Warehouses. CoRR,
IBM Data Stage3 . abs/1106.0304, 2011.
[9] Rahm, E. und P. A. Bernstein: A survey of
4.3 Verwendung von Ontologien approaches to automatic schema matching. VLDB
im ETL-Prozess Journal, 10(4):334–350, 2001.
Die Idee, Ontologien zur Beschreibung von Objekten ein- [10] Sheth, A. P. und J. A. Larson: Federated database
zusetzen, ist weit verbreitet. Im DW-Bereich gibt es einen systems for managing distributed, heterogeneous, and
Vorschlag, Ontologien zu verwenden, um die Metadaten des autonomous databases. ACM Comput. Surv.,
Data Warehouses daraus abzuleiten [8]. In unserem Ansatz 22(3):183–236, Sep. 1990.
soll die Kopplung dieser beiden Gebiete auf andere Weise [11] Vitako: IT-Monitor kommunal . Vitako aktuell.
erfolgen: Aus den Klassifikationsattributen des DW soll eine Bundesarbeitsgemeinschaft der Kommunalen
1 IT-Dienstleister e.V, 2007.
www.altova.com/mapforce.html
2
www.talend.com
3
www.ibm.com/software/data/infosphere/datastage
64
Ereignismuster für die Verwaltung von komplexen
Tupelereignissen in Probabilistischen Datenbanken
Sebastian Lehrack
Brandenburgische Technische Universität Cottbus
Institut für Informatik, Postfach 10 13 44
D-03013 Cottbus, Deutschland
slehrack@informatik.tu-cottbus.de
ABSTRACT Arte
tid aid type sond age ETArte
Probabilistische Datenbanken haben sich als adäquate Tech-
t1 art1 vase fragment 3 300 (X1 = t1 )
nik zur Verwaltung und Verarbeitung von umfangreichen t2 art2 spear head 10 500 (X2 = t2 )
unsicheren Datenmengen etabliert. Eine der größten Her- t3 art3 vase fragment 4 300 (X3 = t3 )
ausforderungen für probabilistische Datenbanken ist eine ef-
fiziente Anfrageverarbeitung. Eine zentrale Rolle spielen da- ArteExp
bei Ableitungsformeln, welche komplexe Tupelereignisse in tid expert aid culture conf ETArteExp
Form von aussagenlogischen Formeln verkörpern. Eine di- t4 Peter art1 roman 0.3 (X4 = t4 )
rekte Abspeicherung und Verarbeitung von komplexen lo- t5 Peter art1 greek 0.4 (X4 = t5 )
gischen Formeln wird von relationalen Datenbanksystemen t6 Kathleen art1 roman 0.4 (X5 = t6 )
jedoch nicht unterstützt. Diese Arbeit stellt Ereignismuster t7 John art2 egyptian 0.6 (X6 = t7 )
als geeignetes Mittel vor, um Ableitungsformeln mittels ei- ArteMat
nes RBDMS verwalten zu können. tid method aid culture conf ETArteM at
t8 XRF art1 roman 0.3 (X7 = t8 )
t9 XRF art1 greek 0.3 (X7 = t9 )
t10 ICS-MS art2 punic 0.8 (X8 = t10 )
1. MOTIVATION t11 XRF art2 egyptian 0.5 (X9 = t11 )
Probabilistische Datenbanken standen in den letzten Jah-
ren im Mittelpunkt intensiver Untersuchungen (für einen Figure 1: Datentabellen Arte, ArteExp und ArteMat
Überblick verweisen wir auf [18]). In einer solchen Daten- des fortlaufenden Beispielszenarios (die unterstri-
bank gehört ein Tupel lediglich mit einer gewissen Wahr- chenen Attribute kennzeichnen den jeweiligen Er-
scheinlichkeit zu einer Datentabelle oder zu einem Anfrage- eignisschlüssel (siehe Kap. (2)))
ergebnis. Die Wahrscheinlichkeit drückt dabei entweder eine
Unsicherheit über die Datengrundlage oder die Anfrageant-
wort aus. durch die Neuentwicklung des CISAR-Projektes1 [5], wel-
Eine der größten Herausforderungen für probabilistische ches als internet-basiertes Geo-Informationssystem für Ar-
Datenbanken ist eine effiziente Anfrageverarbeitung. Ein zen- chäologie und Gebäudegeschichte entwickelt worden ist. Die
trales Konzept sind dabei Ableitungsformeln, welche kom- hier vorgestellten Techniken werden umfassend in dem Nach-
plexe Tupelereignisse in Form von aussagenlogischen For- folgesystem OpenInfRA eingesetzt [17].
meln darstellen [4]. Eine direkte Abspeicherung und Verar- In dem stark vereinfachten Beispielszenario werden die de-
beitung von komplexen logischen Formeln wird von relatio- terministische Tabelle Artefakte (Arte) und die zwei pro-
nalen Datenbanksystemen jedoch nicht unterstützt. Diese babilistischen Tabellen Artefakte klassifiziert bei Experten 2
Arbeit stellt Ereignismuster als geeignetes Mittel vor, um (ArteExp) und Artefakte klassifiziert bei Material (ArteMat)
Ableitungsformeln in einer strukturierten Form mittels ei- verwendet, siehe Abb. (1). In der Datentabelle Arte werden
nes RBDMS verwalten zu können. Informationen über mehrere Artefakten gespeichert, welche
Fortlaufendes Beispiel: Die grundlegenden Ideen wer- während einer archäologischen Ausgrabung gefunden wor-
den in den nächsten Kapiteln anhand eines fortlaufenden den sind. Dabei wird mittels der Sondage-Nummer (Attri-
Beispielszenarios aufgezeigt. Dieses Szenario ist motiviert but sond ) die geographische Fundstelle eines Artefaktes be-
schrieben.
Zusätzlich geben mehrere Spezialisten verschiedene Ex-
pertisen über die Ursprungskultur eines Artefakts (Attribut
culture) ab, siehe Tabelle ArteExp. Diese Einschätzungen
werden mit einem Konfidenzwert annotiert (Attribut conf ),
1
http://www.dainst.org/en/project/cisar/
2
Die Spalten tid, conf und ET (...) gehören nicht zu den ei-
24th GI-Workshop on Foundations of Databases (Grundlagen von Daten- gentlichen Datentabellen. Mittels der Spalte tid werden Tu-
banken), 29.05.2012 - 01.06.2012, Lübbenau, Germany. pel adressiert. Die Bedeutung von conf und ET(...) wird in
Copyright is held by the author/owner(s). den nächsten Abschnitten erläutert.
65
Ereignismuster für die Verwaltung von komplexen Tupelereignissen in Probabilistischen Datenbanken
select aid, type, culture πaid,type,culture
from ( select aid, culture
from ArteExp
union ./
select aid, culture
from ArteMat
) origin ∪ Arte
inner join
( select *
from Arte πaid,culture πaid,culture
) prop
on ( origin.aid = prop.aid ) ArteExp ArteM at
Figure 2: Beispielanfrage Qe als QSQL2-Anfrage und als abstrahierte Algebraanfrage
welche die Wahrscheinlichkeit ausdrückt, dass das entspre- der block-independent-disjoint Datenbanken (BID) [2] be-
chende Artefakt zu der bestimmten Kultur gehört. Neben nutzt, da Tupel- und Attributunsicherheit untersützt wer-
den subjektiven Expertenmeinungen werden auch objekti- den soll. Eine BID ist eine probabilistische Datenbank in
ve Methoden einbezogen. Diese archäometrischen Methoden der die gegebenen Tupel in Blöcke unterteilt werden. Da-
(z.B. XRF und ICS-MS3 ) basieren auf einer Materialanaly- bei kann ein Block sich nicht über mehrere Relationen er-
se. In Kombinationen mit den Fundstellen und dem Artefak- strecken. Es wird vereinbart, dass alle Tupel innerhalb ei-
talter kann die Materialzusammensetzung wichtige Hinweise nes Blockes mit disjunkten Tupelereignissen verbunden sind.
auf die Ursprungskultur geben, welche dann ebenfalls mit- Ein Tupelereignis beschreibt das Vorhandensein oder das
tels Konfidenzwerten quantifiziert werden. Nicht-Vorhandensein eines Tupel in einer beliebigen Welt.
Basierend auf den eingeführten Datentabellen soll exem- Wegen der Disjunktheit der Tupelereignisse kann maximal
plarisch die folgende Anfrage Qe bearbeitet werden: Bestim- ein Tupel eines Blockes in einer bestimmten Welt vorhanden
me alle Artefakte mit ihren jeweiligen Typ und ihren mögli- sein. Dagegen sind Tupel von verschiedenen Blöcken mit ge-
chen Ursprungskulturen. Um diese Anfrage zu beantworten genseitig unabhängigen Tupelereignissen assoziiert.
wird sie zunächst in der Anfragesprache QSQL2 [8] formu- Für die Definition von Blöcken werden Ereignisschlüssel in
liert, siehe Abb. (2). Anschließend wird von dem eigentlichen Form von Attributmengen angewendet4 . So wird ein Block
SQL-Syntax abstrahiert, indem sie in Form einer Algebraan- wird von Tupeln gebildet, welche die gleichen Werte für die
frage in den nächsten Kapiteln weiter verarbeitet wird. Attribute des Schlüssel haben. Anschließend wird für jeden
Die Arbeit ist wie folgt gegliedert. In Kap. (2) werden zu- Block eine unabhängige Zufallsvariable Xk eingeführt. Das
nächst die Grundlagen für die weiteren Betrachtungen ge- konkrete Eintreten einer Zufallsvariable (Xk = tid ) reprä-
legt. Danach steht der wesentliche Beitrag dieser Arbeit in sentiert ein Tupelereignis und wird quantifiziert mit dem
Form der Ereignismuster in Kap. (3) im Mittelpunkt. In Konfidenzwert des Tupels tid , siehe die Spalten conf und
den Kap. (4) und (5) wird die Arbeit mit einer Diskussion ET (...) in der Abb. (1)5 . Die kombinierte Wahrscheinlich-
über verwandte Arbeiten und einer Zusammenfassung ab- keitsverteilung aller Blockvariablen bilden schließlich P. Um
geschlossen. Der Beweis des Satzes (1) wird im Anhang (A) eine Algebraanfrage auf einer probabilistischen Datenbank
geführt. auszuführen, wird folgende Anfragesemantik verwendet [18].
2. GRUNDLAGEN Definition 2. Sei Q eine Algebraanfrage und D = (W, P)
In einer probabilistischen Datenbanken werden mehrere eine probabilistische Datenbank. Die Menge aller möglichen
möglichen Datenbankinstanzen, welche auch Welten genannt Antworttupel einer Anfrage Q ist definiert als Qposs(W) =
werden, gleichzeitig verwaltet und abgefragt. Dabei wird die {t | ∃W ∈ W : t ∈ Q(W )}. Zusätzlich werden die Eintritts-
reale Welt“ als unbekannt angenommen. Um diese Unsi- wahrscheinlichkeiten aller möglichen AntwortenP
in der Funk-
”
cherheit abzubilden wird ein Wahrscheinlichkeitsmaß über tion PrQ : Qposs(W) → (0, 1] als PrQ (t) := P(W ).
der Menge aller möglichen Welten vereinbart. Konkret wird W ∈W:t∈Q(W )
hier auf die Definition von Suciu et al. [18] zurück gegriffen. berechnet.
Definition 1. Angenommen werden k Relationennamen: Dies bedeutet, dass die Anfrage Q konzeptionell in jeder
R1 , . . . , Rk . Eine unvollständige Datenbank ist dann eine Welt separat ausgeführt wird. Dann wird die Ergebnisrelati-
endliche Menge von Dateninstanzen W = {W 1 , W 2 , . . . , W n }, on Qposs(W) gebildet, in dem alle möglichen Antworten der
wobei jede Dateninstanz (Welt) durch W i = (R1i , . . . , Rki ) verschiedenen Auswertungen gesammelt werden. Zusätzlich
beschrieben ist. Eine probabilistische Datenbank ist ein Wahr- wird die Eintrittswahrscheinlichkeit einer möglichen Ant-
scheinlichkeitsraum D = (W, P) über einer unvollständigen wort durch das Aufsummieren der Welten, in der das Ant-
Datenbanken W. Damit ist P : W → [0, 1] eine Funktion, worttupel in der Antwort auftritt, gebildet. Offensichtlich
gibt die Def. (2) nur die Semantik der Anfrageauswertung
P
sodass W ∈W P(W ) = 1 gilt. Es wird vorausgesetzt, dass
∀W ∈ W : P(W ) > 0 gilt. vor. Eine einzelne Auswertung in allen Welten ist praktisch
4
Im Allgemeinen ist die Semantik des Wahrscheinlichkeits- In dem Beispielszenario werden die Ereignisschlüssel von
maß P nicht vordefiniert. Konkret wird hier der Spezialfall Arte, ArteExp und ArteMat als {aid}, {exp, aid} und
{method, aid} vereinbart, siehe Abb. (1).
3 5
XRF und ICP-MS stehen für die x-ray fluorescence und die Da die Tabelle Arte deterministisch ist, wird P(X1 = t1 ) =
inductively coupled plasma mass spectrometry Methode. . . . = P(X3 = t3 ) = 1 gesetzt.
66
Ereignismuster für die Verwaltung von komplexen Tupelereignissen in Probabilistischen Datenbanken
nicht umsetzbar, da die Anzahl aller Welten exponentiell in Algorithm 1: gen(Φpa , t)
Datengröße anwachsen kann.
Data: Klauselmustermenge Φpa , Tupel t ∈ Rev
Result: Formel in DNF kodiert als Φt
3. EREIGNISMUSTER 1 Φt := ∅;
In diesem Kapitel wird die praktische Auswertung einer 2 foreach CP ∈ Φpa do
Algebraanfrage Q auf einer probabilistischen Datenbank dis- 3 C := (true);
kutiert. Dabei wird das Konzept der Ableitungsformeln vor- 4 foreach ETRi in CP do
gestellt und eine neue Technik zur Verwaltung von komple- 5 if t[ETRi ] 6= null then
xen Tupelereignissen eingeführt. 6 C := C • t[ETRi ];
7 else
3.1 Ableitungsformeln 8 C := C • (false);
Entsprechend Def. (2) muss zur Auswertung einer Anfra- 9 end
ge die Ergbeniswahrscheinlichkeit PrQ (t) für jedes Ergeb- 10 end
nistupel berechnet werden. Fuhr und Röllecke schlugen in 11 if simpl(C) 6= false then
[4] vor, diese Wahrscheinlichkeiten mittels von Ableitungs- 12 Φt := Φt ∪ {simpl(C)};
formeln φt zu berechnen. Dabei werden alle Ableitungsfor- 13 end
meln neben dem eigentlichen Datenanteil der Tupel verwal- 14 end
tet. Prinzipiell ist eine Ableitungsformel φt durch eine aus- 15 return Φt ;
sagenlogische Formel gegeben, welche mittels den Zufallsva-
riablen (Xk = tid )6 und den logischen Operatoren ∧, ∨ und
¬ gebildet wird. Fuhr und Röllecke haben geschlussfolgert,
dass PrQ (t) durch Wahrscheinlichkeit P(φt ≡ true) ermit- 3.2 Verwaltung von Ableitungsformeln mittels
telt werden kann, d.h. PrQ (t) = P(φt ≡ true). Somit kann Ereignismustern und Basisereignismengen
PrQ (t) durch P(φt ≡ true) berechnet werden, ohne dass Um eine logische Formel in einer strukturierten Form zu
über alle Welten von W iteriert werden muss (siehe Def. verwalten wird sie in die bekannte disjunktive Normalform
(2)). Im Folgenden wird P(φt ≡ true) durch P(φt ) abge- (DNF) transformiert.
kürzt. Die Konstruktion von φt greift auf die Struktur der
betrachteten Anfrage Q zurück. Definition 4. Angenommen φt ist eine Ableitungsformel.
Ein Literal ist gegeben durch ein negiertes oder unnegiertes
Definition 3. Angenommen Q ist eine Algebraanfrage und Basisereignis von φt , d.h. L ≡ ¬(Xk = tid ) oder L ≡ (Xk =
D = (W, P) ist eine probabilistische Datenbank. Die Ablei- tid ). Eine Konjunktion von Literalen wird als Klausel C be-
tungsformel φt ist dann wie folgt rekursiv definiert: zeichnet, d.h. C = L1 ∧ . . . ∧ Lm . Eine Formel φdnf
t in DNF
Q ≡ R : φt := (Xk = tid ), wenn t ∈ TupBl(k) ist eine Disjunktion von Klauseln, d.h. φdnf
t = C1 ∨ . . . ∨ Cr ,
sodass φt ≡ φdnf
t .
Q ≡ σc (Q1 ) : φt := φt1
_ Da relationale Standardoperatoren zur Manipulation von
Q ≡ πA (Q1 ) : φt := φt̂ DNF-Formeln verwendet werden sollen (siehe Def. (6) un-
t̂∈Q1 ,t̂[A]=t ten), empfiehlt es sich DNF-Formeln in Form von Tupeln
Q ≡ Q1 ./ Q2 : φt := φt1 ∧ φt2 und Mengen zu kodieren.
Q ≡ Q1 ∪ Q2 : φt := φt1 ∨ φt2 Definition 5. Um eine Formel φdnf t in DNF zu kodieren,
Q ≡ Q1 \ Q2 : φt := φt1 ∧ ¬(φt2 ) wird eine Menge von Klauseltupeln (bezeichnet als Φt ) be-
nutzt, d.h. Φt := {C1 , . . . , Cr }, wobei Ci ein Klauseltu-
wobei Xk eine Blockvariable ist und TupBl(k) alle Tupel pel ist. Ein Klauseltupel Ci = (L1 , . . . , Lmi ) korrespondiert
eines Blockes k zurück gibt (siehe Kap. (2)). Falls ti nicht dann mit einer Klausel L1 ∧ . . . ∧ Lmi von φdnf t .
in einer Eingabeanfrage existiert (d.h. ti ∈
/ Qi ), wird φti :=
false gesetzt (siehe Vereinigung- und Differenzoperator). Die grundlegende Idee des hier vorgestellten Ansatzes lässt
sich dann in folgenden vier Schritten beschreiben:
Abb. (3) zeigt die Ableitungsformeln für die Ergebnistu-
pel der Beispielanfrage Qe . Die Wahrscheinlichkeit P(φt ) (i) das Bilden einer Menge von Klauselmustern (gekenn-
kann mit Standardalgorithmen berechnet werden (z.B. [12, zeichnet als Φpa ), welche direkt von der Algebraanfrage
6]). Wie man dort sieht, besitzen Ereignistupel im Allgemei- Q abgeleitet wird (d.h. unabhängig von den aktuellen
nen unterschiedliche Ableitungsformeln. Mehrere Verfahren Daten in der Datenbank),
(z.B. [4, 3, 13]) müssen eine komplexe Ableitungsformel für (ii) das Generieren einer Menge relevanter Basisereignissen
jedes einzelne Tupel, welches innerhalb der Anfrageverarbei- für jedes Ergebnistupel während der relationalen An-
tung entsteht, verwalten. Praktische Anwendungsszenarien frageverarbeitung (verwaltet in einer erweiterten Er-
haben jedoch bereits gezeigt, dass Ableitungsformel mit ei- gebnisdatenrelation Rev ),
ner Größe von 10 MB für ein Ergebnistupel auftreten können (iii) die Konstruktion einer DNF-Formel kodiert als Φt
[14]. Dementsprechend folgt der hier entwickelte Ansatz der für jedes Ergebnistupel mittels des Generierungsalgo-
Argumentation von Antova et al. [1] und Das Sarma et al. rithmus gen(Φpa , t), t ∈ Rev und
[16], dass die Verwaltung und die Verarbeitung von komple- (iv) die Berechnung von P(φdnf t ) mit Hilfe eines Standar-
xen Ableitungsformeln durch relationale Datenbanksysteme dalgorithmus (z.B. [12, 6]).
nicht zielführend sind, da solche Systeme nicht für die Ver- Bevor der Generierungsalgorithmus gen(Φpa , t) diskutiert
arbeitung von komplexen logischen Formeln ausgelegt sind. wird, werden zunächst die Bedeutung von Φpa und Rev nä-
6
Ein solches Ereignis wird auch als Basisereignis bezeichnet. her beleuchtet.
67
Ereignismuster für die Verwaltung von komplexen Tupelereignissen in Probabilistischen Datenbanken
tid aid type culture φt P(φt )
r1 (t4 , t6 , t8 , t1 ) art1 vase fragment roman ([(X4 = t4 ) ∨ (X5 = t6 )]∨ 0.706
(X7 = t8 )) ∧ (X1 = t1 )
r2 (t5 , t9 , t1 ) art1 vase fragment greek [(X4 = t5 ) ∨ (X7 = t9 )]∧ 0.58
(X1 = t1 )
r3 (t7 , t11 , t2 ) art2 spear head egyptian [(X6 = t7 ) ∨ (X9 = t11 )]∧ 0.8
(X2 = t2 )
r4 (t10 , t2 ) art2 spear head punic [(X8 = t10 ) ∨ (F alse)]∧ 0.8
(X2 = t2 )
Figure 3: Die Ergebnistupel von Qe mit ihren Ableitungsformeln (φt ) und ihren Ergebniswahrscheinlichkeiten
(P(φt ))
Mustermenge Φpa : Die Mustermenge Φpa besteht aus (W, P) eine probabilistischen Datenbank. Die Klauselmus-
einer Menge von Klauselmustern {CP1 , . . . , CPl }. Ein Klau- termenge Φpa und die Ereignisdatenrelation Rev werden dann
selmuster CP = (ETRi1 , . . . , ETRim ) ist wiederum gegeben rekursiv mittels der folgenden Regel gebildet8 :
durch ein Tupel von Basisereignismustern. Dabei symboli-
siert ein Muster ETRi genau ein Basisereignis (Xk = tid ) Q ≡ Ri : Φpa := {(ETRi )},
der Basisrelation Ri . Falls z.B. das Klauselmuster CP = Rev := {t • (Xk = tid ) | t ∈ Ri }
(ETArteExp , ETArteM at ) betrachtet wird, verkörpert CP al- Q ≡ σc (Q1 ) : Φpa := Φpa ev
:= σc (R1ev )
1 ,R
le Klauseln in denen das erste Basisereignis aus der Relation
ArteExp stammt und das zweite Basisereignis aus ArteM at Q ≡ πA (Q1 ) : Φpa := Φpa
1 ,
genommen wird.
ev
R := πA∪{all ETRi columns} (R1ev )
Basisereignisse in Rev : Die Ereignisdatenrelation Rev Q ≡ Q1 ./ Q2 : Φpa := Φpa pa ev
:= R1ev ./ R2ev
1 × Φ2 , R
besteht aus allen Datentupeln, sowie aus jeweils einer Men-
ge von Basisereignissen für jedes Datentupel. Dabei werden Q ≡ Q1 ∪ Q2 : Φpa := Φpa pa
1 ∪ Φ2 ,
genau die Basisereignisse gespeichert, welche notwendig sind Rev := R1ev ./full outer R2ev
um die Ableitungsformel für ein bestimmtes Datentupel zu
bilden. Zu diesem Zwecke werden die Datenrelationen durch Um die endgültige Ableitungsformel φdnft für ein Ergebni-
zusätzliche Spalten erweitert, welche Basisereignisse spei- stupel t zu bilden, werden die generierten Φt -Formeln aller
chern. Alle Basisereignisse einer spezifischen Zeile gehören Tupel in Rev mit den selben Datenwerten wie das Ergebni-
dabei zu dem jeweiligen Datentupel. Jede neue Spalte wird stupel t disjunktiv verknüpft:
mit einer Basisrelation Ri assoziiert und entsprechend mit _
einem Musternamen ETRi bezeichnet, siehe Abb. (1) und φdnf
t := gen(Φpa , t̂),
(4). t̂∈Rev ,t̂[datAttr]=t
Algorithmus gen(Φpa , t): Nach der Konstruktion von
Φpa und Rev generiert der Algoritmus gen(Φpa , t) eine Ab- wobei datAttr die Menge aller Datenattribute der Ergebnis-
leitungsformel (kodiert als Φpa ) für ein Tupel der Relation datenrelation Rev repräsentiert, d.h. alle Attribut ohne die
Rev . Im Wesentlichen ersetzt der Algorithmus der Basiser- jeweiligen ETRi Spalten9 .
eignismuster mit den jeweiligen zuordenbaren Basisereignis-
sen (siehe Zeilen 2 bis 11 in Algorithmus (1)). Die Vergleichs- Satz 1. Sei Rev und φdnf
t konstruiert wie in Def. (6) an-
kriterien sind durch die Musternamen ETRi und die korre- gegeben, dann gilt (i) Qposs(W) = πdatAttr (Rev ) und (ii)
spondieren Bezeichnungen der Ereignisspalten von Rev ge- ∀t ∈ Qposs(W) : PrQ (t) = P(φdnf
t ).
geben. Der Operator • konkateniert zwei Tupel. Bevor eine
erzeugte Klausel C zu der Ergebnisformel Φt hinzugenom-
men wird, werden alle Klauseln C logisch vereinfacht (siehe
Zeilen 12 und 13). Hierfür werden logische Gesetze wie Idem- 4. VERWANDTE ARBEITEN
potenz und Kontradiktion eingesetzt. Eine umfassende Monographie über probabilistische Da-
tenbank wurde kürzlich von Suciu et al. [18] veröffentlicht.
Die Klauselmustermenge Φpa und die Ereignisdatenrelati- Daneben wurden in den letzten Jahren mehrere probabilis-
on Rev werden rekursiv über die Struktur der betrachteten tische Datenbanksysteme erfolgreich umgesetzt (z.B. [15, 7,
Algebraanfrage Q definiert. Prinzipiell wird Φpa in einer Art 19]). In vorangegangenen Arbeiten [10, 11] des Autors wurde
und Weise konstruiert, dass die erzeugten Muster der grund- ein probabilistisches Daten- und Anfargemodell entworfen,
legenden Semantik der Def. (3) genügt und alle möglichen welches Konzepte aus dem Gebiet des Information Retrievals
Ereignisse erzeugt werden können, die nötig sind um φdnf
t zu mit Technologien der Datenbankwelt kombiniert. Die dabei
erzeugen. Exemplarisch wird die Ereignisdatenrelation der 8
Beispielanfrage Qe in Abb. (4) gezeigt. Um die DNF-Repräsentation von Def. (5) zu bewah-
ren werden Tupel verflacht. Wenn z.B. Φpa 1 = {(L1 , L2 )}
Definition 6. Sei Q eine positive Algebraanfrage7 und D = und Φpa 2 = {(L 3 , L 4 )} gegeben sind, dann ergibt sich
Φpa pa pa
1 × Φ2 = {(L1 , L2 , L3 , L4 )} anstelle von Φ1 × Φ2 =
pa
7
Genau wie die Systeme [15], [19] und [7] fokussiert sich {((L1 , L2 ), (L3 , L4 ))}.
9
der hier vorgestellte Ansatz momentan auf Anfragen ohne Diese Notation von datAttr wird in der restlichen Arbeit
Differenzoperationen. weiter verwendet.
68
Ereignismuster für die Verwaltung von komplexen Tupelereignissen in Probabilistischen Datenbanken
tid aid type culture ETArteExp ETArteM at ETArte
(t4 , t8 , t1 ) art1 vase fragment roman X4 = t4 X7 = t8 X1 = t1
(t5 , t9 , t1 ) art1 vase fragment greek X4 = t5 X7 = t9 X1 = t1
(t6 , t8 , t1 ) art1 vase fragment roman X5 = t6 X7 = t8 X1 = t1
(t7 , t11 , t2 ) art2 spear head egyptian X6 = t7 X9 = t11 X2 = t2
(t10 , t2 ) art2 spear head punic null X8 = t10 X2 = t2
Φpa
e = {(ETArteExp , ETArte ), (ETArteM at , ETArte )}
Figure 4: Die Ergebnisdatenrelation Reev für die Beispielanfrage Qe .
entwickelten Techniken werden in dem erweiterten proba- • Induktionsschritt: n → n + 1 mit der Induktionsannah-
bilistischen Datenbanksystem ProQua 10 umgesetzt. Im Ge- me (IA), dass für alle Anfragen mit bis zu n Operatoren gilt:
gensatz zu anderen Systemen (z.B. [15, 7, 19]) unterstützt
ProQua logik-basierte Ähnlichkeitsanfragen, sowie die Ge- (i) t ∈ R1ev ⇔ t ∈ W
Q1 und
wichtung von Teilanfragen innerhalb seiner Anfragesprache (ii) ∀t ∈ Q1 : gen(Φpa
1 , t̂) ≡ φt1 .
ev ,
QSQL2 [8, 9]. t̂∈R1
t̂[datAttr]=t
• Operator: Q ≡ σsc (Q1 ), d.h. zu zeigen
5. ZUSAMMENFASSUNG
?
In dieser Arbeit wurde ein Konzept vorgestellt, welches (i) t ∈ πdatAttr (σsc (R1ev )) ⇔ t ∈ σsc (Q1 ),
?
mit der Hilfe von Ereignismustern und Basisereignismen- gen(Φpa
W
(ii) ∀t ∈ σsc (Q1 ) : 1 , t̂) ≡ φt1
gen komplexe Tupelereignisse verwalten kann. Diese Tupe- t̂∈σsc (R1ev ),
lereignisse entstehen bei der Auswertung einer komplexen t̂[datAttr]=t
positiven Algebraanfrage auf einer probabilistischen BID- Beweis:
Datenbank. Der wesentliche Vorteil dieser Methode liegt in
dem natürlichen Ablegen von Ableitungsformeln in einer (i) t ∈ πdatAttr (σsc (R1ev )) ⇔ ∃t̂ ∈ R1ev ∧ t̂[datAttr] = t ∧
strukturierten Form innerhalb einer erweiterten Datenrelati- IA
sc(t) = true ⇔ t̂[datAttr] ∈ Q1 ∧ t̂[datAttr] = t ∧ sc(t) =
on. Dadurch können die Tupelereignisse direkt mittels eines true ⇔ t ∈ σsc (Q1 ) X
RDBMS verarbeitet werden.
(Bed. sc(t) ist nur über Attribute von datAttr definiert)
Danksagung: Sebastian Lehrack wurde innerhalb der Pro-
jekte SCHM 1208/11-1 und SCHM 1208/11-2 von der Deut- (ii) ∀t ∈ σsc (Q1 ) ⇒ sc(t) = true ∧(t̂[datAttr] = t ⇒ sc(t̂) =
schen Forschungsgesellschaft unterstützt. true) ⇒
gen(Φpa
W
∀t ∈ σsc (Q1 ) : 1 , t̂) =
t̂∈σsc (R1ev ),
APPENDIX t̂[datAttr]=t
IA
1 , t̂) ≡ φt1 X
gen(Φpa
W
A. BEWEIS FüR SATZ (1) ev ,
t̂∈R1
Es wird angenommen, dass PrQ (t) = P(φt ), falls φt gebil- t̂[datAttr]=t
det wurde wie in Def. (3) spezifiziert (siehe [4]). Somit muss (Bed. t̂[datAttr] = t ist strenger als sc(t))
gezeigt werden, dass (i) Qposs(W) = πdatAttr (Rev ) und (ii)
∀t ∈ Qposs(W) : φt ≡ φdnf
t .
• Operator: Q ≡ πA (Q1 ), d.h. zu zeigen
Induktion über die Anzahl der Operatoren n von Q
?
(i) t ∈ πdatAttr (πA∪{all ETs} (R1ev )) ⇔ t ∈ πA (Q1 ),
• Induktionsanfang: n = 1 : Q = Ri , d.h. zu zeigen ?
gen(Φpa
W W
? (ii) ∀t ∈ πA (Q1 ) : 1 , t̂) ≡ φt̂ ,
(i) t ∈ πdatAttr ({t • (Xk = tid ) | t ∈ Ri }) ⇔ t ∈ Ri , ev ),
t̂∈πA∪{all ETs} (R1 t̂∈Q1 ,
W ? t̂[A]=t
(ii) ∀t ∈ Ri : gen(ETRi , t̂) ≡ (Xk = tid ), t̂[datAttr]=t
t̂∈{t•(Xk =tid )|t∈Ri },
Beweis:
t̂[datAttr]=t
Beweis: (i) t ∈ πdatAttr (πA∪{all ETs} (R1ev )) ⇔ t ∈ πA (R1ev ) ⇔ ∃t̂ :
IA
(i) πdatAttr ({t • (Xk = tid ) | t ∈ Ri }) = Ri X t̂[A] = t∧ t̂ ∈ R1ev ⇔ ∃t̂ : t̂[A] = t ∧ t̂ ∈ Q1 ⇔ t ∈ πA (Q1 )X
(ii) ∀t̂ ∈ {t • (Xk = tid ) | t ∈ Ri } : nach Konstruktion gibt
es eineindeutiges t ∈ Ri , sodass t̂ = t • (Xk = tid ) (A besteht nur aus Datenattributen, d.h. A = datAttr)
gen(Φpa
W
⇒ ∀t ∈ Ri :
W
gen(ETRi , t̂) ≡ (ii) ∀t ∈ πA (Q1 ) : 1 , t̂) =
ev ),
t̂∈πA∪{all ETs} (R1
t̂∈{t•(Xk =tid )|t∈Ri },
t̂[datAttr]=t
t̂[datAttr]=t 0 1
gen(ETRi , t • (Xk = tid )) ≡ (Xk = tid ) X C IA
gen(Φpa
W W
1 , ṫ)A =
B
@
ev ),
t̂∈πA∪{all ETs} (R1 ev ,
ṫ∈R1
10
http://dbis.informatik.tu-cottbus.de/ProQua/ t̂[A]=t ṫ[datAttr1 ]=t̂
69
Ereignismuster für die Verwaltung von komplexen Tupelereignissen in Probabilistischen Datenbanken
φt̂ X B. REFERENCES
W W
φt̂ =
ev ),
t̂∈πA∪{all ETs} (R1 t̂∈Q1 ,
t̂[A]=t t̂[A]=t [1] L. Antova, T. Jansen, C. Koch, and D. Olteanu. Fast
and simple relational processing of uncertain data. In
(da A ⊆ datAttr1 und Idempotenz gilt) ICDE, pages 983–992, 2008.
[2] D. Barbará, H. Garcia-Molina, and D. Porter. The
management of probabilistic data. IEEE Trans. on
• Operator: Q ≡ Q1 ./ Q2 , d.h. zu zeigen
Knowl. and Data Eng., 4:487–502, October 1992.
? [3] R. Fink, D. Olteanu, and S. Rath. Providing support
(i) t ∈ πdatAttr (R1ev ./ R2ev ) ⇔ t ∈ Q1 ./ Q2 ,
? for full relational algebra in probabilistic databases. In
gen(Φpa pa
W
(ii) ∀t ∈ Q1 ./ Q2 : 1 × Φ2 , t̂) ≡ φt1 ∧ φt2 ICDE, pages 315–326, 2011.
t̂∈R1 ev ./Rev ,
2
t̂[datAttr]=t
[4] N. Fuhr and T. Roelleke. A probabilistic relational
algebra for the integration of information retrieval and
Beweis:
database systems. ACM Trans. IS, 15(1):32–66, 1997.
[5] F. Henze, H. Lehmann, and W. Langer. CISAR - A
(i) t ∈ πdatAttr (R1ev ./jc R2ev ) ⇔ ∃t1 , t2 : t = t1 [datAttr1 ] •
Modular Database System as a Basis for Analysis and
t2 [datAttr2 ] ∧ jc(t1 , t2 ) = true ⇔ t1 ∈ πdatAttr1 (R1ev ) ∧ t2 ∈
IA Documentation of Spatial Information. In CAA, pages
πdatAttr2 (R2ev ) ⇔ t1 ∈ Q1 ∧ t2 ∈ Q2 ∧ jc(t1 , t2 ) = true ⇔ 228–233, 2007.
t1 • t2 ∈ Q1 ./jc Q2 ⇔ t ∈ Q1 ./ Q2 X [6] R. M. Karp, M. Luby, and N. Madras. Monte-carlo
approximation algorithms for enumeration problems.
(Verbundbed. jc(t1 , t2 ) (nat. Verbund) bezieht sich nur auf Journal of Algorithms, 10(3):429–448, 1989.
Datenattributen, da durch Konstruktion stets gilt
[7] C. Koch. MayBMS: A System for Managing Large
evAttr1 ∩ evAttr2 = ∅)
Uncertain and Probabilistic Databases. In Managing
and Mining Uncertain Data, ch. 6. Springer-Verlag,
gen(Φpa pa
W
(ii) ∀t ∈ Q1 ./ Q2 : 1 × Φ2 , t̂) =
t̂∈R1 ev ./Rev , 2008.
2
t̂[datAttr]=t [8] S. Lehrack, S. Saretz, and I. Schmitt. QSQL2: Query
gen(Φpa pa
W
1 × Φ2 , t 1 • t 2 ) = Language Support for Logic-Based Similarity
t1 ∈R1ev ,t ∈Rev ,
2 2
(t1 •t2 )[datAttr]=t
Conditions on Probabilistic Databases. In RCIS, 2012
W
gen(Φpa pa (to appear).
1 , t1 ) ∧ gen(Φ2 , t2 ) =
t1 ∈R1ev ,t ∈Rev ,
2 2 [9] S. Lehrack and I. Schmitt. QSQL: Incorporating
(t1 •t2 )[datAttr]=t
Logic-Based Retrieval Conditions into SQL. In
IA
gen(Φpa 2 , t2 ) = φt1 ∧ φt2 X
gen(Φpa
W W
1 , t1 )∧ DASFAA, pages 429–443, 2010.
ev ,
t1 ∈R1 ev ,
t2 ∈R2
t1 [datAttr1 ]=t t2 [datAttr2 ]=t
[10] S. Lehrack and I. Schmitt. A Probabilistic
Interpretation for a Geometric Similarity Measure. In
(da (t1 • t2 )[datAttr] = t ⇒ jc(t1 • t2 ) = true; konkate- ECSQARU, pages 749–760, 2011.
nierte Muster (erzeugt durch ×) drücken Konjunktion aus
[11] S. Lehrack and I. Schmitt. A Unifying Probability
und Φpai enthält nur Basisereignismuster von ti )
Measure for Logic-Based Similarity Conditions on
Uncertain Relational Data. In NTSS, pages 14–19,
• Operator: Q ≡ Q1 ∪ Q2 , d.h. zu zeigen
2011.
?
(i) t ∈ πdatAttr (R1ev ./f o R2ev ) ⇔ t ∈ Q1 ∪ Q2 , [12] D. Olteanu, J. Huang, and C. Koch. Approximate
? confidence computation in probabilistic databases. In
gen(Φpa pa
W
(ii) ∀t ∈ Q1 ∪ Q2 : 1 ∪ Φ2 , t̂) ≡ φt1 ∨ φt2 ICDE, pages 145–156, 2010.
ev ./f o Rev ,
t̂∈R1 2
t̂[datAttr]=t
[13] D. Olteanu and H. Wen. Ranking Query Answers in
Probabilistic Databases: Complexity and Efficient
Beweis:
Algorithms. In ICDE, 2012 (to appear).
[14] C. Ré and D. Suciu. Approximate lineage for
(i) t ∈ πdatAttr (R1ev ./f o R2ev ) ⇒ t ∈ πdatAttr1 (R1ev ) ∨ t ∈
IA probabilistic databases. PVLDB, 1(1):797–808, 2008.
πdatAttr2 (R2ev ) ⇔ t ∈ Q1 ∨ t2 ∈ Q2 ⇔ t ∈ Q1 ∪ Q2 [15] C. Ré and D. Suciu. Managing Probabilistic Data with
MystiQ: The Can-Do, the Could-Do, and the
(wegen der Def. eines vollen äußeren Verbundes und datAttr = Can’t-Do. In SUM, pages 5–18, 2008.
datAttr1 = datAttr2 )
[16] A. D. Sarma, O. Benjelloun, A. Y. Halevy, and
J. Widom. Working models for uncertain data. In
gen(Φpa pa
W
(ii) ∀t ∈ Q1 ∪ Q2 : 1 ∪ Φ2 , t̂) =
ev ./f o Rev ,
t̂∈R1
ICDE, page 7, 2006.
2
t̂[datAttr]=t [17] F. Schaefer and A. Schulze. OpenInfRA – Storing and
gen(Φpa pa
retrieving information in a heterogenous
W ` ´
1 , t̂) ∨ gen(Φ2 , t̂) =
ev ∨t̂∈Rev ,
t̂∈R1 2 documentation system. In CAA, 2012 (to appear).
t̂[datAttr]=t
IA
[18] D. Suciu, D. Olteanu, C. Ré, and C. Koch.
gen(Φpa 2 , t̂) = φt1 ∨ φt2 X
gen(Φpa
W W
1 , t̂) ∨ Probabilistic Databases. Synthesis Lectures on Data
ev ,
t̂∈R1 ev ,
t̂∈R2
t̂[datAttr]=t t̂[datAttr]=t
Management. Morgan & Claypool Publishers, 2011.
[19] J. Widom. Trio: A system for data, uncertainty, and
(wegen der Def. eines vollen äußeren Verbundes und da Φpa
lineage. In Managing and Mining Uncertain Data,
eine disjunktiv verknüpfte Klauselkombination beschreibt)
pages 113–148. Springer, 2008.
70
Flexible Indexierung für Ähnlichkeitssuche mit
logikbasierten Multi-Feature-Anfragen
Marcel Zierenberg
Brandenburgische Technische Universität Cottbus
Institut für Informatik, Informations- und Medientechnik
Lehrstuhl Datenbank- und Informationssysteme
Postfach 10 13 44, 03013 Cottbus, Deutschland
zieremar@tu-cottbus.de
KURZFASSUNG sich dabei um eine Menge von Werten, die bestimmte Eigenschaf-
Ähnlichkeitssuche beschäftigt sich mit dem Auffinden ähnlicher ten eines Objekts charakterisieren. Die Nutzung von Features, wel-
Objekte zu einem vorgegebenen Anfrageobjekt. Die logische Kom- che die gewünschte Semantik geeignet beschreiben, ist dabei ent-
bination verschiedener Features des Anfrageobjekts erhöht dabei scheidend für eine effektive Ähnlichkeitssuche.
die Ausdruckskraft von Anfragen und führt zu besseren Anfra- Die Verwendung mehrerer Features und einer geeigneten Kom-
geergebnissen. Um eine effiziente Suche zu ermöglichen ist eine bination dieser, erhöht die Ausdruckskraft von Anfragen und führt
Indexierung der Datenbankobjekte nötig. Neben einer möglichst somit zu besseren Anfrageergebnissen [20]. Multi-Feature-Anfra-
hohen Sucheffizienz spielt die Flexibilität des Indexierungsverfah- gen nutzen daher eine Vielzahl von Features für die Anfrageformu-
rens eine entscheidende Rolle. Das in dieser Arbeit vorgestell- lierung.
te Indexierungsverfahren ermöglicht eine effiziente Verarbeitung Logikbasierte Anfragemodelle, wie die Commuting Quantum
von Multi-Feature-Anfragen mit beliebigen logischen Kombinatio- Query Language (CQQL [14]) oder die Fuzzy-Logik [18], erlau-
nen und Gewichtungen anhand eines einzigen Index. Die Verwen- ben die Kombination mehrerer Features mithilfe boolescher Junk-
dung metrischer Indexierungsmethoden garantiert die Anwendbar- toren. Neben der verbesserten Ausdruckskraft von Anfragen wird
keit des Konzepts für ein großes Spektrum von Features und Di- hierdurch eine Verbindung von (unscharfen) Ähnlichkeitsbedin-
stanzfunktionen. gungen und (scharfen) relationalen Datenbankbedingungen ermög-
licht [13]. Eine Gewichtung der einzelnen Anfrageatome erlaubt
weiterhin eine dynamische Anpassung der Anfragen. Das Lernen
Kategorien und Themenbeschreibung dieser Gewichte anhand von Nutzerpräferenzen [19] ermöglicht ei-
H.3.1 [Information Storage and Retrieval]: Content Analysis and ne schrittweise Verfeinerung von Anfragen in Form von Relevance
Indexing — Indexing methods Feedback.
Der naive Ansatz zur Umsetzung einer Ähnlichkeitssuche ist der
lineare Scan der Datenbank, bei dem alle Distanzen zwischen An-
Allgemeine Begriffe frageobjekt und Datenbankobjekten ermittelt werden. Für Multi-
Algorithms, Performance Feature-Anfragen bedeutet dies, dass für jedes einzelne Feature die
Distanz zwischen Anfrage- und jedem Datenbankobjekt ermittelt
wird. Anschließend werden diese Teildistanzen für jedes Objekt
Schlüsselwörter zu einer Gesamtdistanz aggregiert. Da die Evaluierung von Di-
similarity search, retrieval, nearest neighbor search, metric inde- stanzfunktionen mitunter hohe CPU- und das Lesen der zugehö-
xing, complex query rigen Features hohe I/O-Kosten verursachen, ist der lineare Scan
für große Datenbanken mit einer Vielzahl von Objekten und Fea-
tures nicht praktikabel. Stattdessen sollten Indexierungsverfahren
1. EINLEITUNG genutzt werden, um eine effizientere Suche zu realisieren. Sie er-
Ähnlichkeitssuche [13] verfolgt das Ziel, in einer Menge von Ob- möglichen einen frühzeitigen Ausschluss von Objekten, die nicht
jekten genau die Objekte zu finden, die einem Anfrageobjekt am zur Ergebnismenge gehören können, und verringern somit die An-
ähnlichsten sind. Die (Un-)Ähnlichkeit der Objekte wird mithilfe zahl der nötigen Distanzberechnungen und I/O-Operationen.
von Distanz- oder Ähnlichkeitsmaßen1 anhand der aus den Objek- Eine besondere Anforderung an die logikbasierte Indexierung
ten extrahierten Features bestimmt. Bei einem Feature handelt es stellt die Flexibilität dar. Die logische Kombination der Anfrage
1
und auch die Anfragegewichte können sich im Rahmen von Re-
Im Folgenden gehen wir von Distanzmaßen aus. levance Feedback dynamisch verändern, dennoch sollte nur ein
einziger Index zur Verarbeitung beliebiger Anfragen benötigt wer-
den. Weiterhin sollte das Indexierungsverfahren unabhängig von
Art und Struktur der verwendeten Features und Distanzfunktionen
sein.
Hauptbeitrag dieser Arbeit ist die Entwicklung eines effizien-
ten Indexierungsverfahrens zur Verarbeitung logikbasierter Multi-
Feature-Anfragen am Beispiel von CQQL. Dazu werden spezifi-
24th GI-Workshop on Foundations of Databases (Grundlagen von Daten- sche Anforderungen an die logikbasierte Indexierung definiert und
banken), 29.05.2012 - 01.06.2012, Lübbenau, Germany. anhand dieser ein Indexierungsverfahren entworfen, das eine effizi-
Copyright is held by the author/owner(s).
71
Flexible Indexierung für Ähnlichkeitssuche mit logikbasierten Multi-Feature-Anfragen
Tabelle 1: Umwandlung boolescher Ausdrücke in arithmetische Tabelle 2: Einbettung von Gewichten in die Logik
Formeln in CQQL Ausdruck Einbettung
Ausdruck arithmetische Formel a ∧θ1 ,θ2 b (a ∨ ¬θ1 ) ∧ (b ∨ ¬θ2 )
¬a 1−a a ∨θ1 ,θ2 b (a ∧ θ1 ) ∨ (b ∧ θ2 )
a∧b a∗b
a∨b a+b−a∗b
aggregierter
(c ∧ a) ∨ (¬c ∧ b) a+b Ähnlichkeitswert sagg
i
agg(s1i , s2i , . . . , sm
i )
ente und gleichzeitig flexible Verarbeitung beliebiger logikbasierter
Multi-Feature-Anfragen und eine dynamische Gewichtung dieser ...
Ähnlichkeitswerte s1i s2i sm
ermöglicht. i
Die Arbeit ist wie folgt aufgebaut. Abschnitt 2 definiert die
t(dji )
grundlegenden Begriffe und die Notationen dieser Arbeit. In Ab-
schnitt 3 wird ein theoretisches Anwendungsbeispiel aus dem ... dm
Distanzen d1i d2i i
Bereich der Bildähnlichkeitssuche mithilfe logikbasierter Multi-
Feature-Anfragen präsentiert. Auf die speziellen Anforderungen an
δ j (q j , oji )
Indexierungsverfahren für derartige Anfragen wird in Abschnitt 4
detailliert eingegangen. Abschnitt 5 beschäftigt sich mit dem Stand ... qm om
Features q1 o1i q2 o2i i
der Technik zur Indexierung. Abschnitt 6 zeigt das Konzept eines
Indexierungsverfahrens und Kriterien zur Indexauswahl. Abschlie-
ßend wird in Abschnitt 7 eine Zusammenfassung der Arbeit gege- Featureextraktion
dynamisch
ben.
statisch
Objekte q oi
2. GRUNDLAGEN
Der folgende Abschnitt definiert die grundlegenden Begriffe und
Abbildung 1: Ablauf einer logikbasierten Multi-Feature-
die Notationen, die in dieser Arbeit verwendet werden. Anfrage
2.1 Nächste-Nachbarn-Suche
Ähnlichkeitsanfragen anhand von Distanzmaßen werden auch als [0,1] beschränkt ist: agg : [0, 1]m 7→ [0, 1]. Hierbei steht ein Ähn-
k-Nächste-Nachbarn-Suche (kNN) bezeichnet und geben die k Ob- lichkeitswert von 1 für die maximale Ähnlichkeit (Identität), wäh-
jekte aus einer Datenbank zurück, deren Distanz zum Anfrageob- rend ein Wert von 0 die größtmögliche Unähnlichkeit darstellt.
jekt am geringsten ist. Um eine Nächste-Nachbarn-Suche anhand logikbasierter Anfra-
Eine Ähnlichkeitsanfrage kNN(q) besteht aus einem Anfrage- gen zu realisieren, müssen alle Teildistanzen dji vor ihrer Aggre-
objekt q aus dem Universum U und bezieht sich auf eine Daten- gation in Ähnlichkeitswerte sji umgewandelt werden. Die nächs-
bank D = {o1 , o2 , . . . , on } ⊆ U von Objekten oi . Die Distanz ten Nachbarn sind nach der Aggregation dieser Ähnlichkeitswerte
(Unähnlichkeit) von Objekten wird mithilfe einer Distanzfunktion dann genau die Objekte, deren aggregierte Ähnlichkeitswerte sagg i
δ : U × U 7→ R≥0 anhand der aus den Objekten extrahierten Featu- bezüglich dem Anfrageobjekt am größten sind. Abbildung 1 ver-
res q 0 und o0i bestimmt. Das Ergebnis der Anfrage kNN(q) ist dann deutlicht den Suchablauf.
eine (nichtdeterministische) Menge K ⊆ D, für die gilt: |K| = k Beispiele für geeignete Funktionen zur Umwandlung von Di-
und ∀oi ∈ K, oj ∈ D \ K : δ(q, oi ) ≤ δ(q, oj ). stanzen in Ähnlichkeitswerte sind t(x) = e−x oder t(x) = 1 −
Bei einer kNN-Anfrage bestehend aus m Features werden die
x
δmax
, wobei δmax der maximale Distanzwert der genutzen Distanz-
Features eines Objekts mit q 0 = (q 1 , q 2 , . . . , q m ) beziehungsweise funktion darstellt [13].
o0i = (o1i , o2i , . . . , om
i ) bezeichnet. Jedem Feature wird eine eigene
Distanzfunktion δ j zugeordnet. Die Teildistanzen dji aller Features 2.4 Monotonie
werden durch eine Aggregationsfunktion agg : Rm ≥0 7→ R≥0 zu ei- Eine Aggregationsfunktion ist monoton steigend im i-ten Argu-
ner Gesamtdistanz dagg i vereinigt. Die k nächsten Nachbarn werden ment2 , wenn gilt:
dann anhand dieser Gesamtdistanz bestimmt.
xi ≤ y i =⇒ (1)
2.2 CQQL 1 i m 1
agg(x , . . . , x , . . . , x ) ≤ agg(x , . . . , y , . . . , x ) i m
Für die Evaluation einer auf CQQL basierenden Anfrage werden
boolesche Ausdrücke nach ihrer DNF-Normalisierung anhand von Das bedeutet, dass wenn alle Parameter außer xi festgelegt sind
festgelegten Transformationsregeln in arithmetische Formeln um- und xi vergrößert wird, kann das Ergebnis der Aggregationfunktion
gewandelt [14]. Tabelle 1 zeigt die in CQQL verwendeten Trans- nicht kleiner werden. Eine Aggregationsfunktion ist global mono-
formationsregeln. Ebenso ist eine Umsetzung der Gewichtung in ton steigend, wenn sie in allen m Argumenten monoton steigend
CQQL direkt innerhalb der booleschen Logik möglich. Dazu wer- ist. Ein Beispiel ist agg(x1 , x2 ) = x1 + x2 .
den Gewichte anhand der in Tabelle 2 gezeigten Transformations- Eine Aggregationsfunktion ist lokal monoton, wenn sie in einem
regeln in die Logik eingebettet. Teil ihrer m Argumente monoton steigend und in allen anderen
Argumenten monoton fallend ist. Ein Beispiel ist agg(x1 , x2 ) =
2.3 Logikbasierte kNN x1 − x2 .
Im Folgenden werden die in Abschnitt 2.2 beschriebenen arith-
metischen Formeln als Aggregationsfunktionen betrachtet, deren 2
Monoton fallend im i-ten Argument ist analog anhand des ≥-
Definitions- und Wertebereich auf Ähnlichkeitswerte im Intervall Operators definiert.
72
Flexible Indexierung für Ähnlichkeitssuche mit logikbasierten Multi-Feature-Anfragen
3. ANWENDUNGSBEISPIEL für die Bewertung der Sucheffizienz bildet der Vergleich mit dem
Das folgende Anwendungsbeispiel illustriert eine logikbasierte Suchaufwand des linearen Scans der Datenbank. Ein effizientes In-
Ähnlichkeitsanfrage anhand mehrerer Features. dexierungsverfahren sollte diesen linearen Aufwand stets unterbie-
Gegeben sei eine Datenbank mit Bildern verschiedener Pilze und ten. Es existieren zwar Verfahren, welche eine sehr hohe Suchef-
Informationen über deren Art und Giftigkeit. Ziel sei es nun anhand fizienz bieten, dabei aber einen nicht realisierbar hohen Speicher-
eines Anfragebildes eines gesammelten Pilzes, die Art des Pilzes verbrauch verursachen (vgl. [16]). Ein geeignetes Indexierungsver-
zu ermitteln und so zu bestimmen, ob der Pilz essbar ist. Die aus fahren sollte daher einen möglichst geringen Speicherverbrauch bei
den Bildern extrahierten Features umfassen dabei aus den Pixelda- gleichzeitig möglichst hoher Sucheffizienz aufweisen.
ten erzeugte Farb- (color ) und Formfeatures (shape) sowie aus den Skalierbarkeit: Ein inhärentes Problem der Ähnlichkeitssuche
Metadaten stammende Informationen, wie das Datum der Bildauf- ist der Fluch der hohen Dimensionen (FdhD [13, 5]). Dieser be-
nahme (date) oder die GPS-Koordinaten des Aufnahmeortes (gps). wirkt, dass die Performanz von Indexierungsverfahren mit steigen-
Zur Ermittlung der (Un-)Ähnlichkeit von Objekten werden jeweils der (intrinsischer) Dimensionalität3 eines Features abnimmt. In-
für das Feature geeignete Distanzfunktionen genutzt, beispielswei- dexierungsverfahren können den Suchaufwand des linearen Scans
se die Earth Mover’s Distanzfunktion [11] für Farbsignaturen oder dann nicht mehr signifikant unterbieten oder übersteigen ihn so-
verschiedene Minkowski-Distanzfunktion (Lp -Distanzfunktion). gar. Analog zur Erhöhung der Dimensionsanzahl bei einem Feature
Eine Anfrage, bestehend aus nur einem Feature, genügt nicht, lässt sich der FdhD auch bei Multi-Feature-Anfragen beobachten.
um eine korrekte Zuordnung der Pilzarten vorzunehmen. So kann Die Kombination von Features bewirkt hier ebenfalls eine Erhö-
zum Beispiel allein anhand der Farbfeatures eines Pilzes nicht hung der (intrinsischen) Dimensionalität. Ein geeignetes Indexie-
immer ein Rückschluss auf dessen Art gezogen werden, wenn rungsverfahren für Multi-Feature-Anfragen muss daher Möglich-
sich etwa die Form stark von der des Anfragebildes unterschei- keiten bieten, mit dem FdhD umzugehen und möglichst ohne Ef-
det. In diesem Fall ist eine UND-Verknüpfung der Features nötig: fizienzeinbußen skalierbar bezüglich der (intrinsischen) Dimensio-
shape ≈ ∧ color ≈ . Für den Fall, dass der Pilz des Anfragebildes nalität einzelner Features und der Kombination mehrerer Features
eine für seine Art sehr untypische Form aufweist (¬shape ≈ ) und sein.
daher anhand dieser nicht zugeordnet werden kann, soll stattdessen
allein anhand der GPS-Koordinaten des Bildes (gps ≈ ) auf dessen 5. STAND DER TECHNIK
Art geschlossen werden. Als zusätzliche relationale (scharfe) Be- Der folgende Abschnitt geht auf den Stand der Technik auf dem
dingung sollen nur Pilze betrachtet werden, die im selben Monat Gebiet der effizienten Verarbeitung von Multi-Feature-Anfragen
gesammelt wurden, wie der Pilz des Anfragebildes (date = ). Eine ein. Die existierenden Verfahren werden kurz vorgestellt und aus-
logische Verknüpfung der Features eines Anfragebildes sieht dann schnittsweise hinsichtlich der in Abschnitt 4 definierten Anforde-
wie folgt aus, wobei θ1 , θ2 für Parameter stehen, die eine unter- rungen bewertet. Wir beschränken uns dabei auf Verfahren für die
schiedliche Gewichtung der Teilbedingungen ermöglichen. exakte Suche der nächsten Nachbarn und gehen nicht auf Spezi-
date = ∧ ((shape ≈ ∧ color ≈ ) ∨θ1 ,θ2 (¬shape ≈ ∧ gps ≈ )) (2) alfälle wie die approximative Suche oder zusätzliche Anfragearten
wie getNext (Ranking-Anfrage) ein.
Nach einer DNF-Normalisierung und Transformation anhand
der in Abschnitt 2.2 beschriebenen Transformationsregeln, ergibt 5.1 Combiner-Algorithmen
sich aus dem booleschen Ausdruck (2) folgende arithmetische For- Combiner-Algorithmen [8] kombinieren die Ergebnisse mehrerer
mel: Ähnlichkeitsanfragen zu einem aggregierten Ergebnis. Für Multi-
Feature-Anfragen existiert dazu je Feature eine nach Distanz4 zum
(θ1 ∗ date = ∗ shape ≈ ∗ color ≈ ) + (3)
Anfrageobjekt sortierte Liste der Datenbankobjekte.
(θ2 ∗ date = ∗ (1 − shape ≈ ) ∗ gps ≈ ) Combiner-Algorithmen sind keine Indexierungsverfahren, son-
dern arbeiten auf einer darüber liegenden Ebene. Sie legen nicht
4. ANFORDERUNGEN fest, wie die sortierten Listen bereitgestellt werden. Um eine effi-
In [13] werden allgemeine Anforderungen an Indexierungsverfah- ziente Suche zu ermöglichen, sollte der Zugriff über Indexierungs-
ren im Bereich des Multimedia Retrievals definiert. Auf Grundlage verfahren mit Unterstützung von getNext-Anfragen umgesetzt wer-
dieser werden im Folgenden die spezifischen Anforderungen für In- den.
dexierungsverfahren zur effizienten Verarbeitung von logikbasier- Combiner-Algorithmen erlauben eine dynamische Auswahl der
ten Multi-Feature-Anfragen vorgestellt. verwendeten Features sowie unterschiedliche Aggregationsfunk-
Flexibilität: Multi-Feature-Anfragen setzen sich aus unter- tionen und Gewichtungen. Aufgrund der Forderung nach globaler
schiedlichen Features und Distanzfunktionen zusammen, das Inde- Monotonie kommen sie jedoch nicht für alle logikbasierten Multi-
xierungsverfahren muss daher unabhängig von Art und Struktur der Feature-Anfragen in Frage. Formel 3 ist beispielsweise nicht glo-
Features sein und ein breites Spektrum an Distanzfunktionen unter- bal monoton steigend, da eine Erhöhung des Ähnlichkeitswerts
stützen. Die Anzahl der unterschiedlichen zur Verfügung stehenden shape ≈ nicht in jedem Fall zu einer Erhöhung des aggregierten
Features ist potentiell hoch. Das Indexierungsverfahren muss da- Ähnlichkeitswerts führt. Ein weiterer Nachteil ist die geforderte
her mit einer großen Menge von Features umgehen können, auch Bereitstellung der sortierten Listen, da Indexstrukturen mit effizien-
wenn nur eine Teilmenge dieser für eine Anfrage genutzt wird. Je ten getNext-Anfragen nicht immer zur Verfügung stehen und sich
nach Anfrage können sich die genutzten Features unterscheiden. durch die getrennte Verwaltung jedes einzelnen Index ein Mehrauf-
Ebenso sind unterschiedliche logische Kombinationen und unter- wand ergibt.
schiedliche Gewichtungen der selben Features möglich. Das Inde- 3
Die Dimensionalität eines Features ergibt sich aus der Anzahl
xierungsverfahren darf daher nicht nur auf eine logische Kombina- seiner Featurewerte. Die intrisische Dimensionalität lässt sich bei-
tion zugeschnitten werden, sondern muss mit beliebigen logischen spielsweise anhand der paarweisen Distanzen zwischen den Fea-
Kombinationen und Gewichtungen umgehen können. turewerten der Datenbankobjekte abschätzen und ist dann definiert
Sucheffizienz: Die Anzahl der nötigen Berechnungen der Di- als ρ = µ2 /2 ∗ σ 2 [1].
4
stanzfunktion und die Anzahl von I/O-Operationen (Seitenzugriffe) Combiner-Algorithmen sind ohne größere Anpassungen auch für
dienen als Effizienzmaß für Indexierungsverfahren. Die Grundlage Ähnlichkeitswerte nutzbar.
73
Flexible Indexierung für Ähnlichkeitssuche mit logikbasierten Multi-Feature-Anfragen
5.2 Räumliche Indexierung textuelle Daten) oder die nicht die euklidsche Distanzfunktion ver-
Räumliche Indexierungsverfahren gehen davon aus, dass die Fea- wenden. Sie erfordern lediglich das Vorliegen einer Metrik.
tures in Form von Vektoren vorliegen und die euklidsche Distanz- Eine Metrik δ ist eine Distanzfunktion, für die folgenden Eigen-
funktion (L2 -Distanzfunktion) zur Berechnung der Unähnlichkeit schaften für alle oi , oj , ok ∈ U gelten: δ(oi , oj ) > 0 für oi 6= oj
zwischen den Featurevektoren verwendet wird. Da diese Beschrän- (Positivität), δ(oi , oi ) = 0 (Selbstidentität), δ(oi , oj ) = δ(oj , oi )
kung im Widerspruch zur Flexibilität steht, scheidet die Verwen- (Symmetrie) und δ(oi , ok ) ≤ δ(oi , oj ) + δ(oj , ok ) (Dreiecksun-
dung räumlicher Indexierungsverfahren aus. Dennoch soll im Fol- gleichung).
genden auf sie eingegangen werden, da ihre Konzepte teilweise Der Ausschluss von Objekten wird mithilfe der Dreiecksunglei-
übertragbar sind. chung erreicht, die es ermöglicht, untere und obere Grenzen be-
Hierarchische Verfahren, wie zum Beispiel der R-Baum [9], be- züglich der Distanz von Anfrageobjekt und Datenbankobjekten zu
schreiben Mengen von Objekten durch geometrische Regionen bestimmen. Die Grenzen können effizient anhand von vorberechne-
(Cluster). Aufgrund des Fluchs der hohen Dimensionen sinkt die ten Distanzen zu einem oder mehreren Referenzobjekten5 ermittelt
Sucheffizienz dieser Verfahren jedoch bereits ab einer Dimensi- werden. Die untere und die obere Grenze für die Distanz δ(q, oi )
onsanzahl der Featurevektoren von 10-20 unter die des linearen und ein Referenzobjekt p sind wie folgt definiert:
Scans [13]. Im Folgenden stellen wir daher lediglich den nicht- |δ(q, p) − δ(p, oi )| ≤ δ(q, oi ) ≤ δ(q, p) + δ(p, oi ) (4)
hierarchischen Ansatz der VA-Datei vor. | {z } | {z }
δlb (q,oi ) δub (q,oi )
5.2.1 VA-Datei Analog zu räumlichen Indexierungsverfahren lässt sich zwischen
Die Vektor-Approximations-Datei (VA-Datei) [17] ist ein nicht- hierarchischen (M-Baum [7]) und nicht-hierarchischen (AESA [16])
hierarchisches Verfahren und akzeptiert den FdhD in dem Sinne, metrischen Indexierungsverfahren unterscheiden. Eine umfassen-
dass sie statt Cluster zu bilden, direkt einen linearen Scan der Da- de Übersicht metrischer Indexierungsverfahren bietet zum Beispiel
tenbank durchführt. Sie setzt dazu einen Filter-Refinement-Ansatz das Lehrbuch von Samet [12].
auf Basis kompakter Bitsignaturen ein. Ziel dieses Ansatzes ist es Der Großteil der existierenden metrischen Indexierungsverfah-
in der Filterphase, anhand der durch Bitsignaturen approximierten ren ist auf die Indexierung anhand einer einzigen Distanzfunk-
Objekte, Distanzgrenzen zu ermitteln und mithilfe dieser möglichst tion ausgelegt. Die Forderung nach der Unterstützung beliebiger
viele Objekte von der weiteren Suche auszuschließen. Die exakte logischer Kombinationen kann daher nicht erfüllt werden. Multi-
Distanz muss in der Verfeinerungsphase dann lediglich für die Ob- Metrische Indexierungsverfahren [4] ermöglichen die Indexierung
jekte berechnet werden, die in der Filterphase nicht ausgeschlossen auf Grundlage einer dynamischen Kombination mehrerer Distanz-
werden konnten. funktionen zu einer Aggregationsfunktion. Sie unterstützen da-
Die Sucheffizienz des Verfahrens ergibt sich daraus, dass die Bit- durch mit einem einzigen Index unterschiedliche Gewichtungen
signaturen in der Filterphase sequentiell aus Signaturdateien ge- der gleichen Aggregationsfunktion. Da es sich bei der Aggregati-
lesen werden und durch den Ausschluss von Objekten die An- onsfunktion jedoch um eine Metrik handeln muss, ist diese auf die
zahl teurer, wahlfreier Zugriffe in der Verfeinerungsphase verrin- gewichtete Summe metrischer Distanzfunktion beschränkt. Für lo-
gert wird. Für Multi-Feature-Anfragen ist eine Anpassung der VA- gikbasierte Multi-Feature-Anfragen sind diese Verfahren daher nur
Datei nötig. eingeschränkt anwendbar.
5.2.2 GeVAS 5.3.1 M2 -Baum
GeVAS [2] ist eine Erweiterung der VA-Datei für Multi-Feature- Der M2 -Baum [6] ist eine Erweiterung des M-Baums für Multi-
Anfragen und erlaubt eine dynamische Auswahl der in der An- Feature-Anfragen. Statt die Distanzen bezüglich aller Features be-
frage verwendeten Features aus einer großen Menge vorhandener reits bei der Indexierung zu aggregierten Distanzen zusammen-
Features. Für jedes Feature wird dazu eine separate VA-Datei er- zufassen, werden die Distanzgrenzen bei der Anfrage dynamisch
zeugt, wobei die Reihenfolge der Objekte in allen Signaturdateien für jedes einzelne Feature abgeschätzt. Diese Grenzen werden an-
gleich ist. Bei einer Multi-Feature-Anfrage werden nun nur die Si- schließend in Ähnlichkeitswerte umgewandelt und zu aggregierten
gnaturdateien der Features parallel abgearbeitet, die tatsächlich in Ähnlichkeitsgrenzen kombiniert (vergleiche aggregierte Distanz-
der Anfrage eingesetzt werden. Für jedes einzelne Feature eines grenzen bei GeVAS). Der Vorteil bei diesem Vorgehen ist, dass die
Objekts werden Distanzgrenzen ermittelt und dynamisch zu ag- metrischen Eigenschaften in diesem Fall nicht für die Aggregati-
gregierten Distanzgrenzen zusammengefasst. Der Ausschluss von onsfunktion gelten müssen, sondern nur für jede zugrundeliegende
Objekten geschieht in der Filterphase anhand dieser aggregierten Distanzfunktionen.
Distanzgrenzen. Voraussetzung für die korrekte Aggregation von Der M2 -Baum verlangt die lokale Monotonie der Aggregati-
Distanzgrenzen ist, dass die Aggregationsfunktion global mono- onsfunktion. Die arithmetische Formel 3 erfüllt jedoch auch die-
ton steigend ist. Diese Forderung lässt sich jedoch so abschwä- se Eigenschaft nicht. Analog zu GeVAS lässt sich die Monotonie-
chen, dass beliebige, logikbasierte Multi-Feature-Anfragen ermög- Eigenschaft aber auch hier so abschwächen, dass beliebige, lo-
licht werden (siehe Abschnitt 6.1). gikbasierte Multi-Feature-Anfragen möglich werden (siehe Ab-
Liegen die einzelnen VA-Dateien auf der gleichen Festplatte schnitt 6.1). Der M2 -Baum erlaubt somit beliebige, logische Kom-
(HDD) ergeben sich für GeVAS Effizienzprobleme beim Lesen der binationen und eine dynamische Auswahl der tatsächlich genutzten
Daten vom Sekundärspeicher, da statt jede VA-Datei einzeln se- Features. Da es sich beim M2 -Baum um ein hierarchisches Verfah-
quentiell zu lesen, der Lesekopf der Festplatte zwischen den ver- ren handelt, nimmt die Sucheffizienz jedoch aufgrund des Fluchs
schiedenen VA-Dateien hin und her springen muss [13]. der hohen Dimensionen mit steigender intrinsischer Dimensionali-
tät der Features stärker ab, als bei nicht-hierarchischen Verfahren
5.3 Metrische Indexierung [13].
Metrische Indexierungsverfahren stellen keine Anforderungen an
die Art der Featuredaten. Im Gegensatz zu räumlichen Indexie- 5
Für Referenzobjekte existieren unterschiedliche Benennungen in
rungsverfahren erlauben sie daher auch die Indexierung von Fea- der Literatur, wie zum Beispiel Routing-, Focus-, Vantage- oder
tures bei denen es sich nicht um Vektoren handelt (zum Beispiel Pivot-Objekt, die das gleiche Konzept widerspiegeln.
74
Flexible Indexierung für Ähnlichkeitssuche mit logikbasierten Multi-Feature-Anfragen
6. KONZEPT Für die Auswahl geeigneter Referenzobjekte stehen verschiede-
Dieser Abschnitt beschreibt das Konzept eines Indexierungsver- ne Verfahren zur Verfügung, darunter die zufällige Auswahl oder
fahrens zur effizienten Verarbeitung logikbasierter Multi-Feature- die inkrementelle Auswahl entfernter Objekte [3]. Um möglichst
Anfragen. Dazu wird zuerst auf die Berechnung aggregierter Di- enge Grenzen zu garantieren, nutzt jedes Datenbankobjekt eine dy-
stanzgrenzen eingegangen. Die Übertragung des GeVAS-Ansatzes namisch ausgewählte Teilmenge seiner nächsten Referenzobjekte.
auf den metrischen Raum stellt den Kern des Konzepts dar. Wir Bei der Indexerzeugung werden für einen repräsentativen Aus-
wählen GeVAS aufgrund seiner Flexibilität im Bezug auf Featu- schnitt der Datenbank die paarweisen Distanzen je Feature be-
reanzahl und -auswahl sowie aufgrund seiner besseren Skalierbar- stimmt. Ein Equi-Height-Histogramm [10] dieser Distanzen wird
keit im Bezug auf die Dimensionalität als hierarchische Verfahren. genutzt um Distanzintervalle für jedes Feature zu berechnen. Die-
Zusätzliche Anpassungen, wie die direkte Berechnung exakter Di- se Distanzintervalle dienen dann der Quantisierung der Distanzen
stanzen für eine Teilmenge der Features, dienen dazu, die Sucheffi- zwischen Referenzobjekten und Datenbankobjekten. Statt also zur
zienz des entworfenen Verfahrens bei steigender Featureanzahl zu Indexierung exakte Distanzen zu speichern, werden die exakten
verbessern. Distanzen durch nummerierte Distanzintervalle repräsentiert (vgl.
[4]). Die kompakte Darstellung dieser Nummern durch Bitsigna-
6.1 Aggregierte Distanzgrenzen turen verringert den Speicherverbrauch und erhöht gleichzeitig die
Sucheffizienz in der Filterphase, da weniger Daten von der Fest-
Die korrekte Berechnung aggregierter Distanzgrenzen6 hängt von
platte gelesen werden müssen. Der Approximationsfehler der Di-
der Monotonie der Aggregationsfunktion ab. Zur Berechnung der
stanzgrenzen steigt jedoch durch die Verwendung von Distanzinter-
oberen Distanzgrenze einer global monoton steigenden Aggregati-
vallen. Die Festlegung der Anzahl an Bits pro Signatur entspricht
onsfunktion müssen die oberen Grenzen aller Teildistanzen in die
daher der Steuerung der Genauigkeit der Distanzintervalle.
Aggregationsfunktion eingesetzt werden [2].
Für die obere Distanzgrenze lokal monotoner Aggregationsfunk-
tionen kommt es auf die Monotonie der einzelnen Argumente an.
6.3 Lesefenster
Bei monoton steigenden Argumenten muss die obere Distanzgren- Dem in Abschnitt 5.2.2 erläuterten GeVAS-Problem der sinkenden
ze und bei monoton fallenden Argumenten die untere Distanzgren- Sucheffizienz bei der Ablage aller Signaturedateien auf einer Fest-
ze eingesetzt werden [6]. platte begegnen wir mit der Einführung eines Lesefensters. Statt für
Die arithmetische Formel (3) ist nicht lokal monoton. Jedoch jedes Objekt parallel auf alle genutzten Signaturdateien zuzugrei-
liegt eine Monotonie vor, für die wir den Begriff fixe Monotonie fen, wird jede Signaturdatei einzeln in Größe des Lesefensters aus-
einführen. Hierbei hängt die Monotonie eines Arguments der Ag- gelesen. Der Vorteil dabei ist, dass längere sequentielle Lesephasen
gregationsfunktion von den Wertebelegungen der anderen Argu- entstehen und weniger Sprünge zwischen den Signaturdateien statt-
mente ab. Eine fix monotone Funktion kann also in einem Argu- finden. Allerdings müssen die gelesenen Daten jeweils solange im
ment für bestimmte Wertebelegungen monoton fallend und für alle Hauptspeicher gehalten werden, bis alle genutzten Signaturdateien
andere Wertebelegungen monoton steigend sein. In Formel (3) er- in Größe des Lesefensters abgearbeitet wurden.
gibt sich die fixe Monotonie daraus, dass das Argument shape≈
in einem Teil der Formel negiert und in einem anderen Teil nicht- 6.4 Begrenzter Hauptspeicher
negiert auftritt. Ein Problem des Filter-Refinements ist, dass alle Objekte, die in der
Die aggregierte obere Distanzgrenze für fix monotone Funktio- Filterphase nicht ausgeschlossen werden können, bis zur Verfeine-
nen ergibt sich durch das Einsetzen aller möglichen Kombinationen rungsphase in einer nach unterer Distanzgrenze sortierten Kandida-
von oberen und unteren Grenzen in die Aggregationsfunktion und tenliste gehalten werden müssen. Für große Datenbanken kann es
einer Auswahl des maximalen Ergebnisses. jedoch vorkommen, dass der vorhandene Hauptspeicher dazu nicht
ausreicht. Ein weiteres Lesefenster ermöglicht daher die Einhal-
C = d1lb , d1ub × · · · × {dm m
lb , dub } (5) tung von festen Grenzen für die Hauptspeichernutzung.
dagg
ub = max agg(c) (6) Nach einem in [15] vorgeschlagenen Prinzip werden Filter- und
c∈C
Verfeinerungsphase verschränkt. Die Filterphase wird gestoppt, so-
Wie zuvor erwähnt, lässt sich die Berechnung der aggregierten bald eine festgelegte Speichergrenze erreicht ist. In der nun folgen-
Grenzen in GeVAS und M2 -Baum entsprechend anpassen. den Verfeinerungsphase wird die Kandidatenliste abgearbeitet, bis
Es kann gezeigt werden, dass alle mithilfe von CQQL erzeugten k vorläufige nächste Nachbarn ermittelt wurden. Damit diese k Ob-
arithmetischen Formeln eine der beschriebenen Monotonien erfül- jekte nicht verloren gehen, werden sie abschließend in die zuvor
len. Die Monotonie kann dabei allein anhand der Syntax der An- geleerte Kandidatenliste eingefügt, bevor die Filterphase wieder an
frage bestimmt werden. Auf die Darstellung der Beweise dieser Ei- der abgebrochenen Stelle fortgesetzt wird. Der Effizienznachteil
genschaften wird an dieser Stelle aus Platzgründen verzichtet. dieses Vorgehens ist, dass das sequentielle Lesen der Filterphase
regelmäßig unterbrochen wird und durch einen wahlfreien Zugriff
6.2 Metrisches Filter-Refinement wieder fortgesetzt werden muss.
Im Gegensatz zu GeVAS werden die Signaturen beim metrischen
Filter-Refinement nicht anhand der Featuredaten der Datenbankob- 6.5 Steigende Featureanzahl
jekte ermittelt, sondern ergeben sich aus den Distanzen der Daten- Steigt die Anzahl der in der Anfrage genutzten Features, steigt der
bankobjekte zu Referenzobjekten. Jede Signaturdatei besteht daher Approximationsfehler bei der Abschätzung der aggregierten Ähn-
aus den Bitsignaturen der Distanzen jedes Datenbankobjekts zu ei- lichkeitsgrenzen, da alle Teildistanzen in Form von Distanzgrenzen
ner Menge von Referenzobjekten. Die Reihenfolge der Datenban- eingehen. Für Anfragen mit vielen Features bedeutet dies, dass sich
kobjekte ist dabei in allen Signaturdateien gleich. Die kNN-Suche die Anzahl der Objekte, die anhand dieser Grenzen ausgeschlossen
verläuft analog zu GeVAS, wobei der Ausschluss von Objekten je- werden können, verringert und die Sucheffizienz des Verfahrens
doch anhand aggregierter Ähnlichkeitsgrenzen stattfindet. sinkt.
Um diesem Problem zu begegnen, werden bei steigender Featu-
6
Die Beschreibungen lassen sich analog auf Ähnlichkeitsgrenzen reanzahl, statt Distanzgrenzen für jedes einzelne Feature zu nut-
anwenden. zen, nur noch für eine Teilmenge der verwendeten Features Di-
75
Flexible Indexierung für Ähnlichkeitssuche mit logikbasierten Multi-Feature-Anfragen
stanzgrenzen abgeschätzt. Für alle anderen Features werden direkt Unterstützung von Multi-Objekt-Anfragen sowie von Distanzfunk-
die exakten Distanzen berechnet. Aus der exakten Berechnung von tionen die keine Metriken sind, stellen weitere Herausforderungen
Teildistanzen ergibt sich ein Mehraufwand gegenüber der Nutzung dar.
von Distanzgrenzen. Dieser Mehraufwand kann jedoch ausgegli-
chen werden, wenn durch diese exakte Berechnung genügend zu- Literatur
sätzliche Objekte ausgeschlossen werden können. [1] Stanislav Barton u. a. “Estimating the indexability of multimedia de-
Dieses Prinzip lässt sich in der Filterphase anwenden um mehr scriptors for similarity searching”. In: Adaptivity, Personalization
Objekte auszuschließen. Analog zum sequentiellen Lesen der Si- and Fusion of Heterogeneous Information. RIAO ’10. 2010, S. 84–
gnaturdateien müssen die Features in diesem Fall ebenfalls sequen- 87.
tiell gelesen werden, um die Sucheffizienz in der Filterphase zu ga- [2] Klemens Böhm u. a. “Fast Evaluation Techniques for Complex Simi-
larity Queries”. In: Proceedings of the 27th International Conference
rantieren. on Very Large Data Bases. VLDB ’01. 2001, S. 211–220.
Das gleiche Prinzip kann in der Verfeinerungsphase genutzt wer- [3] Benjamin Bustos, Gonzalo Navarro und Edgar Chávez. “Pivot selec-
den, um die Suche früher und mit weniger exakten Distanzberech- tion techniques for proximity searching in metric spaces”. In: Pattern
nungen abbrechen zu können. Statt für ein Objekt in der Verfei- Recogn. Lett. 24 (14 2003), S. 2357–2366.
nerungsphase direkt alle Teildistanzen auf einmal exakt zu berech- [4] Benjamin Bustos und Tomáš Skopal. “Dynamic similarity search in
nen und zu aggregieren, wird schrittweise vorgegangen. Jedes Mal, multi-metric spaces”. In: Proceedings of the 8th ACM internatio-
wenn ein Objekt in der Verfeinerungsphase am Anfang der Kan- nal workshop on Multimedia information retrieval. MIR ’06. 2006,
S. 137–146.
didatenliste steht, für das noch nicht alle Teildistanzen berechnet
[5] Edgar Chávez u. a. “Searching in metric spaces”. In: ACM Comput.
wurden, wird eine Teildistanz berechnet und das Objekt anhand Surv. 33 (3 2001), S. 273–321.
der neuen (genaueren) aggregierten Ähnlichkeitsgrenze wieder in
[6] Paolo Ciaccia und Marco Patella. “The M2 -tree: Processing Com-
die Kandidatenliste einsortiert. Ein Vorteil ergibt sich dann, wenn plex Multi-Feature Queries with Just One Index”. In: DELOS Work-
der Ausschluss eines Objekts von nur wenigen Teildistanzen ab- shop: Information Seeking, Searching and Querying in Digital Li-
hängt. Bei einer geeigneten Reihenfolge der berechneten Teildi- braries. 2000.
stanzen müssen dann nur diese diskriminierenden Distanzen ex- [7] Paolo Ciaccia, Marco Patella und Pavel Zezula. “M-tree: An Effi-
cient Access Method for Similarity Search in Metric Spaces”. In:
akt berechnet werden, die Berechnung aller weiteren Teildistanzen VLDB’97, Proceedings of 23rd International Conference on Very
kann gespart werden. Large Data Bases, August 25-29, 1997, Athens, Greece. Hrsg. von
Die Auswahl der Features, für die exakte Distanzen berechnet Matthias Jarke u. a. 1997, S. 426–435.
werden, erfolgt statisch (zur Indexierungszeit) oder dynamisch (zur [8] Ronald Fagin, Amnon Lotem und Moni Naor. “Optimal aggrega-
Anfragezeit) nach unterschiedlichen Kriterien, wie der (intrinsi- tion algorithms for middleware”. In: Proceedings of the twentieth
schen) Dimensionalität der Features oder der Berechnungsdauer ACM SIGMOD-SIGACT-SIGART symposium on Principles of data-
base systems. PODS ’01. 2001, S. 102–113.
der zugehörigen Distanzfunktion.
[9] Antonin Guttman. “R-trees: a dynamic index structure for spatial
searching”. In: Proceedings of the 1984 ACM SIGMOD internatio-
6.6 Indexauswahl nal conference on Management of data. SIGMOD ’84. 1984, S. 47–
Die Sucheffizienz des beschriebenen Verfahrens hängt besonders 57.
von der Anzahl der verwendeten Features und der daraus resul- [10] Yannis Ioannidis. “The history of histograms (abridged)”. In: Pro-
tierenden (intrinsischen) Dimensionalität ab. Hierarchische Verfah- ceedings of the 29th international conference on Very large data ba-
ses - Volume 29. VLDB ’03. 2003, S. 19–30.
ren können bei niedriger (intrinsischer) Dimensionalität, aufgrund
[11] Yossi Rubner, Carlo Tomasi und Leonidas J. Guibas. “The Earth Mo-
der hohen Lokalität der Daten, größere Mengen von Objekten auf ver’s Distance as a Metric for Image Retrieval”. In: Int. J. Comput.
einmal ausschließen und dadurch effizienter als nicht-hierarchische Vision 40 (2 2000), S. 99–121.
Verfahren sein. Ein Vergleich des entworfenen Konzepts mit dem [12] Hanan Samet. Foundations of Multidimensional and Metric Data
angepassten M2 -Baum dient daher zur Bestimmung der Schnitt- Structures (The Morgan Kaufmann Series in Computer Graphics and
punkte bezüglich der Sucheffizienz beider Ansätze. Eine Selektion Geometric Modeling). 2005.
des effizienteren Index kann dann entweder bereits bei der Index- [13] Ingo Schmitt. Ähnlichkeitssuche in Multimedia-Datenbanken - Re-
erzeugung oder erst zur Anfragezeit anhand der in der Anfrage ge- trieval, Suchalgorithmen und Anfragebehandlung. 2005.
nutzten Features und ihrer (intrinsischen) Dimensionalität stattfin- [14] Ingo Schmitt. “QQL: A DB&IR Query Language”. In: The VLDB
den. Überschreitet die (intrinsische) Dimensionalität eine bestimm- Journal 17 (1 2008), S. 39–56.
te Grenze, ist unter Umständen ein Rückfall auf den linearen Scan [15] Ingo Schmitt und Sören Balko. “Filter ranking in high-dimensional
space”. In: Data Knowl. Eng. 56 (3 2006), S. 245–286.
sinnvoll.
[16] Enrique Vidal. “An algorithm for finding nearest neighbours in (ap-
proximately) constant average time”. In: Pattern Recognition Letters
7. ZUSAMMENFASSUNG 4.3 (1986), S. 145 –157.
In dieser Arbeit wurde ein Konzept zur flexiblen Indexierung für [17] Roger Weber, Hans-Jörg Schek und Stephen Blott. “A Quantitative
Analysis and Performance Study for Similarity-Search Methods in
Ähnlichkeitssuche mit logikbasierten Multi-Feature-Anfragen vor- High-Dimensional Spaces”. In: Proceedings of the 24rd Internatio-
gestellt. Dazu wurden die spezifischen Anforderungen an geeignete nal Conference on Very Large Data Bases. VLDB ’98. 1998, S. 194–
Indexierungsverfahren definiert und der Stand der Technik im Be- 205.
zug auf diese Anforderungen analysiert. Das entwickelte Konzept [18] Lofti A. Zadeh. “Fuzzy Logic”. In: Computer 21 (1988), S. 83–93.
zur Indexierung basiert auf einer Übertragung und Anpassung des [19] David Zellhöfer und Ingo Schmitt. “A preference-based approach
GeVAS-Ansatzes auf den metrischen Raum. Der Index ist dadurch for interactive weight learning: learning weights within a logic-
unabhängig von der genutzten logischen Kombination, der Art und based query language”. In: Distributed and Parallel Databases 27
(1 2010), S. 31–51.
Struktur der verwendeten Features und unterstützt eine Vielzahl
[20] David Zellhöfer und Ingo Schmitt. “Approaching Multimedia Retrie-
unterschiedlicher Features und Distanzfunktionen zur Berechnung val from a Polyrepresentative Perspective”. In: Adaptive Multimedia
der Unähnlichkeit. Retrieval. Context, Exploration, and Fusion. Hrsg. von Marcin De-
Als zukünftige Arbeiten verbleiben Teile der Implementierung, tyniecki u. a. Bd. 6817. Lecture Notes in Computer Science. 2011,
die Bestimmung der optimalen Indexparameter und die Evaluati- S. 46–60.
on des Konzeptes anhand von synthetischen und realen Daten. Die
76
Challenges in Finding an Appropriate Multi-Dimensional
Index Structure with Respect to Specific Use Cases
Alexander Grebhahn David Broneske Martin Schäler
Institute of Technical and Institute of Technical and Institute of Technical and
Business Information Systems Business Information Systems Business Information Systems
University of Magdeburg University of Magdeburg University of Magdeburg
grebhahn@st.ovgu.de dbronesk@st.ovgu.de schaeler@ovgu.de
Reimar Schröter Veit Köppen Gunter Saake
Institute of Technical and Center for Digital Engineering Institute of Technical and
Business Information Systems University of Magdeburg Business Information Systems
University of Magdeburg vkoeppen@ovgu.de University of Magdeburg
rschroet@st.ovgu.de saake@ovgu.de
ABSTRACT It is possible to extract feature vectors from an item to man-
In recent years, index structures for managing multi-dimen- age the data in a compressed and meaningful way. For man-
sional data became increasingly important. Due to hetero- aging these feature vectors, multi-dimensional index struc-
geneous systems and specific use cases, it is a complex chal- tures can be used. In general, the question arises, which
lenge to find an appropriate index structure for specific prob- index structure supports managing data best. Throughout
lems, such as finding similar fingerprints or micro traces in a this paper, index structure performance describes suitability
database. One aspect that should be considered in general is with respect to a specific use case. However, we analyze core
the dimensionality and the related curse of dimensionality. aspects that have to be considered, if trying to answer this
However, dimensionality of data is just one component for a specific use case. In order to achieve a reconstructible
that have to be considered. To address the challenges of and valid comparison, we present the idea of a framework
finding the appropriate index, we motivate the necessity of that allows the comparison of different index structures in a
a framework to evaluate indexes for specific use cases. Fur- homogeneous test environment.
thermore, we discuss core components of a framework that This paper is organized as follows: In Section 2, we give
supports users in finding the most appropriate index struc- a short overview of basic components that have to be con-
ture for their use case. sidered for evaluating the performance of index structures.
Within Section 3, we give an overview of additional chal-
lenges, which have to be handled by using index structures
Keywords in a specific use case. Finally, in Section 4, we present core
index structures, evaluation, multi-dimensional data components that a framework needs for quantitatively eval-
uation of multi-dimensional index structures with respect to
different use cases.
1. INTRODUCTION
In the last years, data storage and management in com- 2. BASIC CHALLENGES
puter-aided systems became more advanced, because of an
increasing amount of unstructured data being stored. For Querying multi-dimensional data in an efficient way is
example, in multimedia databases images or videos are stored a complex challenge. Within the last decades, new index
and analyzed to find similar data items. A special use case structures are proposed and existing once are improved to
is the Digi-Dak Database Project1 , where multi-dimensional solve this challenge. Regarding a specific use case, it is not
feature vectors of fingerprints and micro traces are stored in suitable to consider an index structure in isolation. Addi-
a database. To manage these data items, methods are re- tionally data properties, used query types, and underlying
quired to handle unstructured data in an appropriate way. distance metrics have to be taken into account. In this sec-
tion, we give a short overview of these four basic challenges.
1
https://omen.cs.uni-magdeburg.de/digi-dak
2.1 Data Properties
Characteristics of data cause main challenges of querying
data within a database system. For instance, data dimen-
sionality has to be considered, because existing index struc-
tures are generally effected by the curse of dimensionality
[7, 23]. As a result, index structures, that are suitable for
a small number of dimensions are not necessarily suitable
for a larger amount of dimensions. An additional important
24th GI-Workshop on Foundations of Databases (Grundlagen von Daten-
banken), 29.05.2012 - 01.06.2012, Lübbenau, Germany. property is the data distribution, because some index struc-
Copyright is held by the author/owner(s). tures are more practicable for clustered data than others.
77
Challenges in Finding an Appropriate Multi-Dimensional Index Structure with Respect to Specific Use Cases
Furthermore, value domain and the type of the data has to R1 R4
be considered. R7
2.2 Query Types R5 R6
R2
Based on the work of Böhm et al. [8], query types can be R8
categorized into two groups: -similarity queries and Nearest- R3
Neighbor-similarity (NN-similarity) queries. The former de- R10
A R9 B
scribes a query, resulting in a set of data points being situ- R11
C
ated in a defined -distance to the query point, whereas the
latter results in a data point being the nearest item to the R12
query point. Describing these two groups, the -similarity
and NN-similarity has to be defined.
Figure 1: R-Tree with overlapping MBRs.
Definition: -similarity Query.
Two data points p1 and p2 are -similar if and only if
d(p1 , p2 ) ≤ . The function d defines a similarity measure
2.4 Index Structures
for two points. In literature, similarity measures are of- Since we aim at providing a comprehensive set of indexes,
ten replaced by distance metrics, which we review in Sec- we want to consider different types of index structures. Thus,
tion 2.3. For finding all points in the data base being - we use the classification of Weber et al. [23] to address a
similar, an -similarity query is executed. A special case of broad variety of different approaches. Thus, index struc-
the -similarity is represented for = 0, because this implies tures are classified by partitioning of the data space. Index
two identical points and an exact match is executed [8]. structures that partition the whole space are called space
partitioning methods, whereas data partitioning methods
Definition: NN-similarity Query. partition the necessary space according to the location of
The data point p1 is NN-similar to p2 with respect to a data points [8, 23]. Consequently, there are regions that
data base of points DB if and only if ∀p ∈ DB, p 6= p1 : are not taken into account by performing a query on data
d(p2 , p1 ) ≤ d(p2 , p). For NN-similarity queries, all points partitioning methods.
in a database are retrieved that are NN-similar to the query Alternatively, Andoni and Indyk [2] classify index struc-
point. An extension to the NN-similarity query is presented, tures by query results. There are exact index structures that
when instead of a nearest neighbor, k nearest neighbors have guarantee to retrieve the exact result of a query. Although,
to be retrieved. In this paper, we call the resulting query this behavior is usually preferred, there are approximation-
k-NN query. based index structures, guaranteeing to retrieve points that
are similar to the correct result of a query. For instance for k-
Apart from the mentioned similarity range query, window NN queries, approximation-based index structures provide k
queries are common queries and often called range queries in near neighbors to the query point instead of all exact nearest
literature [24]. These window queries are defined by intervals neighbors. Hereby, the quality of the retrieved results, called
for every queried dimension. precision, can differ significantly, because approximate in-
2.3 Distance Metrics dex structures aim at improving the query performance by
decreasing the precision. Nevertheless, an approximation-
To execute similarity queries, we require a function com-
based index should hold a threshold, because resulting data
puting the similarity of two data items. To this end, similar-
would not be useful. In the following sections, we present
ity for equal points is 1 whereas the maximum dissimilarity
some representatives of index structures. First, exact index
is expressed by 0. Equivalent information is delivered from
structures, such as R-Tree [11], Pyramid Technique [5], and
distance metrics, whereupon two data items are more simi-
VA-File [22] are introduced. Subsequently, p-stable Local-
lar, the smaller their distance is.
ity Sensitive Hashing [12] as an approximation-based index
The most common distance metrics are Minkowsky class
structure is presented.
metrics, also called Lp distance metrics. The distance of two
data items x and y is computed by: 2.4.1 Exact Index Structures
X
d 1/p Giving an overview of existing index structures, we intro-
Lp (x, y) = (xi − yi )p . duce promising exact index structures in this section. Fur-
i=1 thermore, the difference between space partitioning and data
By choosing different values for p, different representatives partitioning methods is stated by presenting at least one in-
of this class are produced. For p = 2, the Euclidean distance dex structure for each category.
metric is generated, which dominates common database sys-
tems according to Bugatti et al. [9]. R-Tree.
Beneath these distance metrics, there are many other met- One of the most important multi-dimensional index struc-
rics, such as Canberra [9] or Dynamical-Partial [16] dis- tures is the R-Tree [11], introduced by Guttmann in 1984.
tance function. In contrast to Minkowsky distance func- Since this time, many new index structures are proposed
tions, Dynamical-Partial distance metric dm uses only the based on the ideas used in the R-Tree. For instance R+ -
m smallest distances for the computation of the distance of Tree [21], R∗ -Tree [4], X-Tree [6], A-Tree [19], and SR-
data items [16]. As a result, in some specific use cases, it Tree [13]. Beside these structures, there are many more
can be a great benefit using the Dynamical-Partial distance index structures which are not mentioned here. For fur-
metric, because the influence of particular dimensions can ther informations, see Samet [20], giving a comprehensive
deteriorate the distance of data items. overview of existing index structures.
78
Challenges in Finding an Appropriate Multi-Dimensional Index Structure with Respect to Specific Use Cases
(0; 1) (0; 1) Approximation File
A 00 11 N 11 01
A D
B B 01 11 O 11 01
11 J
(0,5; 0,5) C C 01 11 P 11 00
K
(0,5; 0,5) D 10 11 Q 10 01
E L
H E 01 10 R 11 00
F M
10
G F 01 10 S 10 00
I
W G 01 10 T 01 00
N H 00 10 U 10 00
01 X I 00 10 V 10 01
Y V Q O
J 10 11 W 10 10
Z U P K 11 11 X 00 01
00 L 11 10 Y 01 01
(0; 0) (1; 0) (0; 0) (1; 0) T S
R
M 11 10 Z 00 00
(a) (b) 00 01 10 11
Figure 2: Space partition of a 2-d space by Berchtold Figure 3: Partitioning of the VA-File.
et al. [5] (a) and Lee and Kim [15] (b).
However, the basic idea of these index structures is to ad- degeneration of most index structures to a sequential scan, if
ministrate points hierarchically in a tree. The R-Tree par- the dimensionality of data points exceeds a certain limit [23].
titions the data space using minimum bounding rectangles Hence, the authors propose to accelerate the sequential scan
(MBR). A minimum bounding rectangle can be described by using vector approximation.
by two points, being the end of the diagonal of the rectan- The VA-File divides each dimension of the space into 2b
gle. Stepwise, the space is partitioned by MBRs, so that the equally filled cells, where b is an user defined amount of bits
superordinate MBR encloses all of its subordinate MBRs, as per dimension. Each cell is labeled with a unique bit string,
we visualize in Figure 1. being the concatenation of the corresponding bit strings for
With increasing dimensionality, R-Trees face the challenge every dimension. For every point, the bit string of the cell is
of overlapping MBRs. A query rectangle, situated in a re- stored, which the point is inserted into. Thus, the VA-File
gion, where two or more MBRs overlap (like the MBR R2 uses two lists: an approximation file that stores the bit string
and R3 in Figure 1), forces the R-Tree to follow up two or of the cells for every point and a vector file with the vector
more different routes in the tree. Thus, the query perfor- data for each point. An exemplary space partitioning and
mance decreases [6]. To overcome this disadvantage other the corresponding approximation file can be seen in Figure 3.
index structures that we mentioned before, are developed. Generally, the query algorithm of the VA-File traverses
the whole approximation file to collect suitable candidates
for the query result at first. After that, exact comparisons
Pyramid Technique. between the vector data of the candidates and the query are
An example for an exact space partitioning index struc-
performed.
ture is the Pyramid Technique, which was introduced by
The approximation technique of the VA-File helps to re-
Berchtold et al. [5]. The Pyramid Technique divides an n-
duce hard-disk accesses, because small bit strings can be
dimensional space into 2d pyramids [5]. A d dimensional
kept in main memory. Even if the whole approximation
normalized point x is inserted into a pyramid according to
file does not fit into the main memory, the sequential ex-
the dimension jmax with its maximum distance to the center
amination of the approximations reduces disk access costs
of the data space. Thus, the pyramid number pi is computed
compared to random accesses to many data items [22]. An-
as follows:
other advantage is, in contrast to the Pyramid Technique,
jmax if xjmax < 0, 5 the availability of different algorithms to efficiently support
i=
(jmax + d) if xjmax ≥ 0, 5 all query types being executable on a sequential scan with-
Second, for managing the space enclosed by a pyramid, out adaption of the space partitioning of the VA-File.
the pyramids are divided in pyramid slices. According to the 2.4.2 Approximation-based Index Structures
query types supported by the index structure, the partition
of pyramids can be done in different ways. In Figure 2, Typical representatives for an approximation-based index
we present two different possible methods for partitioning a structure are based on hash schemes. Apart from common
pyramid, for a two dimensional normalized space. hashing algorithms, scattering inserted data points over the
In particular, the partition of Figure 2 (a) is proposed amount of buckets is not applicable for similarity queries.
by Berchtold et al. [5] to support range queries. The other Consequently, there is a need for hash functions, causing
partition, shown in Figure 2 (b), is used by the approach of collisions when hashing locally near situated points. This
Lee and Kim [15] to support k-NN queries. It is possible to challenge is handled by Locality Sensitive Hashing (LSH).
use the partitioning from Berchtold et al. for k-NN queries as The aim of LSH is to map the key to a one dimensional
well, but not in an efficient way. Anyway, a point is inserted hash value. Thus, all comparisons are made on the hash
into the slice depending on its distance to the center of the value instead of a high dimensional key. Supporting nearest
space. To sum up, for supporting different query types in neighbor queries, LSH uses (P 1, P 2, r, cr)-sensitive functions
an efficient way, different pyramid partitions are required. h to compute the hash value. These functions h have to fulfill
the following constraints [12]:
VA-File. For every dataset in a d-dimensional space p, q ∈ Rd :
In 1997, Weber and Blott [22] introduce the VA-File to
overcome the curse of dimensionality. The VA-File is an 1. if ||p − q|| ≤ r, then P r[h(p) = h(q)] > P 1
improved sequential scan, because Weber et al. noticed a 2. if ||p − q|| ≥ cr, then P r[h(p) = h(q)] < P 2
79
Challenges in Finding an Appropriate Multi-Dimensional Index Structure with Respect to Specific Use Cases
The first constraint demands that the probability for two the approximation-based index structure p-stable LSH pre-
points to be hashed into the same bucket has to be larger sented in Section 2.4 are number of hash functions and width
than P 1 if their distance is smaller than r. Whereas, if their of hash buckets.
distance is bigger than cr, the probability should be smaller Thus, we have to assume, that these parameters have an
than P 2. In order to be an useful locality sensitive function, impact on the performance of index structures. Therefore,
P 1 should be much bigger than P 2. it is necessary to analyze suitable parameter values when
Improving the precision of the index structure, usually trying to identify an appropriate index structure for a given
several hash tables with different hash functions are used. use case. However, there are some problems considering an
Consequently, the need for (P 1, P 2, r, cr)-sensitive functions appropriate value of some parameters. For example, the
is obvious. A promising family of hash functions is used in vectors used for p-stable LSH are randomly chosen from p-
p-stable LSH. stable distributions. As a result of this random component
it is possible that the performance and precision results of
p-stable LSH. the same index structure created with different seeds of the
The approach of p-stable LSH is based on p-stable distri- random component can differ very much, within the same
butions. A distribution D is p-stable for p ≥ 0 if for any n the use case. This is problematic when trying to quantitatively
real numbers v1 , ..., vn and i.i.d. random variables X1 , ..., Xn evaluate the index structure.
with distribution D, the following constraint is fulfilled:
3.2 Workload and used Queries
n
X X
n 1/p Although, two different applications can deal with the
(vi Xi ) ∼ (kvi kp ) X, same data, they can have a different workload. For that
i=1 i=1 reason, they can differ in requirements of index structures.
The workload of an application depends on the used query
∼ means the operands have the same distribution and X is
types. Yet, it is obvious, not to use the Pyramid Technique
a random variable from the distribution D [18].
presented from Berchtold et al. [5] for performing a k-NN
Using d random variables from D to form a d-dimensional
query, but the version presented by Lee and Kim [15], be-
Vector ~a, the scalar of vector ~a and the data point ~v result in
P d 1/p cause it is optimized for this query type.
a random variable with distribution (kvi kp ) X [12]. For defining the workload of a database system we use
i=1 a definition inspired by Ahmad et al. [1]. As a result, the
Several of these scalar products with different vectors can
workload is defined by the percentage of the query types
be used to estimate k~v kp (the Lp distance metric). The
used and the amount of concurrent requests performed.
corresponding distributions are:
• The Cauchy Distribution DC (0, 1), defined by the den-
1
3.3 DBMS Environment
sity function c(x) = (π(1+x 2 )) is 1-stable and can be
In addition to use cases and workload, the test environ-
used to estimate the Manhattan distance metric. ment has an impact on the performance of each index struc-
• The Gaussian (Normal) Distribution DG (0, 1), defined ture. As already mentioned, the VA-File is optimized for
2
by the density function g(x) = √12π e−x /2 is 2-stable database systems, storing data items on a disk and not in
and can be used to estimate the Euclidean distance main memory. Evaluations of VA-File and sequential scan,
metric. result in different conclusions according to an evaluation
Instead of estimating a distance metric, the scalar prod- with an in-memory database or a database storing items
uct with vectors from p-stable distributions can be used to on the disk. Consequently, it is necessary to consider the
compute hash values of the data points, because the scalar underlying storage management of the database system as
product maps the vectors to a one dimensional space. Fur- well.
thermore, the result of the scalar product has the same dis- Beside the storage management of a database, the amount
tribution as the Lp distance metric, which guarantees the of main memory and the CPU performance are other impact
(P 1, P 2, r, cr)-sensitiveness. factors to the performance.
3. ADVANCED CHALLENGES 4. TOWARDS A FRAMEWORK
After giving a short introduction to general challenges of Since we aim at providing a comprehensive library of use
indexing multi-dimensional data, in this section we provide cases and suitable indexes, we motivate a framework to give
existing challenges of evaluating the performance of index users the possibility to evaluate own use cases with different
structures for a specific use case. For giving an overview index structures. In this paper, we summarize key aspects
of possible challenges when evaluating index structures, we of a framework that supports four groups. In Figure 4, we
group the challenges into three groups. give an overview of these four groups.
3.1 Parameter of the Index Structures 4.1 Extensibility
Some index structures have specific parameters for tuning First, the framework has to be extensible w.r.t. four key
their performance. Thus, when evaluating the performance aspect, we present in Section 2. In other words, for an user,
of index structures, these parameter have to be considered it has to be possible to implement, integrate, and evaluate
as well. For index structures given in Section 2.4, these pa- own index structures. Furthermore, it has to be possible
rameter are: the minimum and the maximum number of to extend the framework and existing index structures with
points within a MBR for the R-Tree, the number of slices a additional distance metrics and also other query types. Fi-
pyramid is divided in, for the Pyramid Technique, and the nally, it has to be possible to integrate existing data in the
length of the bit vector for the VA-File. The parameters of framework and to create data with specific properties like a
80
Challenges in Finding an Appropriate Multi-Dimensional Index Structure with Respect to Specific Use Cases
USER or pit-falls of the chosen index structure. For instance, the
user is able to follow the split of MBRs in the R-Tree and
can easily identify overlapping regions while the tree is be-
ing constructed. Another aspect, being worth to visualize,
test environment
workload visualization extensibility is a statistic on query performance. These statistics help to
simulator
analyze the performance of different index structures for a
given workload or an index structure under different work-
FRAMEWORK loads. Apart form the query performance, other interesting
values may be worth visualizing. The time spent on con-
structing the index structure is important for systems with
Figure 4: Structure of the Framework. many delete and update queries, because a reconstruction of
the index is sometimes necessary when a certain threshold
of changed data is reached. Furthermore, when using an ap-
specific data distribution. Thus, creating data distributions proximate index structure, the precision of executed queries
is not trivial, an interface has to be created for importing and the overall precision of the index structure is worth vi-
existing data sets and communicating with systems like R, sualizing, because it has an impact on the suitability of an
see for instance [14]. index structure for a special use case.
4.2 Adaptability to Different Workload 4.5 Working with the Framework
In real world applications, the workload differs quite much. Finally, our framework shall help finding the most suit-
On the one hand, there are use cases that use only read able index structures for a given use case. For this, the
transactions. On the other hand, the workload can consist expected workload has to be known. These parameters in-
of read and write transactions. Thus, the performance re- clude supported query types, exact or approximate results,
sults of workloads can differ very much. Hence, an interface data dimensionality and distribution, amount of data, the
is needed for importing workloads from existing systems. A delay of the data access, and the environment. By finding
further requirement, is to support standardized benchmarks, suitable index structures for the given parameters, there are
e.g. the TPC-H Benchmark2 . index structures that do not have to be taken into account,
Beside the queries used, the desired precision of the query because they do not support certain query types or work
results have to be defined by the user. Thus, if approximate approximately although the result is restricted to be exact.
results are allowed, the user has to define the accuracy of After excluding unsuitable index structures, the remaining
the results. Nevertheless, the precision depends on the data index structures are evaluated under the given workload. By
properties, the given distance metric, the used queries and reviewing the performance results, the user can choose the
the parameters of the index structure as well. suitable index structure for her use case.
4.3 Test Environment Simulator
Existing index structures are created with respect to dif- 5. RELATED WORK
ferent optimization criteria. As already mentioned, the VA- In the last decades, many new index structures are cre-
File is optimized for reducing disk accesses. Consequently, ated [5, 10, 22]. In addition, existing index structures are
another criteria our framework has to consider is the envi- improved for supporting new query types [15] or to increase
ronment the tests are located in. Thus, within the frame- performance [6]. However, within the presented evaluation
work a parameter has to exist, for setting whether the test of these index structures only a small set of existing in-
is for an in-memory database or if a disk access is needed for dex structures is considered. For example, within Berchtold
accessing the data. Due to an assumption, that the access et al. [5], the Pyramid Technique is evaluated against X-
time of data differs very much considering Hard-Disk-Drives Tree, Hilbert R-Tree, and sequential scan. Therefore, it is
and Solid-State-Disks, the framework should have a compo- problematic to identify, which is the most appropriate in-
nent for virtualizing the disk access. With this component dex structure for a given problem. Additionally, different
it is possible to perform tests on one system while simulat- performance evaluations are done in different environments
ing an access delay of another system. In addition to this with different data characteristics. So, it is problematic to
storage device simulator, a simulator for all hardware com- generalize the results of an evaluation.
ponents is required to give an useful hint about the best For giving a comparison of the performance of multi-di-
performing index structure. mensional index structures, there already exists some frame-
Additionally, within the framework a parameter has to works, like the GiST 3 framework or the MESSIF [3] frame-
exist for defining the values of some index structure param- work. In contrast to the framework we present here, these
eters such as the maximum number of data items of leaves frameworks have some additional constraints. For example,
of the R-Tree. the GiST framework only focuses on trees, hence no other
multi-dimensional index structures such as the VA-File or
the Pyramid Technique are considered, while the MESSIF
4.4 Visualization framework only focuses on metric data. Another framework
In case the index structure has to struggle with a specific limiting the available index structures is introduced by Muja
data distribution or query type, it can be useful to visualize et al. [17]. The aim of this framework is to optimize param-
the space partitioning of the index structure. With this vi- eters of approximate index structures in order to match the
sualization, further hypothesis can be drawn on the benefits required precision under given data distributions.
2 3
http://www.tpc.org/tpch/ http://gist.cs.berkeley.edu/
81
Challenges in Finding an Appropriate Multi-Dimensional Index Structure with Respect to Specific Use Cases
6. CONCLUSION IEEE Trans. on Pattern Analysis and Machine
In this paper, we provide an overview of existing chal- Intelligence (TPAMI), 30(9):1647–1658, 2008.
lenges in finding an appropriate index for multi-dimensional [11] A. Guttman. R-Trees: A dynamic index structure for
data for a specific use case. First, we explain distance met- spatial searching. In SIGMOD’84, Proc. of Annual
rics and common query types that have to be considered. Meeting, pages 47–57, 1984.
Second, the parameters of the index structures can have an [12] P. Indyk and R. Motwani. Approximate nearest
impact on the performance of an index structure. Third, for neighbors: Towards removing the curse of
users, it has to be possible to define own workload pattern dimensionality. In Proc. Symp. on Theory of Compu.
and the environment, the application is located in. (STOC). ACM, 1998.
For supporting these characteristics of real-world use cases [13] N. Katayama and S. Satoh. The SR-tree: An Index
we present requirements of a framework we intend to de- Structure for High-Dimensional Nearest Neighbor
velope. Our framework has to support four key aspects. Queries. In Proc. Int’l. Conf. on Mgmt. of Data
Namely, it has to be extensible, support different workload (SIGMOD), pages 369–380. ACM, 1997.
patterns, virtualize different use case environments, and con- [14] V. Köppen. Improving the Quality of Indicator
tain a visualization component for improving user experi- Systems by MoSi – Methodology and Evaluation. PhD
ences. thesis, Freie Universität Berlin, 2008.
[15] D.-H. Lee and H.-J. Kim. An efficient technique for
7. ACKNOWLEDGMENTS nearest-neighbor query processing on the SPY-TEC.
The work in this paper has been funded in part by the Trans. on Knowl. and Data Eng. (TKDE),
German Federal Ministry of Education and Science (BMBF) 15:1472–1486, 2003.
through the Research Programme under Contract No. [16] B. Li, E. Chang, and Y. Wu. Discovery of a perceptual
FKZ:13N10817 and FKZ:13N10818. Additionally we want distance function for measuring image similarity.
to thank Sandro Schulze for giving us useful comments. Multimedia Systems, 8(6):512–522, Apr. 2003.
[17] M. Muja and D. G. Lowe. Fast approximate nearest
8. REFERENCES neighbors with automatic algorithm configuration. In
[1] M. Ahmad, A. Aboulnaga, and S. Babu. Query Proc. Int’l. Conf. on Computer Vision Theory and
interactions in database workloads. In Proc. Int’l. Applications (VISAPP), pages 331–340, 2009.
Workshop on Testing Database Systems, DBTest, [18] J. P. Nolan. Stable distributions: Models for heavy
pages 11:1–11:6. ACM, 2009. tailed data. Springer-Verlag, 2009.
[2] A. Andoni and P. Indyk. Near-optimal hashing [19] Y. Sakurai, M. Yoshikawa, S. Uemura, and H. Kojima.
algorithms for approximate nearest neighbor in high The A-tree: An index structure for high-dimensional
dimensions. Commun. ACM, 51(1):117–122, 2008. spaces using relative approximation. In Proc. Int’l.
[3] M. Batko, D. Novak, and P. Zezula. Messif: Metric Conf. on Very Large Data Bases (VLDB), pages
similarity search implementation framework. In Proc. 516–526. Morgan Kaufmann Publishers Inc., 2000.
Conf. on Digital Libraries (DELOS), 2007. [20] H. Samet. Foundations of Multidimensional and
[4] N. Beckmann, H.-P. Kriegel, R. Schneider, and Metric Data Structures. Morgan Kaufmann Publishers
B. Seeger. The R*-Tree: An efficient and robust access Inc., 2005.
method for points and rectangles. In Proc. Int’l. Conf. [21] T. K. Sellis, N. Roussopoulos, and C. Faloutsos. The
on Mgmt. of Data (SIGMOD), pages 322–331. ACM, R+-Tree: A dynamic index for multi-dimensional
1990. objects. In Proc. Int’l. Conf. on Very Large Data
[5] S. Berchtold, C. Böhm, and H.-P. Kriegel. The Bases (VLDB), pages 507–518. Morgan Kaufmann
Pyramid-Technique: Towards breaking the curse of Publishers Inc., 1987.
dimensionality. SIGMOD Rec., 27:142–153, 1998. [22] R. Weber and S. Blott. An approximation-based data
[6] S. Berchtold, D. A. Keim, and H.-P. Kriegel. The structure for similarity search. Technical Report
X-Tree: An index structure for high-dimensional data. ESPRIT project, no. 9141, 1997.
In Proc. Int’l. Conf. on Very Large Data Bases [23] R. Weber, H.-J. Schek, and S. Blott. A quantitative
(VLDB), pages 28–39. Morgan Kaufmann Publishers analysis and performance study for similarity-search
Inc., 1996. methods in high-dimensional spaces. In Proc. Int’l.
[7] C. Böhm. Efficiently Indexing High-Dimensional Data Conf. on Very Large Data Bases (VLDB), pages
Spaces. PhD thesis, Ludwig-Maximilians-Universität 194–205. Morgan Kaufmann Publishers Inc., 1998.
München, 1998. [24] R. Zhang, B. C. Ooi, and K.-L. Tan. Making the
[8] C. Böhm, S. Berchtold, and D. A. Keim. Searching in pyramid technique robust to query types and
high-dimensional spaces: Index structures for workloads. In Proc. Int’l. Conf. on Data Engineering
improving the performance of multimedia databases. (ICDE), pages 313–324. IEEE Computer Society,
ACM Comput. Surv., 33:322–373, 2001. 2004.
[9] P. H. Bugatti, A. J. M. Traina, and C. Traina, Jr.
Assessing the best integration between
distance-function and image-feature to answer
similarity queries. In Proc. ACM Symp. on Applied
Computing (SAC), pages 1225–1230. ACM, 2008.
[10] E. Chavez Gonzalez, K. Figueroa, and G. Navarro.
Effective proximity retrieval by ordering permutations.
82
Minimal-Invasive Indexintegration
Transparente Datenbankbeschleunigung
Alexander Adam Sebastian Leuoth Wolfgang Benn
dimensio informatics GmbH dimensio informatics GmbH Technische Universität
Brückenstraße 4 Brückenstraße 4 Chemnitz
09111 Chemnitz 09111 Chemnitz Straße der Nationen 62
alad@dimensio-informatics.de lese@dimensio-informatics.de 09107 Chemnitz
benn@cs.tu-chemnitz.de
Keywords nen schlechten Portabilität der entwickelten Module. Beson-
Datenbankenerweiterung, Indizierung, Transparent ders im Bereich der Indizierung um den es in diesem Papier
gehen soll, stellen sich aber noch weitere Probleme dar.
Normalerweise kann ein Index auf einer beliebigen Ta-
ZUSAMMENFASSUNG belle und deren Spalten definiert werden. Die Anwendung
Aktuelle Datenbanksysteme bieten dem Nutzer eine enor- bemerkt nur insoweit etwas von dieser Aktion, als dass An-
me Funktionsvielfalt [12, 8]. Selbst sehr spezielle Gebiete fragen schneller beantwortet werden sollten.
wie z. B. Geodatentypen [9, 14] werden unterstützt. Abhän- Ein kleines Beispiel soll dies verdeutlichen. Die folgende
gig vom verwendeten Datenbanksystem können diese Fä- Anfrage gibt alle Mitarbeiterinformationen zurück, die zu
higkeiten durch einen Nutzer noch erweitert werden. Bei- Mitarbeitern mit mehr als 1000 Euro Gehalt gehören:
spiele hierfür wären Funktionen und nutzerdefinierte Da-
tentypen [12, 8]. Alle diese Erweiterungen sollten natür-
Listing 1: SQL-Anfrage mit Bedingung im WHERE-Teil
lich nicht die Geschwindigkeit des Datenbanksystems nega-
tiv beeinflussen. So gibt es neben normalen Indexen auch SELECT ∗
Funktionsindexe und Indexe für nutzerdefinierte Datenhal- FROM mitarb
tungen [20, 2]. Die Möglichkeiten, zu indizieren sind dabei, je WHERE mitarb.gehalt > 1000
nach Datenbankhersteller, vorbestimmt und selbst nicht er-
Für die Anwendung, die diese Anfrage an die Datenbank
weiterbar. Allen diesen Techniken ist weiterhin gemein, dass
stellt, ist es vollkommen unerheblich, ob sich auf der Ge-
sie direkt am Datenbanksystem ansetzen und teils auch in
haltsspalte der Mitarbeitertabelle ein Index befindet oder
der Anfragesprache sichtbar sind. Es ist daher nicht einfach
nicht. Die Anfrage würde, ob nun mit oder ohne Index, im-
möglich, eine Anwendung, die fest vorgegeben ist, mittels
mer gleich aussehen.
solcher Techniken zu beschleunigen. In diesem Papier wol-
Wir nehmen nun an, dass die Gehaltsspalte durch einen
len wir eine Möglichkeit vorstellen, mit der eine solche Be-
anderen Typ ersetzt werden soll, Gründe hierfür könnten ei-
schleunigung auch dann noch möglich ist, wenn weder das
ne effizientere Speicherung oder bessere Zugriffsmöglichkei-
Datenbanksystem noch die Anwendung im Zugriff des Nut-
ten sein. Wir nehmen weiter an, dass das Datenbanksystem
zers stehen. Verdeutlicht wird dieses am Beispiel der JDBC-
für den neuen Typ den >-Operator nicht mehr anbietet. Es
Schnittstelle [15].
muss nun eine Vergleichsfunktion geschrieben werden, die
die Aufgabe des >-Operators übernimmt. Diese tiefgreifen-
1. EINLEITUNG de Umstrukturierung scheint nun bis in die Anfrage durch,
Datenbanksysteme haben in den letzten Jahrzehnten ein ist also nicht mehr transparent:
breites Anwendungsspektrum erschlossen. Funktionalitäten
wurden oft aufgrund der Bedürfnisse der Anwender hinzuge-
Listing 2: SQL-Anfrage mit Anfrage an eine nutzer-
fügt [17]. So gibt es heute nutzerdefinierte Datentypen, nut-
definierte Funktion im WHERE-Teil
zerdefinierte Datenablagen und selbst elementare Dinge wie
Indexe, die durch einen Nutzer in ihrer Struktur bestimmt SELECT ∗
werden. FROM mitarb
Allen gemein ist eine gewisse Abhängigkeit der Implemen- WHERE pruefe( mitarb.gehalt, 1000) = 1
tation vom Datenbankhersteller und einer damit verbunde-
Eine Anwendung, die der Nutzer nicht verändern kann, wür-
de also von diesem neuen Typ ausschließlich dann profi-
tieren, wenn der Hersteller diese Möglichkeit vorsieht oder
standardmäßig einbaut. Für bestehende Umgebungen ist all
dies also keine Option.
Im obigen Fall würde noch die Möglichkeit des automati-
schen SQL-Umschreibens einen Ausweg bieten [12, 8]. Dabei
wird eine materialisierte Sicht angelegt. Anschließend wird
24th GI-Workshop on Foundations of Databases (Grundlagen von Daten-
banken), 29.05.2012 - 01.06.2012, Lübbenau, Germany. der Datenbank mitgeteilt, dass bestimmte Anfragen nicht so
Copyright is held by the author/owner(s). gestellt werden sollen, wie sie der Anwender abgesetzt hatte,
83
Minimal-Invasive Indexintegration - Transparente Datenbankbeschleunigung
sondern in veränderter Form auf der materialisierten Sicht 2.2 Datenbanktreiber
abgearbeitet werden. Das Vorgehen muss vom Datenbank- Der Datenbanktreiber ist die Schnittstelle für einen An-
system aber auch unterstützt werden. Je nach Ausprägung wendungsprogrammierer, um mit dem Datenbanksystem zu
müssen außerdem genaue Übereinstimmungsmerkmale an- kommunizieren. Er stellt Funktionen bereit, um Verbindun-
gegeben werden, mit denen das Umschreiben ausgelöst wird. gen zu verwalten und Datenbankanfragen abzuarbeiten (sei
Scheitert das Umschreiben, weil es eine kleine Varianz in der es nun SQL oder irgendeine andere Art der Anfrage) [5,
Anfrage gibt, wird das Ergebnis u. U. falsch. 11]. Es ist wichtig, zu beobachten, dass dabei jeder Ab-
Im Folgenden werden wir eine Möglichkeit aufzeigen, wie arbeitungsschritt von der Anwendung ausgelöst wird. Alle
es ohne einen Eingriff – weder bei der Anwendung noch Ergebnisse einer Anfrage werden nicht einfach als Resultat
bei der Datenbank – möglich ist, einen Index weitestgehend einer query()-Funktion zurückgegeben, sondern müssen ak-
transparent in ein bestehendes System zu integrieren. Da- tiv angefordert werden. Eine typische Schrittfolge, die eine
zu wird zunächst untersucht, an welchen Stellen und wie in Anwendung verwenden könnte, ist in Listing 3 aufgezeigt.
die Kommunikation von Anwendung und Datenbanksystem
eingegriffen werden kann. Anschließend wird auf die Heraus-
forderungen eingegangen, die sich bei dem hier genutzten Listing 3: Mögliche, stark reduzierte, Schrittfolge
Ansatz zeigen und wie diese gelöst werden können. bei der Nutzung einer Datenbankbibliothek, hier
JDBC. Es wird zunächst eine Verbindung geöffnet,
2. INTEGRATIONSPUNKTE dann ein Statement mit ungebundenen Variablen
vorbereitet und gebunden. Schließlich werden die
2.1 Überblick angefragten Daten abgeholt.
Connection conn = DriverManager.getConnection(
Um mögliche Integrationspunkte zu finden, muss zunächst
"jdbc:mysql://localhost/testdb",
untersucht werden, wie eine Anwendung mit einem Daten-
"username",
banksystem kommuniziert. Üblicherweise werden hierfür Da-
"password");
tenbanktreiber eingesetzt. Das sind Programmbibliotheken,
Statement ps = conn.prepareStatement(
die die Anfragen in ein dem Datenbanksystem verständli-
"SELECT ∗ FROM mitarb
ches Protokoll überführen und dieses dann übermitteln. Der
WHERE gehalt > ?");
Datenbankserver dekodiert das Protokoll und arbeitet die
ps. setInt (1, 1000);
darin enthaltenen Anweisungen ab.
ResultSet rs = ps.executeQuery();
String name = rs.getString("name");
ps. close () ;
conn.close () ;
Wie nun stellt sich hier eine Möglichkeit zur Integration
dar? Es ist möglich, vor jede Funktion, die eine Anwendung
vom originalen Datenbanktreiber aufruft, eine eigene Funk-
tion zu setzen. Die Anwendung ruft nun die eigene Funk-
tion, ohne dies zu bemerken, und die eigene Funktion ruft
schließlich die originale. Da nun alle Daten, die von einer
Anwendung zum Datenbanksystem gesendet werden, vorher
Abbildung 1: Schematische Darstellung des Zusam-
analysiert und verändert werden können, stellt sich so dieser
menspiels zwischen Anwendung und Datenbank. Die
Integrationspunkt dar. Außerdem können eigene Funktionen
Anwendung verwendet ein API für einen Daten-
auf der so abgefangenen Datenbankverbindung „huckepack“
banktreiber, welcher vom Datenbankhersteller zur
aufgesetzt werden.
Verfügung gestellt wird. Dieser Treiber ist dann für
Ein erster Gedanke, dies zu realisieren, könnte in die Rich-
die Kommunikation mit dem Datenbanksystem über
tung einer DLL-Injection [18] gehen. Das bedeutet das kom-
ein Netzwerk verantwortlich.
plette Ersetzen des vom Datenbankhersteller bereitgestell-
ten Treibers durch einen eigenen. Dieser kann, da die Proto-
Das beschriebene Szenario – abgebildet in Abbildung 1 –
kolle nicht zwingend offengelegt sein müssen, die Kommuni-
offenbart drei Möglichkeiten, eine Integration vorzunehmen:
kation mit dem Datenbanksystem nicht selbst übernehmen,
• den Datenbanktreiber, sondern ruft den ursprünglichen Datenbanktreiber. Abhän-
gig von der Anzahl der zu implementierenden Funktionen
• die Kommunikation über das Netzwerk und kann dies ein möglicher Weg sein. Eine weit verbreitete sol-
che Schnittstelle, um aus einer Javaanwendung mit einem
• das Datenbanksystem selbst. Datenbanksystem in Verbindung zu treten, ist JDBC. Mit
seinen vielen Klassen und mehr als 1000 zugehörigen Me-
Im Folgenden werden wir uns auf den Datenbanktreiber, al- thoden [6] wäre es eine sehr langwierige Aufgabe, einen sol-
so die Anwendungsseite, konzentrieren. Die Vorgehensweise chen sogenannten Wrapper [7] zu implementieren. In einem
bei der Integration in die Kommuniktion ist bereits in [1] unserer Produkte namens Cardigo ist dieses aber bereits im-
beschrieben. Möglichkeiten, ein Datenbanksystem zu erwei- plementiert und erleichtert so die Aufgabe enorm. Weitere
tern, wurden in den letzten Jahrzehnten vielfach an anderer Projekte und Arbeiten zu diesem Thema sind unter anderem
Stelle beschrieben [4, 20, 2]. auch bei [19, 22, 21] und [13] zu finden.
84
Minimal-Invasive Indexintegration - Transparente Datenbankbeschleunigung
Cardigo ist ein Rahmenwerk, welches u. a. alle Klassen Index an das Datenbanksystem zu übertragen. Es schließt
und Methoden enthält, die das JDBC-API anbietet. An- sich eine Betrachtung an, die die programmtechnische Inte-
statt selbst ein kompletter Treiber zu sein, bietet es lediglich gration betrachtet, da sich hier noch einige weitere Probleme
einen Wrapper für einen „richtigen“ Datenbanktreiber. Das auftun.
Ziel dieses Produktes ist es, einem Anwender die Möglichkeit
zu geben, die Datenbankkommunikation – in diesem Falle 3.1 Logische Integration
hauptsächlich Anfragen, Ergebnisse u. s. w. – zu loggen oder Die Grundidee der Integration ist es nun, die Anfrage, die
gar zu verändern. Mit diesem Werkzeug können wir nun die eine Anwendung absetzt, so zu verändern, dass sie das Ver-
Integration des Index angehen. halten eines datenbankinternen Index nachahmt. Die Anfra-
Technisch ist zur Integration von Cardigo nichts weiter ge aus Listing 1 könnte nun, wie in Listing 4 aufgezeigt, um
nötig, als ein geänderter Verbindungsparameter für die An- das Primärschlüsselattribut erweitert werden.
wendung. Dieser bewirkt, dass anstelle des originalen JDBC-
Treibers nun Cardigo geladen wird. Der Aufbau dieser ver-
änderten Umgebung ist in Abbildung 2 verdeutlicht. Listing 4: SQL-Anfrage, die um die Ergebnisse eines
externen Index erweitert wurde
SELECT ∗
FROM mitarb
WHERE gehalt > 2000
AND id IN (4, 18)
Dieses Vorgehen vertraut darauf, dass der Optimierer des
Datenbanksystems erkennt, dass es sich bei den Werten in
der IN-Klausel um Primärschlüssel handelt. Er muss diese
möglichst am Anfang der Anfrageverarbeitung einbeziehen,
um die Menge der zu untersuchenden Tupel zu minimieren.
Durch Tests haben wir herausgefunden, dass die Anzahl
der in IN-Listen enthaltenen Elemente eine Obergrenze hat.
Durch die Disjunktion mehrerer IN-Listen kann diese zu ei-
nem gewissen Grad ausgeglichen werden. Somit ist es mög-
lich, sehr lange Anfragen zu erzeugen, Allerdings gibt es auch
eine Grenze für die maximale, vom Datenbanksystem zuge-
lassene, Anfragelänge. Bei IBM DB2 und Oracle ist diese
Maximallänge bspw. 64kB [8, 16].
Ein weiterer Aspekt, der bei diesen langen Anfragen be-
trachtet werden muss, ist, dass diese vom Datenbanksystem
auch geparst werden. Werden die Anfragen lang, so stei-
Abbildung 2: Anwendung, die Cardigo durch einen gen auch deren Parsezeiten, selbst optimistisch betrachtet
veränderten Kommunikationsparameter nutzt. Der ist dieser Zusammenhang linear. Auch systematisch bedingt,
Code, den ein Nutzer schreibt, umfasst typischer- ist, dass der Optimierer zu lange und viele IN-Listen nicht
weise nicht den gesamten API-Umfang von JDBC, beachtet, selbst wenn es sich um Primärschlüssel handelt.
weshalb er hier nicht über die gesamte Breite dar- Mit Hinweisen an den Optimierer kann hier gegengesteuert
gestellt ist. Exemplarisch sind die in Listing 3 ver- werden. Zusammenfassend lässt sich aber sagen, dass ab ei-
wendeten Methoden dargestellt. ner gewissen Anfragelänge, der Gewinn durch den Index sich
im schlechtesten Falle sogar ins Gegenteil verkehren kann.
Um diese Beschränkungen zu umgehen, können die Er-
gebnisse des Index auch in eine Tabelle in der Datenbank
3. INTEGRATION eingefügt werden. Hier gibt es wieder mehrere Möglichkei-
Bevor wir die Integration des Index weiter betrachten, wol- ten:
len wir kurz darauf eingehen, wie ein in ein Datenbanksys-
tem integrierter Index arbeitet: Wird eine Anfrage an die 1. Einfügen in eine Tabelle, die angelegt ist
Datenbank gestellt und treffen einige der verwendeten At- 2. Einfügen in eine temporäre Tabelle
tribute die im Index enthaltenen, so wird der Index verwen-
det. Dabei wird die Anfrage vom Index bearbeitet und im In beiden Fällen muss allerdings die Datenbank in der Wei-
Ergebnis entsteht einen Liste von Ergebniskandidaten. Die- se modifiziert werden, dass die Anwendung, in die der In-
se können in Form von RowIDs [3] oder auch einfach als dex integriert wurde, das Recht hat, auf diese Tabellen zu
Primärschlüssel vorliegen. Das Datenbanksystem überprüft schreiben. Die Tabellen müssen prinzipiell eine Spalte für
dann nur noch die Datensätze, deren Identifikatoren der In- die Anfrage und eine Spalte für die Ergebnisse des Index
dex als Ergebnis lieferte. Auf diese Art wird der Aufwand, besitzen.
den das Datenbanksystem beim Laden der Datensätze und Werden über eine Sitzung Anfragen nur sequenziell be-
ihrer Verifikation hat, erheblich verringert [10]. arbeitet, haben temporäre Tabellen den Vorteil, dass zwi-
Im Folgenden wird zunächst die logische Integration be- schen verschiedenen Datenbanksitzungen nicht mittels der
trachtet, d. h., wie es überhaupt möglich ist, Ergebnisse eines eben beschriebenen zusätzlichen AnfrageID-Spalte in dieser
85
Minimal-Invasive Indexintegration - Transparente Datenbankbeschleunigung
Tabelle unterschieden werden muss. Das ist darin begrün- 4. ERGEBNISSE UND AUSBLICK
det, dass temporäre Tabellen für jede Sitzung als leere neue Das hier beschriebene System war bereits erfolgreich im Ein-
Tabellen erscheinen. Die Aktionen einer Sitzung wirken sich satz. Die Latenzen für das reine Abfangen der Datenban-
nicht auf den Inhalt der temporären Tabelle in einer anderen kaufrufe bewegen sich im einstelligen Mikrosekundenbereich,
Sitzung aus. also dem, was für einen Funktionsaufruf erwartet werden
Ein bisher nicht zur Sprache gekommener Punkt ist das kann. Hinzu kommt die Zeit für die Indexanfrage. Für einen
Aktualisieren des Index. Natürlich muss ein datenbankexter- realen Gewinn muss natürlich die Zeit für die Integrati-
ner Index über INSERT-, UPDATE- und DELETE-Operationen on, die Indexanfrage und den Einbau der Ergebnisse in das
informiert werden. Der einfachste Weg ist, wenn alle Ope- Statement in Summe geringer sein, als die einer Anfrage oh-
rationen, die auf der Datenbank laufen, über die gleiche ab- ne den externen Index.
gefangene Schnittstelle gehen und so direkt gelesen werden Es zeigte sich auch, dass, wird eine Integration über Ta-
können. In der Realität ist dies jedoch unpraktisch, da die- bellen angestrebt, es verschiedene Arten gibt, die Ergebnisse
se Voraussetzung nicht zu 100% gewährleistet werden kann. aus der Ergebnistabelle zu entfernen. In 3.1 wurden die ver-
Trigger sind eine Variante, wie Veränderungen in der Daten- schiedenen Arten von Tabellen hierfür beschrieben. Wenn
bank nach außen gereicht werden können, diese müssen je- keine Spalte für die AnfrageID verwendet werden muss, so
doch integriert werden dürfen. Hier ergeben sich damit auch können die Ergebnisse mit einem TRUNCATE entfernt werden.
Grenzen, über die hinaus unser Ansatz nicht angewendet Dieses wird erheblich schneller ausgeführt, als ein DELETE
werden kann. Eine andere Möglichkeit sind statische Daten- FROM ... WHERE anfrage_id == .
haltungen, die nur in definierten Zeitabschnitten aktualisiert Unsere weitere Arbeit beschränkt sich nicht nur auf eine
werden, bspw. einmal pro Monat. Hier kann ein statischer Integration in JDBC, die wir hier aufgezeigt haben, sondern
Index genutzt werden, der über eine simple Zeitsteuerung geht auch darüberhinaus auf native Datenbanktreiber ein,
aktualisiert wird. die dann jedoch herstellerspezifisch sind. Hier müssen andere
Mechanismen angewandt werden, eine Integration elegant zu
3.2 Programmtechnische Integration vollziehen, die Prinzipien bleiben jedoch die gleichen. Auch
Oft halten sich Anwendungsprogrammierer an die Beispiele der bereits vorgestellte Ansatz, einen Proxy zu integrieren,
der Autoren der jeweiligen Datenbankschnittstelle. Jedoch der das Protokoll, welches das Datenbanksystem im Netz-
erlauben alle APIs auch eine freiere Nutzung, d. h., dass die werk verwendet, versteht, wurde weitergeführt und zeigte
Schrittfolge der Kommandos nicht festgelegt ist und es ver- sich bereits im Einsatz als wertvolle Hilfe. Das oben bereits
schiedene Gründe geben kann, die so aufgezeigten Standar- erwähnte Cardigo dient uns dabei als Werkzeugkasten, der
droutinen zu verwerfen. Listing 3 zeigt zunächst einen Stan- alle diese Möglichkeiten vereint.
dardweg auf. Für diesen wollen wir nun die Schritte, die ein
datenbankexterner Index verfolgen kann, aufzeigen:
• Statement vorbereiten (conn.prepareStatement(...)):
if Anfrage relevant then
Anfrage speichern
end if
• Variablen binden (ps.setInt(...)):
if Anfrage war relevant then
Bindung speichern
end if
• Statement ausführen (ps.executeQuery()):
if Anfrage war relevant then
Index anfragen
Indexergebnisse in DB laden
Anfrage modifizieren
Datenbank anfragen
end if
• Ergebnisse holen (rs.getString(...)):
hier sind keine weiteren Schritte notwendig
Beobachtungen an realen Programmen zeigen, dass das
Binden von Variablen teils mehrfach auf die gleichen Varia-
blen angewendet wird. Mit dem eben beschriebenen Verfah-
ren ist dies kein Problem. Auch Operationen, die ein State-
ment näher beschreiben, sind nach wie vor ausführbar, da
alle Bestandteile erhalten bleiben und nur Ergänzungen vor-
genommen werden.
86
Minimal-Invasive Indexintegration - Transparente Datenbankbeschleunigung
5. LITERATUR example and in detail, IBM Developer works DB2
library. Dec. 2003.
[1] A. Adam, S. Leuoth, and W. Benn. Nutzung von [21] Thedwick, LLC. jdbcgrabber. http://code.google.
Proxys zur Ergänzung von Datenbankfunktionen. In com/p/jdbcgrabber/.
W.-T. Balke and C. Lofi, editors, Grundlagen von
[22] C. Wege. Steps out of Integration Hell - Protocol
Datenbanken, volume 581 of CEUR Workshop
Interception Wrapper. In A. Rüping, J. Eckstein, and
Proceedings. CEUR-WS.org, 2010.
C. Schwanninger, editors, EuroPLoP, pages 455–458.
[2] E. Belden, T. Chorma, D. Das, Y. Hu, S. Kotsovolos, UVK - Universitaetsverlag Konstanz, 2001.
G. Lee, R. Leyderman, S. Mavris, V. Moore, M. Morsi,
C. Murray, D. Raphaely, H. Slattery, S. Sundara, and
A. Yoaz. Oracle Database Data Cartridge Developers
Guide, 11g Release 2 (11.2). Oracle, July 2009.
[3] P. Bruni, F. Bortoletto, R. Kalyanasundaram,
G. McGeoch, R. Miller, C. Molaro, Y. Ohmori, and
M. Parbs. DB2 10 for z/OS Performance Topics. IBM
Form Number SG24-7942-00, IBM Redbooks, June
2011.
[4] Desloch et al. PatNr. US 6,338,056 B1 – Relational
Database Extender that Supports User-Defined Index
Types and User-Defined Search, Apr. 1999.
[5] R. Elmasri and S. B. Navathe. Grundlagen von
Datenbanksystemen (3. Aufl., Bachelorausgabe).
Pearson Studium, 2009.
[6] M. Fisher, J. Ellis, and J. C. Bruce. JDBC API
Tutorial and Reference. Pearson Education, 3 edition,
2003.
[7] E. Gamma, R. Helm, R. Johnson, and J. Vlissides.
Design Patterns. Addison-Wesley, Boston, MA,
January 1995.
[8] IBM. SQL Reference, Volume 1. IBM Corporation,
Nov. 2009.
[9] IBM Deutschland GmbH. DB2 Spatial Extender und
Geodetic Data Management Feature – Benutzer- und
Referenzhandbuch, July 2006.
[10] T. Lahdenmäki and M. Leach. Relational database
index design and the optimizers: DB2, Oracle, SQL
server, et al. Wiley-Interscience, 2005.
[11] T. Langner and D. Reiberg. J2EE und JBoss:
Grundlagen und Profiwissen ; verteilte
Enterprise-Applikationen auf Basis von J2EE, JBoss
& Eclipse. Hanser, 2006.
[12] D. Lorentz and M. B. Roeser. Oracle Database SQL
Language Reference, 11g Release 2 (11.2). Oracle,
Oct. 2009.
[13] A. Martin and J. Goke. P6spy. http://sourceforge.
net/projects/p6spy/.
[14] C. Murray. Oracle Spatial Developers Guide, 11g
Release 2 (11.2). Oracle, Dec. 2009.
[15] G. Reese. Database Programming with JDBC and
Java, Second Edition. O’Reilly & Associates, Inc.,
Sebastopol, CA, USA, 2nd edition, 2000.
[16] B. Rich. Oracle Database Reference, 11g Release 2
(11.2), Sept. 2011.
[17] G. Saake, K.-U. Sattler, and A. Heuer. Datenbanken:
Konzepte und Sprachen, 3. Auflage. mitp-Verlag,
Redline GmbH, 2008.
[18] J. Shewmaker. Analyzing dll injection, 2006. GSM
Presentation, Bluenotch.
[19] M. Smedberg. Boilerplate JDBC Wrapper. http://
blog.redfin.com/devblog/2011/03/boilerplate_
jdbc_wrapper.html.
[20] K. Stolze and T. Steinbach. DB2 Index Extensions by
87
88
Self-Tuning Distribution of DB-Operations on Hybrid
CPU/GPU Platforms
Sebastian Breß Siba Mohammad Eike Schallehn
Otto-von-Guericke University Otto-von-Guericke University Otto-von-Guericke University
Magdeburg Magdeburg Magdeburg
bress@iti.cs.uni-magdeburg.de siba.mohammad@st.ovgu.de eike@iti.cs.uni-magdeburg.de
ABSTRACT 1.1 New Research Trend
A current research trend focuses on accelerating database A new research trend focuses on speeding up database
operations with the help of GPUs (Graphics Processing Units). operations by performing them on GPUs [4, 6, 13, 14].
Since GPU algorithms are not necessarily faster than their He et al. present the concept and implementation of rela-
CPU counterparts, it is important to use them only if they tional joins on GPUs [6, 7]. Pirk et al. develop an approach
outperform their CPU counterparts. In this paper, we ad- to accelerate indexed foreign key joins with GPUs [13]. The
dress this problem by constructing a decision model for a foreign keys are streamed over the PCIe bus while random
framework that is able to distribute database operations re- lookups are performed on the GPU. Walkowiak et al. dis-
sponse time minimal on CPUs and GPUs. Furthermore, cuss the usability of GPUs for databases [14]. They show the
we discuss necessary quality measures for evaluating our applicability on the basis of an n-gram based text search en-
model. gine. Bakkum et al. develop a concept and implementation
of the SQLite command processor on the GPU [4]. The main
target of their work is the acceleration of a subset of pos-
1. INTRODUCTION sible SQL queries. Govindaraju et al. present an approach
In the context of database tuning, there are many differ- to accelerate selections and aggregations with the help of
ent approaches for performance optimization. A new oppor- GPUs [5]. From the examples, we can conclude that a GPU
tunity for optimization was introduced with General Pur- can be an effective coprocessor for the execution of database
pose Computation on Graphics Processing Units (GPGPU) operations.
[12]. This approach allows to speed up applications that are
suited for parallel processing with the help of GPUs. Parallel 1.2 Problem Statement
computing architectures like compute unified device archi- We assume that an operation is executed through an algo-
tecture (CUDA) [12] make it possible to program a GPU rithm which uses either CPU or GPU. For which operations
almost as simple as a CPU. This technology opens a new and data is it efficient to execute database operations on a
branch in research that focuses on accelerating applications GPU? A GPU algorithm can be faster or slower as its CPU
using GPUs. counterpart. Therefore, the GPU should be used in a mean-
CPUs are optimized for a low response time, meaning ingful way to achieve maximal performance. That means,
that they execute one task as fast as possible. The GPU only if it is to be expected that the GPU algorithm is faster
is optimized for high throughput, meaning they execute as it should be executed.
many tasks as possible in a fixed time. This is accom- We do not know a priori which processing device (CPU
plished by massively parallel execution of programs by using or GPU) is faster for which datasets in a given hardware
multi threading. Furthermore, GPUs specialize on compute- configuration. We have to take different requirements into
intensive tasks, which is typical for graphics applications. account to determine the fastest processing device:
Additionally, tasks with much control flow decrease perfor-
• the operation to be executed,
mance on GPUs, but can be handled well by CPUs [12].
Consequently, database operations benefit differently by us- • the size of the dataset to process,
ing the GPU. Aggregations are most suited for GPU usage,
whereas selections should be outsourced with care. He et al. • the processing power of CPU and GPU (number of
observed that selections are 2-3 times slower on the GPU processor cores, clock rate), and
compared with the CPU [6]. • the current load condition on CPU and GPU.
The following contributions are discussed in the following:
1. A response time minimal distribution of database op-
erations on CPUs and GPUs can achieve shorter exe-
cution times for operations and speedup query execu-
tions. Hence, a basic idea how such a model can be
constructed is depicted in this paper.
24th GI-Workshop on Foundations of Databases (Grundlagen von Daten-
banken), 29.05.2012 - 01.06.2012, Lübbenau, Germany. 2. For the evaluation of our model, we define appropriate
Copyright is held by the author/owner(s). quality measures.
89
Self-Tuning Distribution of DB-Operations on Hybrid CPU/GPU Platforms
To the best of our knowledge, there is no self-tuning deci- mation function FA (D).
sion model that can distribute database operations response Model Components: The model is composed of three
time minimal on CPUs and GPUs. components. The first is the algorithm pool APO which
The remainder of the paper is structured as follows. In contains all available algorithm of an operation O. The sec-
Section 2, we present our decision model. Then, we discuss ond is the estimation component which computes execution
model quality metrics needed for evaluation in Section 3. time estimations for every algorithm of an operation. The
Section 4 provides background about related work. Finally, third part is the decision component which chooses the al-
we present our conclusion and future work. gorithm that fits best for the specified optimization criteria.
Depending on whether the chosen algorithm uses the CPU
2. DECISION MODEL or the GPU, the corresponding operation is executed on the
CPU or the GPU. In this paper, we only consider response
In this section, we present our decision model. At first,
time optimization. However, other optimization criteria like
we discuss the basic model. Then, we explain details of the
throughput can be added in future work. Figure 1 summa-
estimation and the decision components.
rizes the model structure.
2.1 Basic Model 2.2 Estimation Component
We construct a model that is able to choose the response
This section describes the functionality of the estimation
time minimal algorithm from a set of algorithms for process-
component. First, we discuss when the approximation func-
ing a dataset D. We store observations of past algorithm
tions of the algorithms should be updated. Second, we ex-
executions and use statistical methods to interpolate future
amine how the model can adapt to load changes.
execution times. We choose the algorithm with the smallest
estimated execution time for processing a dataset. 2.2.1 Updating the Approximation Functions
Definitions: Let O be a database operation and let APO =
For an operation O that will be applied on a dataset D
{A1 , .., Am } be an algorithm pool for operation O, i.e., a
the estimation component computes for each available algo-
set of algorithms that is available for the execution of O.
rithm of O an estimated execution time. For this, we need
We assume that every algorithm has different performance
an approximation function that can be used to compute esti-
characteristics. Hence, the execution times of different al-
mations. Since we learn such functions with statistical meth-
gorithms needed to process a dataset D are likely to vary.
ods, we need a number of observations for each algorithm
A data set D provides characteristic features of the input
to compute the corresponding approximation functions. Af-
data. In this paper, we consider only the data size. Other
ter we computed an initial function for each algorithm, our
characteristics, e.g., data distribution or data types will be
model is used to make decisions. Hence, the model opera-
considered in future work.
tion can be divided into two phases. The first is the initial
Let TA (D) be the execution time of an algorithm to pro-
training phase. The second is the operational phase.
cess the dataset D. We do not consider hardware specific
Since the load condition can change over time, execution
parameters like clock rate and number of processor cores to
times of algorithms are likely to change as well. Hence, the
estimate execution times. Instead, we learn the execution
model should provide a mechanism for an adoption to load
behavior of every algorithm. For this purpose, we assign to
changes. Therefore, the model continuously collects mea-
every algorithm A a learning method LA and a correspond-
surement pairs of all executed algorithms of an operation.
ing approximation function FA (D). Let Test (A, D)=FA (D)
There are two problems to solve:
be an estimated execution time of algorithm A for a dataset
D. A measured execution time is referred to as Treal (A, D). 1. Re-computation Problem: find a strategy when to
Let a measurement pair (MP) be a tuple (D,Treal (A, D)). re-compute the approximation function for each algo-
Let M P LA be a measurement pair list, containing all cur- rithm, so that a good trade-off between accuracy and
rent measurement pairs of algorithm A. overhead is achieved.
Statistical Methods: We consider the following statis-
tical methods for the approximation of the execution be- 2. Cleanup Problem: delete outdated measurements
havior of all algorithms. The first one is the least squares pairs from a measurement pair list because the consi-
method and the second is spline interpolation with cubic deration of measurement pairs from past load condi-
splines [3]. We use these approaches because we observe in tions is likely to be less beneficial for estimation ac-
our experiments minimal overhead and a good accuracy (rel- curacy. Furthermore, every measurement pair needs
ative error < 10%) of the estimated execution times. While storage space and results in higher processing time for
other methods can learn the execution behavior depending the statistical methods.
on more than one feature, they often need a large amount of
time for updating approximation functions and computing There are different heuristics that deal with the re-com-
estimations, see Section 4. In the case of the least square putation of approximation functions. Zhang et al. present
method FA (D) is a polynomial of degree n. In the case of possible approaches in [15]. These are:
cubic splines, FA (D) is a spline.
Abstraction: The execution time of algorithms is highly 1. Re-compute the approximation function always after a
dependent on specific parameters of the given processing new measurement pair was added to the measurement
hardware. In practice, it is problematic to manage all pa- pair list.
rameters, so maintenance would become even more costly. 2. Re-compute the approximation function periodically.
Hence, we do not consider hardware specific parameters and
let the model learn the execution behavior of algorithms us- 3. Re-compute the approximation function, if the estima-
ing statistical method LA and the corresponding approxi- tion error exceeds a certain threshold.
90
Self-Tuning Distribution of DB-Operations on Hybrid CPU/GPU Platforms
operation O dataset D optimization criterion
A1, Test(A1,D),
A2,..., Test(A2,D),...,
algorithm pool An estimation component Test(An,D)
CPU GPU MPLA1 ... MPLAi ... MPLAn
decision component
MP=(D,Treal(Ai))
Ai
Figure 1: Information flow in the model
As Zhang et al. point out, the most aggressive method is Self Tuning Cycle: The model performs the following
unlikely to achieve good results because the expected over- self tuning cycle during the operational phase:
head for re-computing the approximation function counter-
acts possible performance gains. Hence, we have to choose 1. Use approximation functions to compute execution time
between approach 2 and 3. There is no guarantee that one estimations for all algorithms in the algorithm pool of
approach causes less overhead than the other. operation O for the dataset D.
On one hand, periodic re-computation causes a predictable
overhead, but it may re-compute approximation functions 2. Select the algorithm with the minimal estimated re-
when it is not necessary, e.g., the relative estimation error sponse time.
is still beneath an error threshold. On the other hand, an
3. Execute the selected algorithm and measure its execu-
event based approach re-computes the approximation func-
tion time. Add the new measurement pair to the mea-
tions only if it is necessary, but has the disadvantage, that
surement pair list M P LA of the executed algorithm
the quality of estimations has to decrease until the approx-
A.
imation functions are re-computed. We choose the periodic
approach, because of it’s predictable overhead. We will con- 4. If the new measurement pair is the RCR new pair in
sider the event based approach in future work. the list, then the approximation function of the cor-
Parameters: Now we discuss necessary parameters of responding algorithm will be re-computed using the
the model. Let RCR be the re-computation rate of an algo- assigned statistical method.
rithm. That means that after RCR measurement pairs were
added to the measurement pair list of an algorithm A, the 2.2.2 Adaption to Load Changes
approximation function FA (D) of A is re-computed.1 Hence, This section focuses on the adaption to load changes of the
the used time measure is the number of added measurement model. We start with necessary assumptions, then proceed
pairs. Let ITL be the initial training length, which is the with the discussion how the model can adapt to new load
number of measurement pairs that have to be collected for conditions.
each algorithm, before the model switches into its opera- Let ACP U be a CPU algorithm and AGP U a GPU algo-
tional phase. rithm for the same operation O.
Now we address the Cleanup Problem. We have to limit The basic assumptions are:
the number of measurement pairs in the measurement pair
list to keep space and computation requirements low. Fur- 1. Every algorithm is executed on a regular basis, even in
thermore, we want to delete old measurement pairs from the overload conditions. That ensures a continuing supply
list that do not contribute to our current estimation problem of new measurement pairs. If this assumption holds
sufficiently. These requirements are fulfilled by a ring buffer then a gradual adaption of the approximation func-
data structure. Let RBS be the ring buffer size in number of tions to a changed load condition is possible.
measurement pairs. If a new measurement pair is added to
a full ring buffer, it overrides the oldest measurement pair. 2. A change in the load condition has to last a certain
Hence, the usage of a ring buffer solves the Cleanup Problem. amount of time, otherwise the model cannot adapt
RCR and RBS are related because if RCR is greater than and delivers more vague execution time estimations.
RBS there would be measurement pairs that are never con- If this assumption does not hold, it is not possible to
sidered for computing the approximation functions. Hence, continuously deliver good estimations.
RCR should be smaller than RBS .
Statistical Methods: The used statistical methods have 3. The load condition of CPU and GPU are not related.
to be computationally efficient when computing approxima-
tion functions and estimation values. Additionally, they As long as the assumptions are fulfilled, the estimated exe-
should provide good estimations (relative estimation error cution time curves2 approach the real execution time curves
<10%). Since the times needed to compute estimations if the load changes. Increase and decrease of the load con-
sums up over time, we consider a method computationally dition on the side of the CPU is symmetric compared to an
efficient if it can compute one estimation value in less than equivalent change on the side of the GPU. For simplicity, but
50µs. Our experiments with the ALGLIB [2] show that this without the loss of generality, we discuss the load adaption
is the case for the least squares and cubic splines. mechanism for the CPU side.
2
An execution time curve is the graphical representation of
1
For each operation one measurement pair is added to the all execution times an algorithm needs to process all datasets
list of the selected algorithm. in a workload.
91
Self-Tuning Distribution of DB-Operations on Hybrid CPU/GPU Platforms
Treal(AGPU,D) Treal(AGPU,D)
Treal(ACPU,D) Treal(ACPU,D)
Test (ACPU,D) Test (ACPU,D)
execution time
execution time
data size data size
Figure 2: Example for increase load condition on Figure 3: Example for strong increase of load on
CPU side CPU side
Increasing Load Condition: If the load condition in- 2.3 Decision Component
creases on the side of the CPU then the execution times of In this section, we describe the decision component of our
CPU algorithms increase and the real execution time curves model. Due to limited space, we introduce only one opti-
are shifted upwards. In contrast, the estimated execution mization criterion, namely response time, but other criteria
time curves stay as they are. We illustrate this situation in like throughput are possible.
Figure 2. The model is adapted to the new load condition
by collecting new measurement pairs and recomputing the 2.3.1 Response Time Optimization
approximation function. This will shift the estimated execu- If we optimize the operation execution for response time,
tion time curve in the direction of the measured execution we want to select the algorithm with the minimal execu-
time curve. Hence, the estimations become more precise. tion time for the dataset D. In choosing the algorithm with
After at maximum RCR newly added measurement pairs the minimal execution time, we distribute the operation re-
for one algorithm the estimated execution time curve ap- sponse time minimal to CPU and GPU. There is always one
proaches the real execution time curve. This implies the as- decision per operation that considers the size of the dataset
sumption that a re-computation of approximation functions that has to be processed.
never has a negative impact on the estimation accuracy. Definition: Let a workload W be a tuple W = (DS, O),
Decreasing Load Condition: The case of a decreasing where DS = D1 , D2 , · · · , Dn is a set of datasets Di that are
load is mostly symmetric to the case of increased load. A to be processed and O the operation to be executed.3
decreased load on CPU side causes shorter execution time Goal: The goal is to choose the fastest algorithm Aj ∈
of CPU algorithms. The consequence is that real execution APO for every dataset Di ∈ DS for the execution of opera-
time curves are shifted downwards, whereas the estimated tion O.
execution time curves stay as they are.
Limits of the Adaption: There is the possibility that X
the described load adaption scheme can break, if the load min = Treal (Ak , Di ) with Ak ∈ APO (1)
on CPU side increases or decreases too much. We consider Di ∈DS
the case, where the load increases too much, the other case Usage: The algorithm with the minimal estimated exe-
is symmetric. In Figure 3, we illustrate the former case. cution time for the dataset D is chosen for execution. The
Hence, the real execution time curve of ACP U lies above the function choose Algorithm (choose Alg) chooses an algorithm
real execution time curve of AGP U . according to the optimization criterion.
If this state continues to reside a certain amount of time,
the estimated execution time curves will approach the real
execution time curves. If the load condition normalizes choose Alg(D, O) = Aj with (2)
again, then only algorithm AGP U is executed, regardless of Test (Aj , D) = min({Test (Ak , D)|∀Ak ∈ APO })
datasets that can be faster processed by algorithm ACP U .
The model is now stuck in an erroneous state since it can- It is expected that the accuracy of the estimated execution
not make response time minimal decisions for operation O times has a large impact on the decisions and the model
anymore. quality.
However, this cannot happen due to the assumption that Practical Use: The execution of the fastest algorithm
every algorithm is executed on a regular basis, even in over- reduces the response time of the system and results in better
load conditions. Hence, a continuing supply of new mea- performance of a DBS. These response time optimization is
surement pairs is ensured which allows the adaption of the necessary to accelerate time critical tasks4 . Furthermore, it
3
model to the current load condition. For simplicity, we only consider one operation per work-
load. However, a set of operations is more realistic and can
be added in future work.
4
A task is an operation in execution.
92
Self-Tuning Distribution of DB-Operations on Hybrid CPU/GPU Platforms
is possible to automatically fine-tune algorithm selection on Let DMideal be the ideal decision model and let DMreal
a specific hardware configuration. be the real decision model. Then, the model quality MQ is
defined as:
3. MODEL QUALITY CRITERIA
In this section, we present four model quality measures, TDMideal (W )
M Q(W, DMreal ) = (5)
namely average percentage estimation error, hit rate, model TDMreal (W )
quality, and percentage speed increase. This measure describes to which degree the optimization
goal described in formula 1 is achieved. Note, that the ideal
3.1 Average Percentage Estimation Error model is not introducing overhead (TOh (DMideal , W ) = 0).
The idea of the average percentage estimation error is to
compute the estimation error for each executed algorithm 3.4 Percentage Speed Increase
and the corresponding estimation value. Then, the abso-
The idea of the percentage speed increase (PSI) is to quan-
lute percentage estimation error is computed. Finally, the
tify the performance gain, if a decision model DMi is re-
average of all computed percentage estimation errors is com-
placed with a decision model DMj .
puted. This measure is also called relative error and is used,
e.g., in [1].
TDMi (W ) − TDMj (W )
P SI(DMi → DMj , W ) = (6)
3.2 Hit Rate TDMi (W )
The idea of this measure is to compute the ratio of the
If P SI(DMi → DMj , W ) is greater than zero, DMj had a
number of correct decisions and the total number of deci-
better performance than DMi and vice versa.
sions. A decision is correct, if and only if the model decided
for the fastest algorithm. In the ideal case all decisions are
correct, so the hit rate is 100%. In the worst case all de- 4. RELATED WORK
cisions are wrong. Hence, the hit rate is 0%. The benefit In this section, we present the related work. We con-
of the hit rate is that it can provide statistical information sider analytical models for estimating execution times of
about how many decisions are wrong. If the hit rate is X GPU algorithms. Furthermore, we discuss learning based
then every 1/(1-X) decision is incorrect. However, we can- approaches to estimate execution times. Finally, we present
not quantify the impact of an incorrect decision. This is existing decision models and provide a comparison to our
addressed by the model quality. Note, that algorithms with approach.
very similar execution time curves can lead to a bad hit rate, Analytical Models Hong et al. present an analytical
although the overall performance is acceptable. model which estimates execution times of massively parallel
programs [8]. The basic idea is to estimate the number of
3.3 Model Quality parallel memory requests. The approach uses information
The idea of the model quality is to compute the ratio of like number of running threads and the memory bandwidth.
the resulting execution times that a system using an ideal Depending on their case study, relative estimation errors
model and a real model needs to process a workload W . between 5,4% and 13,3% are observed.
In the ideal case, the real model would be as good as the Zhang et al. develop a model that should help optimizing
ideal model. Hence, the model quality is 100%. The worst GPU programs by arranging qualitative performance analy-
case model would always select the slowest algorithm and ses [16]. They use a micro benchmark-based approach which
provides a lower bound for the model quality. needs hardware specific parameters, e.g., the number of pro-
Let TDM (W ) be the time a system using a decision model cessors or the clock rate. The model cannot adapt to load
(DM ) needs to process a workload W . It is computed out of changes and therefore, it is not considered for use in our ap-
the sum of all algorithm execution times resulting from the proach. The observed relative estimation error lies between
algorithm selection of the decision model for the workload 5% and 15%.
added with the overhead caused by DM . Let TOh (DM, W ) Learning based Execution Time Estimation Akdere
be the overhead the decision model DM causes. If a decision et al. investigate modeling techniques for analytical work-
model introduces to much overhead, it can eliminate their loads [1]. They estimate the execution behavior of queries
gain. Hence the overhead has to be considered, which is the on the basis of different granularities. They presented a
sum of the total time needed for computing estimation val- modeling approach for the estimation on query level and
ues and the total time needed to re-compute approximation operation level. The basic idea of their approach is to per-
functions. The time needed for all estimation value compu- form a feature extraction on queries and compute execution
tation (EVC) for a workload W is TEVC (W ). The time needed time estimations based on them.
to re-compute the approximation functions of all algorithms Matsunaga et al. present a short overview over machine
is TRC (W ). Both measures are highly dependent on DM . learning algorithms and their fields of application [11]. The
Hence, we get the following formulas: goal is the estimation of the resource usage for an applica-
tion. One considered resource is the execution time. The
developed method PQR2 needs a few milliseconds for the
TOh (DM, W ) = TEVC (W ) + TRC (W ) (3) computation of estimations. Since we need for n datasets
X and m algorithms n·m computations the time for a single
TDM (W ) = Treal (choose AlgDM (D, O), D) (4)
computation should be less than 50µs to keep the overhead
D∈DS
at an absolute minimum. Hence, the approach of Matsunaga
+ TOh (DM, W ) et al. is to be investigated, whether it achieves good results
93
Self-Tuning Distribution of DB-Operations on Hybrid CPU/GPU Platforms
for a response time minimal operation distribution. This model from operations to queries is necessary for better ap-
can be done in future work. plicability of our model. This leads to the problem of hybrid
Zhang et al. present a model for predicting the costs of query plan optimization.
complex XML queries [15]. They use the statistical learn-
ing method called ”transform regression technique”. The 6. REFERENCES
approach allows a self-tuning query optimizer that can dy-
[1] M. Akdere and U. Çetintemel. Learning-based query
namically adapt to load condition changes. The approach
performance modeling and prediction. IEEE, 2012.
of Zhang and our model are similar in basic functionalities.
The difference to our approach is that Zhang et al. estimate [2] ALGLIB Project. ALGLIB. http://www.alglib.net/,
the execution time of XML queries whereas our approach 2012. [Online; accessed 05-January-2012].
estimates execution times of single database operations to [3] P. R. Anthony Ralston. A first course in numerical
dynamically distribute them on CPU and GPU. Addition- analysis. dover publications, second edition, 2001.
ally, we use a different learning method that is optimized for [4] P. Bakkum and K. Skadron. Accelerating sql database
computational efficiency. operations on a gpu with cuda. GPGPU ’10, pages
Decision Models Kerr et al. present a model that pre- 94–103, New York, NY, USA, 2010. ACM.
dicts the performance of similar application classes for differ- [5] N. K. Govindaraju, B. Lloyd, W. Wang, M. Lin, and
ent processors [10]. The approach allows to choose between D. Manocha. Fast computation of database operations
CPU and GPU implementation. This choice is made stat- using graphics processors. SIGMOD ’04, pages
ically in contrast to our work, where an algorithm for an 215–226, New York, NY, USA, 2004. ACM.
operation execution is chosen dynamically at runtime. Kerr [6] B. He, M. Lu, K. Yang, R. Fang, N. K. Govindaraju,
et al. are using only parameters that are statically known Q. Luo, and P. V. Sander. Relational query
before program execution. Hence, it allows no adaption to coprocessing on graphics processors. ACM Trans.
load changes in contrast to our model that allows load adap- Database Syst., 34:21:1–21:39, December 2009.
tion. [7] B. He, K. Yang, R. Fang, M. Lu, N. Govindaraju,
Iverson et al. develop an approach that estimates execu- Q. Luo, and P. Sander. Relational joins on graphics
tion times of tasks in the context of distributed systems [9]. processors. SIGMOD ’08, pages 511–524, New York,
The approach, similar to our model, does not require hard- NY, USA, 2008. ACM.
ware specific information. They use the learning method k- [8] S. Hong and H. Kim. An analytical model for a gpu
nearest-neighbor, a non-parametric regression method. We architecture with memory-level and thread-level
use least squares and cubic splines that are parametric re- parallelism awareness. ACM SIGARCH Computer
gression methods which need less time for computing esti- Architecture News, 37(3):152, 2009.
mations compared to non parametric regression methods. [9] M. A. Iverson, F. Ozguner, and G. J. Follen. Run-time
The goal of Iverson et al. is an optimal selection of nodes statistical estimation of task execution times for
in a distributed system, where a task is executed. Unlike heterogeneous distributed computing. HPDC ’96,
this approach, our work has the goal for optimal algorithm pages 263–270, Washington, DC, USA, 1996. IEEE
selection. It is possible to apply the approach of Iverson et Computer Society.
al. on hybrid CPU/GPU platform. However, we consider, [10] A. Kerr, G. Diamos, and S. Yalamanchili. Modeling
the GPU is a coprocessor of the CPU. Hence, a CPU/GPU gpu-cpu workloads and systems. GPGPU ’10, pages
platform is not a distributed system from our point of view. 31–42, New York, NY, USA, 2010. ACM.
In a way, our model is less general than the model of Iverson
[11] A. Matsunaga and J. A. B. Fortes. On the use of
et al.
machine learning to predict the time and resources
consumed by applications. CCGRID, pages 495–504,
5. CONCLUSION 2010.
In this paper, we addressed a current research problem, [12] NVIDIA. NVIDIA CUDA C Programming Guide.
namely the optimal distribution of database operations on http://developer.download.nvidia.com/compute/
hybrid CPU/GPU platforms. Furthermore, we develop a DevZone/docs/html/C/doc/CUDA_C_Programming_
self-tuning decision model that is able to distribute database Guide.pdf, 2012. pages 1–5, Version 4.0, [Online;
operations on CPUs and GPUs in a response time mini- accessed 1-February-2012].
mal manner. We discuss the basic structure of the model [13] H. Pirk, S. Manegold, and M. Kersten. Accelerating
and provide a qualitative argumentation of how the model foreign-key joins using asymmetric memory channels.
works. Additionally, we present suitable model quality mea- ADMS ’11, pages 585–597. VLDB Endowment, 2011.
sures, which are required to evaluate our model. Our exper- [14] S. Walkowiak, K. Wawruch, M. Nowotka, L. Ligowski,
iments show that our model is almost as good as the ideal and W. Rudnicki. Exploring utilisation of gpu for
model if the model parameters are set appropriately. We database applications. Procedia Computer Science,
omit the evaluation due to limited space. We conclude that 1(1):505–513, 2010.
distributing database operations on CPUs and GPUs has [15] N. Zhang, P. J. Haas, V. Josifovski, G. M. Lohman,
a large optimization potential. We believe our model is a and C. Zhang. Statistical learning techniques for
further step to address this issue. costing xml queries. VLDB ’05, pages 289–300. VLDB
In ongoing research, we use the defined quality measures Endowment, 2005.
to evaluate our model on suitable use cases. A further pos-
[16] Y. Zhang and J. D. Owens. A quantitative
sible extension is using the model in a more general context,
performance analysis model for gpu architectures.
where response-time optimal decisions have to be made, e.g.,
Computer Engineering, pages 382–393, 2011.
an optimal index usage. Furthermore, an extension of the
94