Lade...
 

Clustering

Clustering

Bei ObjectStore ist der Datentransfer zwischen dem Datenbank-Server und den Clients pageorientiert. Deshalb bestimmt die Anordnung der Objekte in der Datenbank in hohem Maße die Performance der Anwendungen.

Das Clustering der Objekte ist steuerbar für

Für beide Fälle kann das Clustering stufenweise aktiviert bzw. deaktiviert werden.

Unter dem Aspekt des Clustering ist ein Objekt entweder ein Master- oder Slave-Objekt:

Ein Masterobjekt wird in einem für seine Klasse festgelegtem Segment der Datenbank gespeichert; Falls in der CLASSIX.INI für die anzulegende Klasse Angabe Cluster(1) vorhanden ist, dann wird für das Masterobjekt ein eigener Cluster angelegt. Die Information über das Segment und ein eventuell anzulegende Cluster sind im Datenbank-Layout (CLASSIX.INI) beschrieben.

Achtung: Das Clustering von Objekten kann sich negativ auf die Performance auswirken, falls die geclusterten Objekte in Sets oder Bags gehalten werden. Siehe: Hinweise zu Clustering und Collections

Wenn das Clustering vollständig deaktiviert ist gibt es nur Masterobjekte – dies ist die Standardannahme im ClassiX®-System.

Die Position eines Slaveobjektes in der Datenbank bestimmt ein anderes, bereits in der Datenbank gespeichertes Objekt, mit dem es verbunden wird. Die Erzeugung solch eines Objekts mit CreatePersObject, CopyPersObject muss verzögert werden bis zu dem Zeitpunkt, wenn eine Relation zu einem bereits in der Datenbank existierenden Objekt aufgebaut wird. Die genannten InstantView®-Befehle erzeugen deshalb zunächst ein (transientes) Objekt der Klasse CX_LAZY_CREATOR.
Der Ablauf beim Entladen / Laden einer Datenbank ist davon abweichend und wird dort beschrieben.

Beispiele für verschiedene Clustering-Einstellungen.

Das nachfolgende Entscheidungsdiagramm verdeutlicht, wo persistente Objekte allokiert werden.

Entscheidungsdiagramm für persistente Allokation
Entscheidungsdiagramm für persistente Allokation

 


Hinweis: der folgende Abschnitt beschreibt das Clustering beim Entladen / Laden der Datenbank

Hier soll aber auf die Regeln eingegangen werden, mit denen bestimmt wird, wann ein Objekt Master ist und wann nicht.

Die Clustering-Regeln wurden – nach pragmatischen Gesichtspunkten – in Kategorien zusammengefasst, und, in dem jeder Kategorie ein Bit zugeordnet wird, erhält man ein Pattern, mit dem die Kategorien unabhängig voneinander ein- und ausgeschaltet werden können.

Dieses Pattern wird mit der Environment-Variablen CX_CLUSTERING gesetzt; Standardannahme ist CX_CLUSTERING=0.

Das Pattern kann zur Laufzeit durch den Aufruf von SetClusteringMode verändert werden.

Die folgende Tabelle zeigt die Kategorien und die damit verbundenen Regeln; neben dem Bit in Spalte 1 wurde in der zweiten Spalte ein Name vergeben.

Spalte 3 gibt an, welche Klassen als Slaveobjekte auftreten können. Während bei elementaren Objekten (z.B. der Basisklassen CX_DATE, CX_VALUE ...) die Klassenzugehörigkeit als alleiniges Kriterium genügt, werden für komplexere Objekte Zusatzbedingungen angegeben:

Bit Kategorie Klassen Bedingung1
1 BASIC CX_NUMERIC..., CX_VECTOR_AMOUNT..., CX_TERM..., CX_FORMULA, CX_FCONDITION, CX_NAMED_FCONDITION, CX_CONDITIONED_BAG

aber nicht CX_NAMED_FORMULA

-
2 VALIDITY CX_VALIDITY... -
4 WRAPPER CX_DESCRIPTIVE_REF, CX_OVERWRITING_REF -
8 SLAVE_SEG alle -
16 ATTRIBUTES CX_ATTRIBUTE_SET... -
32 MODEL CX_PASSWORD..., CX_GENERAL_TERMS..., CX_CONDITION..., CX_ACCESS... -
64 TXNS CX_TRANSACTION... -

if ($ transaction ) transaction = master

else master is a CX_TRANSACTION

    CX_ALLOCATION...

if (card allocators > 0) master ∈ allocators

else true

128 MONITORS CX_MONITOR... außer CX_COST_CENTER_ACCOUNT..., CX_COST_OBJECTIVE_ACCOUNT..., CX_COST_TYPE_ACCOUNT..., CX_FINANCIAL_ACOCUNT..., CX_DEBIT_ACCOUNT..., CX_CREDIT_ACCOUNT..., CX_EXPENSES_ACCOUNT..., CX_PRINT_MEDIA... -
    CX_ACCOUNT... if ($ owner) owner = master else true
    CX_DATA_CUBE...
Dimension[0] = master

1 =  Die Bedingung spielt nur für das Entladen von Objekten eine Rolle, denn dort muss bei einem Slave-Objekt, das mit mehreren Master-Objekten verbunden ist, entschieden werden, zu welchem es gehört damit es nicht mehrfach entladen wird. Bei der Erzeugung von persistenten Objekten gilt nur die Bedingung, dass das REP-Pattern 0 sein muss (Ausnahme: SLAVE_SEG, dort gilt, dass das Objekt kein eigenes Segment definieren darf).

 

  • A... bedeutet Klasse A und alle davon abgeleiteten Klassen
  • REP_pattern ist das Bit-Pattern, das die Einordnung des Objekts in die REP-Collection bestimmt; entweder vorgegeben durch die Beschreibung der Klasse in CLASSIX.ODB oder durch explizite Angabe bei CreatePersObject
  • Bedingungen, die sich auf das Masterobjekt master beziehen, gelten nur beim Entladen/Laden, bei CreatePersObject / CopyPersObject wird immer ein CX_LAZY_CREATOR erzeugt
  • Wenn ein Objekt mit CreatePersObject erzeugt wird, gilt für alle Kategorien die Zusatzbedingung REP_pattern = 0. Ein transientes Objekt CX_LAZY_CREATOR kann nicht in eine REP-Collection eingefügt werden.