文章的翻譯是專門為課程的學生準備的 .
是一個開源的柱狀資料庫。 這是一個很棒的環境，即使每天輸入數百億筆新記錄，數百名分析師也可以快速查詢詳細資料。 支援此類系統的基礎設施成本每年可能高達 100 美元，根據使用情況，可能會減半。 Yandex Metrics 的 ClickHouse 安裝一度包含 10 兆筆記錄。 除了 Yandex 之外，ClickHouse 還在 Bloomberg 和 Cloudflare 上取得了成功。
兩年前我花了 使用一台機器的資料庫，它變成了 我見過的免費資料庫軟體。 從那時起，開發人員就沒有停止添加功能，包括對 Kafka、HDFS 和 ZStandard 壓縮的支援。 去年他們增加了對級聯壓縮方法的支持，並且 編碼成為可能。 在壓縮時間序列資料時，使用delta編碼可以很好地壓縮gauge值，但是對於計數器來說，使用delta-by-delta編碼會更好。 良好的壓縮成為ClickHouse效能的關鍵。
ClickHouse 由 170 萬行 C++ 程式碼（不含第三方函式庫）組成，是最小的分散式資料庫程式庫之一。 相較之下，SQLite不支援分散式，由235萬行C程式碼組成，截至本文撰寫時，已經有207名工程師為ClickHouse做出了貢獻，並且最近提交的強度一直在增加。
2017年XNUMX月，ClickHouse開始進行 作為追蹤開發的簡單方法。 他們也將整體文件文件分解為基於 Markdown 的文件層次結構。 問題和功能透過 GitHub 進行跟踪，總體而言，該軟體在過去幾年中變得更加易於訪問。
在本文中，我將了解使用 2 核心處理器和 NVMe 儲存的 AWS EC36 上的 ClickHouse 叢集的效能。
更新：最初發布這篇文章一周後，我使用改進的配置重新運行了測試，並取得了更好的結果。 這篇文章已更新以反映這些變更。
啟動 AWS EC2 集群
我將在本文中使用三個 c5d.9xlarge EC2 執行個體。 每個都包含 36 個虛擬 CPU、72 GB RAM、900 GB NVMe SSD 儲存並支援 10 Gigabit 網路。 在 eu-west-1,962 區域，按需運行時，每台的費用為 1 美元/小時。 我將使用 Ubuntu Server 16.04 LTS 作為作業系統。
配置了防火牆，讓每台機器都可以不受限制地互相通信，並且叢集中只有我的IPv4位址被SSH列入白名單。
NVMe 驅動器處於操作就緒狀態
為了讓 ClickHouse 正常運作，我將在每台伺服器上的 NVMe 磁碟機上建立一個 EXT4 格式的檔案系統。
$ sudo mkfs -t ext4 /dev/nvme1n1
$ sudo mkdir /ch
$ sudo mount /dev/nvme1n1 /ch配置完所有內容後，您可以看到安裝點和每個系統上的 783 GB 可用空間。
$ lsblkNAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
loop0 7:0 0 87.9M 1 loop /snap/core/5742
loop1 7:1 0 16.5M 1 loop /snap/amazon-ssm-agent/784
nvme0n1 259:1 0 8G 0 disk
└─nvme0n1p1 259:2 0 8G 0 part /
nvme1n1 259:0 0 838.2G 0 disk /ch$ df -hFilesystem Size Used Avail Use% Mounted on
udev 35G 0 35G 0% /dev
tmpfs 6.9G 8.8M 6.9G 1% /run
/dev/nvme0n1p1 7.7G 967M 6.8G 13% /
tmpfs 35G 0 35G 0% /dev/shm
tmpfs 5.0M 0 5.0M 0% /run/lock
tmpfs 35G 0 35G 0% /sys/fs/cgroup
/dev/loop0 88M 88M 0 100% /snap/core/5742
/dev/loop1 17M 17M 0 100% /snap/amazon-ssm-agent/784
tmpfs 6.9G 0 6.9G 0% /run/user/1000
/dev/nvme1n1 825G 73M 783G 1% /ch我將在本次測試中使用的資料集是我根據紐約市六年來 1.1 億次計程車行程產生的資料轉儲。 在部落格上 詳細說明了我如何收集該資料集。 它們儲存在 AWS S3 中，因此我將使用我的存取金鑰和金鑰來配置 AWS CLI。
$ sudo apt update
$ sudo apt install awscli
$ aws configure我將客戶端的並發請求限制設為 100，以便檔案下載速度比預設值更快。
$ aws configure set
default.s3.max_concurrent_requests
100我將從 AWS S3 下載計程車行程資料集並將其儲存在第一台伺服器上的 NVMe 磁碟機上。 此資料集採用 GZIP 壓縮的 CSV 格式，大小約為 104GB。
$ sudo mkdir -p /ch/csv
$ sudo chown -R ubuntu /ch/csv
$ aws s3 sync s3://<bucket>/csv /ch/csvClickHouse安裝
我將安裝 Java 8 的 OpenJDK 發行版，因為它是運行 Apache ZooKeeper 所必需的，而 Apache ZooKeeper 是在所有三台電腦上分散式安裝 ClickHouse 所必需的。
$ sudo apt update
$ sudo apt install
openjdk-8-jre
openjdk-8-jdk-headless
然後我設定環境變數 JAVA_HOME.
$ sudo vi /etc/profile
export JAVA_HOME=/usr
$ source /etc/profile然後，我將使用 Ubuntu 的套件管理系統在所有三台機器上安裝 ClickHouse 18.16.1、glances 和 ZooKeeper。
$ sudo apt-key adv
--keyserver hkp://keyserver.ubuntu.com:80
--recv E0C56BD4
$ echo "deb http://repo.yandex.ru/clickhouse/deb/stable/ main/" |
sudo tee /etc/apt/sources.list.d/clickhouse.list
$ sudo apt-get update$ sudo apt install
clickhouse-client
clickhouse-server
glances
zookeeperd我將為 ClickHouse 建立一個目錄，並在所有三台伺服器上進行一些配置覆蓋。
$ sudo mkdir /ch/clickhouse
$ sudo chown -R clickhouse /ch/clickhouse
$ sudo mkdir -p /etc/clickhouse-server/conf.d
$ sudo vi /etc/clickhouse-server/conf.d/taxis.conf這些是我將使用的配置覆蓋。
<?xml version="1.0"?>
<yandex>
<listen_host>0.0.0.0</listen_host>
<path>/ch/clickhouse/</path>
<remote_servers>
<perftest_3shards>
<shard>
<replica>
<host>172.30.2.192</host>
<port>9000</port>
</replica>
</shard>
<shard>
<replica>
<host>172.30.2.162</host>
<port>9000</port>
</replica>
</shard>
<shard>
<replica>
<host>172.30.2.36</host>
<port>9000</port>
</replica>
</shard>
</perftest_3shards>
</remote_servers> <zookeeper-servers>
<node>
<host>172.30.2.192</host>
<port>2181</port>
</node>
<node>
<host>172.30.2.162</host>
<port>2181</port>
</node>
<node>
<host>172.30.2.36</host>
<port>2181</port>
</node>
</zookeeper-servers> <macros>
<shard>03</shard>
<replica>01</replica>
</macros>
</yandex>然後，我將在所有三台電腦上執行 ZooKeeper 和 ClickHouse 伺服器。
$ sudo /etc/init.d/zookeeper start
$ sudo service clickhouse-server start上傳資料到ClickHouse
在第一台伺服器上，我將建立一個行程表（trips），它將使用日誌引擎儲存出租車行程的資料集。
$ clickhouse-client --host=0.0.0.0
CREATE TABLE trips (
trip_id UInt32,
vendor_id String,
pickup_datetime DateTime,
dropoff_datetime Nullable(DateTime),
store_and_fwd_flag Nullable(FixedString(1)),
rate_code_id Nullable(UInt8),
pickup_longitude Nullable(Float64),
pickup_latitude Nullable(Float64),
dropoff_longitude Nullable(Float64),
dropoff_latitude Nullable(Float64),
passenger_count Nullable(UInt8),
trip_distance Nullable(Float64),
fare_amount Nullable(Float32),
extra Nullable(Float32),
mta_tax Nullable(Float32),
tip_amount Nullable(Float32),
tolls_amount Nullable(Float32),
ehail_fee Nullable(Float32),
improvement_surcharge Nullable(Float32),
total_amount Nullable(Float32),
payment_type Nullable(String),
trip_type Nullable(UInt8),
pickup Nullable(String),
dropoff Nullable(String),
cab_type Nullable(String),
precipitation Nullable(Int8),
snow_depth Nullable(Int8),
snowfall Nullable(Int8),
max_temperature Nullable(Int8),
min_temperature Nullable(Int8),
average_wind_speed Nullable(Int8),
pickup_nyct2010_gid Nullable(Int8),
pickup_ctlabel Nullable(String),
pickup_borocode Nullable(Int8),
pickup_boroname Nullable(String),
pickup_ct2010 Nullable(String),
pickup_boroct2010 Nullable(String),
pickup_cdeligibil Nullable(FixedString(1)),
pickup_ntacode Nullable(String),
pickup_ntaname Nullable(String),
pickup_puma Nullable(String),
dropoff_nyct2010_gid Nullable(UInt8),
dropoff_ctlabel Nullable(String),
dropoff_borocode Nullable(UInt8),
dropoff_boroname Nullable(String),
dropoff_ct2010 Nullable(String),
dropoff_boroct2010 Nullable(String),
dropoff_cdeligibil Nullable(String),
dropoff_ntacode Nullable(String),
dropoff_ntaname Nullable(String),
dropoff_puma Nullable(String)
) ENGINE = Log;
然後，我提取每個 CSV 檔案並將其載入到行程表中（trips）。 以下內容用時55分10秒完成。 執行此操作後，資料目錄的大小為134 GB。
$ time (for FILENAME in /ch/csv/trips_x*.csv.gz; do
echo $FILENAME
gunzip -c $FILENAME |
clickhouse-client
--host=0.0.0.0
--query="INSERT INTO trips FORMAT CSV"
done)未壓縮 CSV 內容的導入速度為每秒 155 MB。 我懷疑這是由於 GZIP 解壓縮的瓶頸造成的。 使用 xargs 並行解壓縮所有 gzip 檔案然後載入解壓縮的資料可能會更快。 以下是 CSV 導入過程中所報告的內容的描述。
$ sudo glancesip-172-30-2-200 (Ubuntu 16.04 64bit / Linux 4.4.0-1072-aws) Uptime: 0:11:42
CPU 8.2% nice: 0.0% LOAD 36-core MEM 9.8% active: 5.20G SWAP 0.0%
user: 6.0% irq: 0.0% 1 min: 2.24 total: 68.7G inactive: 61.0G total: 0
system: 0.9% iowait: 1.3% 5 min: 1.83 used: 6.71G buffers: 66.4M used: 0
idle: 91.8% steal: 0.0% 15 min: 1.01 free: 62.0G cached: 61.6G free: 0
NETWORK Rx/s Tx/s TASKS 370 (507 thr), 2 run, 368 slp, 0 oth sorted automatically by cpu_percent, flat view
ens5 136b 2Kb
lo 343Mb 343Mb CPU% MEM% VIRT RES PID USER NI S TIME+ IOR/s IOW/s Command
100.4 1.5 1.65G 1.06G 9909 ubuntu 0 S 1:01.33 0 0 clickhouse-client --host=0.0.0.0 --query=INSERT INTO trips FORMAT CSV
DISK I/O R/s W/s 85.1 0.0 4.65M 708K 9908 ubuntu 0 R 0:50.60 32M 0 gzip -d -c /ch/csv/trips_xac.csv.gz
loop0 0 0 54.9 5.1 8.14G 3.49G 8091 clickhous 0 S 1:44.23 0 45M /usr/bin/clickhouse-server --config=/etc/clickhouse-server/config.xml
loop1 0 0 4.5 0.0 0 0 319 root 0 S 0:07.50 1K 0 kworker/u72:2
nvme0n1 0 3K 2.3 0.0 91.1M 28.9M 9912 root 0 R 0:01.56 0 0 /usr/bin/python3 /usr/bin/glances
nvme0n1p1 0 3K 0.3 0.0 0 0 960 root -20 S 0:00.10 0 0 kworker/28:1H
nvme1n1 32.1M 495M 0.3 0.0 0 0 1058 root -20 S 0:00.90 0 0 kworker/23:1H在繼續之前，我將透過刪除原始 CSV 檔案來釋放 NVMe 磁碟機上的空間。
$ sudo rm -fr /ch/csv轉換為列形式
Log ClickHouse 引擎將以面向行的格式儲存資料。 為了更快地查詢數據，我使用 MergeTree 引擎將其轉換為柱狀格式。
$ clickhouse-client --host=0.0.0.0以下耗時34分50秒完成。 執行此操作後，資料目錄的大小為237 GB。
CREATE TABLE trips_mergetree
ENGINE = MergeTree(pickup_date, pickup_datetime, 8192)
AS SELECT
trip_id,
CAST(vendor_id AS Enum8('1' = 1,
'2' = 2,
'CMT' = 3,
'VTS' = 4,
'DDS' = 5,
'B02512' = 10,
'B02598' = 11,
'B02617' = 12,
'B02682' = 13,
'B02764' = 14)) AS vendor_id,
toDate(pickup_datetime) AS pickup_date,
ifNull(pickup_datetime, toDateTime(0)) AS pickup_datetime,
toDate(dropoff_datetime) AS dropoff_date,
ifNull(dropoff_datetime, toDateTime(0)) AS dropoff_datetime,
assumeNotNull(store_and_fwd_flag) AS store_and_fwd_flag,
assumeNotNull(rate_code_id) AS rate_code_id,
assumeNotNull(pickup_longitude) AS pickup_longitude,
assumeNotNull(pickup_latitude) AS pickup_latitude,
assumeNotNull(dropoff_longitude) AS dropoff_longitude,
assumeNotNull(dropoff_latitude) AS dropoff_latitude,
assumeNotNull(passenger_count) AS passenger_count,
assumeNotNull(trip_distance) AS trip_distance,
assumeNotNull(fare_amount) AS fare_amount,
assumeNotNull(extra) AS extra,
assumeNotNull(mta_tax) AS mta_tax,
assumeNotNull(tip_amount) AS tip_amount,
assumeNotNull(tolls_amount) AS tolls_amount,
assumeNotNull(ehail_fee) AS ehail_fee,
assumeNotNull(improvement_surcharge) AS improvement_surcharge,
assumeNotNull(total_amount) AS total_amount,
assumeNotNull(payment_type) AS payment_type_,
assumeNotNull(trip_type) AS trip_type,
pickup AS pickup,
pickup AS dropoff,
CAST(assumeNotNull(cab_type)
AS Enum8('yellow' = 1, 'green' = 2))
AS cab_type,
precipitation AS precipitation,
snow_depth AS snow_depth,
snowfall AS snowfall,
max_temperature AS max_temperature,
min_temperature AS min_temperature,
average_wind_speed AS average_wind_speed,
pickup_nyct2010_gid AS pickup_nyct2010_gid,
pickup_ctlabel AS pickup_ctlabel,
pickup_borocode AS pickup_borocode,
pickup_boroname AS pickup_boroname,
pickup_ct2010 AS pickup_ct2010,
pickup_boroct2010 AS pickup_boroct2010,
pickup_cdeligibil AS pickup_cdeligibil,
pickup_ntacode AS pickup_ntacode,
pickup_ntaname AS pickup_ntaname,
pickup_puma AS pickup_puma,
dropoff_nyct2010_gid AS dropoff_nyct2010_gid,
dropoff_ctlabel AS dropoff_ctlabel,
dropoff_borocode AS dropoff_borocode,
dropoff_boroname AS dropoff_boroname,
dropoff_ct2010 AS dropoff_ct2010,
dropoff_boroct2010 AS dropoff_boroct2010,
dropoff_cdeligibil AS dropoff_cdeligibil,
dropoff_ntacode AS dropoff_ntacode,
dropoff_ntaname AS dropoff_ntaname,
dropoff_puma AS dropoff_puma
FROM trips;這是操作過程中掃視輸出的樣子：
ip-172-30-2-200 (Ubuntu 16.04 64bit / Linux 4.4.0-1072-aws) Uptime: 1:06:09
CPU 10.3% nice: 0.0% LOAD 36-core MEM 16.1% active: 13.3G SWAP 0.0%
user: 7.9% irq: 0.0% 1 min: 1.87 total: 68.7G inactive: 52.8G total: 0
system: 1.6% iowait: 0.8% 5 min: 1.76 used: 11.1G buffers: 71.8M used: 0
idle: 89.7% steal: 0.0% 15 min: 1.95 free: 57.6G cached: 57.2G free: 0
NETWORK Rx/s Tx/s TASKS 367 (523 thr), 1 run, 366 slp, 0 oth sorted automatically by cpu_percent, flat view
ens5 1Kb 8Kb
lo 2Kb 2Kb CPU% MEM% VIRT RES PID USER NI S TIME+ IOR/s IOW/s Command
241.9 12.8 20.7G 8.78G 8091 clickhous 0 S 30:36.73 34M 125M /usr/bin/clickhouse-server --config=/etc/clickhouse-server/config.xml
DISK I/O R/s W/s 2.6 0.0 90.4M 28.3M 9948 root 0 R 1:18.53 0 0 /usr/bin/python3 /usr/bin/glances
loop0 0 0 1.3 0.0 0 0 203 root 0 S 0:09.82 0 0 kswapd0
loop1 0 0 0.3 0.1 315M 61.3M 15701 ubuntu 0 S 0:00.40 0 0 clickhouse-client --host=0.0.0.0
nvme0n1 0 3K 0.3 0.0 0 0 7 root 0 S 0:00.83 0 0 rcu_sched
nvme0n1p1 0 3K 0.0 0.0 0 0 142 root 0 S 0:00.22 0 0 migration/27
nvme1n1 25.8M 330M 0.0 0.0 59.7M 1.79M 2764 ubuntu 0 S 0:00.00 0 0 (sd-pam)在上次測試中，轉換並重新計算了幾列。 我發現其中一些函數在此資料集上不再按預期工作。 為了解決這個問題，我刪除了不適當的函數並加載了數據，而沒有轉換為更細粒度的類型。
數據在集群中的分佈
我將在所有三個叢集節點上分發資料。 首先，下面我將在所有三台機器上建立一個表格。
$ clickhouse-client --host=0.0.0.0CREATE TABLE trips_mergetree_third (
trip_id UInt32,
vendor_id String,
pickup_date Date,
pickup_datetime DateTime,
dropoff_date Date,
dropoff_datetime Nullable(DateTime),
store_and_fwd_flag Nullable(FixedString(1)),
rate_code_id Nullable(UInt8),
pickup_longitude Nullable(Float64),
pickup_latitude Nullable(Float64),
dropoff_longitude Nullable(Float64),
dropoff_latitude Nullable(Float64),
passenger_count Nullable(UInt8),
trip_distance Nullable(Float64),
fare_amount Nullable(Float32),
extra Nullable(Float32),
mta_tax Nullable(Float32),
tip_amount Nullable(Float32),
tolls_amount Nullable(Float32),
ehail_fee Nullable(Float32),
improvement_surcharge Nullable(Float32),
total_amount Nullable(Float32),
payment_type Nullable(String),
trip_type Nullable(UInt8),
pickup Nullable(String),
dropoff Nullable(String),
cab_type Nullable(String),
precipitation Nullable(Int8),
snow_depth Nullable(Int8),
snowfall Nullable(Int8),
max_temperature Nullable(Int8),
min_temperature Nullable(Int8),
average_wind_speed Nullable(Int8),
pickup_nyct2010_gid Nullable(Int8),
pickup_ctlabel Nullable(String),
pickup_borocode Nullable(Int8),
pickup_boroname Nullable(String),
pickup_ct2010 Nullable(String),
pickup_boroct2010 Nullable(String),
pickup_cdeligibil Nullable(FixedString(1)),
pickup_ntacode Nullable(String),
pickup_ntaname Nullable(String),
pickup_puma Nullable(String),
dropoff_nyct2010_gid Nullable(UInt8),
dropoff_ctlabel Nullable(String),
dropoff_borocode Nullable(UInt8),
dropoff_boroname Nullable(String),
dropoff_ct2010 Nullable(String),
dropoff_boroct2010 Nullable(String),
dropoff_cdeligibil Nullable(String),
dropoff_ntacode Nullable(String),
dropoff_ntaname Nullable(String),
dropoff_puma Nullable(String)
) ENGINE = MergeTree(pickup_date, pickup_datetime, 8192);然後我將確保第一台伺服器可以看到叢集中的所有三個節點。
SELECT *
FROM system.clusters
WHERE cluster = 'perftest_3shards'
FORMAT Vertical;Row 1:
──────
cluster: perftest_3shards
shard_num: 1
shard_weight: 1
replica_num: 1
host_name: 172.30.2.192
host_address: 172.30.2.192
port: 9000
is_local: 1
user: default
default_database:Row 2:
──────
cluster: perftest_3shards
shard_num: 2
shard_weight: 1
replica_num: 1
host_name: 172.30.2.162
host_address: 172.30.2.162
port: 9000
is_local: 0
user: default
default_database:Row 3:
──────
cluster: perftest_3shards
shard_num: 3
shard_weight: 1
replica_num: 1
host_name: 172.30.2.36
host_address: 172.30.2.36
port: 9000
is_local: 0
user: default
default_database:
然後我將在第一台伺服器上定義一個基於該架構的新表 trips_mergetree_third 並使用分散式引擎。
CREATE TABLE trips_mergetree_x3
AS trips_mergetree_third
ENGINE = Distributed(perftest_3shards,
default,
trips_mergetree_third,
rand());然後，我會將資料從基於 MergeTree 的表複製到所有三台伺服器。 以下耗時34分44秒完成。
INSERT INTO trips_mergetree_x3
SELECT * FROM trips_mergetree;經過上述操作後，我給了 ClickHouse 15 分鐘的時間來遠離最大儲存等級標記。 三台伺服器上的資料目錄最終分別為 264 GB、34 GB 和 33 GB。
ClickHouse集群效能評估
接下來我看到的是我所見過的在表上多次運行每個查詢的最快時間 trips_mergetree_x3.
$ clickhouse-client --host=0.0.0.0以下任務以時 2.449 秒完成。
SELECT cab_type, count(*)
FROM trips_mergetree_x3
GROUP BY cab_type;以下任務以時 0.691 秒完成。
SELECT passenger_count,
avg(total_amount)
FROM trips_mergetree_x3
GROUP BY passenger_count;以下在 0 秒內完成。
SELECT passenger_count,
toYear(pickup_date) AS year,
count(*)
FROM trips_mergetree_x3
GROUP BY passenger_count,
year;以下任務以時 0.983 秒完成。
SELECT passenger_count,
toYear(pickup_date) AS year,
round(trip_distance) AS distance,
count(*)
FROM trips_mergetree_x3
GROUP BY passenger_count,
year,
distance
ORDER BY year,
count(*) DESC;為了進行比較，我在僅駐留在第一台伺服器上的基於 MergeTree 的表上運行了相同的查詢。
單一ClickHouse節點效能評估
接下來我看到的是我所見過的在表上多次運行每個查詢的最快時間 trips_mergetree_x3.
以下任務以時 0.241 秒完成。
SELECT cab_type, count(*)
FROM trips_mergetree
GROUP BY cab_type;以下任務以時 0.826 秒完成。
SELECT passenger_count,
avg(total_amount)
FROM trips_mergetree
GROUP BY passenger_count;以下任務以時 1.209 秒完成。
SELECT passenger_count,
toYear(pickup_date) AS year,
count(*)
FROM trips_mergetree
GROUP BY passenger_count,
year;以下任務以時 1.781 秒完成。
SELECT passenger_count,
toYear(pickup_date) AS year,
round(trip_distance) AS distance,
count(*)
FROM trips_mergetree
GROUP BY passenger_count,
year,
distance
ORDER BY year,
count(*) DESC;對結果的思考
在我的測試中，這是第一次基於 CPU 的免費資料庫的效能優於基於 GPU 的資料庫。 此後，基於 GPU 的資料庫經歷了兩次修訂，但 ClickHouse 在單一節點上提供的效能仍然非常令人印象深刻。
同時，在分散式引擎上執行查詢1時，開銷成本要高出一個數量級。 我希望我在這篇文章的研究中遺漏了一些東西，因為當我向叢集添加更多節點時，如果看到查詢時間減少，那就太好了。 不過，很高興的是，在執行其他查詢時，效能提高了大約 2 倍。
很高興看到 ClickHouse 朝著能夠分離儲存和運算的方向發展，以便它們可以獨立擴展。 去年新增的 HDFS 支援可能是朝著這個目標邁出的一步。 在運算方面，如果可以透過向叢集添加更多節點來加速單一查詢，那麼這個軟體的未來是非常光明的。
感謝您花時間閱讀這篇文章。 我為北美和歐洲的客戶提供諮詢、架構和實踐開發服務。 如果您想討論我的建議如何幫助您的業務，請透過以下方式與我聯繫 .
來源： www.habr.com