ALIBABA CLOUD → STACKIT · WIDE-COLUMN-ARCHITEKTUR

Alibaba Cloud Tablestore und HBase auf STACKIT

STACKIT hat keinen verwalteten Wide-Column-Store, und der Lauf sagt das für beide Dienste. Tablestore und ApsaraDB for HBase sind als REDESIGN mit denselben zwei Zielen klassifiziert: ein Wide-Column-Store im Eigenbetrieb auf SKE oder MongoDB Flex nach einem Redesign des Datenmodells. Diese Seite stellt beide nebeneinander, zeigt, was die Tablestore- und HBase-Einstellungen für die Wahl bedeuten, und benennt, was der Lauf Ihnen überlässt.

Eine Tablestore-Instanz, ihre Tabelle und ein HBase-Cluster, bewertet

Eine für diese Seite geschriebene Telemetrie-Umgebung, am 4. November 2026 von StackToIT bewertet. Links: die drei Datenressourcen der Eingabe. Rechts: ein Auszug aus assessment.json mit den Werten, die der Lauf geschrieben hat. Da assessment.json in einer einzigen Zeile geschrieben ist, zeigt der Ausschnitt ausgewählte Felder jeder Einheit, eingerückt und so verschachtelt wie in der Datei, mit unveränderten Werten.

Beispieleingabemain.tf
resource "alicloud_ots_instance" "devices" {
  name        = "device-state"
  description = "Device state and recent readings"
  accessed_by = "Vpc"
  instance_type = "HighPerformance"
}

resource "alicloud_ots_table" "readings" {
  instance_name = alicloud_ots_instance.devices.name
  table_name    = "readings"
  time_to_live  = -1
  max_version   = 1
  primary_key {
    name = "device_id"
    type = "String"
  }
  primary_key {
    name = "ts"
    type = "Integer"
  }
}

resource "alicloud_hbase_instance" "history" {
  name                   = "telemetry-history"
  engine_version         = "2.0"
  master_instance_type   = "hbase.sn2.2xlarge"
  core_instance_type     = "hbase.sn2.2xlarge"
  core_instance_quantity = 3
  core_disk_type         = "cloud_ssd"
  core_disk_size         = 400
  vswitch_id             = alicloud_vswitch.data.id
  vpc_id                 = alicloud_vpc.main.id
  zone_id                = "eu-central-1a"
  pay_type               = "PostPaid"
}
StackToIT-Bewertungassessment.json
[
  {
    "id": "alicloud_ots_instance.devices",
    "result": {
      "class": "REDESIGN",
      "confidence": "MEDIUM",
      "target": {
        "service": "a self-managed wide-column store on SKE, or MongoDB Flex after a data-model redesign"
      },
      "reason": "STACKIT has no managed wide-column store. Run one yourself on SKE, or redesign the data model for MongoDB Flex."
    }
  },
  {
    "id": "alicloud_ots_table.readings",
    "result": {
      "class": "MANUAL_REVIEW",
      "confidence": "LOW",
      "reason": "alicloud_ots_table is not in the knowledge base catalogue; an architect has to decide the target. Nothing of this resource is assessed or drafted (unknown source type)."
    }
  },
  {
    "id": "alicloud_hbase_instance.history",
    "result": {
      "class": "REDESIGN",
      "confidence": "LOW",
      "target": {
        "service": "a self-managed wide-column store on SKE, or MongoDB Flex after a data-model redesign"
      },
      "reason": "STACKIT has no managed wide-column store. Run one yourself on SKE, or redesign the data model for MongoDB Flex."
    }
  }
]
  • Zwei Instanzen, ein Urteil

    Die Tablestore-Instanz ist REDESIGN mit Konfidenz MEDIUM, die HBase-Instanz REDESIGN mit Konfidenz LOW. Beide nennen dieselben zwei Ziele.

  • Die Tabelle fehlt im Katalog

    alicloud_ots_table ist als MANUAL_REVIEW mit Konfidenz LOW klassifiziert, weil StackToIT diesen Ressourcentyp noch nicht katalogisiert. Primärschlüssel, Versions- und Ablaufeinstellungen lesen Sie selbst aus der Eingabe.

  • Verantwortliche

    Der Lauf legt beide Instanzen in ein Arbeitspaket für den Data Architect. Die Tabelle liegt in einem eigenen Paket, dessen Verantwortlicher NOT_STATED lautet; legen Sie ihn fest.

Die Optionen und was jede kostet

OptionWas es bedeutetAbwägung
Selbst betriebener Wide-Column-Store auf SKEDas Ziel, das der Lauf zuerst nennt. Sie deployen und betreiben einen Wide-Column-Store auf Ihrem SKE-Cluster.Behält das Wide-Column-Modell und das Row-Key-Design. Sie betreiben Speicher, Updates, Backups und Monitoring.
MongoDB Flex nach RedesignDas zweite Ziel des Laufs. Eine verwaltete Dokumentdatenbank mit Replica Sets und Sharded Clusters.Verwalteter Betrieb. Row Keys, Versionen und Column Families werden zu einem Dokumentmodell und Indizes, und der Anwendungscode ändert sich.
Aufteilung nach ZugriffsmusterEine Option für den Architekten, kein Laufergebnis: aktueller Zustand per Schlüssel auf MongoDB Flex, große Historie in einem selbst betriebenen Store.Zwei Systeme in Ihrer Verantwortung, jedes passend zu seinem Zugriffsmuster. Nur sinnvoll, wenn Ihre Workload diese Trennung tatsächlich zeigt.

Der Lauf entscheidet nicht zwischen den ersten beiden. Seine Klasse ist REDESIGN, weil keines der Ziele ein Drop-in-Ersatz ist.

Was die Quelleinstellungen für die Wahl bedeuten

  • Primärschlüssel und Partitionsschlüssel

    Ein Tablestore-Primärschlüssel hat eine bis vier Spalten, Zeilen sind danach sortiert, und die erste Spalte ist der Partitionsschlüssel. Die Beispieltabelle nutzt device_id und ts; ein Schlüssel, der mit dem Gerät beginnt, ist der natürliche Anfang eines MongoDB-Index oder Row-Key-Designs.

  • Versionen und Ablauf

    Die Tabelle setzt max_version auf 1 und time_to_live auf -1. Eine Version und kein Ablauf sind der einfachste Fall für ein Redesign; eine Tabelle mit mehreren Versionen je Zelle braucht im Dokumentmodell eine bewusste Antwort.

  • Eine Größengrenze, die mitwandert

    Tablestore empfiehlt, alle Zeilen eines Partitionsschlüsselwerts zusammen unter 10 GB zu halten. Liegen Sie nahe daran, gehört das Schlüsseldesign zum Redesign.

  • HBase-API im Code

    Tablestore bietet einen HBase-Client, der den HBase-Client kapselt und nur eine Column Family je Tabelle unterstützt, standardmäßig f. Anwendungen mit HBase-Aufrufen behalten diese API-Oberfläche, was für den Wide-Column-Weg spricht.

  • ApsaraDB for HBase

    Der Dienst hat ein eigenes SDK auf derselben Hauptversionslinie wie Open-Source-HBase; in der Build-Datei wird die Open-Source-Abhängigkeit ersetzt. Der Rückweg zu einem Open-Source-HBase-Client ist der umgekehrte Tausch. Das ist ein Vorschlag aus Architektensicht, keine Ausgabe des Laufs; testen Sie ihn also.

  • Dokumentmodell

    MongoDB Flex bietet Replica Sets für Verfügbarkeit und Sharded Clusters, die Daten für mehr Leistung auf mehrere Einheiten verteilen. Ablauf und Zugriffsmuster werden dann in MongoDB selbst ausgedrückt; das ist allgemeine Praxis, die Sie je Workload prüfen.

So entscheiden Sie

  1. 1. Zugriff auf die Daten klären

    Lesen Sie den Anwendungscode: Tablestore-SDK, Tablestore-HBase-Client oder ApsaraDB-for-HBase-Client. Das bestimmt, wie viel Code sich je Option ändert.

  2. 2. Größe und Wachstum messen

    Das Terraform nennt einen HBase-Cluster mit drei Core-Knoten und je 400 GB Disk und eine Tablestore-Instanz ohne Größenangabe. Das echte Volumen kommt aus Ihrem Konto, nicht aus dem Lauf.

  3. 3. Betriebsmodell wählen

    Einen Store auf SKE betreiben Sie selbst. MongoDB Flex ist verwaltet. Benennen Sie den Verantwortlichen, bevor Sie wählen.

  4. 4. Die Kopie planen

    Der Lauf wählt kein Verfahren für den Datenumzug. Alibaba Cloud dokumentiert Data Integration für HBase zu Tablestore; für den Weg nach STACKIT wählen Sie das Verfahren selbst, nach Größe und tolerierter Ausfallzeit.

  5. 5. Mit einer Kopie proben

    Laden Sie eine Stichprobe ins Ziel, führen Sie die Lesepfade der Anwendung aus und vergleichen Sie die Ergebnisse vor jedem Cutover.

Fragen, die Datenteams stellen

Bietet STACKIT ein verwaltetes HBase oder Tablestore?

Laut Lauf hat STACKIT keinen verwalteten Wide-Column-Store. Sie betreiben selbst einen auf SKE oder entwerfen das Datenmodell für MongoDB Flex neu.

Warum ist die Tablestore-Tabelle MANUAL_REVIEW?

StackToIT katalogisiert den Ressourcentyp der Tabelle noch nicht, daher wird nichts davon bewertet. Der Lauf bittet einen Architekten, das Ziel zu entscheiden, und führt keine Einstellung als übernommen auf.

Plant der Lauf die Datenkopie?

Nein. Seine Datei zum Datenumzug meldet für diese Umgebung NOT APPLICABLE mit dem Hinweis, die Quelle enthalte keine Datenbank, keinen Cache oder ähnlichen Speicher. Dieser Text zählt Wide-Column-Instanzen nicht mit; lesen Sie ihn also als „kein Verfahren gewählt“, nicht als „keine Daten zu übertragen“.

Kann die HBase-Anwendung unverändert bleiben?

Sie kann die HBase-API behalten, wenn Sie einen selbst betriebenen Wide-Column-Store wählen, allerdings ändern sich Verbindungseinstellungen und Client-Abhängigkeit. Mit MongoDB Flex wird der Datenzugriffscode neu geschrieben.

Quellen

Ihr nächster Schritt: STACKIT.

Erzählen Sie uns von Ihrer Umgebung. Wir zeigen Ihnen, was StackToIT dafür liefert: Zielarchitektur, Terraform-Artefakte und einen strukturierten Migrationsplan.