Les bases de données relationnelles (SQL) excellent pour l’intégrité référentielle, les transactions ACID et les requêtes complexes. Mais face au big data, aux applications temps réel et aux schémas évolutifs, elles montrent leurs limites : difficulté de scalabilité horizontale, schéma rigide, coût des jointures massives. Les bases NoSQL (Not Only SQL) répondent à ces défis. ISOSET forme les architectes data à choisir la bonne base selon le cas d’usage.

Chaque famille répond à des besoins spécifiques :

• Document stores (MongoDB, Couchbase) — stockent des documents JSON/BSON, idéal pour contenu, catalogues produits, profils utilisateurs.
• Wide-column stores (Cassandra, HBase) — colonnes flexibles, excellentes pour l’écriture massive et la lecture par clé, utilisées dans l’IoT, la messagerie, la finance.
• Key-Value stores (Redis, DynamoDB) — accès ultra-rapide par clé, parfaits pour cache, sessions, file d’attente.
• Graph databases (Neo4j, ArangoDB) — optimisées pour les relations complexes (réseaux sociaux, recommandations).

Ce focus est mis sur MongoDB (document) et Cassandra (wide-column), deux leaders du marché.

MongoDB stocke les données sous forme de documents BSON (JSON binaire), regroupés dans des collections. Pas de schéma fixe : chaque document peut avoir ses propres champs. L’indexation est puissante, le langage de requête (MQL) permet des filtres, agrégations, jointures (lookup) et géospatiales. La scalabilité se fait via le sharding (distribution sur plusieurs serveurs) et la haute disponibilité via les replica sets. Les formations grand public ISOSET incluent des ateliers pratiques sur MongoDB Atlas (cloud).

// Insertion d'un document dans MongoDB (Node.js / Python)
db.collection("utilisateurs").insertOne({
  nom: "Durand",
  prenom: "Marie",
  email: "marie.durand@email.com",
  adresses: [
    { ville: "Lyon", codePostal: 69001 },
    { ville: "Paris", codePostal: 75001 }
  ],
  preferences: { newsletter: true, theme: "dark" }
});

// Requête : trouver les utilisateurs avec une préférence newsletter true
db.utilisateurs.find({ "preferences.newsletter": true }).sort({ nom: 1 });

// Agrégation avec lookup (jointure)
db.commandes.aggregate([
  { $lookup: {
      from: "clients",
      localField: "clientId",
      foreignField: "_id",
      as: "client"
  }},
  { $unwind: "$client" },
  { $group: {
      _id: "$client.nom",
      totalCommandes: { $sum: 1 }
  }},
  { $sort: { totalCommandes: -1 } }
]);

Conçue par Facebook pour sa messagerie, Cassandra est une base de données distribuée wide-column, réputée pour sa tolérance aux pannes et ses performances en écriture. Elle repose sur une architecture pair-à-pair (pas de master unique) et utilise le partitionnement consistent hashing. Le langage de requête est CQL (Cassandra Query Language), proche du SQL mais sans jointures ni agrégations complexes. La modélisation des données est différente : on pense d’abord aux requêtes (query-driven design) pour optimiser les lectures. ISOSET forme dès le plus jeune âge à ces concepts avancés de distribution.

// Création d'une table Cassandra (CQL)
CREATE KEYSPACE IF NOT EXISTS isoset_keyspace
WITH replication = {'class': 'NetworkTopologyStrategy', 'datacenter1': 3};

USE isoset_keyspace;

CREATE TABLE utilisateurs (
    user_id UUID PRIMARY KEY,
    nom text,
    email text,
    date_inscription timestamp,
    pays text
);

// Insertion et requête
INSERT INTO utilisateurs (user_id, nom, email, pays)
VALUES (uuid(), 'Martin', 'martin@mail.com', 'FR');

SELECT * FROM utilisateurs WHERE pays = 'FR';

Le théorème CAP énonce qu’un système distribué ne peut garantir simultanément trois propriétés : Cohérence (Consistency), Disponibilité (Availability) et Tolérance au partitionnement (Partition tolerance). En cas de coupure réseau, il faut choisir entre cohérence et disponibilité. La méthodologie ISOSET aide à comprendre ces arbitrages.

• MongoDB : par défaut, cohérence forte au sein d’un replica set, mais peut être configuré pour une disponibilité accrue. Le sharding introduit une cohérence éventuelle.
• Cassandra : privilégie la disponibilité et la tolérance au partitionnement (AP). La cohérence est ajustable via le niveau de cohérence des requêtes (ONE, QUORUM, ALL).
• Base relationnelle : privilégie la cohérence (CP, mais souvent faible tolérance au partitionnement).

Le choix dépend du workload et des contraintes.

# Exemple : enregistrement de millions d'événements IoT avec Cassandra
# Table dédiée pour les capteurs : (capteur_id, timestamp, valeur)
CREATE TABLE mesures (
    capteur_id text,
    date_hour timestamp,
    valeur float,
    PRIMARY KEY ((capteur_id), date_hour)
) WITH CLUSTERING ORDER BY (date_hour DESC);
# Permet de récupérer rapidement les dernières mesures d'un capteur

Les index sont cruciaux dans les bases NoSQL pour éviter les scans complets. MongoDB supporte les index simples, composés, uniques, TTL (expiration), géospatiaux et full-text. Cassandra, quant à lui, ne permet pas d’index secondaires sur des colonnes à haute cardinalité (performance dégradée). La modélisation des clés primaires (partition key + clustering columns) détermine l’efficacité des requêtes. ISOSET Entreprises propose des modules avancés sur l’optimisation des performances.

// Index composé dans MongoDB
db.produits.createIndex({ "categorie": 1, "prix": -1 });

// Index sur colonne de clustering Cassandra
// (déjà défini par la clé primaire composite)

Les bases NoSQL s’intègrent naturellement avec Spark (Spark MongoDB Connector, Spark Cassandra Connector), Kafka, et les pipelines de données. On utilise souvent une architecture polyglotte : une base relationnelle pour la gestion des commandes (ACID), MongoDB pour le catalogue produit, Cassandra pour les logs d’activité, Redis pour le cache. Les formateurs ISOSET sont des experts de ces architectures hybrides.

# Lecture d'une table Cassandra depuis Spark
df = spark.read.format("org.apache.spark.sql.cassandra") \
    .options(table="utilisateurs", keyspace="isoset_keyspace") \
    .load()
df.groupBy("pays").count().show()