* split up select.md * array-join.md basic refactoring * distinct.md basic refactoring * format.md basic refactoring * from.md basic refactoring * group-by.md basic refactoring * having.md basic refactoring * additional index.md refactoring * into-outfile.md basic refactoring * join.md basic refactoring * limit.md basic refactoring * limit-by.md basic refactoring * order-by.md basic refactoring * prewhere.md basic refactoring * adjust operators/index.md links * adjust sample.md links * adjust more links * adjust operatots links * fix some links * adjust aggregate function article titles * basic refactor of remaining select clauses * absolute paths in make_links.sh * run make_links.sh * remove old select.md locations * translate docs/es * translate docs/fr * translate docs/fa * remove old operators.md location * change operators.md links * adjust links in docs/es * adjust links in docs/es * minor texts adjustments * wip * update machine translations to use new links * fix changelog * es build fixes * get rid of some select.md links * temporary adjust ru links * temporary adjust more ru links * improve curly brace handling * adjust ru as well * fa build fix * ru link fixes * zh link fixes * temporary disable part of anchor checks
3.8 KiB
machine_translated | machine_translated_rev | toc_priority | toc_title |
---|---|---|---|
true | 72537a2d52 |
78 | 一般的な質問 |
一般的な質問
なぜMapReduceのようなものを使わないのですか?
MapReduceのようなシステムは、reduce操作が分散ソートに基づいている分散コンピューティングシステムと呼ぶことができます。 このクラ Apache Hadoop. Yandexは社内ソリューションYTを使用しています。
これらのシステムなの適切なオンラインのクエリによる高の待ち時間をゼロにすることに つまり、webインターフェイスのバックエンドとして使用することはできません。 これらのシステムなに役立つリアルタイムデータの更新をした。 分散ソートは、操作の結果とすべての中間結果(存在する場合)が単一のサーバーのRAMにある場合、reduce操作を実行する最良の方法ではありません。 このような場合、ハッシュテーブルはreduce操作を実行する最適な方法です。 Map-reduceタスクを最適化するための一般的なアプローチは、RAM内のハッシュテーブルを使用した事前集約(部分削減)です。 ユーザーはこの最適化を手動で実行します。 分散ソートは、単純なmap-reduceタスクを実行するときのパフォーマンスの低下の主な原因の一つです。
ほとんどのMapReduce実装では、クラスター上で任意のコードを実行できます。 しかし、宣言型クエリ言語は、実験を迅速に実行するためにOLAPに適しています。 たとえば、HadoopにはHiveとPigがあります。 また、SparkのCloudera ImpalaやShark(旧式)、Spark SQL、Presto、Apache Drillについても検討してください。 このようなタスクを実行するときのパフォーマンスは、特殊なシステムに比べて非常に最適ではありませんが、比較的遅延が高いため、これらのシステ
になっているのでしょうか?しているのでエンコーディング利用の場合OracleをODBC?
外部ディクショナリのソースとしてODBCドライバを介してOracleを使用する場合は、外部ディクショナリの正しい値を設定する必要が NLS_LANG
環境変数in /etc/default/clickhouse
. 詳細については、を参照してください Oracle NLS_LANG FAQ.
例
NLS_LANG=RUSSIAN_RUSSIA.UTF8
ClickHouseからファイルにデータをエクスポートするには?
INTO OUTFILE句の使用
追加 INTO OUTFILE クエリの句。
例えば:
SELECT * FROM table INTO OUTFILE 'file'
デフォルトでは、ClickHouseは TabSeparated 出力データの形式。 選択するには データ形式 は、 FORMAT句.
例えば:
SELECT * FROM table INTO OUTFILE 'file' FORMAT CSV
ファイルエンジンテーブルの使用
見る ファイル.
コマンドラインリダイレクト
$ clickhouse-client --query "SELECT * from table" --format FormatName > result.txt
{## 元の記事 ##}