Database Reference
In-Depth Information
Eine Sache noch: Die ersten beiden mit
/.logs
beginnenden Zeilen am An-
fang der Ausgabe zeigen den Platz an, der von den sog. WAL-Dateien (Write-
Ahead-Log) verwendet wird. HBase nutzt das Write-Ahead-Logging als Schutz
vor ausfallenden Knoten. Das ist eine recht typische Disaster-Recovery-Tech-
nik. So wird das Write-Ahead-Logging bei Dateisystemen beispielsweise
Jour-
naling
genannt. Bei HBase werden die Logs an den WAL angehangen, bevor
Editier-Operationen (put und increment) auf der Platte festgehalten werden.
Aus Performance-Gründen werden Edits nicht unbedingt direkt auf die Fest-
platte geschrieben. Das System läuft wesentlich besser, wenn die E/A-Ope-
rationen gepuffert und in größeren Blöcken geschrieben werden. Wenn der
für die Region verantwortliche
Regions-Server
in diesem Übergangsstadium
abstürzt, nutzt HBase den WAL, um herauszufinden, welche Operationen
erfolgreich waren, und nimmt entsprechende Korrekturen vor.
Das Schreiben in den WAL ist optional und standardmäßig aktiviert. Edit-
Klassen wie
Put
und
Increment
besitzen eine Setter-Methode namens
set-
WriteToWAL
, mit der man unterbinden kann, dass die Operation in den WAL
geschrieben wird. Generell sollten Sie an der Standard-Einstellung festhal-
ten, doch in manchen Fällen kann es sinnvoll sein, das zu ändern. Wenn Sie
beispielsweise einen Import-Job laufen haben, den Sie jederzeit wiederho-
len können (wie etwa unser Wikipedia-Import-Skript), dann könnten Sie den
Performance-Vorteil durch das Abschalten des WAL der Disaster-Recovery
vorziehen.
Regionale Fragen
Wenn Sie das Skript lange genug laufen lassen, teilt HBase die Tabelle in
mehrere Regionen auf. Hier noch einmal die Ausgabe von
du
, aber diesmal
nach etwa 150000 eingefügten Seiten:
