En parcourant ce tutoriel, vous apprendrez à configurer un cluster ClickHouse simple. Ce sera petit, mais tolérant aux pannes et évolutif. Ensuite, nous utiliserons l’un des exemples de jeux de données pour le remplir de données et exécuter des requêtes de démonstration.
Pour retarder les complexités d’un environnement distribué, nous allons commencer par déployer ClickHouse sur un seul serveur ou une machine virtuelle. ClickHouse est généralement installé à partir de [deb](install.md#install-from-deb-packages) ou [rpm](install.md#from-rpm-packages) les paquets, mais il y a [alternative](install.md#from-docker-image) pour les systèmes d’exploitation qui ne sont pas les soutenir.
Les fichiers de configuration du serveur sont `/etc/clickhouse-server/`. Avant d’aller plus loin, notez le `<path>` élément `config.xml`. Path détermine l’emplacement pour le stockage des données, il doit donc être situé sur le volume avec une grande capacité de disque; la valeur par défaut est `/var/lib/clickhouse/`. Si vous souhaitez ajuster la configuration, il n’est pas pratique de modifier directement `config.xml` fichier, considérant qu’il pourrait obtenir réécrit sur les futures mises à jour du progiciel. La façon recommandée de remplacer les éléments de configuration est de créer [fichiers dans config.d: répertoire](../operations/configuration-files.md) qui servent de “patches” config.XML.
Comme vous l’avez peut-être remarqué, `clickhouse-server` n’est pas lancé automatiquement après l’installation du paquet. Il ne sera pas redémarré automatiquement après les mises à jour, non plus. La façon dont vous démarrez le serveur dépend de votre système d’initialisation, généralement, c’est:
L’emplacement par défaut pour les journaux du serveur est `/var/log/clickhouse-server/`. Le serveur est prêt à gérer les connexions client une fois `Ready for connections` message.
Une fois l’`clickhouse-server` est opérationnel, nous pouvons utiliser `clickhouse-client` pour se connecter au serveur et effectuer des tests de requêtes comme `SELECT "Hello, world!";`.
Maintenant, il est temps de remplir notre serveur ClickHouse avec quelques exemples de données. Dans ce tutoriel, nous allons utiliser les données anonymisées de Yandex.Metrica, le premier service qui exécute ClickHouse en production avant de devenir open-source (plus à ce sujet dans [section d’histoire](../introduction/history.md)). Il y a [plusieurs façons d’importer Yandex.Metrica dataset](example-datasets/metrica.md), et pour le bien du tutoriel, nous irons avec le plus réaliste.
Comme dans la plupart des systèmes de gestion de bases de données, clickhouse regroupe logiquement les tables en “databases”. Il y a un `default` base de données, mais nous allons en créer une nouvelle nommée `tutorial`:
``` bash
clickhouse-client --query "CREATE DATABASE IF NOT EXISTS tutorial"
La syntaxe pour créer des tables est beaucoup plus compliquée par rapport aux bases de données (voir [référence](../sql-reference/statements/create.md). En général `CREATE TABLE` déclaration doit spécifier trois choses clés:
2. Table schema, i.e.list of columns and their [types de données](../sql-reference/data-types/index.md).
3. [Tableau moteur](../engines/table-engines/index.md) et ce sont les paramètres, qui déterminent tous les détails sur la façon dont les requêtes à cette table seront physiquement exécutées.
Yandex.Metrica est un service d’analyse web, et l’exemple de jeu de données ne couvre pas toutes ses fonctionnalités, il n’y a donc que deux tables à créer:
Vous pouvez exécuter ces requêtes en utilisant le mode interactif de `clickhouse-client` (lancez - le simplement dans un terminal sans spécifier une requête à l’avance) ou essayez-en [interface de rechange](../interfaces/index.md) Si tu veux.
Comme nous pouvons le voir, `hits_v1` utilise la [moteur MergeTree de base](../engines/table-engines/mergetree-family/mergetree.md) tandis que le `visits_v1` utilise la [Effondrer](../engines/table-engines/mergetree-family/collapsingmergetree.md) variante.
L’importation de données vers ClickHouse se fait via [INSERT INTO](../sql-reference/statements/insert-into.md) requête comme dans de nombreuses autres bases de données SQL. Toutefois, les données sont généralement fournies dans l’une des [formats de sérialisation pris en charge](../interfaces/formats.md) plutôt `VALUES` clause (qui est également pris en charge).
ClickHouse a beaucoup de [les paramètres de tune](../operations/settings/index.md) et une façon de Les spécifier dans le client console est via des arguments, comme nous pouvons le voir avec `--max_insert_block_size`. La façon la plus simple de comprendre quels paramètres sont disponibles, que signifient-ils et quelles sont les valeurs par défaut est d’interroger le `system.settings` table:
Optionnellement, vous pouvez [OPTIMIZE](../query_language/misc/#misc_operations-optimize) les tables après l’importation. Les Tables configurées avec un moteur de MergeTree-family font toujours des fusions de parties de données en arrière-plan pour optimiser le stockage des données (ou au moins vérifier si cela a du sens). Ces requêtes forcent le moteur de table à optimiser le stockage dès maintenant au lieu d’un certain temps plus tard:
Ces requêtes démarrent une opération intensive D’E/S et de CPU, donc si la table reçoit systématiquement de nouvelles données, il est préférable de la laisser seule et de laisser les fusions s’exécuter en arrière-plan.
[Distribué table](../engines/table-engines/special/distributed.md) est en fait une sorte de “view” aux tables locales du cluster ClickHouse. SELECT query from a distributed table s’exécute à l’aide des ressources de tous les fragments du cluster. Vous pouvez spécifier des configurations pour plusieurs clusters et créer plusieurs tables distribuées fournissant des vues à différents clusters.
Exemple de configuration pour un cluster avec trois fragments, une réplique chacun:
``` xml
<remote_servers>
<perftest_3shards_1replicas>
<shard>
<replica>
<host>example-perftest01j.yandex.ru</host>
<port>9000</port>
</replica>
</shard>
<shard>
<replica>
<host>example-perftest02j.yandex.ru</host>
<port>9000</port>
</replica>
</shard>
<shard>
<replica>
<host>example-perftest03j.yandex.ru</host>
<port>9000</port>
</replica>
</shard>
</perftest_3shards_1replicas>
</remote_servers>
```
Pour plus de démonstration, créons une nouvelle table locale avec le même `CREATE TABLE` la requête que nous avons utilisé pour `hits_v1`, mais nom de table différent:
Une pratique courante consiste à créer des tables distribuées similaires sur toutes les machines du cluster. Il permet d’exécuter des requêtes distribuées sur n’importe quelle machine du cluster. Il existe également une autre option pour créer une table distribuée temporaire pour une requête SELECT donnée en utilisant [distant](../sql-reference/table-functions/remote.md) table de fonction.
Cette approche ne convient pas au sharding de grandes tables. Il y a un outil séparé [clickhouse-copieur](../operations/utilities/clickhouse-copier.md) cela peut re-fragmenter de grandes tables arbitraires.
Dans ce cas, nous avons utilisé un cluster avec 3 fragments, et chacun contient une seule réplique.
Pour assurer la résilience dans un environnement de production, nous recommandons que chaque fragment contienne 2-3 répliques réparties entre plusieurs zones de disponibilité ou centres de données (ou au moins des racks). Notez que ClickHouse prend en charge un nombre illimité de répliques.
Pour activer la réplication native [ZooKeeper](http://zookeeper.apache.org/) est requis. ClickHouse s’occupe de la cohérence des données sur toutes les répliques et exécute automatiquement la procédure de restauration après l’échec. Il est recommandé de déployer le cluster ZooKeeper sur des serveurs séparés (où aucun autre processus, y compris ClickHouse, n’est en cours d’exécution).
ZooKeeper est pas une exigence stricte: dans certains cas simples, vous pouvez dupliquer les données par écrit dans tous les réplicas de votre code d’application. Cette approche est **pas** recommandé, dans ce cas, ClickHouse ne sera pas en mesure de garantir la cohérence des données sur toutes les répliques. Ainsi, il devient la responsabilité de votre application.
S’il n’y a pas de répliques pour le moment lors de la création de la table répliquée, une nouvelle première réplique est instanciée. S’il existe déjà des répliques en direct, la nouvelle réplique clone les données de celles existantes. Vous avez la possibilité de créer toutes les tables répliquées d’abord, et ensuite insérer les données. Une autre option consiste à créer des répliques et à en ajouter d’autres Après ou pendant l’insertion des données.
Ici, nous utilisons [ReplicatedMergeTree](../engines/table-engines/mergetree-family/replication.md) tableau moteur. Dans les paramètres, nous spécifions le chemin Zookeeper contenant des identificateurs de fragments et de répliques.
La réplication fonctionne en mode multi-maître. Les données peuvent être chargées dans n’importe quel réplica, et le système les synchronise ensuite automatiquement avec d’autres instances. La réplication est asynchrone, donc à un moment donné, toutes les répliques ne peuvent pas contenir de données récemment insérées. Au moins une réplique devrait être en place pour permettre l’ingestion de données. D’autres synchroniseront les données et répareront la cohérence une fois qu’ils redeviendront actifs. Notez que cette approche permet une faible possibilité de perte de données récemment insérées.