Bases de données SQL distribuées (NewSQL)

VérifiéPrudence

Guide complet couvrant 12 bases de données SQL distribuées (CockroachDB, YugabyteDB, TiDB, Spanner, Vitess, etc.) pour la mise en œuvre de systèmes distribués globalement et la scalabilité horizontale.

Spar Skills Guide Bot
Data & IAAvancé
4002/06/2026
Claude Code
#newsql#distributed-sql#sql-scaling#htap

Recommandé pour

Notre avis

Guide opérationnel avancé couvrant 12 bases de données NewSQL/distribuées pour la scalabilité horizontale et les charges HTAP.

Points forts

  • Comparaison détaillée de 12 bases de données NewSQL avec tableaux récapitulatifs
  • Anti-patrons concrets pour éviter les erreurs courantes (clés primaires auto-incrément, requêtes cross-shard)
  • Références vers des fichiers de référence spécialisés pour chaque technologie
  • Explication du contexte CAP et des compromis de cohérence

Limites

  • Ne fournit pas de connexion directe aux bases de données
  • Les conseils restent génériques et peuvent nécessiter adaptation
  • Ne remplace pas une expertise humaine pour des architectures complexes
Quand l'utiliser

Lors de la conception ou du dépannage de bases de données distribuées à l'échelle mondiale ou de charges HTAP.

Quand l'éviter

Pour des applications monorégion simples ne nécessitant pas de scalabilité horizontale ou de distribution géographique.

Analyse de sécurité

Prudence
Score qualité88/100

The skill provides guidance on managing distributed SQL databases and uses Bash for operational tasks. While not explicitly malicious, it grants powerful execution capabilities that could result in accidental data loss or misconfiguration if reference files are not carefully reviewed.

Points d'attention
  • Uses Bash tool, which could allow execution of destructive database operations if reference files contain dangerous commands.
  • Potentially interacts with production databases, risking data loss or corruption.

Exemples

Compare CockroachDB and TiDB for HTAP
I'm choosing between CockroachDB and TiDB for a multi-region HTAP workload. Compare their consistency models, scaling characteristics, and HTAP support. Which one is better for real-time analytics on transactional data?
Anti-patterns in Vitess sharding
We're planning to use Vitess for a large MySQL sharding project. What are the key anti-patterns to avoid when designing VSchema and choosing shard keys? Include examples of hotspot mitigation.
Spanner TrueTime implications
Explain how Google Spanner's TrueTime API ensures external consistency and its implications for read/write latency. How does it compare to CockroachDB's hybrid logical clocks?

name: newsql-distributed description: | Deep operational guide for 12 NewSQL/distributed SQL databases. CockroachDB (multi-region, geo-partitioning, CDC), YugabyteDB (YSQL/YCQL, DocDB, xCluster), TiDB (TiKV/TiFlash HTAP), Spanner (TrueTime), Vitess (sharding, VSchema), PlanetScale, Citus, SingleStore, OceanBase. Use when implementing globally distributed SQL, horizontal scaling, or HTAP workloads. allowed-tools: Read, Grep, Glob, Bash

You are a NewSQL and distributed SQL database specialist providing production-level guidance across 12 database technologies.

Distributed SQL Comparison

| Database | Consistency | PG Compatible | Scale | HTAP | Managed | |---|---|---|---|---|---| | CockroachDB | Serializable | Wire + SQL | Auto sharding | No | CockroachDB Cloud | | YugabyteDB | Serializable | YSQL (PG) + YCQL (CQL) | Auto sharding | No | YugabyteDB Aeon | | TiDB | Snapshot isolation | MySQL wire | TiKV auto-split | Yes (TiFlash) | TiDB Cloud | | Google Spanner | External consistency | PG via pgAdapter | Auto splits | No | Fully managed | | Vitess | MySQL-dependent | MySQL wire | Manual (VSchema) | No | PlanetScale | | PlanetScale | MySQL-dependent | MySQL wire | Vitess sharding | No | Fully managed | | Citus | PG defaults (RC) | Native PG extension | Manual distribution | No | Azure Cosmos for PG | | SingleStore | Read committed | MySQL wire | Shard-nothing | Yes (columnstore) | SingleStore Helios | | OceanBase | RC / Snapshot | MySQL + Oracle modes | Auto partitioning | Yes | OceanBase Cloud | | Neon | PG defaults | Full PG | Scale-to-zero | No | Fully managed serverless | | AlloyDB | PG defaults | Full PG | Read replicas | Analytics accelerator | Google Cloud managed |

Reference Files

Load the relevant reference for the task at hand:

CAP Theorem Context

NewSQL databases choose CP (Consistency + Partition Tolerance):

  • Raft/Paxos consensus ensures consistency across partitions
  • Automatic failover preserves availability in practice
  • Latency increases with geographic distance between replicas
  • Use follower reads (CRDB) or bounded staleness reads for geo-distributed latency reduction

Anti-Patterns

  • Auto-increment primary keys as shard keys (hotspot on insert)
  • Cross-shard JOINs without table colocation (scatter-gather overhead)
  • Long-running transactions in serializable isolation (contention explosion)
  • Missing retry loop for 40001 RETRY_SERIALIZABLE in CockroachDB applications
  • Blocking DDL on distributed tables without expand-contract migration
  • Skipping connection pooling (per-connection overhead is significant at scale)
Skills similaires