f315e5079b
* replace exit with assert in test_single_page * improve save_raw_single_page docs option * More grammar fixes * "Built from" link in new tab * fix mistype * Example of include in docs * add anchor to meeting form * Draft of translation helper * WIP on translation helper * Replace some fa docs content with machine translation * add normalize-en-markdown.sh * normalize some en markdown * normalize some en markdown * admonition support * normalize * normalize * normalize * support wide tables * normalize * normalize * normalize * normalize * normalize * normalize * normalize * normalize * normalize * normalize * normalize * normalize * normalize * lightly edited machine translation of introdpection.md * lightly edited machhine translation of lazy.md * WIP on translation utils * Normalize ru docs * Normalize other languages * some fixes * WIP on normalize/translate tools * add requirements.txt * [experimental] add es docs language as machine translated draft * remove duplicate script * Back to wider tab-stop (narrow renders not so well) * Links to nowhere check at least for English * use f string * More complete es translation
3.5 KiB
Preguntas generales
¿Por qué no usar algo como MapReduce?
Podemos referirnos a sistemas como MapReduce como sistemas informáticos distribuidos en los que la operación de reducción se basa en la clasificación distribuida. La solución de código abierto más común en esta clase es Acerca de nosotros. Yandex utiliza su solución interna, YT.
Estos sistemas no son apropiados para consultas en línea debido a su alta latencia. En otras palabras, no se pueden usar como back-end para una interfaz web. Estos tipos de sistemas no son útiles para actualizaciones de datos en tiempo real. La clasificación distribuida no es la mejor manera de realizar operaciones de reducción si el resultado de la operación y todos los resultados intermedios (si los hay) se encuentran en la RAM de un único servidor, que suele ser el caso para las consultas en línea. En tal caso, una tabla hash es una forma óptima de realizar operaciones de reducción. Un enfoque común para optimizar las tareas de reducción de mapas es la preagregación (reducción parcial) utilizando una tabla hash en RAM. El usuario realiza esta optimización manualmente. La clasificación distribuida es una de las principales causas de un rendimiento reducido cuando se ejecutan tareas simples de reducción de mapas.
La mayoría de las implementaciones de MapReduce le permiten ejecutar código arbitrario en un clúster. Pero un lenguaje de consulta declarativo es más adecuado para OLAP para ejecutar experimentos rápidamente. Por ejemplo, Hadoop tiene Hive y Pig. También considere Cloudera Impala o Shark (obsoleto) para Spark, así como Spark SQL, Presto y Apache Drill. El rendimiento cuando se ejecutan tales tareas es muy subóptimo en comparación con los sistemas especializados, pero la latencia relativamente alta hace que sea poco realista utilizar estos sistemas como back-end para una interfaz web.
¿Qué sucede si tengo un problema con las codificaciones al usar Oracle a través de ODBC?
Si utiliza Oracle a través del controlador ODBC como fuente de diccionarios externos, debe establecer el valor NLS_LANG variable de entorno en /etc/default/clickhouse. Para obtener más información, consulte Oracle NLS_LANG Preguntas frecuentes.
Ejemplo
NLS_LANG=RUSSIAN_RUSSIA.UTF8
Cómo exporto datos de ClickHouse a un archivo?
Uso de la cláusula INTO OUTFILE
Añadir un INTO OUTFILE cláusula a su consulta.
Por ejemplo:
SELECT * FROM table INTO OUTFILE 'file'
De forma predeterminada, ClickHouse usa el TabSeparated formato de datos de salida. Para seleccionar el Formato de datos, utilizar el Cláusula FORMAT.
Por ejemplo:
SELECT * FROM table INTO OUTFILE 'file' FORMAT CSV
Uso de una tabla de motor de archivo
Ver File.
Uso de la redirección de línea de comandos
$ clickhouse-client --query "SELECT * from table" --format FormatName > result.txt