Limitations avant qu'une table puisse être partitionnée ou partitionnée

Question

Je suis nouveau dans la conception de systèmes de bases de données. Après avoir lu de nombreux articles, je ne sais vraiment pas quelle est la limite à laquelle nous devrions avoir 1 table sans partitionnement ni partitionnement. Je sais que c'est vraiment difficile de donner une réponse universelle, les choses dépendent de facteurs comme

• Taille des lignes
• Type de données (chaîne, blob, etc.)
• Nombre de demandes actives
• Quel genre de requête
• Index
• Relire/Réécrire
• Retards prévus

Mais quand quelqu'un pose cette question

• Que feriez-vous si 1 milliard de données et des millions de lignes étaient ajoutées chaque jour ? Pour une base de données aussi volumineuse, la latence pour une requête de 4 lectures, 1 écriture et 2 mises à jour doit être inférieure à 5 millisecondes.
• Si vous n'aviez que 10 millions de lignes mais un volume de mise à jour et de lecture élevé, que choisiriez-vous ? Le nombre de nouvelles lignes ajoutées n'a pas d'importance. Une cohérence élevée et une faible latence sont des exigences.

Si le nombre de lignes est inférieur à un million et que la taille des lignes augmente de plusieurs milliers, le choix est simple. Mais les choses se compliquent lorsque la sélection implique des millions ou des milliards de lignes.

Remarque : je n'ai pas mentionné le numéro de retard dans la question. s'il te plaît Répondez en fonction du nombre de retards avec lesquels vous êtes à l’aise. Nous parlons également de données structurées.

Je ne suis pas sûr, mais je peux ajouter 3 questions spécifiques :

• Supposons que vous choisissiez une base de données SQL pour Amazon ou tout autre système de gestion des commandes de commerce électronique. Le nombre de commandes augmente chaque jour par millions. Il existe déjà 1 milliard d'enregistrements. Supposons maintenant qu’il n’y ait pas d’archive de données. Requêtes de lecture élevée avec plus d'un millier de requêtes par seconde. Et aussi écrit. Le rapport lecture/écriture est de 100:1
• Prenons l’exemple d’un nombre désormais plus petit. Supposons que vous choisissiez la base de données SQL pour ABC ou tout autre système de gestion des commandes de commerce électronique. Le nombre de commandes augmente chaque jour par milliers. Il existe déjà 10 millions de disques. Supposons maintenant qu’il n’y ait pas d’archive de données. Requêtes de lecture élevée avec plus de dix mille requêtes par seconde. Et aussi écrit. Le ratio de lecture et d'écriture est de 10:1
• Troisième exemple : distribution gratuite. Nous avons 10 millions de cadeaux à offrir. 1 goody par utilisateur. Une cohérence élevée et une faible latence sont les objectifs. En supposant qu'il y ait déjà 20 millions d'utilisateurs qui attendent la distribution gratuite, une fois le temps commencé, ils essaieront tous de mettre la main sur les cadeaux gratuits.

Remarque : tout au long de cette question, il est supposé que nous choisirons Solution SQL. De plus, si le cas d’utilisation fourni n’a pas de sens logique, ignorez-le. L'objectif est d'acquérir des connaissances numériques.

Quelqu'un peut-il m'aider à comprendre ce qu'est la référence ? Tous les chiffres réels du projet sur lequel vous travaillez actuellement montreront que pour une grande base de données avec autant de requêtes, c'est la latence observée. Tout ce qui peut m'aider à justifier le nombre de tables de sélection pour un certain nombre de requêtes pour une latence précise.

Answer 1

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