lots of docs fixes

docs/en/getting_started/example_datasets/metrica.md

@@ -57,6 +57,6 @@ clickhouse-client --query "SELECT COUNT(*) FROM datasets.visits_v1"
 
 ## Example Queries
 
-[ClickHouse tutorial](../tutorial.md) is based on Yandex.Metrica dataset and the recommended way to get started with this dataset is to just go through tutorial.
+[ClickHouse tutorial](../../getting_started/tutorial.md) is based on Yandex.Metrica dataset and the recommended way to get started with this dataset is to just go through tutorial.
 
 Additional examples of queries to these tables can be found among [stateful tests](https://github.com/yandex/ClickHouse/tree/master/dbms/tests/queries/1_stateful) of ClickHouse (they are named `test.hists` and `test.visits` there).

docs/en/getting_started/tutorial.md

@@ -459,7 +459,7 @@ clickhouse-client --query "INSERT INTO tutorial.hits_v1 FORMAT TSV" --max_insert
 clickhouse-client --query "INSERT INTO tutorial.visits_v1 FORMAT TSV" --max_insert_block_size=100000 < visits_v1.tsv
 ```
 
-ClickHouse has a lot of [settings to tune](../operations/settings.md) and one way to specify them in console client is via arguments, as we can see with `--max_insert_block_size`. The easiest way to figure out what settings are available, what do they mean and what the defaults are is to query the `system.settings` table:
+ClickHouse has a lot of [settings to tune](../operations/settings/index.md) and one way to specify them in console client is via arguments, as we can see with `--max_insert_block_size`. The easiest way to figure out what settings are available, what do they mean and what the defaults are is to query the `system.settings` table:
 
 ``` sql
 SELECT name, value, changed, description

docs/en/index.md

@@ -1,8 +1,8 @@
-# What is ClickHouse?
+# ClickHouseとは?
 
-ClickHouse is a column-oriented database management system (DBMS) for online analytical processing of queries (OLAP).
+ClickHouseは、クエリのオンライン分析処理（OLAP）用の列指向のデータベース管理システム（DBMS）です。
 
-In a "normal" row-oriented DBMS, data is stored in this order:
+「通常の」行指向のDBMSでは、データは次の順序で保存されます。
 
 | Row | WatchID | JavaEnable | Title | GoodEvent | EventTime |
 | ------ | ------------------- | ---------- | ------------------ | --------- | ------------------- |
@@ -11,12 +11,12 @@ In a "normal" row-oriented DBMS, data is stored in this order:
 | #2 | 89953706054 | 1 | Mission | 1 | 2016-05-18 07:38:00 |
 | #N | ... | ... | ... | ... | ... |
 
-In other words, all the values related to a row are physically stored next to each other.
+つまり、行に関連するすべての値は物理的に隣り合わせに格納されます。
 
-Examples of a row-oriented DBMS are MySQL, Postgres, and MS SQL Server.
+行指向のDBMSの例：MySQL, Postgres および MS SQL Server
 {: .grey }
 
-In a column-oriented DBMS, data is stored like this:
+列指向のDBMSでは、データは次のように保存されます：
 
 | Row: | #0 | #1 | #2 | #N |
 | ----------- | ------------------- | ------------------- | ------------------- | ------------------- |
@@ -26,68 +26,74 @@ In a column-oriented DBMS, data is stored like this:
 | GoodEvent: | 1 | 1 | 1 | ... |
 | EventTime: | 2016-05-18 05:19:20 | 2016-05-18 08:10:20 | 2016-05-18 07:38:00 | ... |
 
-These examples only show the order that data is arranged in.
-The values from different columns are stored separately, and data from the same column is stored together.
+これらの例は、データが配置される順序のみを示しています。
+異なる列の値は別々に保存され、同じ列のデータは一緒に保存されます。
 
-Examples of a column-oriented DBMS: Vertica, Paraccel (Actian Matrix and Amazon Redshift), Sybase IQ, Exasol, Infobright, InfiniDB, MonetDB (VectorWise and Actian Vector), LucidDB, SAP HANA, Google Dremel, Google PowerDrill, Druid, and kdb+.
+列指向DBMSの例：Vertica, Paraccel (Actian Matrix and Amazon Redshift), Sybase IQ, Exasol, Infobright, InfiniDB, MonetDB (VectorWise and Actian Vector), LucidDB, SAP HANA, Google Dremel, Google PowerDrill, Druid および kdb+
 {: .grey }
 
-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.
+異なったデータ格納の順序は、異なったシナリオにより適します。
+データアクセスシナリオとは、クエリの実行内容、頻度、割合を指します。クエリで読み取られるの各種データの量（行、列、バイト）。データの読み取りと更新の関係。作業データのサイズとローカルでの使用方法。トランザクションが使用されるかどうか、およびそれらがどの程度分離されているか。データ複製と論理的整合性の要件。クエリの種類ごとの遅延とスループットの要件など。
 
-The higher the load on the system, the more important it is to customize the system set up to match the requirements of the usage scenario, and the more fine grained this customization becomes. There is no system that is equally well-suited to significantly different scenarios. If a system is adaptable to a wide set of scenarios, under a high load, the system will handle all the scenarios equally poorly, or will work well for just one or few of possible scenarios.
+システムの負荷が高いほど、使用シナリオの要件に一致するようにセットアップされたシステムをカスタマイズすることがより重要になり、このカスタマイズはより細かくなります。大きく異なるシナリオに等しく適したシステムはありません。システムがさまざまなシナリオに適応可能である場合、高負荷下では、システムはすべてのシナリオを同等に不十分に処理するか、1つまたはいくつかの可能なシナリオでうまく機能します。
 
-## Key Properties of the OLAP scenario
+## OLAPシナリオの主要なプロパティ
 
-- The vast majority of requests are for read access.
-- Data is updated in fairly large batches (> 1000 rows), not by single rows; or it is not updated at all.
-- Data is added to the DB but is not modified.
-- For reads, quite a large number of rows are extracted from the DB, but only a small subset of columns.
-- Tables are "wide," meaning they contain a large number of columns.
-- Queries are relatively rare (usually hundreds of queries per server or less per second).
-- For simple queries, latencies around 50 ms are allowed.
-- Column values are fairly small: numbers and short strings (for example, 60 bytes per URL).
-- Requires high throughput when processing a single query (up to billions of rows per second per server).
-- Transactions are not necessary.
-- Low requirements for data consistency.
-- There is one large table per query. All tables are small, except for one.
-- A query result is significantly smaller than the source data. In other words, data is filtered or aggregated, so the result fits in a single server's RAM.
+- リクエストの大部分は読み取りアクセス用である。
+- データは、単一行ではなく、かなり大きなバッチ（> 1000行）で更新されます。または、まったく更新されない。
+- データはDBに追加されるが、変更されない。
+- 読み取りの場合、非常に多くの行がDBから抽出されるが、一部の列のみ。
+- テーブルは「幅が広く」、多数の列が含まれる。
+- クエリは比較的まれ（通常、サーバーあたり毎秒数百あるいはそれ以下の数のクエリ）。
+- 単純なクエリでは、約50ミリ秒の遅延が容認される。
+- 列の値はかなり小さく、数値や短い文字列（たとえば、URLごとに60バイト）。
+- 単一のクエリを処理する場合、高いスループットが必要（サーバーあたり毎秒最大数十億行）。
+- トランザクションは必要ない。
+- データの一貫性の要件が低い。
+- クエリごとに1つの大きなテーブルがある。 1つを除くすべてのテーブルは小さい。
+- クエリ結果は、ソースデータよりも大幅に小さくなる。つまり、データはフィルター処理または集計されるため、結果は単一サーバーのRAMに収まる。
 
-It is easy to see that the OLAP scenario is very different from other popular scenarios (such as OLTP or Key-Value access). So it doesn't make sense to try to use OLTP or a Key-Value DB for processing analytical queries if you want to get decent performance. For example, if you try to use MongoDB or Redis for analytics, you will get very poor performance compared to OLAP databases.
+OLAPシナリオは、他の一般的なシナリオ（OLTPやKey-Valueアクセスなど）とは非常に異なることが容易にわかります。 したがって、まともなパフォーマンスを得るには、OLTPまたはKey-Value DBを使用して分析クエリを処理しようとするのは無意味です。 たとえば、分析にMongoDBまたはRedisを使用しようとすると、OLAPデータベースに比べてパフォーマンスが非常に低下します。
 
-## Why Column-Oriented Databases Work Better in the OLAP Scenario
+## OLAPシナリオで列指向データベースがよりよく機能する理由
 
-Column-oriented databases are better suited to OLAP scenarios: they are at least 100 times faster in processing most queries. The reasons are explained in detail below, but the fact is easier to demonstrate visually:
+列指向データベースは、OLAPシナリオにより適しています。ほとんどのクエリの処理が少なくとも100倍高速です。 理由を以下に詳しく説明しますが、その根拠は視覚的に簡単に説明できます：
 
-**Row-oriented DBMS**
+**行指向DBMS**
 
 ![Row-oriented](images/row_oriented.gif#)
 
-**Column-oriented DBMS**
+**列指向DBMS**
 
 ![Column-oriented](images/column_oriented.gif#)
 
-See the difference?
+違いがわかりましたか？
 
 ### Input/output
 
-1. For an analytical query, only a small number of table columns need to be read. In a column-oriented database, you can read just the data you need. For example, if you need 5 columns out of 100, you can expect a 20-fold reduction in I/O.
-2. Since data is read in packets, it is easier to compress. Data in columns is also easier to compress. This further reduces the I/O volume.
-3. Due to the reduced I/O, more data fits in the system cache.
+1. 分析クエリでは、少数のテーブル列のみを読み取る必要があります。列指向のデータベースでは、必要なデータのみを読み取ることができます。たとえば、100のうち5つの列が必要な場合、I/Oが20倍削減されることが期待できます。
+2. データはパケットで読み取られるため、圧縮が容易です。列のデータも圧縮が簡単です。これにより、I/Oボリュームがさらに削減されます。
+3. I/Oの削減により、より多くのデータがシステムキャッシュに収まります。
 
-For example, the query "count the number of records for each advertising platform" requires reading one "advertising platform ID" column, which takes up 1 byte uncompressed. If most of the traffic was not from advertising platforms, you can expect at least 10-fold compression of this column. When using a quick compression algorithm, data decompression is possible at a speed of at least several gigabytes of uncompressed data per second. In other words, this query can be processed at a speed of approximately several billion rows per second on a single server. This speed is actually achieved in practice.
+たとえば、「各広告プラットフォームのレコード数をカウントする」クエリでは、1つの「広告プラットフォームID」列を読み取る必要がありますが、これは非圧縮では1バイトの領域を要します。トラフィックのほとんどが広告プラットフォームからのものではない場合、この列は少なくとも10倍の圧縮が期待できます。高速な圧縮アルゴリズムを使用すれば、1秒あたり少なくとも非圧縮データに換算して数ギガバイトの速度でデータを展開できます。つまり、このクエリは、単一のサーバーで1秒あたり約数十億行の速度で処理できます。この速度はまさに実際に達成されます。
 
 <details markdown="1"><summary>Example</summary>
-```bash
+```
 $ clickhouse-client
 ClickHouse client version 0.0.52053.
 Connecting to localhost:9000.
 Connected to ClickHouse server version 0.0.52053.
-```
-```sql
-SELECT CounterID, count() FROM hits GROUP BY CounterID ORDER BY count() DESC LIMIT 20
-```
-```text
+
+:) SELECT CounterID, count() FROM hits GROUP BY CounterID ORDER BY count() DESC LIMIT 20
+
+SELECT
+CounterID,
+count()
+FROM hits
+GROUP BY CounterID
+ORDER BY count() DESC
+LIMIT 20
+
 ┌─CounterID─┬──count()─┐
 │    114208 │ 56057344 │
 │    115080 │ 51619590 │
@@ -110,23 +116,27 @@ SELECT CounterID, count() FROM hits GROUP BY CounterID ORDER BY count() DESC LIM
 │    115079 │  8837972 │
 │    337234 │  8205961 │
 └───────────┴──────────┘
+
+20 rows in set. Elapsed: 0.153 sec. Processed 1.00 billion rows, 4.00 GB (6.53 billion rows/s., 26.10 GB/s.)
+
+:)
 ```
 
 </details>
 
 ### CPU
 
-Since executing a query requires processing a large number of rows, it helps to dispatch all operations for entire vectors instead of for separate rows, or to implement the query engine so that there is almost no dispatching cost. If you don't do this, with any half-decent disk subsystem, the query interpreter inevitably stalls the CPU.
-It makes sense to both store data in columns and process it, when possible, by columns.
+クエリを実行するには大量の行を処理する必要があるため、個別の行ではなくベクター全体のすべての操作をディスパッチするか、ディスパッチコストがほとんどないようにクエリエンジンを実装すると効率的です。 適切なディスクサブシステムでこれを行わないと、クエリインタープリターが必然的にCPUを失速させます。
+データを列に格納し、可能な場合は列ごとに処理することは理にかなっています。
 
-There are two ways to do this:
+これを行うには2つの方法があります:
 
-1. A vector engine. All operations are written for vectors, instead of for separate values. This means you don't need to call operations very often, and dispatching costs are negligible. Operation code contains an optimized internal cycle.
+1. ベクトルエンジン。 すべての操作は、個別の値ではなく、ベクトルに対して記述されます。 これは、オペレーションを頻繁に呼び出す必要がなく、ディスパッチコストが無視できることを意味します。 操作コードには、最適化された内部サイクルが含まれています。
 
-2. Code generation. The code generated for the query has all the indirect calls in it.
+2. コード生成。 クエリ用に生成されたコードには、すべての間接的な呼び出しが含まれています。
 
-This is not done in "normal" databases, because it doesn't make sense when running simple queries. However, there are exceptions. For example, MemSQL uses code generation to reduce latency when processing SQL queries. (For comparison, analytical DBMSs require optimization of throughput, not latency.)
+これは、単純なクエリを実行する場合には意味がないため、「通常の」データベースでは実行されません。 ただし、例外があります。 たとえば、MemSQLはコード生成を使用して、SQLクエリを処理する際の遅延を減らします。 （比較のために、分析DBMSではレイテンシではなくスループットの最適化が必要です。）
 
-Note that for CPU efficiency, the query language must be declarative (SQL or MDX), or at least a vector (J, K). The query should only contain implicit loops, allowing for optimization.
+CPU効率のために、クエリ言語は宣言型（SQLまたはMDX）、または少なくともベクトル（J、K）でなければなりません。 クエリには、最適化を可能にする暗黙的なループのみを含める必要があります。
 
 [Original article](https://clickhouse.yandex/docs/en/) <!--hide-->

docs/fa/getting_started/install.md

@@ -20,7 +20,7 @@ grep -q sse4_2 /proc/cpuinfo && echo "SSE 4.2 supported" || echo "SSE 4.2 not su
 
 ##ﺩﻮﺟﻮﻣ ﺐﺼﻧ ﯼﺎﻫ ﻪﻨﯾﺰﮔ
 
-### نصب از طریق پکیج های Debian/Ubuntu
+### نصب از طریق پکیج های Debian/Ubuntu {#from-deb-packages}
 
 در فایل `/etc/apt/sources.list` (یا در یک فایل جدا `/etc/apt/sources.list.d/clickhouse.list`)، Repo زیر را اضافه کنید:
 
@@ -51,7 +51,7 @@ sudo apt-get install clickhouse-client clickhouse-server
 
 ClickHouse دارای تنظیمات محدودیت دسترسی می باشد. این تنظیمات در فایل 'users.xml' (کنار 'config.xml') می باشد. به صورت پیش فرض دسترسی برای کاربر 'default' از همه جا بدون نیاز به پسورد وجود دارد. 'user/default/networks' را مشاهده کنید. برای اطلاعات بیشتر قسمت "تنظیمات فایل ها" را مشاهده کنید.
 
-### RPM ﯼﺎﻫ ﻪﺘﺴﺑ ﺯﺍ
+### RPM ﯼﺎﻫ ﻪﺘﺴﺑ ﺯﺍ {#from-rpm-packages}
 
 .ﺪﻨﮐ ﯽﻣ ﻪﯿﺻﻮﺗ ﺲﮐﻮﻨﯿﻟ ﺮﺑ ﯽﻨﺘﺒﻣ rpm ﺮﺑ ﯽﻨﺘﺒﻣ ﯼﺎﻫ ﻊﯾﺯﻮﺗ ﺮﯾﺎﺳ ﻭ CentOS ، RedHat ﯼﺍ
 
@@ -78,7 +78,7 @@ sudo yum install clickhouse-server clickhouse-client
 .ﺪﻨﻨﮐ ﯽﻣ ﻩﺩﺎﻔﺘﺳﺍ ﻞﺧﺍﺩ ﺭﺩ "deb" ﯽﻤﺳﺭ ﯼﺎﻫ ﻪﺘﺴﺑ ﺯﺍ ﺮﯾﻭﺎﺼﺗ ﻦﯾﺍ .ﺪﯿﻨﮐ ﻝﺎﺒﻧﺩ ﺍﺭ (/ht
 
 
-### نصب از طریق Source
+### نصب از طریق Source {#from-sources}
 
 برای Compile، دستورالعمل های فایل build.md را دنبال کنید:
 
@@ -108,7 +108,7 @@ Server: dbms/programs/clickhouse-server
 
 به مسیر لاگ ها در تنظیمات سرور توجه کنید (src/dbms/programs/config.xml).
 
-### روش های دیگر نصب
+### روش های دیگر نصب {#from-docker-image}
 
 Docker image: <https://hub.docker.com/r/yandex/clickhouse-server/>
 

docs/fa/getting_started/tutorial.md

@@ -0,0 +1 @@
+../../en/getting_started/tutorial.md

docs/ja/changelog.md

@@ -0,0 +1 @@
+../../CHANGELOG.md

docs/ja/data_types/array.md

@@ -0,0 +1 @@
+../../en/data_types/array.md

docs/ja/data_types/boolean.md

@@ -0,0 +1 @@
+../../en/data_types/boolean.md

docs/ja/data_types/date.md

@@ -0,0 +1 @@
+../../en/data_types/date.md

docs/ja/data_types/datetime.md

@@ -0,0 +1 @@
+../../en/data_types/datetime.md

docs/ja/data_types/decimal.md

@@ -0,0 +1 @@
+../../en/data_types/decimal.md

docs/ja/data_types/domains/ipv4.md

@@ -0,0 +1 @@
+../../../en/data_types/domains/ipv4.md

docs/ja/data_types/domains/ipv6.md

@@ -0,0 +1 @@
+../../../en/data_types/domains/ipv6.md

docs/ja/data_types/domains/overview.md

@@ -0,0 +1 @@
+../../../en/data_types/domains/overview.md

docs/ja/data_types/enum.md

@@ -0,0 +1 @@
+../../en/data_types/enum.md

docs/ja/data_types/fixedstring.md

@@ -0,0 +1 @@
+../../en/data_types/fixedstring.md

docs/ja/data_types/float.md

@@ -0,0 +1 @@
+../../en/data_types/float.md

docs/ja/data_types/index.md

@@ -0,0 +1 @@
+../../en/data_types/index.md

docs/ja/data_types/int_uint.md

@@ -0,0 +1 @@
+../../en/data_types/int_uint.md

docs/ja/data_types/nested_data_structures/aggregatefunction.md

@@ -0,0 +1 @@
+../../../en/data_types/nested_data_structures/aggregatefunction.md

docs/ja/data_types/nested_data_structures/index.md

@@ -0,0 +1 @@
+../../../en/data_types/nested_data_structures/index.md

docs/ja/data_types/nested_data_structures/nested.md

@@ -0,0 +1 @@
+../../../en/data_types/nested_data_structures/nested.md

docs/ja/data_types/nullable.md

@@ -0,0 +1 @@
+../../en/data_types/nullable.md

docs/ja/data_types/special_data_types/expression.md

@@ -0,0 +1 @@
+../../../en/data_types/special_data_types/expression.md

docs/ja/data_types/special_data_types/index.md

@@ -0,0 +1 @@
+../../../en/data_types/special_data_types/index.md

docs/ja/data_types/special_data_types/interval.md

@@ -0,0 +1 @@
+../../../en/data_types/special_data_types/interval.md

docs/ja/data_types/special_data_types/nothing.md

@@ -0,0 +1 @@
+../../../en/data_types/special_data_types/nothing.md

docs/ja/data_types/special_data_types/set.md

@@ -0,0 +1 @@
+../../../en/data_types/special_data_types/set.md

docs/ja/data_types/string.md

@@ -0,0 +1 @@
+../../en/data_types/string.md

docs/ja/data_types/tuple.md

@@ -0,0 +1 @@
+../../en/data_types/tuple.md

docs/ja/data_types/uuid.md

@@ -0,0 +1 @@
+../../en/data_types/uuid.md

docs/ja/database_engines/index.md

@@ -0,0 +1 @@
+../../en/database_engines/index.md

docs/ja/database_engines/lazy.md

@@ -0,0 +1 @@
+../../en/database_engines/lazy.md

docs/ja/database_engines/mysql.md

@@ -0,0 +1 @@
+../../en/database_engines/mysql.md

docs/ja/development/architecture.md

@@ -0,0 +1 @@
+../../en/development/architecture.md

docs/ja/development/build.md

@@ -0,0 +1 @@
+../../en/development/build.md

docs/ja/development/build_cross_arm.md

@@ -0,0 +1 @@
+../../en/development/build_cross_arm.md

docs/ja/development/build_cross_osx.md

@@ -0,0 +1 @@
+../../en/development/build_cross_osx.md

docs/ja/development/build_osx.md

@@ -0,0 +1 @@
+../../en/development/build_osx.md

docs/ja/development/contrib.md

@@ -0,0 +1 @@
+../../en/development/contrib.md

docs/ja/development/developer_instruction.md

@@ -0,0 +1 @@
+../../en/development/developer_instruction.md

docs/ja/development/index.md

@@ -0,0 +1 @@
+../../en/development/index.md

docs/ja/development/style.md

@@ -0,0 +1 @@
+../../en/development/style.md

docs/ja/development/tests.md

@@ -0,0 +1 @@
+../../en/development/tests.md

docs/ja/development/tests/developer_instruction_ru.md

@@ -0,0 +1 @@
+../../../en/development/tests/developer_instruction_ru.md

docs/ja/development/tests/easy_tasks_sorted_ru.md

@@ -0,0 +1 @@
+../../../en/development/tests/easy_tasks_sorted_ru.md

docs/ja/development/tests/sanitizers.md

@@ -0,0 +1 @@
+../../../en/development/tests/sanitizers.md

docs/ja/faq/general.md

@@ -0,0 +1 @@
+../../en/faq/general.md

docs/ja/getting_started/example_datasets/amplab_benchmark.md

@@ -0,0 +1 @@
+../../../en/getting_started/example_datasets/amplab_benchmark.md

docs/ja/getting_started/example_datasets/criteo.md

@@ -0,0 +1 @@
+../../../en/getting_started/example_datasets/criteo.md

docs/ja/getting_started/example_datasets/metrica.md

@@ -0,0 +1 @@
+../../../en/getting_started/example_datasets/metrica.md

docs/ja/getting_started/example_datasets/nyc_taxi.md

@@ -0,0 +1 @@
+../../../en/getting_started/example_datasets/nyc_taxi.md

docs/ja/getting_started/example_datasets/ontime.md

@@ -0,0 +1 @@
+../../../en/getting_started/example_datasets/ontime.md

docs/ja/getting_started/example_datasets/star_schema.md

@@ -0,0 +1 @@
+../../../en/getting_started/example_datasets/star_schema.md

docs/ja/getting_started/example_datasets/wikistat.md

@@ -0,0 +1 @@
+../../../en/getting_started/example_datasets/wikistat.md

docs/ja/getting_started/index.md

@@ -0,0 +1 @@
+../../en/getting_started/index.md

docs/ja/getting_started/install.md

@@ -0,0 +1 @@
+../../en/getting_started/install.md

docs/ja/getting_started/tutorial.md

@@ -0,0 +1 @@
+../../en/getting_started/tutorial.md

docs/ja/guides/apply_catboost_model.md

@@ -0,0 +1 @@
+../../en/guides/apply_catboost_model.md

docs/ja/guides/index.md

@@ -0,0 +1 @@
+../../en/guides/index.md

docs/ja/images/logo.svg

@@ -0,0 +1,12 @@
+<svg xmlns="http://www.w3.org/2000/svg" width="54" height="48" viewBox="0 0 9 8">
+    <style>
+        .o{fill:#fc0}
+        .r{fill:#f00}
+    </style>
+    <path class="r" d="M0,7 h1 v1 h-1 z"/>
+    <path class="o" d="M0,0 h1 v7 h-1 z"/>
+    <path class="o" d="M2,0 h1 v8 h-1 z"/>
+    <path class="o" d="M4,0 h1 v8 h-1 z"/>
+    <path class="o" d="M6,0 h1 v8 h-1 z"/>
+    <path class="o" d="M8,3.25 h1 v1.5 h-1 z"/>
+</svg>

docs/ja/index.md

@@ -1,142 +0,0 @@
-# ClickHouseとは?
-
-ClickHouseは、クエリのオンライン分析処理（OLAP）用の列指向のデータベース管理システム（DBMS）です。
-
-「通常の」行指向のDBMSでは、データは次の順序で保存されます。
-
-| Row | WatchID | JavaEnable | Title | GoodEvent | EventTime |
-| ------ | ------------------- | ---------- | ------------------ | --------- | ------------------- |
-| #0 | 89354350662 | 1 | Investor Relations | 1 | 2016-05-18 05:19:20 |
-| #1 | 90329509958 | 0 | Contact us | 1 | 2016-05-18 08:10:20 |
-| #2 | 89953706054 | 1 | Mission | 1 | 2016-05-18 07:38:00 |
-| #N | ... | ... | ... | ... | ... |
-
-つまり、行に関連するすべての値は物理的に隣り合わせに格納されます。
-
-行指向のDBMSの例：MySQL, Postgres および MS SQL Server
-{: .grey }
-
-列指向のDBMSでは、データは次のように保存されます：
-
-| Row: | #0 | #1 | #2 | #N |
-| ----------- | ------------------- | ------------------- | ------------------- | ------------------- |
-| WatchID: | 89354350662 | 90329509958 | 89953706054 | ... |
-| JavaEnable: | 1 | 0 | 1 | ... |
-| Title: | Investor Relations | Contact us | Mission | ... |
-| GoodEvent: | 1 | 1 | 1 | ... |
-| EventTime: | 2016-05-18 05:19:20 | 2016-05-18 08:10:20 | 2016-05-18 07:38:00 | ... |
-
-これらの例は、データが配置される順序のみを示しています。
-異なる列の値は別々に保存され、同じ列のデータは一緒に保存されます。
-
-列指向DBMSの例：Vertica, Paraccel (Actian Matrix and Amazon Redshift), Sybase IQ, Exasol, Infobright, InfiniDB, MonetDB (VectorWise and Actian Vector), LucidDB, SAP HANA, Google Dremel, Google PowerDrill, Druid および kdb+
-{: .grey }
-
-異なったデータ格納の順序は、異なったシナリオにより適します。
-データアクセスシナリオとは、クエリの実行内容、頻度、割合を指します。クエリで読み取られるの各種データの量（行、列、バイト）。データの読み取りと更新の関係。作業データのサイズとローカルでの使用方法。トランザクションが使用されるかどうか、およびそれらがどの程度分離されているか。データ複製と論理的整合性の要件。クエリの種類ごとの遅延とスループットの要件など。
-
-システムの負荷が高いほど、使用シナリオの要件に一致するようにセットアップされたシステムをカスタマイズすることがより重要になり、このカスタマイズはより細かくなります。大きく異なるシナリオに等しく適したシステムはありません。システムがさまざまなシナリオに適応可能である場合、高負荷下では、システムはすべてのシナリオを同等に不十分に処理するか、1つまたはいくつかの可能なシナリオでうまく機能します。
-
-## OLAPシナリオの主要なプロパティ
-
-- リクエストの大部分は読み取りアクセス用である。
-- データは、単一行ではなく、かなり大きなバッチ（> 1000行）で更新されます。または、まったく更新されない。
-- データはDBに追加されるが、変更されない。
-- 読み取りの場合、非常に多くの行がDBから抽出されるが、一部の列のみ。
-- テーブルは「幅が広く」、多数の列が含まれる。
-- クエリは比較的まれ（通常、サーバーあたり毎秒数百あるいはそれ以下の数のクエリ）。
-- 単純なクエリでは、約50ミリ秒の遅延が容認される。
-- 列の値はかなり小さく、数値や短い文字列（たとえば、URLごとに60バイト）。
-- 単一のクエリを処理する場合、高いスループットが必要（サーバーあたり毎秒最大数十億行）。
-- トランザクションは必要ない。
-- データの一貫性の要件が低い。
-- クエリごとに1つの大きなテーブルがある。 1つを除くすべてのテーブルは小さい。
-- クエリ結果は、ソースデータよりも大幅に小さくなる。つまり、データはフィルター処理または集計されるため、結果は単一サーバーのRAMに収まる。
-
-OLAPシナリオは、他の一般的なシナリオ（OLTPやKey-Valueアクセスなど）とは非常に異なることが容易にわかります。 したがって、まともなパフォーマンスを得るには、OLTPまたはKey-Value DBを使用して分析クエリを処理しようとするのは無意味です。 たとえば、分析にMongoDBまたはRedisを使用しようとすると、OLAPデータベースに比べてパフォーマンスが非常に低下します。
-
-## OLAPシナリオで列指向データベースがよりよく機能する理由
-
-列指向データベースは、OLAPシナリオにより適しています。ほとんどのクエリの処理が少なくとも100倍高速です。 理由を以下に詳しく説明しますが、その根拠は視覚的に簡単に説明できます：
-
-**行指向DBMS**
-
-![Row-oriented](images/row_oriented.gif#)
-
-**列指向DBMS**
-
-![Column-oriented](images/column_oriented.gif#)
-
-違いがわかりましたか？
-
-### Input/output
-
-1. 分析クエリでは、少数のテーブル列のみを読み取る必要があります。列指向のデータベースでは、必要なデータのみを読み取ることができます。たとえば、100のうち5つの列が必要な場合、I/Oが20倍削減されることが期待できます。
-2. データはパケットで読み取られるため、圧縮が容易です。列のデータも圧縮が簡単です。これにより、I/Oボリュームがさらに削減されます。
-3. I/Oの削減により、より多くのデータがシステムキャッシュに収まります。
-
-たとえば、「各広告プラットフォームのレコード数をカウントする」クエリでは、1つの「広告プラットフォームID」列を読み取る必要がありますが、これは非圧縮では1バイトの領域を要します。トラフィックのほとんどが広告プラットフォームからのものではない場合、この列は少なくとも10倍の圧縮が期待できます。高速な圧縮アルゴリズムを使用すれば、1秒あたり少なくとも非圧縮データに換算して数ギガバイトの速度でデータを展開できます。つまり、このクエリは、単一のサーバーで1秒あたり約数十億行の速度で処理できます。この速度はまさに実際に達成されます。
-
-<details markdown="1"><summary>Example</summary>
-```
-$ clickhouse-client
-ClickHouse client version 0.0.52053.
-Connecting to localhost:9000.
-Connected to ClickHouse server version 0.0.52053.
-
-:) SELECT CounterID, count() FROM hits GROUP BY CounterID ORDER BY count() DESC LIMIT 20
-
-SELECT
-CounterID,
-count()
-FROM hits
-GROUP BY CounterID
-ORDER BY count() DESC
-LIMIT 20
-
-┌─CounterID─┬──count()─┐
-│    114208 │ 56057344 │
-│    115080 │ 51619590 │
-│      3228 │ 44658301 │
-│     38230 │ 42045932 │
-│    145263 │ 42042158 │
-│     91244 │ 38297270 │
-│    154139 │ 26647572 │
-│    150748 │ 24112755 │
-│    242232 │ 21302571 │
-│    338158 │ 13507087 │
-│     62180 │ 12229491 │
-│     82264 │ 12187441 │
-│    232261 │ 12148031 │
-│    146272 │ 11438516 │
-│    168777 │ 11403636 │
-│   4120072 │ 11227824 │
-│  10938808 │ 10519739 │
-│     74088 │  9047015 │
-│    115079 │  8837972 │
-│    337234 │  8205961 │
-└───────────┴──────────┘
-
-20 rows in set. Elapsed: 0.153 sec. Processed 1.00 billion rows, 4.00 GB (6.53 billion rows/s., 26.10 GB/s.)
-
-:)
-```
-
-</details>
-
-### CPU
-
-クエリを実行するには大量の行を処理する必要があるため、個別の行ではなくベクター全体のすべての操作をディスパッチするか、ディスパッチコストがほとんどないようにクエリエンジンを実装すると効率的です。 適切なディスクサブシステムでこれを行わないと、クエリインタープリターが必然的にCPUを失速させます。
-データを列に格納し、可能な場合は列ごとに処理することは理にかなっています。
-
-これを行うには2つの方法があります:
-
-1. ベクトルエンジン。 すべての操作は、個別の値ではなく、ベクトルに対して記述されます。 これは、オペレーションを頻繁に呼び出す必要がなく、ディスパッチコストが無視できることを意味します。 操作コードには、最適化された内部サイクルが含まれています。
-
-2. コード生成。 クエリ用に生成されたコードには、すべての間接的な呼び出しが含まれています。
-
-これは、単純なクエリを実行する場合には意味がないため、「通常の」データベースでは実行されません。 ただし、例外があります。 たとえば、MemSQLはコード生成を使用して、SQLクエリを処理する際の遅延を減らします。 （比較のために、分析DBMSではレイテンシではなくスループットの最適化が必要です。）
-
-CPU効率のために、クエリ言語は宣言型（SQLまたはMDX）、または少なくともベクトル（J、K）でなければなりません。 クエリには、最適化を可能にする暗黙的なループのみを含める必要があります。
-
-[Original article](https://clickhouse.yandex/docs/en/) <!--hide-->

docs/ja/index.md

@@ -0,0 +1 @@
+../en/index.md

docs/ja/interfaces/cli.md

@@ -0,0 +1 @@
+../../en/interfaces/cli.md

docs/ja/interfaces/cpp.md

@@ -0,0 +1 @@
+../../en/interfaces/cpp.md

docs/ja/interfaces/formats.md

@@ -0,0 +1 @@
+../../en/interfaces/formats.md

docs/ja/interfaces/http.md

@@ -0,0 +1 @@
+../../en/interfaces/http.md

docs/ja/interfaces/index.md

@@ -0,0 +1 @@
+../../en/interfaces/index.md

docs/ja/interfaces/jdbc.md

@@ -0,0 +1 @@
+../../en/interfaces/jdbc.md

docs/ja/interfaces/odbc.md

@@ -0,0 +1 @@
+../../en/interfaces/odbc.md

docs/ja/interfaces/tcp.md

@@ -0,0 +1 @@
+../../en/interfaces/tcp.md

docs/ja/interfaces/third-party/client_libraries.md

@@ -0,0 +1 @@
+../../../en/interfaces/third-party/client_libraries.md

docs/ja/interfaces/third-party/gui.md

@@ -0,0 +1 @@
+../../../en/interfaces/third-party/gui.md

docs/ja/interfaces/third-party/integrations.md

@@ -0,0 +1 @@
+../../../en/interfaces/third-party/integrations.md

docs/ja/interfaces/third-party/proxy.md

@@ -0,0 +1 @@
+../../../en/interfaces/third-party/proxy.md

docs/ja/introduction/distinctive_features.md

@@ -0,0 +1 @@
+../../en/introduction/distinctive_features.md

docs/ja/introduction/features_considered_disadvantages.md

@@ -0,0 +1 @@
+../../en/introduction/features_considered_disadvantages.md

docs/ja/introduction/history.md

@@ -0,0 +1 @@
+../../en/introduction/history.md

docs/ja/introduction/performance.md

@@ -0,0 +1 @@
+../../en/introduction/performance.md

docs/ja/operations/access_rights.md

@@ -0,0 +1 @@
+../../en/operations/access_rights.md

docs/ja/operations/backup.md

@@ -0,0 +1 @@
+../../en/operations/backup.md

docs/ja/operations/configuration_files.md

@@ -0,0 +1 @@
+../../en/operations/configuration_files.md

docs/ja/operations/index.md

@@ -0,0 +1 @@
+../../en/operations/index.md

docs/ja/operations/monitoring.md

@@ -0,0 +1 @@
+../../en/operations/monitoring.md

docs/ja/operations/quotas.md

@@ -0,0 +1 @@
+../../en/operations/quotas.md

docs/ja/operations/requirements.md

@@ -0,0 +1 @@
+../../en/operations/requirements.md

docs/ja/operations/server_settings/index.md

@@ -0,0 +1 @@
+../../../en/operations/server_settings/index.md

docs/ja/operations/server_settings/settings.md

@@ -0,0 +1 @@
+../../../en/operations/server_settings/settings.md

docs/ja/operations/settings/constraints_on_settings.md

@@ -0,0 +1 @@
+../../../en/operations/settings/constraints_on_settings.md

docs/ja/operations/settings/index.md

@@ -0,0 +1 @@
+../../../en/operations/settings/index.md

docs/ja/operations/settings/permissions_for_queries.md

@@ -0,0 +1 @@
+../../../en/operations/settings/permissions_for_queries.md

docs/ja/operations/settings/query_complexity.md

@@ -0,0 +1 @@
+../../../en/operations/settings/query_complexity.md

docs/ja/operations/settings/settings.md

@@ -0,0 +1 @@
+../../../en/operations/settings/settings.md

docs/ja/operations/settings/settings_profiles.md

@@ -0,0 +1 @@
+../../../en/operations/settings/settings_profiles.md

docs/ja/operations/settings/settings_users.md

@@ -0,0 +1 @@
+../../../en/operations/settings/settings_users.md

docs/ja/operations/system_tables.md

@@ -0,0 +1 @@
+../../en/operations/system_tables.md

docs/ja/operations/table_engines/aggregatingmergetree.md

@@ -0,0 +1 @@
+../../../en/operations/table_engines/aggregatingmergetree.md

docs/ja/operations/table_engines/buffer.md

@@ -0,0 +1 @@
+../../../en/operations/table_engines/buffer.md