diff --git a/docs/_static/custom.css b/docs/_static/custom.css index d8bc77b763b..e9e25250dcd 100644 --- a/docs/_static/custom.css +++ b/docs/_static/custom.css @@ -4,6 +4,15 @@ div.document, div.footer { div.sphinxsidebarwrapper { padding: 2px 10px; } +div.body dd, div.body li, div.body p { + line-height: 1.6em; +} +div.body blockquote, div.body dd, div.body li, div.body p { + -moz-hyphens: none; + -ms-hyphens: none; + -webkit-hyphens: none; + hyphens: none; +} div.sphinxsidebarwrapper p.logo { float: left; diff --git a/docs/en/introduction/what_is_clickhouse.rst b/docs/en/introduction/what_is_clickhouse.rst index 8c5f8a6a494..f9029eb8ccb 100644 --- a/docs/en/introduction/what_is_clickhouse.rst +++ b/docs/en/introduction/what_is_clickhouse.rst @@ -26,7 +26,7 @@ In a column-oriented DBMS, data is stored like this: 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) (Amazon Redshift)``, ``Sybase IQ``, ``Exasol``, ``Infobright``, ``InfiniDB``, ``MonetDB (VectorWise) (Actian Vector)``, ``LucidDB``, ``SAP HANA``, ``Google Dremel``, ``Google PowerDrill``, ``Druid``, ``kdb+`` и т. п. +Examples of a column-oriented DBMS: ``Vertica``, ``Paraccel (Actian Matrix) (Amazon Redshift)``, ``Sybase IQ``, ``Exasol``, ``Infobright``, ``InfiniDB``, ``MonetDB (VectorWise) (Actian Vector)``, ``LucidDB``, ``SAP HANA``, ``Google Dremel``, ``Google PowerDrill``, ``Druid``, ``kdb+``, etc. 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. @@ -113,6 +113,7 @@ Since executing a query requires processing a large number of rows, it helps to It makes sense to both store data in columns and process it, when possible, by columns. There are two ways to do this: + #. 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. #. Code generation. The code generated for the query has all the indirect calls in it. diff --git a/website/index.html b/website/index.html index 1b1538b4fbf..39baa44c299 100644 --- a/website/index.html +++ b/website/index.html @@ -191,6 +191,8 @@ rel="external nofollow" target="_blank">Column Store Database Benchmarks by Percona
  • 1.1 Billion Taxi Rides on ClickHouse & an Intel Core i5 by Mark Litwintschik
    • +
  • ClickHouse vs Amazon RedShift Benchmark by Altinity
  • Geospatial processing with Clickhouse by Carto
  • Subscribe on official ClickHouse blog and it's Russian branch.
    • + rel="external nofollow" target="_blank">counterpart in Russian.
  • Ask any questions on Stack Overflow or