MergeTree con respaldo en Google Cloud Storage (GCS)
Si usas ClickHouse Cloud en Google Cloud, esta página no aplica, ya que tus servicios ya usarán Google Cloud Storage. Si buscas hacer SELECT o INSERT de datos desde GCS, consulta la table function gcs.
ClickHouse reconoce que GCS es una solución de almacenamiento atractiva si buscas separar almacenamiento y cómputo. Para facilitarlo, se ofrece compatibilidad para usar GCS como almacenamiento de un motor MergeTree. Esto te permitirá aprovechar la escalabilidad y las ventajas de costo de GCS, así como el rendimiento de inserción y consulta del motor MergeTree.
Para utilizar un bucket de GCS como disco, primero debemos declararlo en la configuración de ClickHouse, en un archivo dentro de conf.d. A continuación se muestra un ejemplo de declaración de un disco de GCS. Esta configuración incluye varias secciones para configurar el “disco” de GCS, la caché y la política que se especifica en las consultas DDL cuando se crean tablas en el disco de GCS. A continuación se describe cada una de ellas.
Configuración de almacenamiento > políticas > gcs_main
Las políticas de configuración de almacenamiento permiten elegir dónde se almacenan los datos. La política destacada a continuación permite almacenar datos en el disco gcs especificando la política gcs_main. Por ejemplo, CREATE TABLE ... SETTINGS storage_policy='gcs_main'.
Si ha configurado su disco para usar un bucket con acceso de escritura, debería poder crear una tabla como en el ejemplo siguiente. Para simplificar, usamos un subconjunto de las columnas de los taxis de NYC y enviamos los datos directamente a la tabla respaldada por GCS:
Dependiendo del hardware, este último insert de 1m filas puede tardar unos minutos en ejecutarse. Puede confirmar el progreso en la tabla system.processes. Si quiere, puede ajustar el número de filas hasta el límite de 10m y probar algunas consultas de ejemplo.
SELECT passenger_count, avg(tip_amount) AS avg_tip, avg(total_amount) AS avg_amount FROM trips_gcs GROUP BY passenger_count;
La API XML de Cloud Storage es compatible con algunas herramientas y bibliotecas que funcionan con servicios como Amazon Simple Storage Service (Amazon S3).Para obtener más información sobre cómo ajustar los hilos, consulta Optimización del rendimiento.
El almacenamiento de objetos se usa de forma predeterminada en ClickHouse Cloud; no es necesario seguir este procedimiento si ejecutas ClickHouse en ClickHouse Cloud.
Este tutorial se ha escrito para describir una implementación replicada de ClickHouse que se ejecuta en Google Cloud y utiliza Google Cloud Storage (GCS) como “tipo” de disco de almacenamiento de ClickHouse.En este tutorial, implementará nodos de servidor de ClickHouse en máquinas virtuales de Google Compute Engine, cada uno con un bucket de GCS asociado para el almacenamiento. La replicación la coordina un conjunto de nodos de ClickHouse Keeper, también implementados como máquinas virtuales.Requisitos de ejemplo para alta disponibilidad:
Dos nodos de servidor de ClickHouse, en dos regiones de GCP
Dos buckets de GCS, implementados en las mismas regiones que los dos nodos de servidor de ClickHouse
Tres nodos de ClickHouse Keeper; dos de ellos se implementan en las mismas regiones que los nodos de servidor de ClickHouse. El tercero puede estar en la misma región que uno de los dos primeros nodos de Keeper, pero en una zona de disponibilidad distinta.
ClickHouse Keeper requiere dos nodos para funcionar; de ahí la necesidad de tres nodos para alta disponibilidad.
Despliegue ClickHouse en dos hosts; en las configuraciones de ejemplo, se llaman chnode1 y chnode2.Ubique chnode1 en una región de GCP y chnode2 en otra. En esta guía se utilizan us-east1 y us-east4 para las VM de Compute Engine y también para los buckets de GCS.
No inicie clickhouse server hasta haberlo configurado. Limítese a instalarlo.
Consulte las instrucciones de instalación al realizar los pasos de despliegue en los nodos del servidor de ClickHouse.
Implemente ClickHouse Keeper en tres hosts; en las configuraciones de ejemplo, estos se denominan keepernode1, keepernode2 y keepernode3. keepernode1 puede implementarse en la misma región que chnode1, keepernode2 junto con chnode2 y keepernode3 en cualquiera de las dos regiones, pero en una zona de disponibilidad distinta a la del nodo de ClickHouse de esa región.Consulte las instrucciones de instalación al realizar los pasos de implementación en los nodos de ClickHouse Keeper.
Los dos servidores de ClickHouse estarán ubicados en distintas regiones para garantizar alta disponibilidad. Cada uno tendrá un bucket de GCS en la misma región.En Cloud Storage > Buckets, elija CREATE BUCKET. Para este tutorial, se crean dos buckets: uno en us-east1 y otro en us-east4. Los buckets son de región única, de clase de almacenamiento estándar y no son públicos. Cuando se le solicite, habilite la prevención de acceso público. No cree carpetas; se crearán cuando ClickHouse escriba en el almacenamiento.Si necesita instrucciones paso a paso para crear buckets y una clave HMAC, expanda Create GCS buckets and an HMAC key y siga el procedimiento:
Crear una clave HMAC y un secreto para una cuenta de servicio
Abra Cloud Storage > Settings > Interoperability y elija una Access key existente o CREATE A KEY FOR A SERVICE ACCOUNT. Esta guía describe el proceso para crear una clave nueva para una cuenta de servicio nueva.
Si este proyecto no tiene ninguna cuenta de servicio existente, haga clic en CREATE NEW ACCOUNT.La creación de la cuenta de servicio consta de tres pasos; en el primero, asigne a la cuenta un nombre, un ID y una descripción significativos.En el cuadro de diálogo de configuración de Interoperability, se recomienda el rol de IAM Storage Object Admin; selecciónelo en el segundo paso.El tercer paso es opcional y no se utiliza en esta guía. Puede permitir que los usuarios tengan estos privilegios según sus políticas.Se mostrará la clave HMAC de la cuenta de servicio. Guarde esta información, ya que se utilizará en la configuración de ClickHouse.
Todos los nodos de ClickHouse Keeper tienen el mismo archivo de configuración, excepto la línea server_id (la primera línea resaltada a continuación). Modifique el archivo con los nombres de host de sus servidores de ClickHouse Keeper y, en cada uno de ellos, configure server_id para que coincida con la entrada server correspondiente en raft_configuration. Dado que en este ejemplo server_id está establecido en 3, hemos resaltado las líneas correspondientes en raft_configuration.
Edite el archivo con sus nombres de host y asegúrese de que se resuelvan desde los nodos del servidor de ClickHouse y los nodos de Keeper
Copie el archivo en la ubicación correspondiente (/etc/clickhouse-keeper/keeper_config.xml en cada uno de los servidores de Keeper
Edite el server_id en cada máquina según el número de su entrada en raft_configuration
práctica recomendadaEn algunos pasos de esta guía, se le pedirá que coloque un archivo de configuración en /etc/clickhouse-server/config.d/. Esta es la ubicación predeterminada en los sistemas Linux para los archivos de sobrescritura de configuración. Cuando coloque estos archivos en ese directorio, ClickHouse fusionará su contenido con la configuración predeterminada. Al colocarlos en el directorio config.d, evitará perder la configuración durante una actualización.
De forma predeterminada, ClickHouse escucha en la interfaz de bucle local; en una configuración replicada, es necesario disponer de conectividad de red entre las máquinas. Escuche en todas las interfaces:
La replicación se coordina mediante ClickHouse Keeper. Este archivo de configuración identifica los nodos de ClickHouse Keeper por nombre de host y número de puerto.
Modifica los nombres de host para que coincidan con tus servidores Keeper
Este archivo configura el hostname y el puerto de cada servidor de ClickHouse en el clúster. El archivo de configuración predeterminado contiene definiciones de clúster de ejemplo; para mostrar solo los clústeres que estén completamente configurados, se añade el atributo replace="true" a la entrada remote_servers para que, cuando esta configuración se fusione con la predeterminada, reemplace la sección remote_servers en lugar de añadirse a ella.
Edite el archivo con sus nombres de host y asegúrese de que se resuelvan desde los nodos del servidor de ClickHouse
Este archivo configura ajustes relacionados con la ruta de ClickHouse Keeper. En concreto, las macros que se usan para identificar a qué réplica pertenecen los datos. En un servidor, la réplica debe especificarse como replica_1, y en el otro servidor como replica_2. Los nombres pueden cambiarse; siguiendo nuestro ejemplo de una réplica almacenada en Carolina del Sur y la otra en el norte de Virginia, los valores podrían ser carolina y virginia; solo asegúrese de que sean diferentes en cada máquina.
La configuración de almacenamiento de ClickHouse incluye disks y policies. El disco que se configura a continuación se llama gcs y es de types3. El tipo es s3 porque ClickHouse accede al bucket de GCS como si fuera un bucket de AWS S3. Se necesitarán dos copias de esta configuración, una para cada uno de los nodos del servidor de ClickHouse.Estas sustituciones deben realizarse en la configuración siguiente.Estas sustituciones difieren entre los dos nodos del servidor de ClickHouse:
REPLICA 1 BUCKET debe establecerse con el nombre del bucket en la misma región que el servidor
REPLICA 1 FOLDER debe cambiarse a replica_1 en uno de los servidores y a replica_2 en el otro
Estas sustituciones son comunes a ambos nodos:
access_key_id debe establecerse con la clave HMAC generada anteriormente
secret_access_key debe establecerse con el secreto HMAC generado anteriormente
Envíe comandos a ClickHouse Keeper con netcat. Por ejemplo, mntr devuelve el estado del clúster de ClickHouse Keeper. Si ejecuta el comando en cada uno de los nodos de ClickHouse Keeper, verá que uno es el líder y los otros dos son seguidores:
Al examinar los buckets, verá que se creó una carpeta en cada bucket con el nombre usado en el archivo de configuración storage.xml. Expanda las carpetas y verá muchos archivos que representan las particiones de datos.
