Quelques réponses pour MySQL. Étant donné que toutes les bases de données sont soumises à l'espace disque, à la latence du réseau, etc., d'autres moteurs peuvent être similaires.

• Peu importe le nombre de lignes, une « requête ponctuelle » (obtention d'une ligne à l'aide d'un index approprié) prend des millisecondes.
• Il est possible d'en écrire un SELECT qui prend des heures, voire des jours, à s'exécuter. Vous devez donc comprendre si la requête est pathologique comme celle-ci. (Je pense que c'est un exemple de "latence" élevée.)
• Le « sharding » est nécessaire lorsque vous ne pouvez pas maintenir le nombre d'écritures requis sur un seul serveur.
• Les lectures volumineuses peuvent être mises à l'échelle « à l'infini » en utilisant la réplication et en envoyant des lectures aux réplicas.
• PARTITIONing (surtout dans MySQL) a très peu d'utilisations. Plus de détails : Partitions
• INDEX Très important pour la performance.
• Pour les applications d'entrepôt de données, la création et la maintenance de « tableaux récapitulatifs » sont essentielles pour des performances à grande échelle. (Certains autres moteurs ont des outils intégrés.)
• 每天插入Un million de lignes n'est pas un problème. (Bien sûr, certaines conceptions de schéma peuvent causer ce problème.) Règle générale : 100/s peut ne pas être un problème ; 1 000/s peut être possible après cela, cela devient plus difficile. En savoir plus sur Ingestion haute vitesse
• La latence du réseau dépend principalement de la distance entre le client et le serveur. Il lui faut plus de 200 millisecondes pour atteindre l’autre côté de la Terre. En revanche, si le client et le serveur sont dans le même bâtiment, la latence sera inférieure à 1 milliseconde. Si, d'un autre côté, vous faites référence au temps nécessaire pour exécuter une requête, voici quelques règles empiriques : 10 ms pour une requête simple qui doit atteindre le disque dur ; 1 ms pour un SSD.
• Les UUID et les hachages sont très préjudiciables aux performances si les données sont trop volumineuses pour être mises en cache dans la RAM.
• Je n’ai pas évoqué le ratio lecture/écriture car je préfère juger de manière indépendante la lecture et l’écriture.
• « Dix mille lectures par seconde » est difficile à atteindre ; je pense que très peu d'applications en ont vraiment besoin. Ou bien ils peuvent trouver une meilleure façon d’atteindre le même objectif. À quelle vitesse un utilisateur peut-il émettre une requête ? Peut-être un par seconde ? Combien d’utilisateurs peuvent être connectés et actifs en même temps ? Des centaines.
• (Mon avis) La plupart des benchmarks sont inutiles. Certains benchmarks peuvent montrer qu’un système est deux fois plus rapide qu’un autre. et alors? Certains benchmarks montrent que lorsque vous disposez de plus de quelques centaines de connexions actives, le débit stagne et la latence tend vers l'infini. et alors. Capturer les requêtes réelles une fois que l'application est exécutée depuis un certain temps est probablement la meilleure référence. Mais ses utilisations restent encore limitées.
• Une seule table est presque toujours meilleure qu'une table divisée (plusieurs tables ; partitions ; fragments). Si vous avez des exemples précis, nous pouvons discuter des avantages et des inconvénients de la conception de tables.
• Taille des lignes et type de données : les grandes colonnes (TEXT/BLOB/JSON) sont stockées "non enregistrées", provoquant ainsi [potentiellement] des accès supplémentaires au disque. Les accès au disque constituent la partie la plus coûteuse de toute requête.
• Requêtes actives – Après quelques dizaines de fois, les requêtes entreront en conflit les unes avec les autres. (Imaginez une épicerie avec beaucoup de clients poussant leurs caddies – « trop » de clients et tout le monde met beaucoup de temps à finir.)

Lorsque vous accédez à de grandes bases de données, il en existe plusieurs types différents ; chacune a des caractéristiques différentes.

• Entrepôt de données (capteurs, journaux, etc.) - ajouté à la "fin" des tableaux ; tableaux récapitulatifs pour un "reporting" efficace ; d'énormes tableaux de "faits" (avec des archives fragmentées en option) ;
• Recherche (produits, pages Web, etc.) - L'EAV est problématique ; le texte intégral est souvent utile.
• Banque, traitement des commandes - Ceci est très important pour la fonctionnalité ACID et la nécessité de traiter les transactions.
• Médias (Images et Vidéos) - Comment stocker des objets volumineux tout en effectuant des recherches (etc.) raisonnablement rapides.
• "Trouver le plus proche" - nécessite un index 2D, SPATIAL ou une technique ici