Datenbanken als Locks, Heap-Tabellen und mehr - Ergebnisse des letzten Hackathons

Wieder einmal trafen sich alle Entwickler aus dem Unternehmen zu einer weiteren Auflage unseres monatlichen Hackathons - ein Tag, der der Erforschung, dem Lernen und der Diskussion gewidmet ist. Diesmal lag der Schwerpunkt auf SQL-Datenbanken. Wir folgten einer vertrauten Struktur, ähnlich wie bei unseren früheren Git- und Shell-Veranstaltungen:

1. Wir stellten eine lange Liste interessanter Themen zusammen und teilten sie verschiedenen Teammitgliedern zu.
2. Jeder hatte 60-90 Minuten Zeit, um eine kurze Sitzung zu seinem Thema vorzubereiten.
3. Anschließend kamen wir wieder zusammen, um zu präsentieren, zu diskutieren und Erkenntnisse auszutauschen.

Dieses Format ermöglicht es uns, in neue Themen einzutauchen, unsere Lehrfähigkeiten zu verfeinern und in einem kollaborativen, entspannten Umfeld zu lernen. Am Ende des Tages nimmt jeder Teilnehmer seine eigenen wichtigen Erkenntnisse mit nach Hause. Heute möchte ich zwei Erkenntnisse weitergeben, die mir bei diesem tiefen Eintauchen in Datenbanken besonders aufgefallen sind.

Datenbanken für die Verwaltung von Locks

Bei der Diskussion von Transaktionen, Datenbankservern und Verwaltungssystemen haben wir die Idee untersucht, eine Datenbank als Mutex oder Lock zu verwenden, um die parallele Ausführung einer bestimmten Aufgabe zu verhindern. Ursprünglich war dies nur ein Gedankenexperiment - da Locks oft In-Memory verwaltet werden -, aber wir entdeckten ein reales Szenario, in dem dieser Ansatz wertvoll ist: Serverless Computing.

Auf Plattformen wie Vercel haben Entwickler wenig Kontrolle über die horizontale Skalierung ihrer Anwendungen. Die Plattform kann bei Spitzenbelastungen Hunderte von Instanzen hochfahren, während sie im Leerlauf alles wieder herunterfährt. In solchen Fällen kann eine zentrale Datenbank (vorausgesetzt, sie ist nicht verteilt) als belastbarer Lockingmechanismus dienen:

const hasLock = await db.transaction(async (tx) => {
  // Retrieve locks newer than 2 minutes
  const currentLockCount = await tx
    .select()
    .from(lock)
    .where(gt(lock.lastTouched, sql.raw(`(NOW() - INTERVAL 2 MINUTE)`)))
    .for("update")
    .execute();

  if (currentLockCount.length > 0) {
    return false;
  }

  await tx
    .insert(lock)
    .values({ lastTouched: sql`NOW()` })
    .execute();

  return true;
});

if (!hasLock) {
  return { kind: "LOCK_NOT_FREE" };
}

try {
  // Ensuring that only one instance runs this code
  console.log("I'm alone!");
} finally {
  await db.delete(lock).execute();
}

Ein Nachteil dieses Ansatzes ist die Möglichkeit von verwaisten Locks: Wenn ein Prozess abstürzt, bevor er seine Locks freigegeben hat, bleibt der Eintrag in der Datenbank erhalten. Um da gegen zu wirken, ist es wichtig, eine Timeout-Periode zu implementieren, die bestimmt, wie lange ein Lock gültig bleibt.

Heap-Tabellen und verschwendeter Speicherplatz

Natürlich haben wir uns auch mit Indizes, Schlüsseln und Constraints beschäftigt. Eine weniger bekannte Tatsache fiel auf: Tabellen ohne Primärschlüssel werden als Heaps gespeichert.

Einer Heap-Tabelle fehlt die natürliche Ordnung, d. h. es gibt keine direkte Möglichkeit, auf Zeilen zu verweisen (außer über die Zeilennummer). Noch wichtiger ist, dass das Löschen von Zeilen aus einer Heap-Tabelle nicht sofort Speicherplatz freigibt. Stattdessen werden die gelöschten Zeilen lediglich als nicht verfügbar markiert, belegen aber weiterhin Speicherplatz.

Bei häufig aktualisierten Tabellen kann dies zu ernsthaften Ineffizienzen führen. Während unseres Hackathons haben wir zwei Fälle identifiziert, in denen Tabellen in unseren Datenbanken keinen offensichtlichen Primärschlüssel hatten und daher als Heap gespeichert wurden, der massiv gewachsen war, obwohl er nur ein paar hundert Zeilen enthielt - was zu Leistungsproblemen und übermäßiger Festplattennutzung führte.

Die Lösung? Die Einführung eines eindeutigen Schlüssels, auch wenn es sich nur um einen Hash des Inhalts handelt, der die Tabelle zwingt, einen geclusterten Index zu verwenden, wodurch eine unnötige Aufblähung der Festplatte verhindert wird. Man lernt scheinbar nie aus...

Nie aufhören zu Lernen

Dieser Hackathon hat eine wichtige Lektion verstärkt: Egal wie lange man schon mit einer Technologie arbeiten, es gibt immer etwas Neues zu lernen.

Solltest du jemals die Gelegenheit haben, an einer ähnlichen Veranstaltung teilzunehmen, zögere nicht, nur weil du denken, dass du das Thema bereits gut kennst. Diskussionen, Experimente und Forschung werden immer neue Erkenntnisse bringen - manchmal an den unerwartetsten Stellen.