Services de stockage et de récupération de données

Les services de données Google Cloud décrits sur cette page incluent ceux qui stockent et fournissent des données en réponse à une requête. Les SLI de ces services sont semblables aux SLI pour les services de requête-réponse, décrits dans la section Services de requête-réponse, en accordant une accent sur la disponibilité et la latence. Notez que la latence, en particulier lors de la mesure du temps de réponse d'une requête de base de données, est souvent un facteur de quantité de données récupérées et qui peut varier en fonction de la charge de travail de l'application.

Vous pouvez exprimer un SLI de disponibilité basé sur les requêtes en utilisant la structure TimeSeriesRatio pour définir un ratio de "bonnes" requêtes par rapport au nombre total de requêtes. Vous décidez de la manière de filtrer la métrique à l'aide de ses étiquettes disponibles afin d'obtenir votre détermination de "bonne" ou "valide".

Vous pouvez exprimer un SLI de latence basé sur les requêtes à l'aide d'une structure DistributionCut.

Cloud Storage

Cloud Storage est le magasin d'objets durable de Google Cloud pour le monde entier. Cloud Storage est disponible dans plusieurs classes de stockage, qui vous permettent de déterminer le coût et le modèle de récupération appropriés pour votre service ou cas d'utilisation.

Pour en savoir plus, consultez les ressources suivantes:

SLI de disponibilité

Cloud Storage écrit des données de métriques dans Cloud Monitoring à l'aide du type de ressource surveillée gcs_bucket et du type de métrique api/request_count. Vous pouvez filtrer les données à l'aide du libellé de métrique response_code pour comptabiliser les requêtes "bonne". Vous pouvez également utiliser le libellé de métrique method pour mesurer la disponibilité d'une méthode d'API spécifique, telle que ReadObject.

Vous pouvez exprimer un SLI de disponibilité basé sur des requêtes pour lire des objets à partir d'un bucket Cloud Storage à l'aide d'un ratio, TimeSeriesRatio, de requêtes satisfaisantes par rapport au nombre total de requêtes, comme illustré dans l'exemple suivant:

"serviceLevelIndicator": {
  "requestBased": {
    "goodTotalRatio": {
      "totalServiceFilter":
        "metric.type=\"storage.googleapis.com/api/request_count\"
         resource.type=\"gcs_bucket\"
         metric.label.\"method\"=\"ReadObject\"
         resource.label.\"bucket_name\"=\"my_bucket\"",
      "goodServiceFilter":
        "metric.type=\"storage.googleapis.com/api/request_count\"
         resource.type=\"gcs_bucket\"
         metric.label.\"method\"=\"ReadObject\"
         resource.label.\"bucket_name\"=\"my_bucket\"
         metric.label.\"response_code\"=\"OK\"",
    }
  }
}

SLI de latence

Cloud Storage ne fournit pas de métrique de latence. Si la latence pose problème, envisagez d'instrumenter votre service pour collecter ces informations sur le client.

Cloud Bigtable

Cloud Bigtable est un service de base de données NoSQL entièrement géré et évolutif, pour les charges de travail analytiques et opérationnelles d'envergure. Bigtable est idéal pour stocker de très grandes quantités de données dans un magasin de paires clé/valeur. Bigtable prend également en charge un débit de lecture et d'écriture élevé avec une faible latence, offrant un accès rapide à de grandes quantités de données.

Pour en savoir plus, consultez les ressources suivantes:

SLI de disponibilité

Bigtable écrit des données de métrique dans Cloud Monitoring à l'aide du type de ressource surveillée bigtable_table et des types de métriques suivants :

Vous pouvez exprimer un SLI de disponibilité basé sur des requêtes pour lire des objets à partir d'un bucket Cloud Storage à l'aide d'un ratio, TimeSeriesRatio, de requêtes "bad" par rapport au nombre total de requêtes, comme illustré dans l'exemple suivant :

Vous pouvez utiliser ces deux métriques pour exprimer un SLI de disponibilité basé sur les requêtes en créant une structure TimeSeriesRatio pour les requêtes ayant échoué par rapport aux requêtes totales, comme illustré dans l'exemple ci-dessous :

"serviceLevelIndicator": {
  "requestBased": {
    "goodTotalRatio": {
      "totalServiceFilter":
        "metric.type=\"bigtable.googleapis.com/server/request_count\"
         resource.type=\"bigtable_table\"
         resource.label.\"table\"=\"my_table\"
         resource.label.\"cluster\"=\"my_cluster\"",
      "badServiceFilter":
        "metric.type=\"bigtable.googleapis.com/server/error_count\"
         resource.type=\"bigtable_table\"
         resource.label.\"table\"=\"my_table\"
         resource.label.\"cluster\"=\"my_cluster\"",
    }
  }
}

SLI de latence

Pour mesurer la latence, Bigtable écrit des données de métrique dans Cloud Monitoring à l'aide du type de ressource surveillée bigtable_table et du type de métrique server/latencies. Vous pouvez filtrer les données à l'aide du libellé de métrique method pour mesurer les latences de méthodes spécifiques.

Vous pouvez exprimer un SLI de latence basé sur les requêtes à l'aide d'une structure DistributionCut.

L'exemple de SLO suivant attend que 99% de toutes les requêtes adressées à la table my_table du cluster my_cluster tombent entre 0 et 100 ms de latence totale sur une période glissante d'une heure:

{
  "serviceLevelIndicator": {
    "requestBased": {
      "distributionCut": {
        "distributionFilter":
          "metric.type=\"bigtable.googleapis.com/server/latencies\"
           resource.type=\"bigtable_table\"
           resource.label.\"table\"=\"my_table\"
           resource.label.\"cluster\"=\"my_cluster\"",
        "range": {
          "min": 0,
          "max": 100
        }
      }
    }
  },
  "goal": 0.99,
  "rollingPeriod": "86400s",
  "displayName": "98% requests under 100 ms"
}

Cloud Spanner

Cloud Spanner est un service de base de données relationnelle entièrement géré, qui est conçu pour offrir une cohérence transactionnelle à l'échelle mondiale. Il fournit des schémas, SQL (ANSI 2011 avec extensions) et une réplication synchrone automatique pour garantir une haute disponibilité.

Pour en savoir plus, consultez les ressources suivantes:

SLI de disponibilité

Spanner écrit les données de métrique dans Cloud Monitoring à l'aide du type de ressource surveillée spanner_instance et du type de métrique query_count. Vous pouvez filtrer les données à l'aide du libellé de métrique status pour compter les requêtes de base de données ayant abouti et échoué.

Vous pouvez exprimer un SLI de disponibilité basé sur les requêtes en créant une structure TimeSeriesRatio pour les requêtes "satisfaisantes" par rapport au nombre total de requêtes, comme indiqué dans l'exemple suivant :

"serviceLevelIndicator": {
  "requestBased": {
    "goodTotalRatio": {
      "totalServiceFilter":
        "metric.type=\"spanner.googleapis.com/query_count\"
         resource.type=\"spanner_instance\"
         metric.label.\"database\"=\"my_database\"",
      "goodServiceFilter":
        "metric.type=\"spanner.googleapis.com/query_count\"
         resource.type=\"spanner_instance\"
         metric.label.\"database\"=\"my_database\"
         metric.label.\"status\"=\"ok\"",
    }
  }
}

SLI de latence

Pour mesurer la latence, Bigtable écrit des données de métrique dans Cloud Monitoring à l'aide du type de ressource surveillée spanner_instance et du type de métrique api/request_latencies. Vous pouvez filtrer les données à l'aide du libellé de métrique method pour mesurer les latences de méthodes spécifiques. Les données incluent des latences non seulement pour les requêtes mais également pour d'autres appels d'API Spanner.

Vous pouvez exprimer un SLI de latence basé sur les requêtes à l'aide d'une structure DistributionCut. L'exemple de SLO suivant attend que 99 % de toutes les requêtes adressées à la base de données my_database tombent entre 0 et 100 ms de latence totale sur une période glissante d'une heure :

{
  "serviceLevelIndicator": {
    "requestBased": {
      "distributionCut": {
        "distributionFilter":
          "metric.type=\"spanner.googleapis.com/api/request_latencies\"
           resource.type=\"spanner_instance\"
           metric.label.\"database\"=\"my_database\"",
        "range": {
          "min": 0,
          "max": 100
        }
      }
    }
  },
  "goal": 0.99,
  "rollingPeriod": "86400s",
  "displayName": "98% requests under 100 ms"
}

Datastore

Datastore est une base de données NoSQL qui offre une grande évolutivité pour vos applications. Cet outil gère automatiquement la segmentation et la réplication des données. Vous disposez ainsi d'une base de données durable et à disponibilité élevée, capable d'évoluer de manière dynamique pour absorber la charge de vos applications.

Pour en savoir plus, consultez les ressources suivantes:

SLI de disponibilité

Spanner écrit les données de métrique dans Cloud Monitoring à l'aide du type de ressource surveillée datastore_request et du type de métrique api/request_count. Vous pouvez filtrer les données à l'aide du libellé de métrique response_code pour compter les appels d'API réussis et échoués. Vous pouvez également utiliser le libellé de métrique api_method pour, par exemple, ne mesurer que les lectures de documents.

Pour exprimer un SLI de disponibilité basé sur des requêtes, créez une structure TimeSeriesRatio pour les requêtes réussies par rapport au nombre total de requêtes, comme indiqué dans l'exemple suivant :

"serviceLevelIndicator": {
  "requestBased": {
    "goodTotalRatio": {
      "totalServiceFilter":
        "metric.type=\"datastore.googleapis.com/api/request_count\"
         resource.type=\"datastore_request\"",
      "goodServiceFilter":
        "metric.type=\"datastore.googleapis.com/api/request_count\"
         resource.type=\"datastore_request\"
         metric.label.\"response_code\"=\"success\"",
    }
  }
}

SLI de latence

Actuellement, Datastore ne fournit pas de métrique de latence. Pour consulter les métriques disponibles, consultez la page Types de métriques datastore.googleapis.com.