Da der Wertebereich einmal und für immer aufgeteilt wird, ist es problematisch wenn sich die zu Beginn getroffenen Annahmen später ändern (Datenaufkommen und/oder Anzahl Standorte). Bisher versuchten wir dem durch sehr großzügige Abschätzungen gerecht zu werden, jedoch leuchtet ein, dass dies auf Dauer kein tragfähiges Konzept ist, wenn wir aktuelle Kundenforderungen mit rasant wachsendem Datenaufkommen und dynamische Umgebungen bedienen wollen.
In den letzten 10 Jahren haben sich GUIDs als Identifier zu einer charmanten Alternative entwickelt. Diese verwenden wir seit Kurzem. GUIDs haben zwar viele Vorteile, nachteilig ist allerdings der erhöhte Speicherplatz und dass sie im Allgemeinen nicht sortiert sind. Eine Ordnung auf dem Primärschlüssel einer Datenbank zu haben hat sich in den letzten Dekaden so etabliert, dass man es einfach gerne hat.
Eine weitere immer populäre werdende Alternative sind sog. Flake Ids die erstmals mit Twitters SnowFlake Verwendung fanden. Dabei handelt es sich kurz gesagt um geordnete 64bit-Ids die auch von einem Client relativ einfach und eindeutig generiert werden können. Zusätzlich sind dort auch Bereiche für sog. Instance Ids vorgesehen, die man mit unseren Standort-Ids vergleichen könnte.
Das hört sich doch gut an, oder? Gekommen bin ich darauf als wir die neueste ElasticSearch Distribution 1.4.0 integriert haben.
Links:
- Coding Horror: Primary Keys: IDs versus GUIDs (2007)
- twitter/snowflake (GitHub)
- ElasticSearch 1.4.0 Release Notes (Flake Ids)
Möglicherweise habe ich mit meiner Darstellung den Fokus zu stark eingeschränkt. Zwei Kollegen Wolfgang haben sich bisher zu Wort gemeldet und auf den ersten Blick festgestellt, dass Flake Ids konzeptionell nicht so sehr verschieden sind und anschließend die Vor- und Nachteile bezüglich der Bit-Verteilung aufgezeigt. Die Ähnlichkeiten sollten eine kurzfristige Portierung einfacher machen.
Einer der wesentlichen Schmerzpunkte ist aus meiner Sicht, dass die Identifier in Oracle erzeugt werden während Flake Ids client-seitig generiert werden können. Das hat nicht nur aus architekturieller Sicht viele Vorteile und betrifft u.a. die folgenden Aspekte:
- Testbarkeit/Wartbarkeit: Tests können erst sinnvoll stattfinden, wenn eine Oracle-Instanz da ist, d.h. erst ab der Integrationsphase. Unit-Tests scheiden da aus oder können nur mit unnötigem Extra-Aufwand gefahren werden. Das bedeutet, dass Fehler mit höherer Wahrscheinlichkeit erst später gefunden werden, deren Behebung dann unverhältnismäßig teurer ist (vgl. z.B. Software Development Costs Pyramid). Mit Flake-Ids sind Unit-Tests auf Identifier-Logik trivial.
- Interoperabilität/Evolvierbarkeit: DBs die nicht auf Oracle basieren, z.B. NoDB-Varianten oder ElasticSearch, haben zur Zeit ggf. eine Abhängigkeit zu der Identifier-Sequence in Oracle. Für alternative DB-Implementierungen die auch eigenständig und unabhängig funktionieren wollen und sollen, ist das schon ein Show-Stopper. Auch wenn die Prozesskette des Imports mehr als ein Modul umfasst werden die Identifier erst ganz am Ende erzeugt. Mit Flake-Ids gibt es den Ausblick dass die Identifier konsistent schon weiter vorne direkt von den Importern erzeugt werden. Das kann u.a. die Nachvollziehbarkeit bei Prüfungen auf Vollständigkeit verbessern. Auch die Realisierung neuer Komponenten sowie die Wartung bestehender Komponenten, kann von der DB besser entkoppelt werden, sodass die Wahrscheinlichkeit von Wartezeiten aufgrund von Ressourcen-Flaschenhälsen durch Wissensinseln reduziert wird. Für mich ist das ein sehr starkes Argument.
- Vermittelbarkeit/Transparenz: Fragen wie "Wie habt ihr in Projekt XY den Wertebereich gewählt" oder "Wie ist das mit den Identifiern wenn wir den Datenbestand von Kunde/Projekt XY anbinden wollen?" sind bestimmt leichter zu beantworten. Fachliche Abstimmungen mit Kollegen, internen Teams oder Drittfirmen laufen wahrscheinlich reibungsfreier und einfacher ab wenn wir sagen können "Identifier-Konzept? Ja, wir verwenden Flake Ids.". Alles andere gibt es bei Google und GitHub.
No comments:
Post a Comment