Dans le paysage moderne de l'ingénierie des données à haute vélocité, le modèle relationnel traditionnel peine souvent à suivre les exigences de l'analytique en temps réel. Alors que les systèmes migrent vers des architectures événementielles et la surveillance des séries temporelles, les ingénieurs de bases de données font face à un défi critique : comment modéliser les données pour supporter des écritures à faible latence, des agrégations efficaces et des analyses historiques complexes. Cet article explore les meilleures pratiques pour optimiser les schémas dans les charges de travail de séries temporelles et d'event sourcing.
La nature des données de séries temporelles et événementielles
Avant de se plonger dans la conception du schéma, il est essentiel de comprendre les caractéristiques des données. Les données de séries temporelles représentent des mesures collectées à des points successifs dans le temps, telles que les lectures de capteurs IoT ou les données boursières (tick data). Les données d'event sourcing, en revanche, capturent des changements d'état immuables, comme les clics d'utilisateurs ou les mises à jour de statut de commande. Ces deux types de charges de travail partagent des traits communs :
- Fort débit d'écriture : Les données arrivent sous forme de flux continus.
- Immuabilité temporelle : Une fois écrites, les données sont rarement mises à jour ou supprimées.
- Modèles de requête : Les lectures sont généralement bornées dans le temps, impliquant des agrégations sur des fenêtres spécifiques.
Les schémas relationnels normalisés, bien qu'excellents pour l'intégrité transactionnelle, introduisent une surcharge significative pour ces charges de travail en raison des coûts de jointure et de la maintenance des index. Une approche désnormalisée et orientée colonnes est généralement plus appropriée.
Stratégies clés d'optimisation
1. Partitionnement par temps
La manière la plus efficace de gérer les données de séries temporelles est de les partitionner par temps. Cela permet aux bases de données d'éliminer les segments non pertinents lors des requêtes, réduisant drastiquement les entrées/sorties (I/O). Qu'il s'agisse de sharding dans les systèmes NoSQL ou de partitionnement dans les bases de données SQL, aligner votre clé de partition principale avec votre résolution temporelle est crucial.
2. Désnormalisation pour la performance en lecture
Dans l'event sourcing, le modèle "Event Store" stipule que nous stockons l'événement lui-même, et non seulement l'état résultant. Cependant, pour l'analytique, joindre des milliers d'événements pour reconstruire l'état est coûteux en termes de calcul. Au lieu de cela, envisagez de matérialiser des vues ou d'utiliser un stockage à lignes larges (wide-row storage) pour pré-agréger les données. Par exemple, au lieu de joindre une table 'utilisateurs' avec une table 'commandes', intégrez les détails de l'utilisateur directement dans l'enregistrement de l'événement de commande si la vitesse de lecture est priorisée par rapport à l'efficacité du stockage.
3. Choisir la bonne granularité
Les coûts de stockage et la latence des requêtes sont fortement influencés par la granularité des données. Stocker chaque milliseconde de données de capteur peut être inutile si votre logique métier ne nécessite que des agrégations au niveau de la minute. Mettre en œuvre une stratégie de sous-échantillonnage (down-sampling) au niveau de l'ingestion peut préserver les tendances à long terme tout en gardant le stockage léger.
Exemple de conception de schéma : Données IoT de séries temporelles
Considérons un scénario où vous ingérez des lectures de température provenant de milliers de capteurs. Une approche relationnelle naïve pourrait ressembler à ceci :
CREATE TABLE sensor_readings (
id BIGSERIAL PRIMARY KEY,
sensor_id INT,
timestamp TIMESTAMP WITHOUT TIME ZONE,
temperature DECIMAL(5,2),
humidity DECIMAL(5,2),
FOREIGN KEY (sensor_id) REFERENCES sensors(id)
);
Bien que fonctionnelle, ce schéma impose une jointure pour obtenir les métadonnées du capteur et nécessite des index complexes pour les requêtes par plage de temps. Un schéma plus optimisé pour un entrepôt de familles de colonnes (comme Cassandra ou DynamoDB) ou une base de données spécialisée en séries temporelles (comme InfluxDB ou TimescaleDB) aplatirait la structure :
CREATE TABLE sensor_metrics (
sensor_id TEXT,
bucket TIMESTAMP, -- Fenêtre d'agrégation (par ex., 1 minute)
metric_type TEXT, -- 'temperature', 'humidity'
min_value DOUBLE,
max_value DOUBLE,
avg_value DOUBLE,
PRIMARY KEY ((sensor_id, bucket), metric_type)
);
Dans ce modèle, la clé primaire combine l'entité et la fenêtre de temps (bucket). Cela garantit que les données sont localisées ensemble, permettant des scans de plage rapides. L'agrégation en min/max/moyenne au moment de l'écriture décharge le travail de calcul lourd des requêtes de lecture.
Gestion de la complexité de l'event sourcing
Pour les systèmes basés sur l'event sourcing, le défi passe d'une simple agrégation à la maintenance de projections optimisées pour la lecture. Bien que le journal des événements reste en append-only (ajout uniquement), votre couche d'analytique nécessite une vue différente. Mettez en œuvre un modèle de Ségrégation des Responsabilités Commande/Requête (CQRS). Écrivez dans un journal d'événements en append-only pour la durabilité et la rejouabilité, mais diffusez les événements vers un magasin de lecture séparé et optimisé pour l'analytique.
Utilisez la capture de données modifiées (CDC) ou des frameworks de traitement de flux comme Apache Kafka Streams pour transformer les événements bruts en formes analytiques. Ce découplage garantit que les charges de travail analytiques lourdes n'impactent pas la latence du système transactionnel principal.
Conclusion
L'optimisation des modèles de données pour l'analytique en temps réel nécessite un changement d'état d'esprit, passant d'une conception transactionnelle normalisée à des architectures désnormalisées et pilotées par les requêtes. En tirant parti du partitionnement temporel, de la désnormalisation stratégique et d'une granularité appropriée, les ingénieurs peuvent construire des systèmes qui sont à la fois rapides et évolutifs. À mesure que les volumes de données continuent de croître, investir dans une conception de schéma robuste pour les charges de travail de séries temporelles et d'event sourcing sera un facteur déterminant pour la performance du système et l'efficacité des coûts.