Conference PaperPDF Available

Einen Schritt zurück zum negativen Datenbank-Caching.

Authors:
Einen Schritt zurück zum negativen Datenbank-Caching
Andreas Bühmann
Fachbereich Informatik
Technische Universität Kaiserslautern
Gottlieb-Daimler-Straße
D-67663 Kaiserslautern
buehmann@informatik.uni-kl.de
Zusammenfassung: Ein Schlüssel zur Erhöhung der Qualität von Web-Anwendun-
gen ist Caching. Während das Web-Caching Dokumentfragmente bereithält, die zu-
nehmend aus Datenbank-Daten generiert werden, richtet sich das Datenbank-Caching
auf die redundante Speicherung dieser Daten selbst. Eine adaptiv verwaltete Teilmen-
ge der Backend-Daten ermöglicht im Cache durch Vollständigkeitseigenschaften die
korrekte Auswertung von Anfragen.
In Cache Groups für Gleichheitsprädikate, einer Ausprägung des Constraint-ba-
sierten Datenbank-Caching, kann die Auswertbarkeit einer Anfrage durch einfache
Sondierungsanfragen auf dem Cache-Inhalt entschieden werden. Wir stellen ein neues
Sondierungsverfahren vor, das den Cache flexibler und für eine größere Anzahl von
Anfragen nutzbar macht; dazu gehören unter dem Begriff des negativen Caching auch
Anfragen mit leerem Ergebnis.
Wir untersuchen, ob sich das neue Sondierungsverfahren weiter verallgemeinern
lässt, welche Alternativen sich für seine Umsetzung in konkreten Cache Groups bieten
und wie sich der bisherige Ansatz darin einordnet. Das neue Verfahren macht weiterhin
eine Schwäche in der bisherigen Struktur von Cache Groups deutlich, die durch die
Einführung von Kontrolltabellen behoben wird, und verschiebt den Schwerpunkt bei
der statischen Analyse.
1 Constraint-basiertes Datenbank-Caching
Web-Anwendungen finden heutzutage in den verschiedensten Bereichen ihren Einsatz. Es
gibt kaum eine Anwendung, die noch nicht durch Hinzufügen des Präfixes »E-« neu er-
funden wurde. Immer mehr solcher (welt-)weit verteilten Anwendungen entstehen; im-
mer mehr weltweit verteilte Benutzer erwarten von diesen Anwendungen den gewohnten
Komfort: Kurze Reaktionszeiten, Interaktivität der Bedienung, Aktualität der Information,
Zuschnitt auf persönliche Bedürfnisse und ständige Verfügbarkeit des Dienstes.
Auf der anderen Seite haben Anbieter solcher Dienste mit der Erfüllung dieser Anfor-
derungen zu kämpfen: Ein immer größerer Anteil der dem Benutzer präsentierten Informa-
tion beruht auf Daten, die um ihrer Beherrschbarkeit willen in einem zentralen Datenbank-
system verwaltet werden. Alle Wege von den zahlreichen Benutzern zu den Daten (über
Zwischenstationen wie die Anwendungslogik) treffen sich hier, und diese Wege sind lang.
Ein allgemeines Mittel zur Verkürzung solcher Wege ist der Einsatz von Caching.
107
Caching bietet immer dann Vorteile, wenn Benutzer mehrfach auf von ihnen benötig-
te (unveränderte) Daten zugreifen, die sich normalerweise auf einem entfernten Server
(Backend) befinden. Durch Zwischenspeicherung dieser häufig nachgefragten Daten nahe
bei den Benutzern ermöglicht Caching eine Verringerung der Latenzzeit für die Abfra-
ge der Daten, eine Reduktion der Kommunikationskosten, eine Entlastung des Backends
sowie eine Steigerung der Skalierbarkeit und Verfügbarkeit des Gesamtsystems.
Der Nutzen von Web-Caching [VR02], also dem Caching von statischen oder von der
Anwendungslogik generierten Dokumenten oder deren Fragmenten, ist unabstreitbar, aber
begrenzt. Zwei Fragmente, die zwar im Wesentlichen auf denselben Daten basieren (etwa
eine Liste in zwei unterschiedlichen Sortierungen), gelten für den Web-Cache, der sich ir-
gendwo auf dem Weg zwischen Benutzer und Anwendungslogik befindet, als verschieden.
Das Datenbank-Caching konzentriert sich deswegen auf den anderen Teil des Weges,
den von der Anwendungslogik zur Datenbank: Ein Datenbank-Cache (Cache) enthält eine
in letzter Zeit häufig benutzte Teilmenge der Backend-Datenbank, und zwar nicht wie ein
Datenbank-Puffer auf der Ebene referenzierter Seiten, sondern in einer Form, die eine
Anfragebearbeitung auf dem Cache-Inhalt zulässt [HB04a]. Der Cache sollte auf SQL-
Ebene transparent für den Benutzer sein, und unter anderem deshalb bietet es sich an,
ihn als Erweiterung eines vollständigen Datenbankverwaltungssystems zu realisieren. (Wir
bewegen uns im Folgenden in der Welt der relationalen Datenbanksysteme mit SQL als
Anfragesprache, aber die generellen Prinzipien des Datenbank-Caching lassen sich auch
auf andere Datenmodelle übertragen.)
Im Gegensatz zu Ansätzen, denen die Wartung recht starr definierter materialisierter
Sichten zugrunde liegt [HB04a], strebt das Constraint-basierte Datenbank-Caching eine
adaptive Verwaltung des Cache-Inhalts an: Dieser soll sich an den in den Vergangenheit
nachgefragten Daten orientieren. Wir konzentrieren uns im Folgenden auf die Fragen, wie
ein solcher Constraint-basierter Cache beschrieben und mit Daten gefüllt wird und, vor
allem, wie wir mit Hilfe des Cache-Inhalts in möglichst flexibler Art und Weise Anfragen
beantworten können.
Im verbleibenden Teil von Abschnitt 1 führen wir zunächst die grundlegenden Begrif-
fe zur Beschreibung eines Datenbank-Caches ein, der auf Gleichheitsprädikaten basiert.
In Abschnitt 2 zeigen wir, wie man bisher Anfragen in einem solchen Cache bearbeitet
hat. Zentral ist dabei das Verfahren zur Entscheidung, ob eine Anfrage überhaupt korrekt
beantwortet werden kann, die Sondierung. Wir stellen im darauf folgenden Abschnitt 3 ei-
ne Verbesserung dieses Sondierungsverfahrens vor, die eine flexiblere Nutzung des Cache-
Inhalts erlaubt und das Phänomen des negativen Caching ans Licht bringt. In den weiteren
Unterabschnitten diskutieren wir die Eigenschaften dieses Verfahrens und mögliche Op-
timierungen. Schließlich zeigen wir vor einer Zusammenfassung in Abschnitt 4, wie das
Verfahren die Cache-Beschreibung zu vereinheitlichen hilft und welche neue Bedeutung
es einer statischen Analyse der Cache-Struktur verleiht.
1.1 Cache Groups
Beim Constraint-basierten Datenbank-Caching wird ein Ausschnitt der Backend-Daten-
bank im Cache abgebildet. Die statische Struktur dieses Ausschnitts wird in Form von
108
Cache Groups beschrieben.
Eine Cache Group besteht aus einer Menge von Cache-Tabellen sowie einer Menge
von Constraints. Die Cache-Tabellen repräsentieren eine Auswahl von Backend-Tabellen
im Cache und stimmen mit ihnen im Schema überein. Eine Cache-Tabelle enthält stets
eine Teilmenge vollständiger Sätze aus der ihr zugeordneten Backend-Tabelle.
Wir bezeichnen im Folgenden Cache-Tabellen mit Großbuchstaben (S,T,...) und ihre
Spalten mit Kleinbuchstaben (e,q1,...). Die diesen zugeordneten Backend-Tabellen und
-Spalten tragen die gleichen Namen, ergänzt um einen Index B (SB,TB,eB,q1B,...). Wo es
auf die Zuordnung von Spalten zu Tabellen ankommt, kann dem Namen einer Spalte eder
Name der Tabelle Svorangestellt werden, in der eenthalten ist (S.e).
Die Constraints einer Cache Group beschreiben die Inhalte sowie die Abhängigkeiten
zwischen den Inhalten der einzelnen Cache-Tabellen und definieren so gültige Zustände
des Caches. Die Eigenschaften dieser Zustände können dann herangezogen werden, um
zu entscheiden, ob eine gegebene Anfrage aus dem Cache beantwortet werden kann. Con-
straints werden mit dem Ziel definiert, bestimmte Anfragetypen zu unterstützen und dabei
zu gewährleisten, dass die Beantwortbarkeit von Anfragen leicht entschieden werden kann.
Indem der Cache alle definierten Constraints durchsetzt, sorgt er dafür, dass sich die
Extensionen bestimmter Prädikate im Cache befinden; er stellt so deren Prädikatsvollstän-
digkeit im Cache her [HB04a, HB04d]. Unter der Extension eines Prädikats pverstehen
wir dabei die Menge all derer Sätze, die zur Auswertung von pbenötigt werden.
1.2 Gleichheitsprädikate
Ein einfacher, aber nützlicher Typ von Cache Groups basiert auf Gleichheitsprädikaten
[ABK+03, BAM+04]. Wir betrachten dazu einfache PSJ-Anfragen (nur zusammengesetzt
aus Projektion, Selektion und Join). Gleichheitsprädikate in einer PSJ-Anfrage können
zum einen eine Spalte S.eauf einen Wert wfixieren (S.e=w) und zum anderen Equijoins
zwischen zwei Spalten S.aund T.bspezifizieren (S.a=T.b).
Im Kern sollen Cache Groups, die auf Gleichheitsprädikaten basieren, Anfragen unter-
stützen, die die Gestalt einer Kette
T1.s1=wT1.r1=T2.s2T2.r2=T3.s3···∧Tn1.rn1=Tn.sn
für bestimmte Folgen s1,r1,s2,...,snvon Spalten und ausgewählte Werte whaben. (Wenn
wir von einem Prädikat als Anfrage sprechen, meinen wir immer eine PSJ-Anfrage, die
sich nur auf die im Prädikat referenzierten Tabellen bezieht; die Projektion ist unwich-
tig und deswegen beliebig.) Zur Unterstützung solcher Prädikate sind deren Extensionen
vollständig im Cache zu halten. Zur Menge der so unterstützten Anfragen kommen in
natürlicher Weise weitere Anfragen hinzu, etwa Vereinigungen und Schnitte der Kernan-
fragen oder Einschränkungen durch zusätzliche per Konjunktion angebundene Prädikate.
Zusätzlich zeigt sich später, dass die gewählten Constraints weitere Anfragen unterstützen
(auch von der Form der Kernanfragen, aber für weitere Spaltenkombinationen).
Im Rest dieses Abschnittes führen wir die verschiedenen Objekte und Constraints ein,
die den skizzierten Anfragetyp unterstützen. Wie sie das im Einzelnen tun, betrachten wir
erst in Abschnitt 2.
109
Zur Unterstützung des Anfangsstücks T1.s1=wder Anfragen und als Mechanismus,
um den Cache mit Daten zu füllen, führt man Füllspalten ein. Eine Füllspalte ist eine Spal-
te einer Cache Group, über die das Füllen der Cache Group mit Sätzen aus dem Backend
gesteuert wird. Mit einer Füllspalte f(hier T1.s1) ist eine Menge von Kandidatenwerten,
die Kandidatenmenge, assoziiert; diese Kandidatenwerte stellen Werte wdar, die bei einer
Referenz f=w(enthalten in einer Anfrage, die den Cache erreicht) aus dem Backend
in den Cache geladen und dort wertvollständig gemacht werden. (»Laden eines Wertes«
bedeutet immer das Laden ganzer Sätze, die diesen Wert enthalten.)
Definition 1. Ein Wert wheißt wertvollständig (oder kurz vollständig) in einer Spalte S.e
genau dann, wenn alle Sätze aus σe=wSBin Ssind.
Im einfachsten Fall umfasst die Kandidatenmenge einer Füllspalte fden gesamten
Wertebereich aus der Schemadefinition von f(und damit von fB). Man kann jedoch zum
Beispiel Werte mit einer geringen Selektivität, also Werte, die in einem großen Anteil der
Sätze auftreten, aus der Kandidatenmenge ausschließen, damit diese nicht das aufwendige
Laden all dieser Sätze in den Cache bewirken.
Um sicherzugehen, dass jeder Wert aus der Kandidatenmenge, der in der Füllspalte im
Cache gefunden wird, dort auch vollständig ist, muss die Vollständigkeit auch für Werte
hergestellt werden, die auf indirekten Wegen in die Füllspalte gelangen (nicht durch Einfü-
gen nach einer Anfragereferenz, sondern zur Erfüllung anderer Constraints). Die Vollstän-
digkeit von Werten ist wichtig, um Gleichheitsprädikate auf einer Spalte korrekt im Cache
auswerten zu können (siehe Abschnitt 2).
In der Regel lassen wir nur eine einzige Füllspalte pro Cache Group zu; wir wol-
len eine solche Cache Group hier einfach nennen. Sollen allerdings mehrere einfache
Cache Groups parallel in einem Cache unterstützt werden, ist eine Verschmelzung der ver-
schiedenen Cache Groups nötig, damit jede Backend-Tabelle höchstens einmal im Cache
repräsentiert ist. Die so entstehende Struktur, auch als Cache-Group-Föderation bezeich-
net, hat viele Eigenschaften mit einfachen Cache Groups gemein. Da die Unterscheidung
für die folgenden Betrachtungen ohne Belang ist, sprechen wir auch dann (nur) von einer
Cache Group, wenn mehrere Füllspalten existieren.
Zur Unterstützung der Equijoins Ti.ri=Ti+1.si+1, also zur Konstruktion von gegen-
über T1.s1=werweiterten Prädikatsextensionen, wird ein Typ von Constraints eingeführt,
der eine Beziehung zwischen zwei Cache-Tabellen herstellt: Ein referentieller Cache-Con-
straint (RCC)verknüpft zwei Spalten über eine Werte-Beziehung.
Definition 2. Ein RCC S.aT.bvon Quellspalte S.azu Zielspalte T.bist genau dann
erfüllt, wenn alle Werte waus S.avollständig in T.bsind.
Mit anderen Worten sorgt ein RCC also dafür, dass zu Sätzen in Salle Join-Partner
aus TBbezüglich S.a=T.bebenfalls im Cache sind.
Eine wesentliche Aufgabe der Cache-Verwaltung besteht darin, die Einhaltung der
Constraints zu jeder Zeit sicherzustellen. Dazu sind bei Änderungen des Cache-Inhalts,
etwa bei Einfügung eines neuen Wertes in eine Füllspalte, Folgeänderungen in den üb-
rigen Tabellen durchzuführen, um beispielsweise die RCCs zu erfüllen. Gleiches gilt für
die Entfernung (durch Invalidierung oder Verdrängung) oder Änderung von Sätzen. Der
damit verbundenen Problematik (beispielsweise können die von verschiedenen Kandida-
tenwerten abhängigen Satzmengen überlappen [HB04c]) wollen wir uns hier nicht nähern,
110
sondern konzentrieren uns auf die Beantwortung von Anfragen aus Cache Groups, die auf
Gleichheitsprädikaten basieren.
2 Anfragebearbeitung im Cache
Alle Mechanismen zur Verwaltung des Cache-Inhalts sind ohne Wert, wenn der damit
verbundene Aufwand nicht kompensiert wird, indem möglichst viele Anfragen (oder Teile
davon) mit Hilfe dieses Inhalts beantwortet werden können.
Beim Constraint-basierten Caching (mit Gleichheitsprädikaten) erfolgt die Anfrage-
bearbeitung in zwei Schritten: Zunächst prüft man, ob eine gegebene Anfrage aus dem
Cache beantwortet werden kann (dabei kann auch der beantwortbare Teil der Anfrage be-
stimmt werden); die eigentliche Planung und Ausführung der Anfrage geschieht dann in
herkömmlicher Art und Weise ähnlich wie im Backend. Dies ist möglich, weil der Cache
in seinem Schema ausschnittsweise dem Backend entspricht. Im ermittelten Ausführungs-
plan können dabei sowohl Backend- als auch (an ihrer Stelle) Cache-Tabellen auftreten.
Bei der Ausführung des Plans muss in diesem Schritt also nicht darauf geachtet werden,
dass die Cache-Tabellen nur einen Teil der Sätze aus den ihnen zugeordneten Backend-
Tabellen enthalten: Die Korrektheit der Ersetzung einzelner oder aller Backend- durch
Cache-Tabellen und damit die Korrektheit des Anfrageergebnisses wird allein im ersten
Schritt sichergestellt.
2.1 Sondierung, Einstiegspunkt und Verankerung
Der erste Schritt der Anfragebearbeitung sollte möglichst effizient durchführbar sein durch
einfache Operationen auf dem Cache-Inhalt (Daten und Metadaten). In unserem Fall der
Gleichheitsprädikate genügen einfache Testanfragen, die im Cache die Existenz von Wer-
ten überprüfen, die in der Anfrage enthalten sind. Diesen Vorgang, bei dem mit Hilfe
einfacher Testanfragen die Beantwortbarkeit komplexerer Anfragen entschieden wird, be-
zeichnen wir als Sondierung (englisch probing).
Bei Gleichheitsprädikaten des Typs S.e=wgenügt ein Test auf die Existenz von w
in S.e, wenn zusätzlich abgeleitet werden kann (aus der Existenz zusammen mit den Con-
straints), dass wvollständig im Cache sein muss. Denn dann sind alle Sätze aus SB, die
sich für S.e=wqualifizieren, im Cache. Diese Vollständigkeit muss auf einfache Weise
aus dem Cache-Inhalt heraus entschieden werden können. Bei erfolgreichem Abschluss
des Sondierens sagen wir, dass die Spalte S.eals Einstiegspunkt für das Prädikat S.e=w
dient (oder für größere Prädikate, in denen dieses vorkommt).
Ausgehend von einem Einstiegspunkt können ohne weitere Testanfragen Equijoins ent-
lang (und in Richtung) von RCCs korrekt im Cache ausgewertet werden. Existiert also ein
RCC S.aT.bund dient S.ebereits als Einstiegspunkt für das Prädikat S.e=w, dann
kann auch das erweiterte Prädikat S.e=wS.a=T.bkorrekt im Cache ausgewertet wer-
den. Ein Equijoin entlang eines RCCs ist nicht möglich ohne diese Beschränkung in der
Quelltabelle des RCCs auf solche Sätze, die zu einer sich im Cache befindenden Prädi-
katsextension gehören. Bei einem unbeschränkten Join fehlt sonst der Beitrag der nicht im
111
Cache, aber im Backend vorhandenen Sätze, so dass ein falsches Ergebnis erzeugt wird.
Diese Beschränkung als Voraussetzung, einen RCC anwenden zu können, bezeichnen wir
auch als Verankerung eines RCCs im Cache; entsprechend heißt die Quelltabelle des RCCs
in diesem Fall verankert.
Die Verankerung von RCCs und Tabellen erfolgt induktiv: Ein Einstiegspunkt in Spal-
te S.everankert die Tabelle Sund damit alle von Sausgehenden RCCs. Durch die An-
wendung eines RCCsS.aT.bfür einen Equijoin S.a=T.bist wiederum die Tabelle T
verankert, so dass von dort ausgehend weitere RCCs angewandt werden können. RCCs
können also stets nur in ununterbrochenen Folgen von Einstiegspunkten ab angewandt
werden.
f1q1q2
eh
g
f2jB
G
N
F
O
(a) Cache
f1q1q2
eh
g
f2j
m
ABBB
FBGB
MBNBOB
...
...
(b) Backend
B(f2,j)
3,α
4,β
7,β
[8,ψ]
[9,ω]
[0,α]
F(f1,q1)
A,1
B,2
A,3
[Y,8]
[Z,9]
G(q2)
3
4
[6]
[8]
[9]
N(e,g)
1,α
3,β
4,γ
6,α
[5,κ]
[5,λ]
O(h)
α
γ
δ
[ε]
[ζ]
[ε]
(c) Belegung
Abbildung 1: (a) Cache-Tabellen repräsentieren eine Auswahl von (b) Backend-Tabellen im Cache
und (c) enthalten eine Teilmenge derer Sätze (zusätzliche Sätze im Backend sind eingeklammert).
Beispiel 1. Um zu illustrieren, wie eine Anfrage im Cache behandelt wird, betrachten wir
die Konstellation in Abbildung 1; folgende Beispiele beziehen sich immer auf Ausschnitte
daraus, wo nötig mit kleinen Änderungen. Die Legende in Abbildung 2 auf der folgenden
Seite zeigt die in dieser und allen folgenden Abbildungen verwendeten Symbole.
In der dargestellten Backend-Datenbank (b) existiert eine große Anzahl von Tabellen
AB,BB,...,OB. Einige wenige daraus (B,F,G,N,O) sind als Cache-Tabellen im Cache wi-
dergespiegelt (a). Die Spalten F.f1und B.f2sind als Füllspalten deklariert; fünf RCCs stel-
len die Beziehung zwischen den Cache-Tabellen her: q1e,f2q2,q2e,jgund
gh. Die Belegung des Caches (c) zeigt einen Zustand nach der Referenz der Füllspalten-
Werte f1∈{A,B}und f2∈{3,4,7}. (Man beginne mit den Sätzen aus FBund BB, die
diese Werte aufweisen, und stelle dann durch wiederholte Hinzunahme von Sätzen in den
übrigen Tabellen die Gültigkeit aller RCCs her.)
112
aSpalte aFüllspalte
A
Tabelle A(zwei Spalten)
Index RCC zur Sondierung genutzt
Abbildung 2: Legende
Den Cache erreiche die PSJ-Anfrage eines Clients gegen die Tabellen F,Nund Mmit
dem Prädikat f1=Aq1=eg=m. (Wir nehmen an, dass Azur Kandidatenmenge
von f1gehört.) Wie stellen wir fest, ob oder zu welchem Anteil diese Anfrage aus dem
Cache beantwortet werden kann?
Das Gleichheitsprädikat f1=Abietet eine Möglichkeit zur Verankerung im Cache,
da f1eine Füllspalte ist und somit alle im Cache vorhandenen Kandidatenwerte dort voll-
ständig sind. Es genügt also, eine Sondierung in f1durchzuführen; sie bestätigt, dass sich
der Wert Aim Cache befindet. Also kann f1als Einstiegspunkt dienen.
Ausgehend von dieser Verankerung garantiert der RCC q1edie Korrektheit des
Joins q1=e. Dadurch liegt für Tabelle Neine Verankerung vor, die wir für die Anwen-
dung eines RCCsgmzur Unterstützung von g=mheranziehen könnten; aber dieser
RCC existiert in unserer Cache Group nicht. Also muss hier auf die Backend-Tabelle MB
zurückgegriffen werden, während wir für Fund Ndie Cache-Tabellen nutzen und somit
die Anfrage verteilt zwischen Cache und Backend auswerten können. Natürlich ist die-
se verteilte Art der Auswertung im Hinblick auf ihre Kosten zu vergleichen mit anderen
Alternativen, etwa der vollständigen Ausführung im Backend. Bei der Kostenschätzung
sind wesentlich die Kommunikationskosten zu berücksichtigen sowie die Lastsituation im
Backend (schließlich soll dieses zu Gunsten der Caches entlastet werden). Darauf gehen
wir hier aber nicht weiter ein.
2.2 Optimale Cache-Nutzung
Um den im Cache gehaltenen Datenbestand, der durch die Constraints sowie das Refe-
renzverhalten in der Vergangenheit vorgegeben ist, möglichst effektiv nutzen zu können,
muss Klarheit über die verfügbaren Strukturen herrschen, an denen sich die Nutzung ori-
entiert. In unserem Fall ist es wichtig, jeden möglichen Einstiegspunkt zu kennen sowie
alle geltenden RCCs zur Unterstützung von Joins.
Bisher wurde in Cache Groups zur einfachen Erkennung und Handhabung von Ein-
stiegspunkten der Begriff der Bereichsvollständigkeit einer Spalte eingeführt [ABK+03,
HB04b]. Eine Cache-Spalte heißt bereichsvollständig, wenn jeder Wert, der in dieser Spal-
te auftritt, wertvollständig ist. Deswegen genügt beim Sondieren ein bloßer Existenztest
in dieser Spalte zur Entscheidung, ob ein Wert vollständig ist und die Spalte somit als
Einstiegspunkt dienen kann.
Bei der Analyse von Cache Groups wurde daraufhin die Kenntnis aller bereichsvoll-
ständigen Spalten angestrebt. Zum einen wurde in bestimmten Spalten die Bereichsvoll-
ständigkeit erzwungen (durch explizite Spezifikation bestimmter Spalten als so genannte
Cache Keys [ABK+03]; das sind Füllspalten mit maximaler Kandidatenmenge). Zum an-
113
deren wurden Situationen identifiziert, in denen sich durch das Zusammenspiel von Con-
straints induzierte Bereichsvollständigkeit in Spalten ergibt, für die die Bereichsvollstän-
digkeit nicht explizit spezifiziert worden ist [HB04c, HB04d].
Bemerkung. Ein wichtiger Spezialfall bereichsvollständiger Spalten sind Unique-
Spalten, also Spalten mit einem Unique-Constraint im Backend. Diese sind unter al-
len Umständen bereichsvollständig, unabhängig vom Kontext in der Cache Group.
Ähnlich zur induzierten Bereichsvollständigkeit lassen sich auch zusätzliche RCCs fin-
den: Die RCCs, die in einer Cache Group gelten, sind nicht nur die bei der Spezifikation
der Cache Group angegebenen RCCs: Im Allgemeinen lässt sich aus diesen die Gültigkeit
weiterer ableiten (unter der zusätzlichen Annahme, dass die Cache-Tabellen nur solche
Sätze enthalten, die zur Erfüllung der spezifizierten Constraints ausgehend vom Inhalt der
Füllspalten benötigt werden, aber nicht mehr). Solche zusätzlichen RCCs wurden von uns
Optimierungs-RCCs[HB04d] getauft, weil jeder in einer Cache Group bekannte RCC eine
neue Möglichkeit für einen Join (in Richtung des RCCs) darstellt und damit die Nutzbar-
keit des Caches ohne weitere Kosten optimiert.
Beispiel 2. Ein typischer Optimierungs-RCC in Abbildung 1a wäre q2f2: In Spalte q2
tauchen nur durch den spezifizierten RCC f2q2Werte auf; jeder Wert w, der dort auf-
taucht, existiert also auch in Spalte f2. Da die Tabelle Bnicht durch andere RCCs erreicht
wird, ist jeder Wert win der Füllspalte f2aus der Kandidatenmenge und deswegen voll-
ständig in f2. Also gilt der entgegengerichtete Optimierungs-RCC q2f2.
3 Flexiblere Einstiegspunkte durch ein neues Sondierungsverfahren
Um eine Cache Group möglichst flexibel und effektiv nutzen zu können, galt es bisher, alle
geltenden RCCs als mögliche Join-Richtungen zu finden sowie, vor allem, alle bereichs-
vollständigen Spalten als mögliche Einstiegspunkte, denn erst Einstiegspunkte erlauben
die Anwendung von RCCs.
Die Klassifizierung der Spalten der Cache Group in bereichsvollständige und nicht be-
reichsvollständige, die dabei angestrebt wurde, ist recht grob: Nur Spalten, in denen garan-
tiert (zu jeder Zeit) jeder Wert vollständig ist, werden so als Einstiegspunkte in Erwägung
gezogen.
Bei der Suche nach Einstiegspunkten wurde dabei völlig übersehen, dass die Definition
von RCCs (Definition 2) auf natürliche Weise ein differenzierteres Sondieren auf Wertvoll-
ständigkeit erlaubt: In der Zielspalte eines RCCs sind diejenigen Werte sicher vollständig,
die in der Quellspalte des RCCs im Cache vorhanden sind. Deshalb sind in jeder Spalte e,
die von mindestens einem RCC erreicht wird, (zumindest) alle diejenigen Werte vollstän-
dig, die in den Quellspalten eingehender RCCs existieren. Das bedeutet, es reicht aus, in
diesen Quellspalten einen Existenztest durchzuführen, um egegebenenfalls zum Einstieg
in die Cache Group nutzen zu können. Es schadet dabei nicht, wenn in der gemeinsamen
Zielspalte eweitere Werte existieren, die nicht vollständig sind (in diesem Fall ist enicht
bereichsvollständig).
Beispiel 3. Wir betrachten in Abbildung 3 auf der nächsten Seite einen Ausschnitt aus Ab-
bildung 1a: Die Spalte ewird von zwei RCCs mit Quellspalten q1und q2erreicht. Soll
114
die Spalte eals Einstiegspunkt für ein Gleichheitsprädikat e=wdienen, dann genügt eine
Sondierung in diesen beiden Spalten, um zu entscheiden, ob der Wert wvollständig in der
Spalte eist. (Existiert win q1oder in q2, ist wsicher vollständig in e; existiert wweder
in q1noch in q2, wissen wir nichts über die Vollständigkeit von w.)
q1q2
e
Abbildung 3: Existenztest in den Quellspalten eingehender RCCs
Wir bezeichnen im Folgenden den bisher existierenden und in Abschnitt 2.1 vorge-
stellten Ansatz, das Sondieren direkt in derjenigen (bereichsvollständigen) Spalte durch-
zuführen, die als Einstiegspunkt dienen soll, als altes Sondierungsverfahren.Neu ist das
Sondieren in den Quellspalten von RCCs.
Beim Übergang vom alten zum neuen Sondierungsverfahren machen wir, um die Spal-
ten für die Sondierung zu finden, einen Schritt zurück (vom potentiellen Einstiegspunkt
entlang der eingehenden RCCs), aber keinen Rückschritt: Das Sondieren in den Quellspal-
ten von RCCs hat mindestens zwei wichtige Vorteile gegenüber dem alten Sondierungs-
verfahren:
Erhöhte Flexibilität bei der Benutzung des Caches: Die Bereichsvollständigkeit ei-
nes Einstiegspunktes ist nicht mehr notwendig; jede Spalte, die von einem RCC
erreicht wird, ist potentieller Einstiegspunkt.
Negatives Caching: Sogar die Information, dass Sätze im Backend nicht existieren,
wird im Cache zwischengespeichert und kann zur Beantwortung von Anfragen (mit
leerem Ergebnis) genutzt werden. Wir betrachten diese interessante Eigenschaft ge-
nauer im folgenden Abschnitt 3.1.
Ein Nachteil ergibt sich in bestimmten Situationen durch einen erhöhten Sondierungs-
aufwand. In welchen Konstellationen dieser Nachteil zum Tragen kommen, in welchen
nicht, und wie sich die Sondierung in Quellspalten optimieren lässt, diskutieren wir in Ab-
schnitt 3.3.
3.1 Negatives Caching
Beispiel 4. Wir betrachten wieder den Ausschnitt aus einer Cache Group in Abbildung 4
auf der folgenden Seite, dieses Mal mit einer konkreten Belegung der Spalten. Spielen wir
für verschiedene Anfragen mit Gleichheitsprädikaten auf der Spalte edas neue Sondie-
rungsverfahren durch:
e=4: Der Wert 4 ist in der Quellspalte q2des RCCsq2evorhanden, also ist er
vollständig in e: Wir können eals Einstiegspunkt für e=4 nutzen.
115
q1q2
e
Spalte vorhandene Werte
q11,2,3
q23,4
e1,3,4,6
eB1,3,4,5,6
Abbildung 4: Negatives Caching: e=2 kann im Cache ausgewertet werden, weil der Wert 2 in der
Quellspalte q1vorhanden ist, liefert aber ein leeres Ergebnis: Der Wert 2 existiert nicht im Backend
(eB), also auch nicht im Cache (e). (Von unterstrichenen Werten ist bekannt, dass sie vollständig
sind.)
e=6: Der Wert 6 ist in Spalte evorhanden. Wir nehmen an, dass er auf anderem We-
ge in diese Spalte gelangt ist als über die dargestellten RCCs. (Wie man Abbildung 1
entnehmen kann, war RCC jgdafür verantwortlich.) Der Wert 6 ist aber weder
in der Quellspalte q1vorhanden noch in q2. Das bedeutet nicht, dass der Wert 6
nicht vollständig in esein muss; jedoch können wir uns dessen nicht sicher sein.
Entsprechend kann enicht als Einstiegspunkt für e=6 dienen.
e=2: Der Wert 2 existiert nicht in der Spalte eBim Backend, dementsprechend
auch nicht in der Cache-Spalte e. Allerdings existiert er in einer der Quellspalten
(q1) und ist deswegen in ewertvollständig, obwohl er dort nicht auftaucht. Also
kann eanalog zum Fall e=4 auch als Einstiegspunkt für e=2 genutzt werden. Die
Auswertung des Prädikats im Cache liefert dann das korrekte Ergebnis, nämlich ein
leeres.
Im Normalfall stehen bei Caching-Verfahren existierende Objekte aus dem Backend
im Vordergrund; Kopien von ihnen werden im Cache gehalten. Als negatives Caching
bezeichnen wir den Fall, dass die Information, die zwischengespeichert wird, das Nicht-
Vorhandensein von Objekten im Backend ausdrückt. Dieser Begriff taucht bereits beim
Caching von DNS-Anfragen auf: “It is the storage of knowledge that something does not
exist, cannot or does not give an answer that we call negative caching.” [And98]
In unserem Fall wird durch die Sondierung in Quellspalten von RCCs deutlich, dass
eine Cache Group auch Informationen über nicht im Backend vorhandene Sätze enthal-
ten kann. Die Extensionen zu den entsprechenden Gleichheitsprädikaten oder zu darauf
aufbauenden Prädikaten sind leer; die leere Antwort auf Anfragen mit diesen Prädikaten
kann aber direkt aus dem Cache gegeben werden. Im Gegensatz dazu wird anhand des
alten Sondierungsverfahrens in solchen Fällen die Entscheidung getroffen, dass das betrof-
fene Prädikat nicht korrekt im Cache ausgewertet werden kann: Für einen erfolgreichen
(korrekten) Einstieg in die Cache Group wird stets die Existenz der angeforderten Wer-
te in der betroffenen Spalte verlangt. Bei Nicht-Existenz muss nach einer Nachricht an
das Backend dieses die Bearbeitung übernehmen, nur um anschließend das leere Ergebnis
zurückmelden zu können.
Beispiel 5. Wenden wir das alte Sondierungsverfahren auf die Situation aus Beispiel 4 in
Abbildung 4 an, finden wir den Wert 2 nicht in Spalte e. Das Prädikat e=2 muss also im
Backend ausgewertet werden; dort kommt der Wert 2 in Spalte eBaber ebenfalls nicht vor.
116
Jenseits eines erfolgreichen Einstiegs in die Cache Group, bei der Ausnutzung von
RCCs für Joins, ist das negative Caching schon im alten Modell des Sondierens und der
Cache-Benutzung enthalten, blieb aber bisher unbemerkt.
Beispiel 6. Abbildung 5 zeigt eine Situation im Cache, die wir auf ihr Verhalten bei einer
Anfrage mit dem Prädikat e=3g=hhin untersuchen wollen. Dabei legen wir das alte
Sondierungsverfahren zu Grunde. Für dieses Beispiel ignorieren wir außerdem den RCC
jgaus Abbildung 1a. Erst dann kann Spalte eals induziert bereichsvollständig erkannt
werden und daher potentieller Einstiegspunkt sein.
q1q2
eh
gNBOB
Spalten vorhandene Werte
(e,g)(1,α),(3,β),(4,γ)
hα,γ,δ
hBα,γ,δ,ε,ζ
Abbildung 5: Negatives Caching beim alten Sondierungsverfahren: Das Prädikat e=3g=hführt
im Cache zu einem leerem Ergebnis.
Die Sondierung in ezeigt, dass der Wert 3 im Cache vorhanden ist, also wegen der
Bereichsvollständigkeit dort auch wertvollständig ist. Wegen des RCCsghkann ausge-
hend von dieser Verankerung in Tabelle Nder Join g=hzu Tabelle Okorrekt ausgewertet
werden. Somit kann die gesamte Anfrage aus dem Cache beantwortet werden.
Der einzige Satz aus Nmit e=3 ist (3,β), der g-Wert βfindet aber in Spalte hkeine
Entsprechung. Das Ergebnis der Anfrage ist also leer – ein Fall von negativem Caching.
3.2 Transitivität
Wir sind nun grundlegend vertraut mit dem neuen Verfahren, in Quellspalten zu sondieren:
Von der Spalte, die als Einstiegspunkt dienen soll, machen wir einen Schritt zurück entlang
der RCCs, um die Spalten für die Sondierung zu finden.
Die Sondierungsspalten können wiederum von RCCs erreicht werden. Bei solchen Ket-
ten von RCCs stellt sich die Frage, ob sich die Idee der Sondierung nicht transitiv fortset-
zen lässt: Kann man zur Sondierung auch zwei Schritte zurückgehen? (Dies würde eine
flexible Wahl der Sondierungsspalten ermöglichen.)
Wir betrachten eine Kette von RCCsabcüber drei Spalten a,bund c: Jeder
Wert aus aist vollständig in b; jeder Wert aus bist vollständig in c. Ist damit auch jeder
Wert aus avollständig in c; gilt der RCC ac? Ist also die durch eine Menge von RCCs
definierte (mathematische) Relation über den Spalten transitiv?
Im Allgemeinen gilt dies nicht. – Nicht ohne Grund stellen wir diese Frage nach der
Betrachtung des negativen Caching: Dort wurde uns bewusst, dass ein Wert auch dann
vollständig in einer Spalte im Cache sein kann, wenn er dort gar nicht existiert.
Nehmen wir also an, wir haben einen Wert w, der im Backend in aBund cB, aber nicht
in bBexistiert. Weiterhin sei wim Cache in Spalte avorhanden. Dann ist wdurch den
RCC abwertvollständig in b, kann aber dort natürlich nicht existieren. Also macht der
117
zweite RCC bckeinerlei Aussage über die Wertvollständigkeit von win c, da dies die
Existenz von win bvoraussetzt. Sei nun wnicht in centhalten; dann ist wnicht vollständig
in cund unser Gegenbeispiel ist komplett.
Es ist also sorgfältig darauf zu achten, die Existenz von Werten im Cache und deren
Vollständigkeit voneinander zu trennen. Dem eben provozierten Irrtum, dieses nicht zu tun,
sind Altinel et al. erlegen: Sie beweisen den Satz [ABK+03, Abschnitt 3.4.2], dass jede
an einem homogenen Zyklus beteiligte Spalte bereichsvollständig sei. (Ein homogener
Zyklus ist eine geschlossene Kette von RCCs im obigen Sinne, z.B. c1c2→ ··· →
cnc1.) Dieser Beweis ist fehlerhaft; er enthält als wesentliches Element den falschen
Schluss, dass ein vollständiger Wert vjin einer Zyklusspalte ciüber den RCC cici+1
die Wertvollständigkeit von vjin der folgenden Spalte ci+1bewirke. Dies (und der ganze
Satz) lässt sich durch das obige Gegenbeispiel widerlegen.
3.3 Optimierte Sondierung
Bisher haben wir das neue Sondierungsverfahren in allgemeiner Form dargestellt (für be-
liebige Spalten, die von mindestens einem, aber sonst beliebig vielen RCCs erreicht wer-
den) und seine Eigenschaften auf dieser Ebene analysiert. Im Folgenden wollen wir be-
trachten, welche Alternativen es für die Durchführung der Sondierung in konkreten Situa-
tionen gibt.
Zuallererst kann man in direkter Art und Weise in Quellspalten sondieren: Soll eine
Spalte eals Einstiegspunkt für ein Gleichheitsprädikat e=wdienen, wird jede Quellspalte
eines RCCs, der eerreicht, auf die Existenz des Wertes whin überprüft. Findet man den
Wert in einer dieser neSpalten (ne0), ist wvollständig in e, und der Einstieg in die
Cache Group ist gesichert. Ein Nachteil dieses Vorgehens ist, dass pro eingehendem RCC
ein Existenztest auszuwerten ist, was durch den gesteigerten Aufwand (für ne>1), der
bei jeder Anfrage auf die Spalte eanfällt, die Effektivität des Caching mindert. (Natürlich
kann man während des Sondierens sofort abbrechen, wenn zum ersten Mal ein Existenztest
erfolgreich abgeschlossen wird. Deswegen könnte man sich hier auch Gedanken machen
über eine optimale Sondierungsreihenfolge der eingehenden RCCs.)
Als Optimierung für das Sondieren bietet sich die Verwendung eines speziellen Inde-
xes an, der (bezogen auf eine bestimmte Spalte e) die Vereinigung der Wertemengen aller
Quellspalten enthält. Ein solcher Vollständigkeitsindex für eenthält damit alle Werte, deren
Wertvollständigkeit in ebekannt ist.
Bemerkung. In der Spalte eselbst kann es Werte geben, die vollständig in esind,
ohne dass dieses im Cache festgestellt werden könnte. Dementsprechend können
solche Werte auch nie zum Einstieg in eine Cache Group benutzt werden. (Man
erinnere sich beispielsweise an den Wert e=6 in Beispiel 4.)
In Abbildung 6a auf der nächsten Seite ist ein Vollständigkeitsindex (als Dreieck; siehe
auch Abbildung 2) für die Spalte ein der Cache Group dargestellt, die schon aus Abbil-
dung 4 bekannt ist. Dieser Index ist dabei wie eine Spalte durch RCCs in die Cache Group
eingebunden; diese Darstellung wurde gewählt, weil sich ein Vollständigkeitsindex wie
eine an dieser Stelle eingefügte separate Spalte iverhält, wenn man für die zugehörige
118
q1q2
e
(a)
q1q2
e
(b)
e
(c)
e
(d)
q1q2
e
(e)
Abbildung 6: Einsatz von Indexen: (a) Sondierung in Vollständigkeitsindex für eanstatt in den Quell-
spalten q1und q2; (b) naives Sondieren mit normalen Indexen; (c) Abkürzung für (b); (d) nur eine
Quellspalte: normaler Index ist Vollständigkeitsindex; (e) bei bereichsvollständigem e(siehe Bei-
spiel 4) Verlust des negativen Caching.
virtuelle (weil nicht existente) Backend-Spalte iBannimmt, dass sie jeden beliebigen Wert
enthält.
Natürlich wird man auch bei Verzicht auf einen Vollständigkeitsindex die Existenztests
in den verschiedenen Quellspalten durch einzelne Indexe herkömmlicher Art unterstützen
wollen. In Abbildung 6c sind diese Indexe durch Überdeckung der durch sie indexierten
Spalten dargestellt; dies kann als Abkürzung der in Abbildung 6b gezeigten Folge von
Spalte, RCC und Index aufgefasst werden. Im Falle, dass zu einer Spalte enur eine Quell-
spalte q1gehört, fallen dieser Index auf q1und der Vollständigkeitsindex für ezusammen
(Abbildung 6d). In solchen Situationen fallen also keine zusätzlichen Kosten für einen
Vollständigkeitsindex an. Wir erwarten, dass diese Situationen – typisch für baumstruktu-
rierte Cache Groups – deutlich häufiger auftreten als solche, in denen eine Spalte von zwei
oder mehr RCCs erreicht wird.
Das alte Sondieren direkt in der Spalte e(siehe Abschnitt 2) reiht sich nun in diesem
Kontext als eine weitere mögliche Optimierung ein. Sie lässt sich nur dann anwenden,
wenn man ableiten kann, dass estets bereichsvollständig ist. Abbildung 6e zeigt in Anleh-
nung an Beispiel 4 eine solche Situation. Allerdings verliert man bei dem Schritt von den
Quellspalten zur Spalte eeinen Teil der Information über vollständige Werte: Die Sondie-
rung kann dann nur noch für solche Werte erfolgreich sein, die in etatsächlich existieren.
Man büßt also das negative Caching ein.
Integritätsbedingungen (auch »Constraints«) im Backend sind zu unterscheiden von
im Cache definierten Constraints. Ein im Backend gültiger Constraint kann, muss aber
nicht im Cache gelten, da sich dort nur eine Teilmenge aller Sätze befindet.
Es gibt Situationen, in denen wegen Integritätsbedingungen, die im Backend definiert
sind, nie negatives Caching auftreten kann. Haben wir zwei Spalten fund pmit einem
119
RCC fp, und stehen fBund pBim Backend in einer Fremdschlüssel–Primärschlüssel-
Beziehung, können wegen der referentiellen Integrität nie Werte in fauftauchen, die nicht
auch in pexistieren. In solchen Situationen bietet es sich daher an, mit dem alten Sondie-
rungsverfahren direkt in der Zielspalte pzu sondieren (pBist eine Unique-Spalte, also ist p
bereichsvollständig); man verliert dabei keinerlei Information. Allerdings hat man auch in
diesem Fall weiterhin die Option, fstatt pzur Sondierung heranzuziehen, um etwa einen
dort vorhandenen Index auszunutzen.
Es gibt also abhängig von der Zahl der eingehenden RCCs, abhängig von den im Cache
definierten Indexen und abhängig von den im Backend definierten Integritätsbedingungen
eine Vielzahl von Möglichkeiten, die Sondierung in Quellspalten umzusetzen.
3.4 Füllspalten
Bei den Füllspalten kann das beschriebene Verfahren zum Sondieren nicht ohne weiteres
eingesetzt werden; im Allgemeinen müssen diese nicht von RCCs erreicht werden. Der
Schritt zurück zum Sondieren ist hier also nicht möglich. Dieser Makel lässt sich für eine
Füllspalte f1konzeptionell durch die Einführung einer separaten Kontrolltabelle mit nur
einer Unique-Spalte kund einem RCC kf1von dieser Spalte auf die Füllspalte beheben.
Allein die Einträge in dieser Kontrolltabelle bestimmen damit, welche Werte vollständig in
die Füllspalte geladen werden (Abbildung 7). Der zulässige Wertebereich von kist genau
die Kandidatenmenge von f1.
f1q1
e
k
Abbildung 7: Spalte f1ist Füllspalte. Eine Kontrolltabelle mit Spalte kund ein RCC kf1führen
dazu, dass man zum Einstieg in f1bei der Sondierung genau so verfahren kann wie bei jeder anderen
Spalte.
Bei genauerer Betrachtung behebt diese Umstrukturierung auch ein weiteres Problem:
Bisher wurde keine Trennung vorgenommen zwischen Kandidaten-Werten, die direkt re-
ferenziert wurden, und solchen, die auf anderem Wege in die Füllspalte gelangten: Beide
wurden in gleicher Weise vollständig gemacht. Die neue Struktur berücksichtigt diesen Un-
terschied: Nur referenzierte Kandidaten-Werte stehen in der Kontrolltabelle und machen
diese Werte in der Füllspalte wertvollständig; andere Werte, die die Füllspalte auf ande-
ren Wegen erreichen, müssen dort nicht unbedingt vollständig erscheinen, selbst wenn es
sich um Kandidatenwerte handelt. Das verhindert unnötigen Zusatzaufwand bei der War-
tung des Cache-Inhalts, denn jeder unnötig in den Cache geladene Satz kann durch RCCs
weitere Sätze mit sich ziehen.
Eine derartige Kontrolltabelle, die über ihren Inhalt die Belegung der eigentlichen
Cache-Tabellen kontrolliert, taucht auch beim System MTCache auf [LGGZ04, LGZ04].
Dort werden die Inhalte der Cache-Tabellen als materialisierte Sichten beschrieben, die
120
sich in ihrer Definition auf die Kontrolltabelle oder andere Cache-Tabellen beziehen kön-
nen. In der Tat wird durch diesen Bezug (zumindest bei den Sichten im angegebenen Bei-
spiel [LGGZ04, Abschnitt 5]) der Effekt einer Art von RCC beschrieben.
3.5 Bedeutung von Optimierungs-RCCs
Mit der Kenntnis des neuen Sondierungsverfahrens ist die Erkennung von Bereichsvoll-
ständigkeit nicht mehr so relevant wie bisher angenommen. Jede Spalte, die von einem
RCC erreicht wird, ist potentieller Einstiegspunkt, ohne dass wir irgendetwas über ihre Be-
reichsvollständigkeit wissen müssen. Unique-Spalten können zusätzliche Einstiegspunkte
sein; ihre Bereichsvollständigkeit ist von vornherein immer bekannt. Die Ableitung der
Bereichsvollständigkeit einer Spalte ermöglicht damit nur eine optimierte Sondierung in
dem Fall, dass eine Spalte mehr als einen eingehenden RCC besitzt und man bereit ist, auf
das negative Caching zu verzichten.
Stattdessen gewinnt die Kenntnis und Klassifizierung aller in einer Cache Group gel-
tenden RCCs umso mehr an Bedeutung. Das Problem der Ermittlung von Optimierungs-
RCCs stellt sich in zwei Varianten dar:
Gegeben eine Menge von RCCs (z. B. die Menge der in einer Cache Group defi-
nierten), welche RCCs gelten über diese hinaus? Diese Art von Optimierungs-RCCs
erschließt erweiterte Join-Möglichkeiten; dies war die bisherige Motivation für die
Suche nach Optimierungs-RCCs.
Wiederum gegeben eine Menge von RCCs, welche RCCsaus dieser Menge sind
Optimierungs-RCCs bezüglich der übrigen? Welche der RCCs tragen also nicht zum
Füllen der Cache Group bei, welche sind in diesem Sinne redundant?
Die zweite Formulierung des Problems verdient besondere Beachtung: Das Erkennen
von überflüssigen oder redundanten RCCs führt zu Einsparungen sowohl bei der Wartung
des Cache-Inhalts als auch bei der Sondierung.
Redundante RCCs müssen auf der einen Seite nicht beachtet oder überprüft werden,
wenn es nach einer Änderung in den Kontrolltabellen (oder darauf folgend in den Cache-
Tabellen) darum geht, einen gültigen Cache-Zustand wiederherzustellen.
Auf der anderen Seite können redundante RCCs bei der Bestimmung der Quellspalten
eingehender RCCs ausgespart werden, wenn eine Sondierung für ein Gleichheitsprädikat
durchgeführt werden soll. Dies verringert die Anzahl derjenigen Spalten, in denen ein Exis-
tenztest durchgeführt oder deren Änderungen in einem Vollständigkeitsindex nachgeführt
werden müssen, ohne Information über vollständige Werte zu verlieren oder die Korrekt-
heit der Auswertung im Cache zu beeinträchtigen.
Um schon beim Entwurf von Cache Groups und daraus entstehenden Cache-Group-
Föderationen Klarheit über die Folgen und insbesondere Kosten des Entwurfs zu haben
[HB04b], wird also ein Algorithmus (vielleicht auf der Grundlage eines Kalküls) zur Be-
stimmung aller Optimierungs-RCCs einer Cache Group benötigt.
Bemerkung. Steht erst ein Algorithmus zur Bestimmung aller Optimierungs-RCCs
einer Cache Group zur Verfügung, ist damit auch die Ermittlung aller (induziert)
121
bereichsvollständigen Spalten möglich: Eine bereichsvollständige Spalte S.ekann
nämlich charakterisiert werden durch die Existenz eines Selbst-RCCsS.eS.e.
Beispiel 7. Abbildung 8a zeigt eine Cache Group in der Form, wie sie spezifiziert worden
sein könnte, mit einer Füllspalte und fünf explizit angegebenen RCCs. In Abbildung 8b
sind zusätzlich die in dieser Cache Group geltenden Optimierungs-RCCs eingezeichnet.
Dabei sind sowohl neue RCCs hinzugekommen (z. B. q1e) als auch spezifizierte RCCs
als redundant erkannt worden (q1q2). Die ermittelten Selbst-RCCsq1q1,q2q2
und f2f2zeigen an, dass die Spalten q1,q2und f2bereichsvollständig sind.
q1q2
eg
f2jB
G
N
F
(a)
f2
q1q2
eg
jB
G
N
F
(b)
Abbildung 8: Optimierungs-RCCs: (a) Cache Group mit spezifizierten RCCs, (b) mit abgeleiteten
und als redundant erkannten RCCs (gestrichelt).
4 Zusammenfassung und Ausblick
Eine effektive Nutzung des Inhalts eines Constraint-basierten Datenbank-Caches beginnt
bei der Wahl eines auf die benutzen Cache-Constraints zugeschnittenen und möglichst
flexiblen Sondierungsverfahrens. Das alte Sondierungsverfahren für Cache Groups, die
auf Gleichheitsprädikaten basieren, stützt sich (zu) stark auf die Bereichsvollständigkeit
als Eigenschaft, die für eine ganze Spalte gilt und für jeden Wert einer solchen Spalte die
Wertvollständigkeit im Cache sichert. Indem es nur bereichsvollständige Spalten als poten-
tielle Einstiegspunkte ansieht, macht das Verfahren sich die Sondierung zwar sehr einfach,
ignoriert aber all jene Spalten, die zu irgendeiner Zeit einen einzigen nicht vollständigen
Wert enthalten könnten.
Mit dem neuen Sondierungsverfahren machen wir klar, dass es bei der Frage nach dem
korrekten Einstieg in eine Cache Group nur auf die Vollständigkeit einzelner Werte an-
kommt. Anders als im alten Verfahren wird deshalb die Sondierung nicht direkt auf einem
potentiellem Einstiegspunkt durchgeführt, sondern auf Spalten, die durch einen Schritt
zurück in der Cache-Group-Struktur erreicht werden, nämlich auf den Quellspalten der
eingehenden RCCs. Die RCCs selbst sichern zu, dass Werte, die dort gefunden werden,
wertvollständig in ihrer Zielspalte sind.
Durch diese Maßnahme ist jede Spalte, die von mindestens einem RCC erreicht wird,
potentieller Einstiegspunkt, nicht mehr nur jede bereichsvollständige Spalte. Das führt zu
122
einer größeren Flexibilität bei der Nutzung des Cache-Inhalts; es können mehr Anfragen
aus dem Cache beantwortet werden als vorher. Bei Anfragen, die sich auf Satzmengen be-
ziehen, die leer sind, spielt das durch das neue Sondierungsverfahren aufgedeckte negative
Caching seine Vorteile aus: Mit dem im Cache gespeicherten Wissen (aus einer vorange-
gangenen Anfrage), dass Sätze nicht existieren, kann eine leere Antwort direkt im Cache
erzeugt werden, ohne das Backend zu belasten.
Welchen Einfluss negatives Caching im Verhältnis zum üblichen (positiven) Caching
auf die Leistungsfähigkeit eines Datenbank-Caches hat, hängt sicherlich von der Art der
(Web-)Anwendung ab und der relativen Häufigkeit, mit der diese gezielte Anfragen auf
nicht vorhandene Objekte (etwa Benutzer, Produkte oder Bestellungen) durchführt. Die
Analyse des Anfrageverhaltens einer konkreten Anwendung über einen Zeitraum könnte
hierüber Aufschluss geben.
Die Einführung von Kontrolltabellen in Cache Groups führt dazu, dass alle Spalten in
gleicher Art und Weise auf ihre Eignung als Einstiegspunkt überprüft werden können. Ver-
bunden damit ist die strikte Trennung von direkt und indirekt in eine Füllspalte gelangten
Kandidatenwerten; nur erstere werden beim Einsatz von Kontrolltabellen wertvollständig
gemacht. Das ergibt Sinn, da nur diese Werte direkt aus Anfragen, die den Cache erreichen,
stammen.
Beim Einsatz des neuen Sondierungsverfahrens sind je nach Konstellation in mehr
Spalten Existenztests durchzuführen als beim alten Verfahren. Eine wichtige Ausnahme
ist der häufig anzutreffende Fall, dass es nur einen eingehenden RCC für eine Spalte gibt.
In den anderen Fällen können durch übliche Indexierung oder einen speziellen Vollstän-
digkeitsindex die Kosten für die Sondierung klein gehalten werden. Selbst das alte Son-
dierungsverfahren kann – im Falle geeigneter Backend-Constraints sogar ohne Verlust des
negativen Caching – als spezielle Optimierung dienen. Es ergibt sich so auch bei derDurch-
führung der Sondierung eine große Flexibilität.
Die Kenntnis aller Optimierungs-RCCs einer Cache Group ist nach Einführung des
neuen Sondierungsverfahren in zwei Facetten von Bedeutung: Zum einen verbessert sie
die Nutzbarkeit des Caches (durch zusätzliche Join-Richtungen), zum anderen minimiert
sie den Aufwand bei der Verwaltung des Cache-Inhalts.
Gleichheitsprädikate und die sie unterstützenden Constraints stellen einen sehr einfa-
chen Fall des Constraint-basierten Caching dar. Durch welche Constraints andere Prädi-
katstypen unterstützt werden können, und wie diese mit den bestehenden wechselwirken,
falls sie simultan in einem Cache erfüllt werden sollen, ist eine offene Frage. Schon die
Überlagerung mehrerer einfacher (und harmloser) Cache Groups kann durch RCC-Zyklen
rekursives und damit unkontrollierbares Füllen des Caches hervorrufen.
Natürlich sind die Anfragebearbeitung im Cache und die dazu nötige Sondierung nur
ein Aspekt auf dem Weg zu einem effektiven adaptiven Datenbank-Cache. Weitere Aspek-
te umfassen die Entwurfsregeln für Cache Groups, die Bewertung der Kosten und des
Nutzens, die Ermittlung von Referenzhäufigkeiten oder ähnlichem zur Anwendung von
Verdrängungsverfahren, die effiziente Entfernung von gegebenenfalls überlappenden Prä-
dikatsextensionen aus dem Cache sowie verschiedene Strategien zur Bearbeitung und Pro-
pagierung von Änderungen im Cache und im Backend. Weiter reichende Fragestellungen
richten sich beispielsweise auf die Auflösung der starren Rollenverteilung Cache–Backend
123
und auf die Möglichkeit, die Struktur einer Cache Group selbst (nicht nur deren Inhalt) an
ein verändertes Anfrageprofil anzupassen.
Literatur
[ABK+03] Mehmet Altinel, Christof Bornhövd, Sailesh Krishnamurthy, C. Mohan, Hamid Pira-
hesh und Berthold Reinwald. Cache Tables: Paving the Way for an Adaptive Database
Cache. In Proceedings of the 29th International Conference on Very Large Data Bases,
VLDB 2003, Seiten 718–729. Morgan Kaufmann, 2003.
[And98] M. Andrews. Negative Caching of DNS Queries (DNS NCACHE). Request for Com-
ments (RFC) 2308, März 1998. ftp://ftp.rfc-editor.org/in-notes/rfc2308.txt.
[BAM+04] Christof Bornhövd, Mehmet Altinel, C. Mohan, Hamid Pirahesh und Berthold Rein-
wald. Adaptive Database Caching with DBCache. Data Engineering Bulletin,
27(2):11–18, Juni 2004.
[HB04a] Theo Härder und Andreas Bühmann. Datenbank-Caching – Eine systematische Ana-
lyse möglicher Verfahren. Informatik – Forschung und Entwicklung, 19(1):2–16, Juli
2004.
[HB04b] Theo Härder und Andreas Bühmann. Database Caching – Towards a Cost Model for
Populating Cache Groups. In Advances in Databases and Information Systems, 8th
East European Conference, ADBIS 2004,Lecture Notes in Computer Science 3255,
Seiten 215–229. Springer, 2004.
[HB04c] Theo Härder und Andreas Bühmann. Query Processing in Constraint-Based Database
Caches. Data Engineering Bulletin, 27(2):3–10, Juni 2004.
[HB04d] Theo Härder und Andreas Bühmann. Value Complete, Domain Complete, Predi-
cate Complete – Magic Words Driving the Design of Cache Groups. http://wwwdvs.
informatik.uni-kl.de/pubs/papers/HB04.Magic.html, 2004.
[LGGZ04] Per-Åke Larson, Jonathan Goldstein, Hongfei Guo und Jingren Zhou. MTCache: Mid-
Tier Database Caching for SQL Server. Data Engineering Bulletin, 27(2):35–40, Juni
2004.
[LGZ04] Per-Åke Larson, Jonathan Goldstein und Jingren Zhou. MTCache: Transparent Mid-
Tier Database Caching in SQL Server. In Proceedings of the 20th International Con-
ference on Data Engineering, ICDE 2004, Seiten 177–189. IEEE Computer Society,
2004.
[VR02] Gottfried Vossen und Erhard Rahm, Hrsg. Web & Datenbanken: Konzepte, Architektu-
ren, Anwendungen, Kapitel 7, Seiten 191–216. dpunkt.verlag, Heidelberg, September
2002.
The three most important parts
of any Internet application are caching,
caching, and, of course, caching . . .
Larry Ellison, Oracle CEO (2001)
124
... g., to exclude values with low selectivity); however, this approach brings with it basically the same problems as enforced column completeness , albeit to a lesser extent. We propose a new probing approach [7], which does not require new constraints and thus does not load extra records into the cache. Furthermore, it allows more flexible use of the cache contents than probing in complete columns alone. ...
Article
Full-text available
the date of receipt and acceptance should be inserted later Abstract Caching is a proven remedy to enhance scalabil- ity and availability of software systems as well as to reduce latency of user requests. In contrast to Web caching where single Web objects are accessed and kept ready somewhere in caches in the user-to-server path, database caching uses full-fledged database management systems as caches, close to application servers at the edge of the Web, to adaptively maintain sets of records from a remote database and to eval- uate queries on them. We analyze a new class of approaches to database cach- ing where the extensions of query predicates that are to be evaluated are constructed by constraints in the cache. Start- ing from the key concept of value completeness, we explore the application of cache constraints and their implications on query evaluation correctness and on controllable cache load- ing called cache safeness. Furthermore, we identify simple rules for the design of cache groups and their optimization before discussing the use of single cache groups and cache group federations. Finally, we argue that predicate complete- ness can be used to develop new variants of constraint-based database caching.
... Obviously , our goal ought to be to provide simple and efficient means for deciding about the completeness of values in the cache: The process of using simple (existence) queries on the cache to decide about completeness is called probing; the queries used are called probe queries accordingly. In contrast to DBCache [1], we use a new probing approach [3] , which does not require new constraints and thus does not load extra records into the cache (as DBCache's cache keys do). The fundamental insight is that RCCs already provide guarantees about complete values in the cache: The source column S.a of an RCC S.a → T.b (or more precisely, the values therein) controls which values are complete in its target column T.b. ...
Conference Paper
Full-text available
Database caching supports declarative query processing close to the application. Using a full-fledged DBMS as cache manager, it enables the evalua- tion of specific project-select-join queries in the cache. In this paper, we propose significant improvements and optimizations - as compared to the well-known DBCache approach - that make our caching concept truly adaptive. Furthermore, we describe an adaptive constraint-based cache system (ACCache) relying on middleware components as a DBMS-independent realization of this approach.
... g., to exclude values with low selectivity); however, this approach brings with it basically the same problems as enforced column completeness , albeit to a lesser extent. We propose a new probing approach [7], which does not require new constraints and thus does not load extra records into the cache. Furthermore, it allows more flexible use of the cache contents than probing in complete columns alone. ...
Article
Full-text available
Caching is a proven remedy to enhance scalability and availability of software systems as well as to reduce latency of user requests. In contrast to Web caching where single Web objects are accessed and kept ready somewhere in caches in the user-to-server path, database caching uses full-fledged database management systems as caches, close to application servers at the edge of the Web, to adaptively maintain sets of records from a remote database and to evaluate queries on them. We analyze a new class of approaches to database caching where the extensions of query predicates that are to be evaluated are constructed by constraints in the cache. Starting from the key concept of value completeness, we explore the application of cache constraints and their implications on query evaluation correctness and on controllable cache loading called cache safeness. Furthermore, we identify simple rules for the design of cache groups and their optimization before discussing the use of single cache groups and cache group federations. Finally, we argue that predicate completeness can be used to develop new variants of constraint-based database caching.
Chapter
Full-text available
There are a variety of structural indexes which have been proposed to speed up path expression queries over XML data. They usually work by partitioning nodes in the data graph into equivalence classes and storing equivalence classes as index nodes. In most of current structural indexes, the nodes in the same partition have the same label. They are not flexible with queries containing the wild- or alternation cards, and sometimes their size is bigger than the necessity. In this paper, we introduce the dynamic labelling structural indexes. These structural indexes only support a set of frequently used simple alternation path expressions (SAPE for short), where expressions may contain wild- or alternation cards. The labels of data nodes in the same partition may be different. The dynamic labelling not only decreases the size of the structural index, but also supports SAPE’s better. Every static labelling structural index can be improved by using dynamic labelling. Because of the limitation, in this paper we just study the DL-1-index improved from the 1-index, and the DL-A*(k)-index improved from the A(k)-index. The construction and refinement of these indexes are based on our results from the properties of partitions and the split operation. Our experiments show that the size of the improved dynamic labelling structural indexes is smaller and the query processing on these indexes is more efficient comparing to the naive ones.
Article
Full-text available
A key to increasing the quality of web applications is caching. While web caching holds document fragments ready, which are increasingly generated from database data, database caching focuses on the redundant storage of these data themselves. By means of completeness properties, an adaptively managed subset of the backend data permits the correct evaluation of queries in the cache. In cache groups for equality predicates (that is, in an instance of constraint-based database caching) the evaluability of a query can be determined through simple probe queries on the cache contents. We present a new probing procedure that makes the cache usable for more types of queries in a more flexible way; embraced by the term of negative caching, this even includes queries with empty results. We investigate whether the new probing procedure can further be generalized, which alternatives exist for its realization in concrete cache groups, and how the previous approach fits into these. Additionally, the new procedure reveals a shortcoming in the current structure of cache groups, which can be remedied by introducing control tables, and aids in maintaining the cache contents.
Conference Paper
Full-text available
We introduce a new database object called Cache Table that enables persistent caching of the full or partial content of a remote database table. The content of a cache table is either defined declaratively and populated in advance at setup time, or determined dynamically and populated on demand at query execution time. Dynamic cache tables exploit the characteristics of typical transactional web applications with a high volume of short transactions, simple equality predicates, and 3-4 way joins. Based on federated query processing capabilities, we developed a set of new technologies for database caching: cache tables, "Janus" (two-headed) query execution plans, cache constraints, and asynchronous cache population methods. Our solution supports transparent caching both at the edge of content- delivery networks and in the middle-tier of an enterprise application infrastructure, improving the response time, throughput and scalability of transactional web applications.
Article
Caching as a means to improve scalability, throughput, and r esponse time for Web applications has re- ceived a lot of attention. Caching can take place at differen t levels in a multi-tier architecture. However, due to the increased personalization and dynamism in Web con tent, caching at the bottom of the multi- tier architecture - the database level - can be beneficial to a ll upper levels because of better reusability of the cached data. DBCache supports database caching at bot h the edge of content delivery networks and at the middle-tier of Web site infrastructures. Its on-d emand caching functionality provides the key feature for adaptive and transparent data caching for Web ap plications.
die Struktur einer Cache Group selbst (nicht nur deren Inhalt) an ein verändertes Anfrageprofil anzupassen
  • Möglichkeit Auf
auf die Möglichkeit, die Struktur einer Cache Group selbst (nicht nur deren Inhalt) an ein verändertes Anfrageprofil anzupassen.
The three most important parts of any Internet application are caching, caching, and, of course
The three most important parts of any Internet application are caching, caching, and, of course, caching... Larry Ellison, Oracle CEO (2001)