Ces exemples montrent l’ordre que les données sont organisées en. Les valeurs de différentes colonnes sont stockés séparément, et les données de la même colonne sont stockées ensemble.
Exemples D’un SGBD orienté colonne: Vertica, Paraccel (matrice Actian et Amazon Redshift), Sybase IQ, Exasol, Infobright, InfiniDB, MonetDB (VectorWise et Actian Vector), LucidDB, SAP HANA, Google Dremel, Google PowerDrill, Druid et kdb+.
Different orders for storing data are better suited to different scenarios. The data access scenario refers to what queries are made, how often, and in what proportion; how much data is read for each type of query – rows, columns, and bytes; the relationship between reading and updating data; the working size of the data and how locally it is used; whether transactions are used, and how isolated they are; requirements for data replication and logical integrity; requirements for latency and throughput for each type of query, and so on.
Plus la charge sur le système est élevée, plus il est important de personnaliser le système configuré pour correspondre aux exigences du scénario d’utilisation, et plus cette personnalisation devient fine. Il n’y a pas de système qui soit aussi bien adapté à des scénarios significativement différents. Si un système est adaptable à un large ensemble de scénarios, sous une charge élevée, le système traitera tous les scénarios de manière également médiocre, ou fonctionnera bien pour un ou quelques-uns des scénarios possibles.
- Un résultat de requête est significativement plus petit que les données source. En d’autres termes, les données sont filtrées ou agrégées, de sorte que le résultat s’intègre dans la RAM d’un seul serveur.
Il est facile de voir que le scénario OLAP est très différent des autres scénarios populaires (tels que OLTP ou key-Value access). Il n’est donc pas logique d’essayer D’utiliser OLTP ou une base de données clé-valeur pour traiter les requêtes analytiques si vous voulez obtenir des performances décentes. Par exemple, si vous essayez D’utiliser MongoDB ou Redis pour l’analyse, vous obtiendrez des performances très médiocres par rapport aux bases de données OLAP.
## Pourquoi Les Bases De données orientées Colonne Fonctionnent Mieux Dans Le scénario OLAP {#why-column-oriented-databases-work-better-in-the-olap-scenario}
Les bases de données orientées colonne sont mieux adaptées aux scénarios OLAP: elles sont au moins 100 fois plus rapides dans le traitement de la plupart des requêtes. Les raisons sont expliquées en détail ci-dessous, mais le fait est plus facile de démontrer visuellement:
1. Pour une requête analytique, seul un petit nombre de colonnes de table doit être lu. Dans une base de données orientée colonne, vous pouvez lire uniquement les données dont vous avez besoin. Par exemple, si vous avez besoin de 5 colonnes sur 100, Vous pouvez vous attendre à une réduction de 20 fois des e / s.
2. Puisque les données sont lues en paquets, il est plus facile de les compresser. Les données dans les colonnes sont également plus faciles à compresser. Cela réduit d’autant le volume d’e/S.
3. En raison de la réduction des E / S, Plus de données s’insèrent dans le cache du système.
Par exemple, la requête “count the number of records for each advertising platform” nécessite la lecture d’un “advertising platform ID” colonne, qui prend 1 octet non compressé. Si la majeure partie du trafic ne provenait pas de plates-formes publicitaires, vous pouvez vous attendre à une compression d’au moins 10 fois de cette colonne. Lors de l’utilisation d’un algorithme de compression rapide, la décompression des données est possible à une vitesse d’au moins plusieurs gigaoctets de données non compressées par seconde. En d’autres termes, cette requête ne peut être traitée qu’à une vitesse d’environ plusieurs milliards de lignes par seconde sur un seul serveur. Cette vitesse est effectivement atteinte dans la pratique.
Étant donné que l’exécution d’une requête nécessite le traitement d’un grand nombre de lignes, il est utile de répartir toutes les opérations pour des vecteurs entiers au lieu de lignes séparées, ou d’implémenter le moteur de requête de sorte qu’il n’y ait presque aucun coût d’expédition. Si vous ne le faites pas, avec un sous-système de disque à moitié décent, l’interpréteur de requête bloque inévitablement le processeur. Il est logique de stocker des données dans des colonnes et de les traiter, si possible, par des colonnes.
1. Un moteur vectoriel. Toutes les opérations sont écrites pour les vecteurs, au lieu de valeurs séparées. Cela signifie que vous n’avez pas besoin d’appeler les opérations très souvent, et les coûts d’expédition sont négligeables. Le code d’opération contient un cycle interne optimisé.
Ce n’est pas fait dans “normal” bases de données, car cela n’a pas de sens lors de l’exécution de requêtes simples. Cependant, il y a des exceptions. Par exemple, MemSQL utilise la génération de code pour réduire la latence lors du traitement des requêtes SQL. (À titre de comparaison, les SGBD analytiques nécessitent une optimisation du débit, et non une latence.)
Notez que pour l’efficacité du processeur, le langage de requête doit être déclaratif (SQL ou MDX), ou au moins un vecteur (J, K). La requête ne doit contenir que des boucles implicites, permettant une optimisation.
