ਦੋ ਯਾਕੋਜ਼ੁਨਾ ਦੀ ਲੜਾਈ, ਜਾਂ ਕੈਸੈਂਡਰਾ ਬਨਾਮ ਐਚਬੇਸ। Sberbank ਟੀਮ ਦਾ ਤਜਰਬਾ

ਇਹ ਇੱਕ ਮਜ਼ਾਕ ਵੀ ਨਹੀਂ ਹੈ, ਅਜਿਹਾ ਲਗਦਾ ਹੈ ਕਿ ਇਹ ਖਾਸ ਤਸਵੀਰ ਇਹਨਾਂ ਡੇਟਾਬੇਸ ਦੇ ਤੱਤ ਨੂੰ ਸਭ ਤੋਂ ਸਹੀ ਰੂਪ ਵਿੱਚ ਦਰਸਾਉਂਦੀ ਹੈ, ਅਤੇ ਅੰਤ ਵਿੱਚ ਇਹ ਸਪੱਸ਼ਟ ਹੋ ਜਾਵੇਗਾ ਕਿ ਕਿਉਂ:

DB-ਇੰਜਨ ਰੈਂਕਿੰਗ ਦੇ ਅਨੁਸਾਰ, ਦੋ ਸਭ ਤੋਂ ਪ੍ਰਸਿੱਧ NoSQL ਕਾਲਮਨਰ ਡੇਟਾਬੇਸ ਕੈਸੈਂਡਰਾ (ਇਸ ਤੋਂ ਬਾਅਦ CS) ਅਤੇ HBase (HB) ਹਨ।

ਕਿਸਮਤ ਦੀ ਇੱਛਾ ਨਾਲ, Sberbank 'ਤੇ ਸਾਡੀ ਡਾਟਾ ਲੋਡਿੰਗ ਪ੍ਰਬੰਧਨ ਟੀਮ ਪਹਿਲਾਂ ਹੀ ਹੈ ਬਹੁਤ ਚਿਰ ਪਹਿਲਾਂ ਅਤੇ HB ਨਾਲ ਮਿਲ ਕੇ ਕੰਮ ਕਰਦਾ ਹੈ। ਇਸ ਸਮੇਂ ਦੌਰਾਨ, ਅਸੀਂ ਇਸ ਦੀਆਂ ਖੂਬੀਆਂ ਅਤੇ ਕਮਜ਼ੋਰੀਆਂ ਦਾ ਚੰਗੀ ਤਰ੍ਹਾਂ ਅਧਿਐਨ ਕੀਤਾ ਅਤੇ ਇਸਨੂੰ ਪਕਾਉਣ ਦਾ ਤਰੀਕਾ ਸਿੱਖਿਆ। ਹਾਲਾਂਕਿ, CS ਦੇ ਰੂਪ ਵਿੱਚ ਇੱਕ ਵਿਕਲਪ ਦੀ ਮੌਜੂਦਗੀ ਨੇ ਹਮੇਸ਼ਾ ਸਾਨੂੰ ਆਪਣੇ ਆਪ ਨੂੰ ਥੋੜਾ ਜਿਹਾ ਸ਼ੱਕ ਕਰਨ ਲਈ ਮਜਬੂਰ ਕੀਤਾ: ਕੀ ਅਸੀਂ ਸਹੀ ਚੋਣ ਕੀਤੀ ਹੈ? ਇਸ ਤੋਂ ਇਲਾਵਾ, ਨਤੀਜੇ ਤੁਲਨਾ, DataStax ਦੁਆਰਾ ਕੀਤਾ ਗਿਆ, ਉਹਨਾਂ ਨੇ ਕਿਹਾ ਕਿ CS ਆਸਾਨੀ ਨਾਲ ਲਗਭਗ ਇੱਕ ਕੁਚਲਣ ਵਾਲੇ ਸਕੋਰ ਨਾਲ HB ਨੂੰ ਹਰਾਉਂਦਾ ਹੈ। ਦੂਜੇ ਪਾਸੇ, DataStax ਇੱਕ ਦਿਲਚਸਪੀ ਰੱਖਣ ਵਾਲੀ ਪਾਰਟੀ ਹੈ, ਅਤੇ ਤੁਹਾਨੂੰ ਇਸਦੇ ਲਈ ਉਹਨਾਂ ਦਾ ਸ਼ਬਦ ਨਹੀਂ ਲੈਣਾ ਚਾਹੀਦਾ. ਅਸੀਂ ਟੈਸਟਿੰਗ ਸ਼ਰਤਾਂ ਬਾਰੇ ਥੋੜ੍ਹੀ ਜਿਹੀ ਜਾਣਕਾਰੀ ਦੁਆਰਾ ਵੀ ਉਲਝਣ ਵਿੱਚ ਸੀ, ਇਸ ਲਈ ਅਸੀਂ ਆਪਣੇ ਆਪ ਇਹ ਪਤਾ ਲਗਾਉਣ ਦਾ ਫੈਸਲਾ ਕੀਤਾ ਕਿ BigData NoSql ਦਾ ਰਾਜਾ ਕੌਣ ਹੈ, ਅਤੇ ਪ੍ਰਾਪਤ ਨਤੀਜੇ ਬਹੁਤ ਦਿਲਚਸਪ ਨਿਕਲੇ।

ਹਾਲਾਂਕਿ, ਕੀਤੇ ਗਏ ਟੈਸਟਾਂ ਦੇ ਨਤੀਜਿਆਂ 'ਤੇ ਜਾਣ ਤੋਂ ਪਹਿਲਾਂ, ਵਾਤਾਵਰਣ ਦੀਆਂ ਸੰਰਚਨਾਵਾਂ ਦੇ ਮਹੱਤਵਪੂਰਨ ਪਹਿਲੂਆਂ ਦਾ ਵਰਣਨ ਕਰਨਾ ਜ਼ਰੂਰੀ ਹੈ। ਤੱਥ ਇਹ ਹੈ ਕਿ ਸੀਐਸ ਨੂੰ ਇੱਕ ਮੋਡ ਵਿੱਚ ਵਰਤਿਆ ਜਾ ਸਕਦਾ ਹੈ ਜੋ ਡੇਟਾ ਦੇ ਨੁਕਸਾਨ ਦੀ ਆਗਿਆ ਦਿੰਦਾ ਹੈ. ਉਹ. ਇਹ ਉਦੋਂ ਹੁੰਦਾ ਹੈ ਜਦੋਂ ਕਿਸੇ ਖਾਸ ਕੁੰਜੀ ਦੇ ਡੇਟਾ ਲਈ ਸਿਰਫ ਇੱਕ ਸਰਵਰ (ਨੋਡ) ਜ਼ਿੰਮੇਵਾਰ ਹੁੰਦਾ ਹੈ, ਅਤੇ ਜੇਕਰ ਕਿਸੇ ਕਾਰਨ ਕਰਕੇ ਇਹ ਅਸਫਲ ਹੋ ਜਾਂਦਾ ਹੈ, ਤਾਂ ਇਸ ਕੁੰਜੀ ਦਾ ਮੁੱਲ ਖਤਮ ਹੋ ਜਾਵੇਗਾ। ਬਹੁਤ ਸਾਰੇ ਕੰਮਾਂ ਲਈ ਇਹ ਨਾਜ਼ੁਕ ਨਹੀਂ ਹੈ, ਪਰ ਬੈਂਕਿੰਗ ਸੈਕਟਰ ਲਈ ਇਹ ਨਿਯਮ ਦੀ ਬਜਾਏ ਅਪਵਾਦ ਹੈ। ਸਾਡੇ ਕੇਸ ਵਿੱਚ, ਭਰੋਸੇਯੋਗ ਸਟੋਰੇਜ ਲਈ ਡੇਟਾ ਦੀਆਂ ਕਈ ਕਾਪੀਆਂ ਦਾ ਹੋਣਾ ਮਹੱਤਵਪੂਰਨ ਹੈ।

ਇਸ ਲਈ, ਟ੍ਰਿਪਲ ਰੀਪਲੀਕੇਸ਼ਨ ਮੋਡ ਵਿੱਚ ਸਿਰਫ CS ਓਪਰੇਟਿੰਗ ਮੋਡ ਨੂੰ ਮੰਨਿਆ ਗਿਆ ਸੀ, ਯਾਨੀ. ਕੇਸਸਪੇਸ ਦੀ ਸਿਰਜਣਾ ਹੇਠਲੇ ਪੈਰਾਮੀਟਰਾਂ ਨਾਲ ਕੀਤੀ ਗਈ ਸੀ:

CREATE KEYSPACE ks WITH REPLICATION = {'class' : 'NetworkTopologyStrategy', 'datacenter1' : 3};

ਅੱਗੇ, ਇਕਸਾਰਤਾ ਦੇ ਲੋੜੀਂਦੇ ਪੱਧਰ ਨੂੰ ਯਕੀਨੀ ਬਣਾਉਣ ਦੇ ਦੋ ਤਰੀਕੇ ਹਨ. ਆਮ ਨਿਯਮ:
NW + NR > RF

ਜਿਸਦਾ ਮਤਲਬ ਹੈ ਕਿ (NW) ਲਿਖਣ ਵੇਲੇ ਨੋਡਾਂ ਤੋਂ ਪੁਸ਼ਟੀਕਰਨ ਦੀ ਸੰਖਿਆ ਅਤੇ (NR) ਨੂੰ ਪੜ੍ਹਦੇ ਸਮੇਂ ਨੋਡਾਂ ਤੋਂ ਪੁਸ਼ਟੀਕਰਨਾਂ ਦੀ ਗਿਣਤੀ ਪ੍ਰਤੀਕ੍ਰਿਤੀ ਕਾਰਕ ਤੋਂ ਵੱਧ ਹੋਣੀ ਚਾਹੀਦੀ ਹੈ। ਸਾਡੇ ਕੇਸ ਵਿੱਚ, RF = 3, ਜਿਸਦਾ ਮਤਲਬ ਹੈ ਕਿ ਹੇਠਾਂ ਦਿੱਤੇ ਵਿਕਲਪ ਢੁਕਵੇਂ ਹਨ:
2 + 2 > 3
3 + 1 > 3

ਕਿਉਂਕਿ ਸਾਡੇ ਲਈ ਡਾਟਾ ਨੂੰ ਜਿੰਨਾ ਸੰਭਵ ਹੋ ਸਕੇ ਭਰੋਸੇਯੋਗ ਢੰਗ ਨਾਲ ਸਟੋਰ ਕਰਨਾ ਬੁਨਿਆਦੀ ਤੌਰ 'ਤੇ ਮਹੱਤਵਪੂਰਨ ਹੈ, 3+1 ਸਕੀਮ ਚੁਣੀ ਗਈ ਸੀ। ਇਸਦੇ ਇਲਾਵਾ, HB ਇੱਕ ਸਮਾਨ ਸਿਧਾਂਤ 'ਤੇ ਕੰਮ ਕਰਦਾ ਹੈ, i.e. ਅਜਿਹੀ ਤੁਲਨਾ ਵਧੇਰੇ ਨਿਰਪੱਖ ਹੋਵੇਗੀ।

ਇਹ ਨੋਟ ਕੀਤਾ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ ਕਿ DataStax ਨੇ ਆਪਣੇ ਅਧਿਐਨ ਵਿੱਚ ਉਲਟ ਕੀਤਾ, ਉਹਨਾਂ ਨੇ CS ਅਤੇ HB ਦੋਵਾਂ ਲਈ RF = 1 ਸੈੱਟ ਕੀਤਾ (ਬਾਅਦ ਵਿੱਚ HDFS ਸੈਟਿੰਗਾਂ ਨੂੰ ਬਦਲ ਕੇ)। ਇਹ ਇੱਕ ਸੱਚਮੁੱਚ ਮਹੱਤਵਪੂਰਨ ਪਹਿਲੂ ਹੈ ਕਿਉਂਕਿ ਇਸ ਕੇਸ ਵਿੱਚ CS ਪ੍ਰਦਰਸ਼ਨ 'ਤੇ ਪ੍ਰਭਾਵ ਬਹੁਤ ਵੱਡਾ ਹੈ। ਉਦਾਹਰਨ ਲਈ, ਹੇਠਾਂ ਦਿੱਤੀ ਤਸਵੀਰ CS ਵਿੱਚ ਡੇਟਾ ਲੋਡ ਕਰਨ ਲਈ ਲੋੜੀਂਦੇ ਸਮੇਂ ਵਿੱਚ ਵਾਧਾ ਦਰਸਾਉਂਦੀ ਹੈ:

ਇੱਥੇ ਅਸੀਂ ਹੇਠ ਲਿਖਿਆਂ ਨੂੰ ਦੇਖਦੇ ਹਾਂ: ਜਿੰਨੇ ਜ਼ਿਆਦਾ ਮੁਕਾਬਲੇ ਵਾਲੇ ਥ੍ਰੈੱਡ ਡੇਟਾ ਲਿਖਦੇ ਹਨ, ਓਨਾ ਹੀ ਸਮਾਂ ਲੱਗਦਾ ਹੈ। ਇਹ ਕੁਦਰਤੀ ਹੈ, ਪਰ ਇਹ ਮਹੱਤਵਪੂਰਨ ਹੈ ਕਿ RF=3 ਲਈ ਕਾਰਗੁਜ਼ਾਰੀ ਵਿੱਚ ਗਿਰਾਵਟ ਕਾਫ਼ੀ ਜ਼ਿਆਦਾ ਹੈ। ਦੂਜੇ ਸ਼ਬਦਾਂ ਵਿੱਚ, ਜੇਕਰ ਅਸੀਂ 4 ਥ੍ਰੈਡਾਂ ਨੂੰ 5 ਟੇਬਲਾਂ ਵਿੱਚ ਲਿਖਦੇ ਹਾਂ (ਕੁੱਲ ਮਿਲਾ ਕੇ 20), ਤਾਂ RF=3 ਲਗਭਗ 2 ਗੁਣਾ ਹਾਰ ਜਾਂਦਾ ਹੈ (RF=150 ਲਈ 3 ਸਕਿੰਟ ਬਨਾਮ RF=75 ਲਈ 1)। ਪਰ ਜੇਕਰ ਅਸੀਂ 8 ਥਰਿੱਡਾਂ (ਕੁੱਲ 5) ਨਾਲ 40 ਟੇਬਲਾਂ ਵਿੱਚ ਡਾਟਾ ਲੋਡ ਕਰਕੇ ਲੋਡ ਨੂੰ ਵਧਾਉਂਦੇ ਹਾਂ, ਤਾਂ RF=3 ਦਾ ਨੁਕਸਾਨ ਪਹਿਲਾਂ ਹੀ 2,7 ਗੁਣਾ (375 ਸਕਿੰਟ ਬਨਾਮ 138) ਹੈ।

ਸ਼ਾਇਦ ਇਹ ਅੰਸ਼ਕ ਤੌਰ 'ਤੇ CS ਲਈ DataStax ਦੁਆਰਾ ਕੀਤੇ ਗਏ ਸਫਲ ਲੋਡ ਟੈਸਟਿੰਗ ਦਾ ਰਾਜ਼ ਹੈ, ਕਿਉਂਕਿ HB ਲਈ ਸਾਡੇ ਸਟੈਂਡ 'ਤੇ ਪ੍ਰਤੀਕ੍ਰਿਤੀ ਫੈਕਟਰ ਨੂੰ 2 ਤੋਂ 3 ਤੱਕ ਬਦਲਣ ਦਾ ਕੋਈ ਅਸਰ ਨਹੀਂ ਹੋਇਆ। ਉਹ. ਡਿਸਕ ਸਾਡੀ ਸੰਰਚਨਾ ਲਈ HB ਰੁਕਾਵਟ ਨਹੀਂ ਹਨ। ਹਾਲਾਂਕਿ, ਇੱਥੇ ਬਹੁਤ ਸਾਰੀਆਂ ਹੋਰ ਕਮੀਆਂ ਹਨ, ਕਿਉਂਕਿ ਇਹ ਨੋਟ ਕੀਤਾ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ ਕਿ ਐਚਬੀ ਦਾ ਸਾਡਾ ਸੰਸਕਰਣ ਥੋੜ੍ਹਾ ਜਿਹਾ ਪੈਚ ਅਤੇ ਟਵੀਕ ਕੀਤਾ ਗਿਆ ਸੀ, ਵਾਤਾਵਰਣ ਪੂਰੀ ਤਰ੍ਹਾਂ ਵੱਖਰਾ ਹੈ, ਆਦਿ. ਇਹ ਵੀ ਧਿਆਨ ਦੇਣ ਯੋਗ ਹੈ ਕਿ ਹੋ ਸਕਦਾ ਹੈ ਕਿ ਮੈਨੂੰ ਇਹ ਨਹੀਂ ਪਤਾ ਕਿ CS ਨੂੰ ਸਹੀ ਢੰਗ ਨਾਲ ਕਿਵੇਂ ਤਿਆਰ ਕਰਨਾ ਹੈ ਅਤੇ ਇਸਦੇ ਨਾਲ ਕੰਮ ਕਰਨ ਦੇ ਕੁਝ ਹੋਰ ਪ੍ਰਭਾਵਸ਼ਾਲੀ ਤਰੀਕੇ ਹਨ, ਅਤੇ ਮੈਨੂੰ ਉਮੀਦ ਹੈ ਕਿ ਅਸੀਂ ਟਿੱਪਣੀਆਂ ਵਿੱਚ ਲੱਭ ਲਵਾਂਗੇ। ਪਰ ਸਭ ਤੋਂ ਪਹਿਲਾਂ ਪਹਿਲੀਆਂ ਚੀਜ਼ਾਂ.

ਸਾਰੇ ਟੈਸਟ ਇੱਕ ਹਾਰਡਵੇਅਰ ਕਲੱਸਟਰ 'ਤੇ ਕੀਤੇ ਗਏ ਸਨ ਜਿਸ ਵਿੱਚ 4 ਸਰਵਰ ਸ਼ਾਮਲ ਸਨ, ਹਰ ਇੱਕ ਹੇਠ ਦਿੱਤੀ ਸੰਰਚਨਾ ਨਾਲ:

CPU: Xeon E5-2680 v4 @ 2.40GHz 64 ਥ੍ਰੈੱਡਸ।
ਡਿਸਕ: 12 ਟੁਕੜੇ SATA HDD
java ਸੰਸਕਰਣ: 1.8.0_111

CS ਸੰਸਕਰਣ: 3.11.5

cassandra.yml ਪੈਰਾਮੀਟਰnum_tokens: 256
hinted_handoff_enabled: ਸਹੀ
hinted_handoff_throttle_in_kb: 1024
ਅਧਿਕਤਮ_ਸੰਕੇਤ_ਡਿਲੀਵਰੀ_ਥ੍ਰੈੱਡਸ: 2
hints_directory: /data10/cassandra/hints
hints_flush_period_in_ms: 10000
max_hints_file_size_in_mb: 128
batchlog_replay_throttle_in_kb: 1024
ਪ੍ਰਮਾਣਿਕਤਾ: AllowAllAuthenticator
ਅਧਿਕਾਰਕ: AllowAllAuthorizer
ਰੋਲ_ਮੈਨੇਜਰ: ਕੈਸੈਂਡਰਾਰੋਲਮੈਨੇਜਰ
ਭੂਮਿਕਾਵਾਂ_ਵੈਧਤਾ_ਵਿੱਚ_ਐਮਐਸ: 2000
permissions_validity_in_ms: 2000
credentials_validity_in_ms: 2000
ਪਾਰਟੀਸ਼ਨਰ: org.apache.cassandra.dht.Murmur3Partitioner
data_file_directories:
- /data1/cassandra/data # ਹਰੇਕ dataN ਡਾਇਰੈਕਟਰੀ ਇੱਕ ਵੱਖਰੀ ਡਿਸਕ ਹੈ
- /data2/cassandra/data
- /data3/cassandra/data
- /data4/cassandra/data
- /data5/cassandra/data
- /data6/cassandra/data
- /data7/cassandra/data
- /data8/cassandra/data
commitlog_directory: /data9/cassandra/commitlog
cdc_enabled: ਗਲਤ
disk_failure_policy: ਰੋਕੋ
Commit_failure_policy: ਰੋਕੋ
ਤਿਆਰ_ਸਟੇਟਮੈਂਟਸ_ਕੈਸ਼_ਸਾਈਜ਼_mb:
thrift_prepared_statements_cache_size_mb:
key_cache_size_in_mb:
key_cache_save_period: 14400
row_cache_size_in_mb: 0
row_cache_save_period: 0
counter_cache_size_in_mb:
counter_cache_save_period: 7200
saved_caches_directory: /data10/cassandra/saved_caches
commitlog_sync: ਆਵਰਤੀ
commitlog_sync_period_in_ms: 10000
Commitlog_segment_size_in_mb: 32
ਬੀਜ_ਪ੍ਰਦਾਤਾ:
- class_name: org.apache.cassandra.locator.SimpleSeedProvider
ਮਾਪਦੰਡ:
- ਬੀਜ: "*, *"
concurrent_reads: 256 # 64 ਦੀ ਕੋਸ਼ਿਸ਼ ਕੀਤੀ - ਕੋਈ ਫਰਕ ਨਹੀਂ ਦੇਖਿਆ ਗਿਆ
concurrent_writes: 256 # 64 ਦੀ ਕੋਸ਼ਿਸ਼ ਕੀਤੀ - ਕੋਈ ਫਰਕ ਨਹੀਂ ਦੇਖਿਆ ਗਿਆ
concurrent_counter_writes: 256 # 64 ਦੀ ਕੋਸ਼ਿਸ਼ ਕੀਤੀ - ਕੋਈ ਫਰਕ ਨਹੀਂ ਦੇਖਿਆ ਗਿਆ
ਸਮਕਾਲੀ_ਮਟੀਰੀਅਲਾਈਜ਼ਡ_ਵਿਊ_ਰਾਈਟਸ: 32
memtable_heap_space_in_mb: 2048 # ਨੇ 16 GB ਦੀ ਕੋਸ਼ਿਸ਼ ਕੀਤੀ - ਇਹ ਹੌਲੀ ਸੀ
memtable_allocation_type: heap_buffers
index_summary_capacity_in_mb:
index_summary_resize_interval_in_minutes: 60
trickle_fsync: ਗਲਤ
trickle_fsync_interval_in_kb: 10240
ਸਟੋਰੇਜ_ਪੋਰਟ: 7000
ssl_storage_port: 7001
ਸੁਣੋ_ਪਤਾ: *
ਪ੍ਰਸਾਰਣ_ਪਤਾ: *
ਸੁਣੋ_ਤੇ_ਪ੍ਰਸਾਰਣ_ਪਤਾ: ਸਹੀ
internode_authenticator: org.apache.cassandra.auth.AllowAllInternodeAuthenticator
start_native_transport: ਸਹੀ
ਮੂਲ_ਟਰਾਂਸਪੋਰਟ_ਪੋਰਟ: 9042
start_rpc: ਸਹੀ
rpc_address: *
rpc_port: 9160
rpc_keepalive: ਸਹੀ
rpc_server_type: ਸਿੰਕ
thrift_framed_transport_size_in_mb: 15
incremental_backups: ਗਲਤ
snapshot_before_compaction: ਗਲਤ
auto_snapshot: ਸਹੀ
column_index_size_in_kb: 64
column_index_cache_size_in_kb: 2
ਸਮਕਾਲੀ_ਕੰਪੈਕਟਰ: 4
ਕੰਪੈਕਸ਼ਨ_ਥਰੂਪੁਟ_mb_per_sec: 1600
sstable_preemptive_open_interval_in_mb: 50
read_request_timeout_in_ms: 100000
range_request_timeout_in_ms: 200000
write_request_timeout_in_ms: 40000
counter_write_request_timeout_in_ms: 100000
cas_contention_timeout_in_ms: 20000
truncate_request_timeout_in_ms: 60000
request_timeout_in_ms: 200000
slow_query_log_timeout_in_ms: 500
cross_node_timeout: ਗਲਤ
endpoint_snitch: GossipingPropertyFileSnitch
dynamic_snitch_update_interval_in_ms: 100
dynamic_snitch_reset_interval_in_ms: 600000
dynamic_snitch_badness_threshold: 0.1
request_scheduler: org.apache.cassandra.scheduler.NoScheduler
ਸਰਵਰ_ਇਨਕ੍ਰਿਪਸ਼ਨ_ਵਿਕਲਪਾਂ:
ਇੰਟਰਨੋਡ_ਇਨਕ੍ਰਿਪਸ਼ਨ: ਕੋਈ ਨਹੀਂ
client_encryption_options:
ਸਮਰਥਿਤ: ਗਲਤ
internode_compression: dc
inter_dc_tcp_nodelay: ਗਲਤ
tracetype_query_ttl: 86400
tracetype_repair_ttl: 604800
enable_user_defined_functions: ਗਲਤ
enable_scripted_user_defined_functions: ਗਲਤ
windows_timer_interval: 1
transparent_data_encryption_options:
ਸਮਰਥਿਤ: ਗਲਤ
ਕਬਰ ਦਾ ਪੱਥਰ_ਵਾਰਨ_ਥ੍ਰੈਸ਼ਹੋਲਡ: 1000
ਟੋਮਬਸਟੋਨ_ਫੇਲਿਉਰ_ਥ੍ਰੈਸ਼ਹੋਲਡ: 100000
batch_size_warn_threshold_in_kb: 200
batch_size_fail_threshold_in_kb: 250
unlogged_batch_across_partitions_warn_threshold: 10
compaction_large_partition_warning_threshold_mb: 100
gc_warn_threshold_in_ms: 1000
back_pressure_enabled: ਗਲਤ
enable_materialized_views: ਸਹੀ
enable_sasi_indexes: ਸਹੀ

GC ਸੈਟਿੰਗਾਂ:

### CMS ਸੈਟਿੰਗਾਂ-XX:+UseParNewGC
-XX:+ConcMarkSweepGC ਦੀ ਵਰਤੋਂ ਕਰੋ
-XX:+CMSparallelRemark ਯੋਗ
-XX: ਸਰਵਾਈਵਰ ਅਨੁਪਾਤ = 8
-XX:MaxTenuringThreshold=1
-XX:CMSIinitiating OccupancyFraction=75
-XX:+UseCMSIਸ਼ੁਰੂਆਤ ਸਿਰਫ਼ ਆਕੂਪੈਂਸੀ
-XX:CMS WaitDuration=10000
-XX:+CMSparallelInitialMarkEnabled
-XX:+CMSEdenChunksRecordAlways
-XX:+CMSC ਕਲਾਸ ਅਨਲੋਡਿੰਗ ਯੋਗ

jvm.options ਮੈਮੋਰੀ 16Gb ਨਿਰਧਾਰਤ ਕੀਤੀ ਗਈ ਸੀ (ਅਸੀਂ ਵੀ 32 Gb ਦੀ ਕੋਸ਼ਿਸ਼ ਕੀਤੀ, ਕੋਈ ਫਰਕ ਨਹੀਂ ਦੇਖਿਆ ਗਿਆ)।

ਟੇਬਲ ਕਮਾਂਡ ਨਾਲ ਬਣਾਏ ਗਏ ਸਨ:

CREATE TABLE ks.t1 (id bigint PRIMARY KEY, title text) WITH compression = {'sstable_compression': 'LZ4Compressor', 'chunk_length_kb': 64};

HB ਸੰਸਕਰਣ: 1.2.0-cdh5.14.2 (ਕਲਾਸ org.apache.hadoop.hbase.regionserver.HRegion ਵਿੱਚ ਅਸੀਂ MetricsRegion ਨੂੰ ਬਾਹਰ ਰੱਖਿਆ ਜਿਸ ਨਾਲ GC ਹੋ ਗਿਆ ਜਦੋਂ RegionServer 'ਤੇ ਖੇਤਰਾਂ ਦੀ ਗਿਣਤੀ 1000 ਤੋਂ ਵੱਧ ਸੀ)

ਗੈਰ-ਡਿਫੌਲਟ HBase ਪੈਰਾਮੀਟਰzookeeper.session.timeout: 120000
hbase.rpc.timeout: 2 ਮਿੰਟ
hbase.client.scanner.timeout.period: 2 ਮਿੰਟ
hbase.master.handler.count: 10
hbase.regionserver.lease.period, hbase.client.scanner.timeout.period: 2 ਮਿੰਟ
hbase.regionserver.handler.count: 160
hbase.regionserver.metahandler.count: 30
hbase.regionserver.logroll.period: 4 ਘੰਟੇ
hbase.regionserver.maxlogs: 200
hbase.hregion.memstore.flush.size: 1 GiB
hbase.hregion.memstore.block.multiplier: 6
hbase.hstore.compactionThreshold: 5
hbase.hstore.blockingStoreFiles: 200
hbase.hregion.majorcompaction: 1 ਦਿਨ
hbase-site.xml ਲਈ HBase ਸਰਵਿਸ ਐਡਵਾਂਸਡ ਕੌਂਫਿਗਰੇਸ਼ਨ ਸਨਿੱਪਟ (ਸੇਫਟੀ ਵਾਲਵ):
hbase.regionserver.wal.codecorg.apache.hadoop.hbase.regionserver.wal.IndexedWALEditCodec
hbase.master.namespace.init.timeout3600000
hbase.regionserver.optionalcacheflushinterval18000000
hbase.regionserver.thread.compaction.large12
hbase.regionserver.wal.enablecompressiontrue
hbase.hstore.compaction.max.size1073741824
hbase.server.compactchecker.interval.multiplier200
HBase RegionServer ਲਈ ਜਾਵਾ ਸੰਰਚਨਾ ਵਿਕਲਪ:
-XX:+UseParNewGC -XX:+UseConcMarkSweepGC -XX:CMSIinitiatingOccupancyFraction=70 -XX:+CMSParallelRemarkEnabled -XX:ReservedCodeCacheSize=256m
hbase.snapshot.master.timeoutMillis: 2 ਮਿੰਟ
hbase.snapshot.region.timeout: 2 ਮਿੰਟ
hbase.snapshot.master.timeout.millis: 2 ਮਿੰਟ
HBase REST ਸਰਵਰ ਅਧਿਕਤਮ ਲਾਗ ਆਕਾਰ: 100 MiB
HBase REST ਸਰਵਰ ਅਧਿਕਤਮ ਲੌਗ ਫਾਈਲ ਬੈਕਅਪ: 5
HBase ਥ੍ਰੀਫਟ ਸਰਵਰ ਅਧਿਕਤਮ ਲਾਗ ਆਕਾਰ: 100 MiB
HBase ਥ੍ਰੀਫਟ ਸਰਵਰ ਅਧਿਕਤਮ ਲੌਗ ਫਾਈਲ ਬੈਕਅਪ: 5
ਮਾਸਟਰ ਮੈਕਸ ਲੌਗ ਸਾਈਜ਼: 100 MiB
ਮਾਸਟਰ ਅਧਿਕਤਮ ਲੌਗ ਫਾਈਲ ਬੈਕਅਪ: 5
ਰੀਜਨਸਰਵਰ ਅਧਿਕਤਮ ਲਾਗ ਆਕਾਰ: 100 MiB
ਰੀਜਨਸਰਵਰ ਅਧਿਕਤਮ ਲੌਗ ਫਾਈਲ ਬੈਕਅਪ: 5
HBase ਐਕਟਿਵ ਮਾਸਟਰ ਡਿਟੈਕਸ਼ਨ ਵਿੰਡੋ: 4 ਮਿੰਟ
dfs.client.hedged.read.threadpool.size: 40
dfs.client.hedged.read.threshold.millis: 10 ਮਿਲੀਸਕਿੰਡ(s)
hbase.rest.threads.min: 8
hbase.rest.threads.max: 150
ਅਧਿਕਤਮ ਪ੍ਰਕਿਰਿਆ ਫਾਈਲ ਵਰਣਨਕਰਤਾ: 180000
hbase.thrift.minWorkerThreads: 200
hbase.master.executor.openregion.threads: 30
hbase.master.executor.closeregion.threads: 30
hbase.master.executor.serverops.threads: 60
hbase.regionserver.thread.compaction.small: 6
hbase.ipc.server.read.threadpool.size: 20
ਰੀਜਨ ਮੂਵਰ ਥ੍ਰੈਡਸ: 6
ਬਾਈਟਸ ਵਿੱਚ ਕਲਾਇੰਟ ਜਾਵਾ ਹੀਪ ਦਾ ਆਕਾਰ: 1 GiB
HBase REST ਸਰਵਰ ਡਿਫੌਲਟ ਸਮੂਹ: 3 GiB
HBase ਥ੍ਰੀਫਟ ਸਰਵਰ ਡਿਫੌਲਟ ਸਮੂਹ: 3 GiB
ਬਾਈਟਸ ਵਿੱਚ HBase ਮਾਸਟਰ ਦਾ Java ਹੀਪ ਸਾਈਜ਼: 16 GiB
ਬਾਈਟਸ ਵਿੱਚ HBase RegionServer ਦਾ Java ਹੀਪ ਆਕਾਰ: 32 GiB

+ਜ਼ੂਕੀਪਰ
maxClientCnxns: 601
ਅਧਿਕਤਮ ਸੈਸ਼ਨ ਟਾਈਮਆਊਟ: 120000
ਟੇਬਲ ਬਣਾਉਣਾ:
hbase org.apache.hadoop.hbase.util.RegionSplitter ns:t1 UniformSplit -c 64 -f cf
alter 'ns:t1', {NAME => 'cf', DATA_BLOCK_ENCODING => 'FAST_DIFF', COMPRESSION => 'GZ'}

ਇੱਥੇ ਇੱਕ ਮਹੱਤਵਪੂਰਨ ਨੁਕਤਾ ਹੈ - DataStax ਵਰਣਨ ਇਹ ​​ਨਹੀਂ ਦੱਸਦਾ ਹੈ ਕਿ HB ਟੇਬਲ ਬਣਾਉਣ ਲਈ ਕਿੰਨੇ ਖੇਤਰਾਂ ਦੀ ਵਰਤੋਂ ਕੀਤੀ ਗਈ ਸੀ, ਹਾਲਾਂਕਿ ਇਹ ਵੱਡੀ ਮਾਤਰਾ ਲਈ ਮਹੱਤਵਪੂਰਨ ਹੈ। ਇਸ ਲਈ, ਟੈਸਟਾਂ ਲਈ, ਮਾਤਰਾ = 64 ਚੁਣਿਆ ਗਿਆ ਸੀ, ਜੋ ਕਿ 640 GB ਤੱਕ ਸਟੋਰ ਕਰਨ ਦੀ ਇਜਾਜ਼ਤ ਦਿੰਦਾ ਹੈ, ਯਾਨੀ. ਮੱਧਮ ਆਕਾਰ ਦੀ ਸਾਰਣੀ.

ਟੈਸਟ ਦੇ ਸਮੇਂ, HBase ਕੋਲ 22 ਹਜ਼ਾਰ ਟੇਬਲ ਅਤੇ 67 ਹਜ਼ਾਰ ਖੇਤਰ ਸਨ (ਇਹ ਵਰਜਨ 1.2.0 ਲਈ ਘਾਤਕ ਹੋਣਾ ਸੀ ਜੇਕਰ ਉੱਪਰ ਦੱਸੇ ਗਏ ਪੈਚ ਲਈ ਨਹੀਂ)।

ਹੁਣ ਕੋਡ ਲਈ. ਕਿਉਂਕਿ ਇਹ ਸਪੱਸ਼ਟ ਨਹੀਂ ਸੀ ਕਿ ਕਿਸੇ ਖਾਸ ਡੇਟਾਬੇਸ ਲਈ ਕਿਹੜੀਆਂ ਸੰਰਚਨਾਵਾਂ ਵਧੇਰੇ ਫਾਇਦੇਮੰਦ ਸਨ, ਇਸ ਲਈ ਟੈਸਟ ਵੱਖ-ਵੱਖ ਸੰਜੋਗਾਂ ਵਿੱਚ ਕੀਤੇ ਗਏ ਸਨ। ਉਹ. ਕੁਝ ਟੈਸਟਾਂ ਵਿੱਚ, 4 ਟੇਬਲ ਇੱਕੋ ਸਮੇਂ ਲੋਡ ਕੀਤੇ ਗਏ ਸਨ (ਸਾਰੇ 4 ਨੋਡ ਕੁਨੈਕਸ਼ਨ ਲਈ ਵਰਤੇ ਗਏ ਸਨ)। ਹੋਰ ਟੈਸਟਾਂ ਵਿੱਚ ਅਸੀਂ 8 ਵੱਖ-ਵੱਖ ਟੇਬਲਾਂ ਨਾਲ ਕੰਮ ਕੀਤਾ। ਕੁਝ ਮਾਮਲਿਆਂ ਵਿੱਚ, ਬੈਚ ਦਾ ਆਕਾਰ 100 ਸੀ, ਦੂਜਿਆਂ ਵਿੱਚ 200 (ਬੈਚ ਪੈਰਾਮੀਟਰ - ਹੇਠਾਂ ਕੋਡ ਦੇਖੋ)। ਮੁੱਲ ਲਈ ਡੇਟਾ ਦਾ ਆਕਾਰ 10 ਬਾਈਟ ਜਾਂ 100 ਬਾਈਟ (ਡਾਟਾ ਆਕਾਰ) ਹੈ। ਕੁੱਲ ਮਿਲਾ ਕੇ, ਹਰ ਵਾਰ ਹਰੇਕ ਸਾਰਣੀ ਵਿੱਚ 5 ਮਿਲੀਅਨ ਰਿਕਾਰਡ ਲਿਖੇ ਅਤੇ ਪੜ੍ਹੇ ਗਏ ਸਨ। ਉਸੇ ਸਮੇਂ, ਹਰੇਕ ਸਾਰਣੀ ਵਿੱਚ 5 ਥ੍ਰੈੱਡ ਲਿਖੇ/ਪੜ੍ਹੇ ਗਏ ਸਨ (ਥ੍ਰੈੱਡ ਨੰਬਰ - thNum), ਜਿਨ੍ਹਾਂ ਵਿੱਚੋਂ ਹਰੇਕ ਨੇ ਆਪਣੀਆਂ ਕੁੰਜੀਆਂ ਦੀ ਆਪਣੀ ਰੇਂਜ ਦੀ ਵਰਤੋਂ ਕੀਤੀ (ਗਿਣਤੀ = 1 ਮਿਲੀਅਨ):

if (opType.equals("insert")) {
    for (Long key = count * thNum; key < count * (thNum + 1); key += 0) {
        StringBuilder sb = new StringBuilder("BEGIN BATCH ");
        for (int i = 0; i < batch; i++) {
            String value = RandomStringUtils.random(dataSize, true, true);
            sb.append("INSERT INTO ")
                    .append(tableName)
                    .append("(id, title) ")
                    .append("VALUES (")
                    .append(key)
                    .append(", '")
                    .append(value)
                    .append("');");
            key++;
        }
        sb.append("APPLY BATCH;");
        final String query = sb.toString();
        session.execute(query);
    }
} else {
    for (Long key = count * thNum; key < count * (thNum + 1); key += 0) {
        StringBuilder sb = new StringBuilder("SELECT * FROM ").append(tableName).append(" WHERE id IN (");
        for (int i = 0; i < batch; i++) {
            sb = sb.append(key);
            if (i+1 < batch)
                sb.append(",");
            key++;
        }
        sb = sb.append(");");
        final String query = sb.toString();
        ResultSet rs = session.execute(query);
    }
}

ਇਸ ਅਨੁਸਾਰ, HB ਲਈ ਸਮਾਨ ਕਾਰਜਕੁਸ਼ਲਤਾ ਪ੍ਰਦਾਨ ਕੀਤੀ ਗਈ ਸੀ:

Configuration conf = getConf();
HTable table = new HTable(conf, keyspace + ":" + tableName);
table.setAutoFlush(false, false);
List<Get> lGet = new ArrayList<>();
List<Put> lPut = new ArrayList<>();
byte[] cf = Bytes.toBytes("cf");
byte[] qf = Bytes.toBytes("value");
if (opType.equals("insert")) {
    for (Long key = count * thNum; key < count * (thNum + 1); key += 0) {
        lPut.clear();
        for (int i = 0; i < batch; i++) {
            Put p = new Put(makeHbaseRowKey(key));
            String value = RandomStringUtils.random(dataSize, true, true);
            p.addColumn(cf, qf, value.getBytes());
            lPut.add(p);
            key++;
        }
        table.put(lPut);
        table.flushCommits();
    }
} else {
    for (Long key = count * thNum; key < count * (thNum + 1); key += 0) {
        lGet.clear();
        for (int i = 0; i < batch; i++) {
            Get g = new Get(makeHbaseRowKey(key));
            lGet.add(g);
            key++;
        }
        Result[] rs = table.get(lGet);
    }
}

ਕਿਉਂਕਿ HB ਵਿੱਚ ਕਲਾਇੰਟ ਨੂੰ ਡੇਟਾ ਦੀ ਇੱਕਸਾਰ ਵੰਡ ਦਾ ਧਿਆਨ ਰੱਖਣਾ ਚਾਹੀਦਾ ਹੈ, ਕੁੰਜੀ ਸਲਟਿੰਗ ਫੰਕਸ਼ਨ ਇਸ ਤਰ੍ਹਾਂ ਦਿਖਾਈ ਦਿੰਦਾ ਹੈ:

public static byte[] makeHbaseRowKey(long key) {
    byte[] nonSaltedRowKey = Bytes.toBytes(key);
    CRC32 crc32 = new CRC32();
    crc32.update(nonSaltedRowKey);
    long crc32Value = crc32.getValue();
    byte[] salt = Arrays.copyOfRange(Bytes.toBytes(crc32Value), 5, 7);
    return ArrayUtils.addAll(salt, nonSaltedRowKey);
}

ਹੁਣ ਸਭ ਤੋਂ ਦਿਲਚਸਪ ਹਿੱਸਾ - ਨਤੀਜੇ:

ਗ੍ਰਾਫ ਦੇ ਰੂਪ ਵਿੱਚ ਇੱਕੋ ਚੀਜ਼:

HB ਦਾ ਫਾਇਦਾ ਇੰਨਾ ਹੈਰਾਨੀਜਨਕ ਹੈ ਕਿ ਇੱਕ ਸ਼ੱਕ ਹੈ ਕਿ CS ਸੈੱਟਅੱਪ ਵਿੱਚ ਕਿਸੇ ਕਿਸਮ ਦੀ ਰੁਕਾਵਟ ਹੈ। ਹਾਲਾਂਕਿ, ਗੂਗਲਿੰਗ ਅਤੇ ਸਭ ਤੋਂ ਸਪੱਸ਼ਟ ਮਾਪਦੰਡਾਂ ਦੀ ਖੋਜ (ਜਿਵੇਂ ਕਿ ਸਮਕਾਲੀ_ਰਾਈਟਸ ਜਾਂ ਮੈਮਟੇਬਲ_ਹੀਪ_ਸਪੇਸ_ਇਨ_mb) ਨੇ ਚੀਜ਼ਾਂ ਨੂੰ ਤੇਜ਼ ਨਹੀਂ ਕੀਤਾ। ਉਸੇ ਸਮੇਂ, ਲੌਗ ਸਾਫ਼ ਹਨ ਅਤੇ ਕਿਸੇ ਵੀ ਚੀਜ਼ 'ਤੇ ਸਹੁੰ ਨਹੀਂ ਖਾਂਦੇ.

ਡੇਟਾ ਨੂੰ ਨੋਡਾਂ ਵਿੱਚ ਸਮਾਨ ਰੂਪ ਵਿੱਚ ਵੰਡਿਆ ਗਿਆ ਸੀ, ਸਾਰੇ ਨੋਡਾਂ ਦੇ ਅੰਕੜੇ ਲਗਭਗ ਇੱਕੋ ਜਿਹੇ ਸਨ।

ਇਹ ਉਹ ਹੈ ਜੋ ਸਾਰਣੀ ਦੇ ਅੰਕੜੇ ਨੋਡਾਂ ਵਿੱਚੋਂ ਇੱਕ ਤੋਂ ਦਿਖਾਈ ਦਿੰਦੇ ਹਨਕੀ-ਸਪੇਸ: ks
ਪੜ੍ਹੋ ਗਿਣਤੀ: 9383707
ਲੇਟੈਂਸੀ ਪੜ੍ਹੋ: 0.04287025042448576 ms
ਗਿਣਤੀ ਲਿਖੋ: 15462012
ਲੇਟੈਂਸੀ ਲਿਖੋ: 0.1350068438699957 ms
ਬਕਾਇਆ ਫਲੱਸ਼: 0
ਸਾਰਣੀ: t1
SSTable ਗਿਣਤੀ: 16
ਵਰਤੀ ਗਈ ਸਪੇਸ (ਲਾਈਵ): 148.59 MiB
ਵਰਤੀ ਗਈ ਸਪੇਸ (ਕੁੱਲ): 148.59 MiB
ਸਨੈਪਸ਼ਾਟ ਦੁਆਰਾ ਵਰਤੀ ਗਈ ਸਪੇਸ (ਕੁੱਲ): 0 ਬਾਈਟ
ਔਫ ਹੀਪ ਮੈਮੋਰੀ ਵਰਤੀ ਗਈ (ਕੁੱਲ): 5.17 MiB
SSTable ਕੰਪਰੈਸ਼ਨ ਅਨੁਪਾਤ: 0.5720989576459437
ਭਾਗਾਂ ਦੀ ਗਿਣਤੀ (ਅੰਦਾਜ਼ਾ): 3970323
ਯਾਦ ਕਰਨ ਯੋਗ ਸੈੱਲਾਂ ਦੀ ਗਿਣਤੀ: 0
ਮੀਮਟੇਬਲ ਡੇਟਾ ਦਾ ਆਕਾਰ: 0 ਬਾਈਟਸ
ਮੀਮਟੇਬਲ ਆਫ ਹੀਪ ਮੈਮੋਰੀ ਵਰਤੀ ਗਈ: 0 ਬਾਈਟਸ
ਮੀਮਟੇਬਲ ਸਵਿੱਚ ਦੀ ਗਿਣਤੀ: 5
ਸਥਾਨਕ ਪੜ੍ਹਨ ਦੀ ਗਿਣਤੀ: 2346045
ਸਥਾਨਕ ਰੀਡ ਲੇਟੈਂਸੀ: NaN ms
ਸਥਾਨਕ ਲਿਖਣ ਦੀ ਗਿਣਤੀ: 3865503
ਸਥਾਨਕ ਲਿਖਣ ਦੀ ਲੇਟੈਂਸੀ: NaN ms
ਬਕਾਇਆ ਫਲੱਸ਼: 0
ਮੁਰੰਮਤ ਕੀਤੀ ਗਈ ਪ੍ਰਤੀਸ਼ਤ: 0.0
ਬਲੂਮ ਫਿਲਟਰ ਝੂਠੇ ਸਕਾਰਾਤਮਕ: 25
ਬਲੂਮ ਫਿਲਟਰ ਗਲਤ ਅਨੁਪਾਤ: 0.00000
ਬਲੂਮ ਫਿਲਟਰ ਸਪੇਸ ਵਰਤੀ ਗਈ: 4.57 MiB
ਬਲੂਮ ਫਿਲਟਰ ਆਫ ਹੀਪ ਮੈਮੋਰੀ ਵਰਤੀ ਗਈ: 4.57 MiB
ਵਰਤਿਆ ਗਿਆ ਹੈਪ ਮੈਮੋਰੀ ਬੰਦ ਸੂਚਕਾਂਕ ਸੰਖੇਪ: 590.02 KiB
ਵਰਤਿਆ ਗਿਆ ਹੈਪ ਮੈਮੋਰੀ ਬੰਦ ਕੰਪਰੈਸ਼ਨ ਮੈਟਾਡੇਟਾ: 19.45 KiB
ਸੰਕੁਚਿਤ ਭਾਗ ਘੱਟੋ-ਘੱਟ ਬਾਈਟ: 36
ਸੰਕੁਚਿਤ ਭਾਗ ਅਧਿਕਤਮ ਬਾਈਟ: 42
ਸੰਕੁਚਿਤ ਭਾਗ ਦਾ ਮਤਲਬ ਬਾਈਟਸ: 42
ਔਸਤ ਲਾਈਵ ਸੈੱਲ ਪ੍ਰਤੀ ਟੁਕੜਾ (ਪਿਛਲੇ ਪੰਜ ਮਿੰਟ): NaN
ਵੱਧ ਤੋਂ ਵੱਧ ਲਾਈਵ ਸੈੱਲ ਪ੍ਰਤੀ ਟੁਕੜਾ (ਪਿਛਲੇ ਪੰਜ ਮਿੰਟ): 0
ਔਸਤ ਕਬਰ ਪੱਥਰ ਪ੍ਰਤੀ ਟੁਕੜਾ (ਪਿਛਲੇ ਪੰਜ ਮਿੰਟ): NaN
ਪ੍ਰਤੀ ਟੁਕੜਾ (ਆਖਰੀ ਪੰਜ ਮਿੰਟ): 0
ਘਟਾਏ ਗਏ ਪਰਿਵਰਤਨ: 0 ਬਾਈਟ

ਬੈਚ ਦੇ ਆਕਾਰ ਨੂੰ ਘਟਾਉਣ ਦੀ ਕੋਸ਼ਿਸ਼ (ਇੱਥੋਂ ਤੱਕ ਕਿ ਇਸਨੂੰ ਵੱਖਰੇ ਤੌਰ 'ਤੇ ਭੇਜਣਾ) ਦਾ ਕੋਈ ਅਸਰ ਨਹੀਂ ਹੋਇਆ, ਇਹ ਸਿਰਫ ਵਿਗੜ ਗਿਆ. ਇਹ ਸੰਭਵ ਹੈ ਕਿ ਅਸਲ ਵਿੱਚ ਇਹ CS ਲਈ ਅਸਲ ਵਿੱਚ ਵੱਧ ਤੋਂ ਵੱਧ ਪ੍ਰਦਰਸ਼ਨ ਹੈ, ਕਿਉਂਕਿ CS ਲਈ ਪ੍ਰਾਪਤ ਕੀਤੇ ਨਤੀਜੇ ਡੇਟਾਸਟੈਕਸ ਲਈ ਪ੍ਰਾਪਤ ਕੀਤੇ ਗਏ ਨਤੀਜੇ ਦੇ ਸਮਾਨ ਹਨ - ਪ੍ਰਤੀ ਸਕਿੰਟ ਦੇ ਲਗਭਗ ਹਜ਼ਾਰਾਂ ਓਪਰੇਸ਼ਨ। ਇਸ ਤੋਂ ਇਲਾਵਾ, ਜੇਕਰ ਅਸੀਂ ਸਰੋਤ ਉਪਯੋਗਤਾ ਨੂੰ ਦੇਖਦੇ ਹਾਂ, ਤਾਂ ਅਸੀਂ ਦੇਖਾਂਗੇ ਕਿ CS ਬਹੁਤ ਜ਼ਿਆਦਾ CPU ਅਤੇ ਡਿਸਕਾਂ ਦੀ ਵਰਤੋਂ ਕਰਦਾ ਹੈ:

ਚਿੱਤਰ ਦੋਵਾਂ ਡੇਟਾਬੇਸ ਲਈ ਇੱਕ ਕਤਾਰ ਵਿੱਚ ਸਾਰੇ ਟੈਸਟਾਂ ਦੇ ਚੱਲਣ ਦੌਰਾਨ ਉਪਯੋਗਤਾ ਨੂੰ ਦਰਸਾਉਂਦਾ ਹੈ।

HB ਦੇ ਸ਼ਕਤੀਸ਼ਾਲੀ ਪੜ੍ਹਨ ਦੇ ਫਾਇਦੇ ਬਾਰੇ. ਇੱਥੇ ਤੁਸੀਂ ਦੇਖ ਸਕਦੇ ਹੋ ਕਿ ਦੋਵਾਂ ਡੇਟਾਬੇਸ ਲਈ, ਰੀਡਿੰਗ ਦੌਰਾਨ ਡਿਸਕ ਦੀ ਵਰਤੋਂ ਬਹੁਤ ਘੱਟ ਹੈ (ਪੜ੍ਹਨ ਦੇ ਟੈਸਟ ਹਰੇਕ ਡੇਟਾਬੇਸ ਲਈ ਟੈਸਟਿੰਗ ਚੱਕਰ ਦਾ ਅੰਤਮ ਹਿੱਸਾ ਹਨ, ਉਦਾਹਰਨ ਲਈ CS ਲਈ ਇਹ 15:20 ਤੋਂ 15:40 ਤੱਕ ਹੈ)। HB ਦੇ ਮਾਮਲੇ ਵਿੱਚ, ਕਾਰਨ ਸਪੱਸ਼ਟ ਹੈ - ਜ਼ਿਆਦਾਤਰ ਡੇਟਾ ਮੈਮੋਰੀ ਵਿੱਚ, ਮੈਮਸਟੋਰ ਵਿੱਚ ਹੈਂਗ ਹੁੰਦਾ ਹੈ, ਅਤੇ ਕੁਝ ਬਲਾਕਕੈਸ਼ ਵਿੱਚ ਕੈਸ਼ ਹੁੰਦਾ ਹੈ। ਜਿਵੇਂ ਕਿ CS ਲਈ, ਇਹ ਬਹੁਤ ਸਪੱਸ਼ਟ ਨਹੀਂ ਹੈ ਕਿ ਇਹ ਕਿਵੇਂ ਕੰਮ ਕਰਦਾ ਹੈ, ਪਰ ਡਿਸਕ ਰੀਸਾਈਕਲਿੰਗ ਵੀ ਦਿਖਾਈ ਨਹੀਂ ਦੇ ਰਹੀ ਹੈ, ਪਰ ਸਿਰਫ ਇਸ ਸਥਿਤੀ ਵਿੱਚ, ਕੈਸ਼ row_cache_size_in_mb = 2048 ਅਤੇ ਕੈਚਿੰਗ = {'ਕੁੰਜੀਆਂ' ਨੂੰ ਸੈੱਟ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕੀਤੀ ਗਈ ਸੀ: 'ALL', 'rows_per_partition': '2000000'}, ਪਰ ਇਸਨੇ ਇਸਨੂੰ ਥੋੜਾ ਹੋਰ ਵੀ ਖਰਾਬ ਕਰ ਦਿੱਤਾ।

ਇਹ ਇੱਕ ਵਾਰ ਫਿਰ HB ਵਿੱਚ ਖੇਤਰਾਂ ਦੀ ਸੰਖਿਆ ਬਾਰੇ ਇੱਕ ਮਹੱਤਵਪੂਰਣ ਨੁਕਤਾ ਵਰਣਨ ਯੋਗ ਹੈ. ਸਾਡੇ ਕੇਸ ਵਿੱਚ, ਮੁੱਲ ਨੂੰ 64 ਦੇ ਰੂਪ ਵਿੱਚ ਨਿਸ਼ਚਿਤ ਕੀਤਾ ਗਿਆ ਸੀ। ਜੇਕਰ ਤੁਸੀਂ ਇਸਨੂੰ ਘਟਾਉਂਦੇ ਹੋ ਅਤੇ ਇਸਨੂੰ ਬਰਾਬਰ ਕਰਦੇ ਹੋ, ਉਦਾਹਰਨ ਲਈ, 4, ਫਿਰ ਪੜ੍ਹਨ ਵੇਲੇ, ਗਤੀ 2 ਗੁਣਾ ਘੱਟ ਜਾਂਦੀ ਹੈ। ਕਾਰਨ ਇਹ ਹੈ ਕਿ ਮੈਮਸਟੋਰ ਤੇਜ਼ੀ ਨਾਲ ਭਰ ਜਾਵੇਗਾ ਅਤੇ ਫਾਈਲਾਂ ਨੂੰ ਅਕਸਰ ਫਲੱਸ਼ ਕੀਤਾ ਜਾਵੇਗਾ ਅਤੇ ਪੜ੍ਹਨ ਵੇਲੇ, ਵਧੇਰੇ ਫਾਈਲਾਂ 'ਤੇ ਕਾਰਵਾਈ ਕਰਨ ਦੀ ਜ਼ਰੂਰਤ ਹੋਏਗੀ, ਜੋ ਕਿ HB ਲਈ ਇੱਕ ਬਹੁਤ ਹੀ ਗੁੰਝਲਦਾਰ ਕਾਰਵਾਈ ਹੈ। ਅਸਲ ਸਥਿਤੀਆਂ ਵਿੱਚ, ਇਸਦਾ ਇਲਾਜ ਇੱਕ ਪ੍ਰਸਪਲਿਟਿੰਗ ਅਤੇ ਸੰਕੁਚਿਤ ਰਣਨੀਤੀ ਦੁਆਰਾ ਸੋਚ ਕੇ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ; ਖਾਸ ਤੌਰ 'ਤੇ, ਅਸੀਂ ਇੱਕ ਸਵੈ-ਲਿਖਤ ਉਪਯੋਗਤਾ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹਾਂ ਜੋ ਕੂੜਾ ਇਕੱਠਾ ਕਰਦੀ ਹੈ ਅਤੇ ਬੈਕਗ੍ਰਾਉਂਡ ਵਿੱਚ ਲਗਾਤਾਰ HFiles ਨੂੰ ਸੰਕੁਚਿਤ ਕਰਦੀ ਹੈ। ਇਹ ਕਾਫ਼ੀ ਸੰਭਵ ਹੈ ਕਿ ਡੇਟਾਸਟੈਕਸ ਟੈਸਟਾਂ ਲਈ ਉਹਨਾਂ ਨੇ ਪ੍ਰਤੀ ਸਾਰਣੀ ਵਿੱਚ ਸਿਰਫ 1 ਖੇਤਰ ਨਿਰਧਾਰਤ ਕੀਤਾ ਹੈ (ਜੋ ਕਿ ਸਹੀ ਨਹੀਂ ਹੈ) ਅਤੇ ਇਹ ਕੁਝ ਹੱਦ ਤੱਕ ਸਪੱਸ਼ਟ ਕਰੇਗਾ ਕਿ HB ਉਹਨਾਂ ਦੇ ਰੀਡਿੰਗ ਟੈਸਟਾਂ ਵਿੱਚ ਇੰਨਾ ਘਟੀਆ ਕਿਉਂ ਸੀ।

ਇਸ ਤੋਂ ਹੇਠ ਲਿਖੇ ਮੁੱਢਲੇ ਸਿੱਟੇ ਕੱਢੇ ਗਏ ਹਨ। ਇਹ ਮੰਨਦੇ ਹੋਏ ਕਿ ਟੈਸਟਿੰਗ ਦੌਰਾਨ ਕੋਈ ਵੱਡੀ ਗਲਤੀ ਨਹੀਂ ਕੀਤੀ ਗਈ ਸੀ, ਫਿਰ ਕੈਸੈਂਡਰਾ ਮਿੱਟੀ ਦੇ ਪੈਰਾਂ ਨਾਲ ਇੱਕ ਕੋਲੋਸਸ ਵਰਗੀ ਦਿਖਾਈ ਦਿੰਦੀ ਹੈ। ਵਧੇਰੇ ਸਪੱਸ਼ਟ ਤੌਰ 'ਤੇ, ਜਦੋਂ ਉਹ ਇਕ ਲੱਤ 'ਤੇ ਸੰਤੁਲਨ ਰੱਖਦੀ ਹੈ, ਜਿਵੇਂ ਕਿ ਲੇਖ ਦੇ ਸ਼ੁਰੂ ਵਿਚ ਤਸਵੀਰ ਵਿਚ, ਉਹ ਮੁਕਾਬਲਤਨ ਚੰਗੇ ਨਤੀਜੇ ਦਿਖਾਉਂਦੀ ਹੈ, ਪਰ ਉਸੇ ਹਾਲਤਾਂ ਵਿਚ ਲੜਾਈ ਵਿਚ ਉਹ ਪੂਰੀ ਤਰ੍ਹਾਂ ਹਾਰ ਜਾਂਦੀ ਹੈ। ਇਸਦੇ ਨਾਲ ਹੀ, ਸਾਡੇ ਹਾਰਡਵੇਅਰ 'ਤੇ ਘੱਟ CPU ਉਪਯੋਗਤਾ ਨੂੰ ਧਿਆਨ ਵਿੱਚ ਰੱਖਦੇ ਹੋਏ, ਅਸੀਂ ਪ੍ਰਤੀ ਹੋਸਟ ਲਈ ਦੋ ਰੀਜਨਸਰਵਰ HB ਲਗਾਉਣਾ ਸਿੱਖਿਆ ਅਤੇ ਇਸ ਤਰ੍ਹਾਂ ਪ੍ਰਦਰਸ਼ਨ ਨੂੰ ਦੁੱਗਣਾ ਕਰ ਦਿੱਤਾ। ਉਹ. ਸਰੋਤਾਂ ਦੀ ਵਰਤੋਂ ਨੂੰ ਧਿਆਨ ਵਿੱਚ ਰੱਖਦੇ ਹੋਏ, ਸੀਐਸ ਲਈ ਸਥਿਤੀ ਹੋਰ ਵੀ ਤਰਸਯੋਗ ਹੈ।

ਬੇਸ਼ੱਕ, ਇਹ ਟੈਸਟ ਕਾਫ਼ੀ ਸਿੰਥੈਟਿਕ ਹਨ ਅਤੇ ਇੱਥੇ ਵਰਤੇ ਗਏ ਡੇਟਾ ਦੀ ਮਾਤਰਾ ਮੁਕਾਬਲਤਨ ਮਾਮੂਲੀ ਹੈ। ਇਹ ਸੰਭਵ ਹੈ ਕਿ ਜੇਕਰ ਅਸੀਂ ਟੈਰਾਬਾਈਟ 'ਤੇ ਸਵਿਚ ਕਰਦੇ ਹਾਂ, ਤਾਂ ਸਥਿਤੀ ਵੱਖਰੀ ਹੋਵੇਗੀ, ਪਰ ਜਦੋਂ ਕਿ HB ਲਈ ਅਸੀਂ ਟੈਰਾਬਾਈਟ ਲੋਡ ਕਰ ਸਕਦੇ ਹਾਂ, CS ਲਈ ਇਹ ਸਮੱਸਿਆ ਵਾਲਾ ਸਾਬਤ ਹੋਇਆ। ਇਹ ਅਕਸਰ ਇਹਨਾਂ ਵੌਲਯੂਮ ਦੇ ਨਾਲ ਵੀ ਇੱਕ OperationTimedOutException ਸੁੱਟ ਦਿੰਦਾ ਹੈ, ਹਾਲਾਂਕਿ ਜਵਾਬ ਦੀ ਉਡੀਕ ਕਰਨ ਦੇ ਮਾਪਦੰਡ ਪਹਿਲਾਂ ਹੀ ਡਿਫੌਲਟ ਲੋਕਾਂ ਦੀ ਤੁਲਨਾ ਵਿੱਚ ਕਈ ਵਾਰ ਵਧਾ ਦਿੱਤੇ ਗਏ ਸਨ।

ਮੈਂ ਉਮੀਦ ਕਰਦਾ ਹਾਂ ਕਿ ਸਾਂਝੇ ਯਤਨਾਂ ਦੁਆਰਾ ਅਸੀਂ ਸੀਐਸ ਦੀਆਂ ਰੁਕਾਵਟਾਂ ਨੂੰ ਲੱਭ ਸਕਾਂਗੇ ਅਤੇ ਜੇ ਅਸੀਂ ਇਸ ਨੂੰ ਤੇਜ਼ ਕਰ ਸਕਦੇ ਹਾਂ, ਤਾਂ ਮੈਂ ਪੋਸਟ ਦੇ ਅੰਤ ਵਿੱਚ ਅੰਤਮ ਨਤੀਜਿਆਂ ਬਾਰੇ ਜਾਣਕਾਰੀ ਜ਼ਰੂਰ ਜੋੜਾਂਗਾ.

UPD: ਕਾਮਰੇਡਾਂ ਦੀ ਸਲਾਹ ਲਈ ਧੰਨਵਾਦ, ਮੈਂ ਪੜ੍ਹਨ ਨੂੰ ਤੇਜ਼ ਕਰਨ ਵਿੱਚ ਕਾਮਯਾਬ ਰਿਹਾ। ਸੀ:
159 ਓਪਸ (644 ਟੇਬਲ, 4 ਸਟ੍ਰੀਮ, ਬੈਚ 5)।
ਜੋੜਿਆ ਗਿਆ:
.withLoadBalancingPolicy(ਨਵੀਂ TokenAwarePolicy(DCAwareRoundRobinPolicy.builder().build()))
ਅਤੇ ਮੈਂ ਥਰਿੱਡਾਂ ਦੀ ਗਿਣਤੀ ਨਾਲ ਖੇਡਿਆ. ਨਤੀਜਾ ਇਹ ਹੈ:
4 ਟੇਬਲ, 100 ਥ੍ਰੈੱਡ, ਬੈਚ = 1 (ਟੁਕੜੇ ਤੋਂ ਟੁਕੜਾ): 301 ਓਪਸ
4 ਟੇਬਲ, 100 ਥਰਿੱਡ, ਬੈਚ = 10: 447 ਓਪਸ
4 ਟੇਬਲ, 100 ਥਰਿੱਡ, ਬੈਚ = 100: 625 ਓਪਸ

ਬਾਅਦ ਵਿੱਚ ਮੈਂ ਹੋਰ ਟਿਊਨਿੰਗ ਸੁਝਾਅ ਲਾਗੂ ਕਰਾਂਗਾ, ਇੱਕ ਪੂਰਾ ਟੈਸਟ ਚੱਕਰ ਚਲਾਵਾਂਗਾ ਅਤੇ ਪੋਸਟ ਦੇ ਅੰਤ ਵਿੱਚ ਨਤੀਜੇ ਸ਼ਾਮਲ ਕਰਾਂਗਾ।

ਸਰੋਤ: www.habr.com