Partitionnement de base de données - Horizontal vs vertical - Différence entre la normalisation et le fractionnement de lignes?
J'essaie de saisir les différents concepts de Partitionnement de base de données et voici ce que j'en ai compris:
Horizontal Partitioning/Sharding: fractionnement d'une table en une table différente qui contiendra un sous-ensemble des lignes qui se trouvaient dans la table initiale (un exemple que j'ai beaucoup vu si je divise une table Utilisateurs par Continent, comme une sous-table pour l’Amérique du Nord, un autre pour l’Europe, etc ...). Chaque partition se trouvant dans un emplacement physique différent (comprenez «machine»)… .. D'après ce que j'ai compris, la partition horizontale et l'éclatement sont exactement la même chose (?).
Partitionnement vertical: D'après ce que j'ai compris ( http://technet.Microsoft.com/en-us/library/ms178148%28v=sql.105%29.aspx ), il existe 2 types de Partitionnement vertical:
Normalisation (qui consiste à supprimer les redondances d'une base de données en scindant des tables et en les liant à une clé étrangère).
_ {Fractionnement de lignes}, voici ce que je ne comprends pas, quelle est la différence entre Normalisation et Fractionnement de lignes? En quoi ces 2 techniques diffèrent-elles?
J'ai également lu dans cet article ( Différence entre la mise à l'échelle horizontale et verticale des bases de données ) que la différence entre le partitionnement horizontal et le partitionnement vertical réside dans le fait que vous réduisez en premier en ajoutant plusieurs machines, tandis que ajouter plus de puissance (CPU, RAM) à votre machine existante, est-ce une définition correcte? Je pensais que la différence de base _ entre ces deux techniques réside dans la façon dont vous divisez vos tables.
Je suis désolé pour le fardeau des questions, mais je suis un peu confus, car de nombreux sites Web sur lesquels je suis tombé disent des choses différentes.
Toute aide clarifiant serait grandement appréciée. Tout lien vers une démonstration claire et simple avec quelques tableaux serait également très utile.
Le partitionnement est un concept assez général et peut être appliqué dans de nombreux contextes. Lorsqu'il considère le partitionnement relationnel data , il fait généralement référence à la décomposition de vos tables en lignes (horizontalement) ou en colonnes (verticalement).
Le partitionnement vertical, ou fractionnement de lignes, utilise les mêmes techniques de fractionnement que la normalisation de base de données, mais le terme partitionnement de données (vertical/horizontal) désigne généralement une optimisation physique alors que la normalisation est une optimisation au niveau conceptuel.
Puisque vous demandez une démonstration simple, supposez que vous avez un tableau comme celui-ci:
create table data (
id integer primary key,
status char(1) not null,
data1 varchar2(10) not null,
data2 varchar2(10) not null);
Une façon de partitionner data verticalement : Le divise comme suit:
create table data_main (
id integer primary key,
status char(1) not null,
data1 varchar2(10) not null );
create table data_rarely_used (
id integer primary key,
data2 varchar2(10) not null,
foreign key (id) references data_main (id) );
Ce type de partitionnement peut être appliqué, par exemple, lorsque vous avez rarement besoin des données de colonne2 dans vos requêtes. La partition data_main prend moins de place. Par conséquent, les analyses complètes des tables sont plus rapides et il est plus probable qu'elles s'insèrent dans le cache de pages du SGBD. L'inconvénient: lorsque vous devez interroger toutes les colonnes de data, vous devez obligatoirement rejoindre les tables, ce qui coûtera plus cher que d'interroger la table d'origine.
Notez que vous divisez les colonnes de la même manière que lorsque vous normalisez des tableaux. Cependant, dans ce cas, data pourrait déjà être normalisé à 3NF (et même BCNF et 4NF), mais vous décidez de le scinder davantage pour des raisons d'optimisation physique.
Une façon de partitionner data horizontalement , en utilisant la syntaxe Oracle:
create table data (
id integer primary key,
status char(1),
data1 varchar2(10),
data2 varchar2(10) )
partition by list (status) (
partition active_data values ( 'A' ),
partition other_data values(default)
);
Cela indiquerait au SGBD de stocker en interne la table data en deux segments (comme deux tables), en fonction de la valeur de la colonne status. Cette méthode de partitionnement data peut être appliquée, par exemple, lorsque vous interrogez généralement uniquement les lignes d'une partition, par exemple les lignes d'état 'A' (appelons-les des lignes actives). Comme auparavant, les analyses complètes seront plus rapides (en particulier s’il n’ya que quelques lignes actives), les lignes actives (et les autres lignes resp.) Sont stockées de manière contiguë (elles ne seront pas dispersées autour des pages qu’elles partagent avec des lignes d’une autre statut, et il est plus probable que les lignes actives seront dans le cache de page.
Partitionnement horizontal dans une base de données
Garder tous les champs EG: La table Employees a
- identifiant,
- prénom,
- Localisation géographique ,
- email,
- la désignation,
- téléphone
Exemple: 1. Garder tous les champs et distribuer des enregistrements sur plusieurs machines. Identifiant: = 1-100000 ou 100000-200000 enregistrements sur une seule machine et les distribuer sur plusieurs.
EG: 2.Entretien de bases de données distinctes pour les régions EG: Asie Pacifique, Amérique du Nord
Touche: sélection d'un ensemble de lignes en fonction d'un critère
Partitionnement vertical dans la base de données
Il est similaire à la normalisation où la même table est divisée en plusieurs tables et utilisée avec des jointures si nécessaire.
EG: id, name, designation est placé dans une table etphone, email qui peuvent ne pas être fréquemment consultés sont placés dans un autre.
Touche: Sélection d'un ensemble de colonnes en fonction d'un critère.
- Horizontal/Vertical La mise à l'échelle est différente du partitionnement
Mise à l'échelle horizontale:
consiste à ajouter plus de machines pour permettre une réactivité et une disponibilité améliorées de tout système, y compris de la base de données. L’idée est de répartir la charge de travail sur plusieurs machines.
Mise à l'échelle verticale:
il s'agit d'ajouter des capacités supplémentaires sous forme de CPU, de mémoire à une ou plusieurs machines existantes pour améliorer la réactivité et la disponibilité de tout système, y compris de la base de données. Dans une machine virtuelle configurée, elle peut être configurée virtuellement au lieu d'ajouter de vraies machines physiques.
Sameer Sukumaran
Les problèmes avec une base de données unique se posent lorsque celle-ci commence à devenir énorme. Il est donc nécessaire de le partitionner, de réduire l'espace de recherche, afin qu'il puisse exécuter les actions requises plus rapidement. Différentes stratégies de partitionnement sont disponibles, par exemple: partitionnement horizontal, partitionnement vertical, partitionnement basé sur le hachage, partitionnement basé sur la recherche. La mise à l'échelle horizontale et verticale est un concept différent par rapport à ces stratégies.
Partitionnement horizontal : Il divise une table/collection donnée en plusieurs tables/collections en fonction de certaines informations clés pouvant vous aider à obtenir le bon tableau car le partitionnement horizontal aura plusieurs tables sur différents nœuds/machines. Exemple: informations sur les utilisateurs avisés de la région.
Partitionnement vertical : Il divise les colonnes en plusieurs parties, comme indiqué dans l’une des réponses ci-dessus, par exemple: colonnes relatives aux informations de l’utilisateur, likes, commentaires, amis, etc. dans l’application de réseau social.
Partitioning basé sur le hachage : Il utilise la fonction de hachage pour décider de la table/du nœud et prend les éléments clés comme entrée pour la génération de hachage. Si nous changeons le nombre de tables, il faudra réorganiser les données, ce qui est coûteux. Il y a donc un problème lorsque vous souhaitez ajouter plus de table/noeud.
Partitioning basé sur la recherche : Il utilise une table de recherche qui aide à la redirection vers différentes tables/bases de noeuds sur des champs d'entrée donnés. Nous pouvons facilement ajouter une nouvelle table/noeud dans cette approche.
Mise à l'échelle horizontale ou verticale : Lorsque nous concevons une application, nous devons également penser à la mise à l'échelle. Comment allons-nous gérer une énorme quantité de trafic à l'avenir? Nous devons penser en termes de consommation de mémoire, de latence, d’utilisation du processeur, de tolérance aux pannes, de résilience. La mise à l'échelle verticale ajoute davantage de ressources, par exemple: unité centrale de traitement, mémoire à une seule machine afin qu'elle puisse gérer le trafic entrant. Mais il y a des limites à cette approche, vous ne pouvez pas ajouter plus de ressources que certaines limites. La mise à l'échelle horizontale permet au trafic entrant de se répartir sur plusieurs nœuds. Il doit disposer d’un équilibreur de charge à l’avant qui puisse gérer le trafic et le diriger vers un nœud quelconque. La mise à l'échelle horizontale vous permet d'ajouter un nombre suffisant de serveurs, mais vous auriez également besoin de ces nombreux nœuds.
La différence entre la normalisation et le fractionnement réside dans le but de le faire.
Le but principal de la normalisation est de supprimer les données redondantes. Where Le but du fractionnement de lignes est de séparer les données moins requises.
exemple: - Supposons que vous ayez une table All_Details avec nom_colonne, nom_emp, adresse_emp, adresse_emp, adresse_emp, nom_entreprise, nom_entreprise, adresse_entreprise, compte_entreprise.
Maintenant, si vous souhaitez normaliser la table, créez deux nouvelles tables Employee_Details et Company_Details et conservez une clé étrangère company_id dans la table Employee_Details. De cette manière, les données redondantes sur l'entreprise seront supprimées.
Parlons maintenant du fractionnement des lignes. Dites même après la normalisation que vous accédez uniquement à employee_name et emp_phNo mais que vous n'accédez pas à emp_address et emp_other_data aussi souvent. Donc, pour améliorer les performances, vous divisez la table Employee_Details en deux. table1 contenant les données fréquemment utilisées (nom_employé et emp_phNo) et table2 contenant les données moins fréquemment utilisées (Emp_address, Emp_other_data). Les deux tables auront la même colonne unique_key afin que vous puissiez recréer n'importe quelle ligne de la table Employee_Details avec unique_key. Cela peut considérablement améliorer les performances de votre système.