HBase ਦੀ ਵਰਤੋਂ ਕਰਨ ਦਾ ਸਿਧਾਂਤ ਅਤੇ ਅਭਿਆਸ

ਨਮਸਕਾਰ ਮੇਰਾ ਨਾਮ ਡੈਨਿਲ ਲਿਪੋਵੋਏ ਹੈ, Sbertech ਵਿਖੇ ਸਾਡੀ ਟੀਮ ਨੇ HBase ਨੂੰ ਸੰਚਾਲਨ ਡੇਟਾ ਲਈ ਸਟੋਰੇਜ ਵਜੋਂ ਵਰਤਣਾ ਸ਼ੁਰੂ ਕੀਤਾ। ਇਸਦਾ ਅਧਿਐਨ ਕਰਨ ਦੇ ਦੌਰਾਨ, ਤਜਰਬਾ ਇਕੱਠਾ ਹੋਇਆ ਹੈ ਕਿ ਮੈਂ ਵਿਵਸਥਿਤ ਕਰਨਾ ਅਤੇ ਵਰਣਨ ਕਰਨਾ ਚਾਹੁੰਦਾ ਸੀ (ਸਾਨੂੰ ਉਮੀਦ ਹੈ ਕਿ ਇਹ ਬਹੁਤ ਸਾਰੇ ਲੋਕਾਂ ਲਈ ਲਾਭਦਾਇਕ ਹੋਵੇਗਾ). ਹੇਠਾਂ ਦਿੱਤੇ ਸਾਰੇ ਪ੍ਰਯੋਗ HBase ਸੰਸਕਰਣ 1.2.0-cdh5.14.2 ਅਤੇ 2.0.0-cdh6.0.0-beta1 ਨਾਲ ਕੀਤੇ ਗਏ ਸਨ।

1. ਆਮ ਆਰਕੀਟੈਕਚਰ
2. HBASE ਨੂੰ ਡਾਟਾ ਲਿਖਣਾ
3. HBASE ਤੋਂ ਡਾਟਾ ਪੜ੍ਹਨਾ
4. ਡਾਟਾ ਕੈਚਿੰਗ
5. ਬੈਚ ਡਾਟਾ ਪ੍ਰੋਸੈਸਿੰਗ ਮਲਟੀਗੇਟ/ਮਲਟੀਪੁੱਟ
6. ਟੇਬਲ ਨੂੰ ਖੇਤਰਾਂ ਵਿੱਚ ਵੰਡਣ ਲਈ ਰਣਨੀਤੀ (ਵੰਡ ਕਰਨਾ)
7. ਨੁਕਸ ਸਹਿਣਸ਼ੀਲਤਾ, ਸੰਖੇਪਤਾ ਅਤੇ ਡਾਟਾ ਸਥਾਨ
8. ਸੈਟਿੰਗਾਂ ਅਤੇ ਪ੍ਰਦਰਸ਼ਨ
9. ਤਣਾਅ ਟੈਸਟਿੰਗ
10. ਸਿੱਟਾ

1. ਆਮ ਆਰਕੀਟੈਕਚਰ

ਬੈਕਅੱਪ ਮਾਸਟਰ ਜ਼ੂਕੀਪਰ ਨੋਡ 'ਤੇ ਸਰਗਰਮ ਵਿਅਕਤੀ ਦੇ ਦਿਲ ਦੀ ਧੜਕਣ ਨੂੰ ਸੁਣਦਾ ਹੈ ਅਤੇ, ਗਾਇਬ ਹੋਣ ਦੀ ਸਥਿਤੀ ਵਿੱਚ, ਮਾਸਟਰ ਦੇ ਕਾਰਜਾਂ ਨੂੰ ਸੰਭਾਲਦਾ ਹੈ।

2. HBASE ਨੂੰ ਡੇਟਾ ਲਿਖੋ

ਪਹਿਲਾਂ, ਆਓ ਸਭ ਤੋਂ ਸਰਲ ਕੇਸ ਨੂੰ ਵੇਖੀਏ - put(rowkey) ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਇੱਕ ਟੇਬਲ ਵਿੱਚ ਇੱਕ ਮੁੱਖ-ਮੁੱਲ ਵਸਤੂ ਲਿਖਣਾ। ਕਲਾਇੰਟ ਨੂੰ ਪਹਿਲਾਂ ਇਹ ਪਤਾ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ ਕਿ ਰੂਟ ਰੀਜਨ ਸਰਵਰ (RRS), ਜੋ ਕਿ hbase:meta ਟੇਬਲ ਨੂੰ ਸਟੋਰ ਕਰਦਾ ਹੈ, ਕਿੱਥੇ ਸਥਿਤ ਹੈ। ਉਸਨੂੰ ਇਹ ਜਾਣਕਾਰੀ ZooKeeper ਤੋਂ ਮਿਲਦੀ ਹੈ। ਜਿਸ ਤੋਂ ਬਾਅਦ ਇਹ RRS ਨੂੰ ਐਕਸੈਸ ਕਰਦਾ ਹੈ ਅਤੇ hbase:meta ਟੇਬਲ ਨੂੰ ਪੜ੍ਹਦਾ ਹੈ, ਜਿਸ ਤੋਂ ਇਹ ਜਾਣਕਾਰੀ ਕੱਢਦਾ ਹੈ ਕਿ ਕਿਹੜਾ RegionServer (RS) ਦਿਲਚਸਪੀ ਦੀ ਸਾਰਣੀ ਵਿੱਚ ਦਿੱਤੇ ਰੋ-ਕੀ ਲਈ ਡੇਟਾ ਸਟੋਰ ਕਰਨ ਲਈ ਜ਼ਿੰਮੇਵਾਰ ਹੈ। ਭਵਿੱਖ ਦੀ ਵਰਤੋਂ ਲਈ, ਕਲਾਇੰਟ ਦੁਆਰਾ ਮੈਟਾ ਟੇਬਲ ਨੂੰ ਕੈਸ਼ ਕੀਤਾ ਜਾਂਦਾ ਹੈ ਅਤੇ ਇਸਲਈ ਅਗਲੀਆਂ ਕਾਲਾਂ ਤੇਜ਼ ਹੁੰਦੀਆਂ ਹਨ, ਸਿੱਧੇ RS ਨੂੰ।

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

MemStore ਵਿੱਚ ਇੱਕ ਐਂਟਰੀ ਰੱਖਣ ਤੋਂ ਬਾਅਦ, ਗਾਹਕ ਨੂੰ ਇੱਕ ਜਵਾਬ ਵਾਪਸ ਕੀਤਾ ਜਾਂਦਾ ਹੈ ਕਿ ਐਂਟਰੀ ਸਫਲਤਾਪੂਰਵਕ ਸੁਰੱਖਿਅਤ ਕੀਤੀ ਗਈ ਸੀ। ਹਾਲਾਂਕਿ, ਅਸਲ ਵਿੱਚ ਇਹ ਸਿਰਫ ਇੱਕ ਬਫਰ ਵਿੱਚ ਸਟੋਰ ਕੀਤਾ ਜਾਂਦਾ ਹੈ ਅਤੇ ਇੱਕ ਨਿਸ਼ਚਤ ਸਮਾਂ ਬੀਤ ਜਾਣ ਤੋਂ ਬਾਅਦ ਜਾਂ ਜਦੋਂ ਇਹ ਨਵੇਂ ਡੇਟਾ ਨਾਲ ਭਰ ਜਾਂਦਾ ਹੈ ਤਾਂ ਹੀ ਡਿਸਕ ਤੇ ਪਹੁੰਚਦਾ ਹੈ।

"ਮਿਟਾਓ" ਓਪਰੇਸ਼ਨ ਕਰਦੇ ਸਮੇਂ, ਡੇਟਾ ਸਰੀਰਕ ਤੌਰ 'ਤੇ ਨਹੀਂ ਮਿਟਾਇਆ ਜਾਂਦਾ ਹੈ। ਉਹਨਾਂ ਨੂੰ ਸਿਰਫ਼ ਮਿਟਾਏ ਗਏ ਵਜੋਂ ਚਿੰਨ੍ਹਿਤ ਕੀਤਾ ਗਿਆ ਹੈ, ਅਤੇ ਵਿਨਾਸ਼ ਆਪਣੇ ਆਪ ਮੁੱਖ ਸੰਖੇਪ ਫੰਕਸ਼ਨ ਨੂੰ ਕਾਲ ਕਰਨ ਦੇ ਸਮੇਂ ਵਾਪਰਦਾ ਹੈ, ਜਿਸ ਨੂੰ ਪੈਰਾ 7 ਵਿੱਚ ਵਧੇਰੇ ਵਿਸਥਾਰ ਵਿੱਚ ਦੱਸਿਆ ਗਿਆ ਹੈ।

HFile ਫਾਰਮੈਟ ਵਿੱਚ ਫਾਈਲਾਂ HDFS ਵਿੱਚ ਇਕੱਠੀਆਂ ਕੀਤੀਆਂ ਜਾਂਦੀਆਂ ਹਨ ਅਤੇ ਸਮੇਂ-ਸਮੇਂ 'ਤੇ ਛੋਟੀ ਜਿਹੀ ਸੰਖੇਪ ਪ੍ਰਕਿਰਿਆ ਸ਼ੁਰੂ ਕੀਤੀ ਜਾਂਦੀ ਹੈ, ਜੋ ਕਿ ਕੁਝ ਵੀ ਮਿਟਾਏ ਬਿਨਾਂ ਛੋਟੀਆਂ ਫਾਈਲਾਂ ਨੂੰ ਵੱਡੀਆਂ ਫਾਈਲਾਂ ਵਿੱਚ ਮਿਲਾ ਦਿੰਦੀ ਹੈ। ਸਮੇਂ ਦੇ ਨਾਲ, ਇਹ ਇੱਕ ਸਮੱਸਿਆ ਵਿੱਚ ਬਦਲ ਜਾਂਦਾ ਹੈ ਜੋ ਸਿਰਫ ਡੇਟਾ ਨੂੰ ਪੜ੍ਹਦੇ ਸਮੇਂ ਪ੍ਰਗਟ ਹੁੰਦਾ ਹੈ (ਅਸੀਂ ਇਸ 'ਤੇ ਥੋੜ੍ਹੀ ਦੇਰ ਬਾਅਦ ਵਾਪਸ ਆਵਾਂਗੇ)।

ਉੱਪਰ ਦੱਸੀ ਗਈ ਲੋਡਿੰਗ ਪ੍ਰਕਿਰਿਆ ਤੋਂ ਇਲਾਵਾ, ਇੱਥੇ ਇੱਕ ਬਹੁਤ ਜ਼ਿਆਦਾ ਪ੍ਰਭਾਵਸ਼ਾਲੀ ਪ੍ਰਕਿਰਿਆ ਹੈ, ਜੋ ਸ਼ਾਇਦ ਇਸ ਡੇਟਾਬੇਸ ਦਾ ਸਭ ਤੋਂ ਮਜ਼ਬੂਤ ​​ਪੱਖ ਹੈ - ਬਲਕਲੋਡ। ਇਹ ਇਸ ਤੱਥ ਵਿੱਚ ਹੈ ਕਿ ਅਸੀਂ ਸੁਤੰਤਰ ਤੌਰ 'ਤੇ HFiles ਬਣਾਉਂਦੇ ਹਾਂ ਅਤੇ ਉਹਨਾਂ ਨੂੰ ਡਿਸਕ 'ਤੇ ਪਾਉਂਦੇ ਹਾਂ, ਜੋ ਸਾਨੂੰ ਪੂਰੀ ਤਰ੍ਹਾਂ ਸਕੇਲ ਕਰਨ ਅਤੇ ਬਹੁਤ ਵਧੀਆ ਗਤੀ ਪ੍ਰਾਪਤ ਕਰਨ ਦੀ ਇਜਾਜ਼ਤ ਦਿੰਦਾ ਹੈ। ਵਾਸਤਵ ਵਿੱਚ, ਇੱਥੇ ਸੀਮਾ HBase ਨਹੀਂ ਹੈ, ਪਰ ਹਾਰਡਵੇਅਰ ਦੀ ਸਮਰੱਥਾ ਹੈ। ਹੇਠਾਂ 16 RegionServers ਅਤੇ 16 NodeManager YARN (CPU Xeon E5-2680 v4 @ 2.40GHz * 64 ਥਰਿੱਡ), HBase ਵਰਜਨ 1.2.0-cdh5.14.2 ਵਾਲੇ ਕਲੱਸਟਰ 'ਤੇ ਬੂਟ ਨਤੀਜੇ ਹਨ।

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

ਤੁਸੀਂ ਇੱਕੋ ਸਮੇਂ ਦੋ ਟੇਬਲਾਂ ਵਿੱਚ ਲੋਡ ਕਰਨਾ ਸ਼ੁਰੂ ਕਰ ਸਕਦੇ ਹੋ ਅਤੇ ਦੁੱਗਣੀ ਗਤੀ ਪ੍ਰਾਪਤ ਕਰ ਸਕਦੇ ਹੋ। ਹੇਠਾਂ ਤੁਸੀਂ ਦੇਖ ਸਕਦੇ ਹੋ ਕਿ ਦੋ ਟੇਬਲਾਂ ਨੂੰ ਇੱਕ ਵਾਰ ਵਿੱਚ 10 KB ਬਲਾਕ ਲਿਖਣਾ ਹਰ ਇੱਕ ਵਿੱਚ ਲਗਭਗ 600 MB/sec (ਕੁੱਲ 1275 MB/sec) ਦੀ ਰਫਤਾਰ ਨਾਲ ਹੁੰਦਾ ਹੈ, ਜੋ ਕਿ ਇੱਕ ਟੇਬਲ ਨੂੰ ਲਿਖਣ ਦੀ ਗਤੀ 623 MB/sec (ਦੇਖੋ) ਨਾਲ ਮੇਲ ਖਾਂਦਾ ਹੈ। ਉੱਪਰ ਨੰ. 11)

ਪਰ 50 KB ਦੇ ਰਿਕਾਰਡਾਂ ਨਾਲ ਦੂਜੀ ਦੌੜ ਦਰਸਾਉਂਦੀ ਹੈ ਕਿ ਡਾਊਨਲੋਡ ਸਪੀਡ ਥੋੜੀ ਵੱਧ ਰਹੀ ਹੈ, ਜੋ ਇਹ ਦਰਸਾਉਂਦੀ ਹੈ ਕਿ ਇਹ ਸੀਮਾ ਮੁੱਲਾਂ ਦੇ ਨੇੜੇ ਆ ਰਹੀ ਹੈ। ਇਸਦੇ ਨਾਲ ਹੀ, ਤੁਹਾਨੂੰ ਇਹ ਧਿਆਨ ਵਿੱਚ ਰੱਖਣ ਦੀ ਜ਼ਰੂਰਤ ਹੈ ਕਿ HBASE 'ਤੇ ਅਮਲੀ ਤੌਰ 'ਤੇ ਕੋਈ ਲੋਡ ਨਹੀਂ ਬਣਾਇਆ ਗਿਆ ਹੈ, ਇਸਦੇ ਲਈ ਸਭ ਤੋਂ ਪਹਿਲਾਂ hbase:meta ਤੋਂ ਡੇਟਾ ਦੇਣਾ ਹੈ, ਅਤੇ HFiles ਨੂੰ ਲਾਈਨਿੰਗ ਕਰਨ ਤੋਂ ਬਾਅਦ, ਬਲਾਕਕੈਚ ਡੇਟਾ ਨੂੰ ਰੀਸੈਟ ਕਰੋ ਅਤੇ ਸੇਵ ਕਰੋ। MemStore ਬਫਰ ਡਿਸਕ ਤੇ, ਜੇਕਰ ਇਹ ਖਾਲੀ ਨਹੀਂ ਹੈ।

3. HBASE ਤੋਂ ਡਾਟਾ ਪੜ੍ਹਨਾ

ਜੇ ਅਸੀਂ ਮੰਨ ਲੈਂਦੇ ਹਾਂ ਕਿ ਕਲਾਇੰਟ ਕੋਲ ਪਹਿਲਾਂ ਹੀ hbase:meta (ਪੁਆਇੰਟ 2 ਦੇਖੋ) ਤੋਂ ਸਾਰੀ ਜਾਣਕਾਰੀ ਹੈ, ਤਾਂ ਬੇਨਤੀ ਸਿੱਧੇ RS ਨੂੰ ਜਾਂਦੀ ਹੈ ਜਿੱਥੇ ਲੋੜੀਂਦੀ ਕੁੰਜੀ ਸਟੋਰ ਕੀਤੀ ਜਾਂਦੀ ਹੈ। ਪਹਿਲਾਂ, ਖੋਜ MemCache ਵਿੱਚ ਕੀਤੀ ਜਾਂਦੀ ਹੈ। ਇਸ ਗੱਲ ਦੀ ਪਰਵਾਹ ਕੀਤੇ ਬਿਨਾਂ ਕਿ ਉੱਥੇ ਡੇਟਾ ਹੈ ਜਾਂ ਨਹੀਂ, ਖੋਜ ਨੂੰ ਬਲਾਕਕੈਚ ਬਫਰ ਵਿੱਚ ਵੀ ਕੀਤਾ ਜਾਂਦਾ ਹੈ ਅਤੇ, ਜੇ ਲੋੜ ਹੋਵੇ, ਤਾਂ HFiles ਵਿੱਚ. ਜੇਕਰ ਡੇਟਾ ਫਾਈਲ ਵਿੱਚ ਪਾਇਆ ਗਿਆ ਸੀ, ਤਾਂ ਇਸਨੂੰ ਬਲਾਕਕੈਚ ਵਿੱਚ ਰੱਖਿਆ ਗਿਆ ਹੈ ਅਤੇ ਅਗਲੀ ਬੇਨਤੀ 'ਤੇ ਤੇਜ਼ੀ ਨਾਲ ਵਾਪਸ ਕੀਤਾ ਜਾਵੇਗਾ। ਬਲੂਮ ਫਿਲਟਰ ਦੀ ਵਰਤੋਂ ਕਰਕੇ HFile ਵਿੱਚ ਖੋਜ ਕਰਨਾ ਮੁਕਾਬਲਤਨ ਤੇਜ਼ ਹੈ, ਜਿਵੇਂ ਕਿ. ਥੋੜ੍ਹੇ ਜਿਹੇ ਡੇਟਾ ਨੂੰ ਪੜ੍ਹਨ ਤੋਂ ਬਾਅਦ, ਇਹ ਤੁਰੰਤ ਨਿਰਧਾਰਿਤ ਕਰਦਾ ਹੈ ਕਿ ਕੀ ਇਸ ਫਾਈਲ ਵਿੱਚ ਲੋੜੀਂਦੀ ਕੁੰਜੀ ਹੈ ਅਤੇ ਜੇ ਨਹੀਂ, ਤਾਂ ਅਗਲੀ ਇੱਕ ਤੇ ਚਲੀ ਜਾਂਦੀ ਹੈ.

ਇਹਨਾਂ ਤਿੰਨ ਸਰੋਤਾਂ ਤੋਂ ਡੇਟਾ ਪ੍ਰਾਪਤ ਕਰਨ ਤੋਂ ਬਾਅਦ, RS ਇੱਕ ਜਵਾਬ ਤਿਆਰ ਕਰਦਾ ਹੈ। ਖਾਸ ਤੌਰ 'ਤੇ, ਜੇ ਕਲਾਇੰਟ ਨੇ ਵਰਜਨਿੰਗ ਦੀ ਬੇਨਤੀ ਕੀਤੀ ਹੈ ਤਾਂ ਇਹ ਇੱਕ ਵਸਤੂ ਦੇ ਕਈ ਲੱਭੇ ਗਏ ਸੰਸਕਰਣਾਂ ਨੂੰ ਇੱਕ ਵਾਰ ਵਿੱਚ ਟ੍ਰਾਂਸਫਰ ਕਰ ਸਕਦਾ ਹੈ।

4. ਡਾਟਾ ਕੈਸ਼ਿੰਗ

MemStore ਅਤੇ BlockCache ਬਫਰ ਨਿਰਧਾਰਤ ਆਨ-ਹੀਪ RS ਮੈਮੋਰੀ ਦਾ 80% ਤੱਕ ਕਬਜ਼ਾ ਕਰਦੇ ਹਨ (ਬਾਕੀ RS ਸੇਵਾ ਕਾਰਜਾਂ ਲਈ ਰਾਖਵੀਂ ਹੈ)। ਜੇ ਆਮ ਵਰਤੋਂ ਮੋਡ ਅਜਿਹਾ ਹੈ ਜੋ ਪ੍ਰਕਿਰਿਆਵਾਂ ਨੂੰ ਉਸੇ ਡੇਟਾ ਨੂੰ ਲਿਖਣ ਅਤੇ ਤੁਰੰਤ ਪੜ੍ਹਦਾ ਹੈ, ਤਾਂ ਇਹ ਬਲਾਕਕੈਚ ਨੂੰ ਘਟਾਉਣਾ ਅਤੇ ਮੇਮਸਟੋਰ ਨੂੰ ਵਧਾਉਣਾ ਸਮਝਦਾ ਹੈ, ਕਿਉਂਕਿ ਜਦੋਂ ਲਿਖਣਾ ਡਾਟਾ ਪੜ੍ਹਨ ਲਈ ਕੈਸ਼ ਵਿੱਚ ਨਹੀਂ ਆਉਂਦਾ ਹੈ, ਤਾਂ ਬਲਾਕਕੈਚ ਦੀ ਵਰਤੋਂ ਘੱਟ ਵਾਰ ਕੀਤੀ ਜਾਵੇਗੀ। BlockCache ਬਫਰ ਵਿੱਚ ਦੋ ਭਾਗ ਹੁੰਦੇ ਹਨ: LruBlockCache (ਹਮੇਸ਼ਾ ਆਨ-ਹੀਪ) ਅਤੇ BucketCache (ਆਮ ਤੌਰ 'ਤੇ ਆਫ-ਹੀਪ ਜਾਂ SSD' ਤੇ)। BucketCache ਦੀ ਵਰਤੋਂ ਉਦੋਂ ਕੀਤੀ ਜਾਣੀ ਚਾਹੀਦੀ ਹੈ ਜਦੋਂ ਬਹੁਤ ਸਾਰੀਆਂ ਰੀਡਿੰਗ ਬੇਨਤੀਆਂ ਹੁੰਦੀਆਂ ਹਨ ਅਤੇ ਉਹ LruBlockCache ਵਿੱਚ ਫਿੱਟ ਨਹੀਂ ਹੁੰਦੀਆਂ, ਜਿਸ ਨਾਲ ਗਾਰਬੇਜ ਕੁਲੈਕਟਰ ਦਾ ਸਰਗਰਮ ਕੰਮ ਹੁੰਦਾ ਹੈ। ਇਸ ਦੇ ਨਾਲ ਹੀ, ਤੁਹਾਨੂੰ ਰੀਡ ਕੈਸ਼ ਦੀ ਵਰਤੋਂ ਕਰਨ ਤੋਂ ਕਾਰਗੁਜ਼ਾਰੀ ਵਿੱਚ ਮੂਲ ਵਾਧੇ ਦੀ ਉਮੀਦ ਨਹੀਂ ਕਰਨੀ ਚਾਹੀਦੀ, ਪਰ ਅਸੀਂ ਪੈਰਾ 8 ਵਿੱਚ ਇਸ 'ਤੇ ਵਾਪਸ ਆਵਾਂਗੇ।

ਪੂਰੇ RS ਲਈ ਇੱਕ ਬਲਾਕਕੈਸ਼ ਹੈ, ਅਤੇ ਹਰੇਕ ਟੇਬਲ ਲਈ ਇੱਕ ਮੇਮਸਟੋਰ ਹੈ (ਹਰੇਕ ਕਾਲਮ ਪਰਿਵਾਰ ਲਈ ਇੱਕ)।

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

hbase(main):001:0> create 'ns:magic', 'cf'
Created table ns:magic
Took 1.1533 seconds
hbase(main):002:0> put 'ns:magic', 'key1', 'cf:c', 'try_to_delete_me'
Took 0.2610 seconds
hbase(main):003:0> flush 'ns:magic'
Took 0.6161 seconds
hdfs dfs -mv /data/hbase/data/ns/magic/* /tmp/trash
hbase(main):002:0> get 'ns:magic', 'key1'
 cf:c      timestamp=1534440690218, value=try_to_delete_me

"ਪੜ੍ਹਨ 'ਤੇ ਕੈਸ਼ ਡੇਟਾ" ਪੈਰਾਮੀਟਰ ਨੂੰ ਗਲਤ 'ਤੇ ਸੈੱਟ ਕੀਤਾ ਗਿਆ ਹੈ। ਜੇ ਤੁਹਾਡੇ ਕੋਈ ਵਿਚਾਰ ਹਨ, ਤਾਂ ਟਿੱਪਣੀਆਂ ਵਿੱਚ ਇਸ 'ਤੇ ਚਰਚਾ ਕਰਨ ਲਈ ਸਵਾਗਤ ਹੈ.

5. ਬੈਚ ਡਾਟਾ ਪ੍ਰੋਸੈਸਿੰਗ ਮਲਟੀਗੇਟ/ਮਲਟੀਪੁੱਟ

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

ਟੈਸਟ ਇੱਕ ਵਰਚੁਅਲ ਮਸ਼ੀਨ, 8 ਕੋਰ, ਸੰਸਕਰਣ HBase 2.0.0-cdh6.0.0-beta1 'ਤੇ ਕੀਤੇ ਗਏ ਸਨ।

MSLAB ਮੋਡ ਹੀਪ ਫਰੈਗਮੈਂਟੇਸ਼ਨ ਨੂੰ ਘਟਾਉਣ ਲਈ ਤਿਆਰ ਕੀਤਾ ਗਿਆ ਹੈ, ਜੋ ਕਿ ਨਵੀਂ ਅਤੇ ਪੁਰਾਣੀ ਪੀੜ੍ਹੀ ਦੇ ਡੇਟਾ ਦੇ ਮਿਸ਼ਰਣ ਕਾਰਨ ਵਾਪਰਦਾ ਹੈ। ਇੱਕ ਹੱਲ ਵਜੋਂ, ਜਦੋਂ MSLAB ਯੋਗ ਹੁੰਦਾ ਹੈ, ਡੇਟਾ ਨੂੰ ਮੁਕਾਬਲਤਨ ਛੋਟੇ ਸੈੱਲਾਂ (ਚਿੰਕਸ) ਵਿੱਚ ਰੱਖਿਆ ਜਾਂਦਾ ਹੈ ਅਤੇ ਟੁਕੜਿਆਂ ਵਿੱਚ ਪ੍ਰੋਸੈਸ ਕੀਤਾ ਜਾਂਦਾ ਹੈ। ਨਤੀਜੇ ਵਜੋਂ, ਜਦੋਂ ਬੇਨਤੀ ਕੀਤੇ ਡੇਟਾ ਪੈਕੇਟ ਵਿੱਚ ਵਾਲੀਅਮ ਨਿਰਧਾਰਤ ਆਕਾਰ ਤੋਂ ਵੱਧ ਜਾਂਦਾ ਹੈ, ਤਾਂ ਪ੍ਰਦਰਸ਼ਨ ਤੇਜ਼ੀ ਨਾਲ ਘਟਦਾ ਹੈ। ਦੂਜੇ ਪਾਸੇ, ਇਸ ਮੋਡ ਨੂੰ ਬੰਦ ਕਰਨ ਦੀ ਵੀ ਸਲਾਹ ਨਹੀਂ ਦਿੱਤੀ ਜਾਂਦੀ, ਕਿਉਂਕਿ ਇਹ ਤੀਬਰ ਡੇਟਾ ਪ੍ਰੋਸੈਸਿੰਗ ਦੇ ਪਲਾਂ ਦੌਰਾਨ GC ਦੇ ਕਾਰਨ ਰੁਕ ਜਾਵੇਗਾ। ਇੱਕ ਚੰਗਾ ਹੱਲ ਇਹ ਹੈ ਕਿ ਰੀਡਿੰਗ ਦੇ ਨਾਲ ਹੀ ਪੁਟ ਦੁਆਰਾ ਕਿਰਿਆਸ਼ੀਲ ਲਿਖਤ ਦੇ ਮਾਮਲੇ ਵਿੱਚ ਸੈੱਲ ਵਾਲੀਅਮ ਨੂੰ ਵਧਾਉਣਾ। ਇਹ ਧਿਆਨ ਦੇਣ ਯੋਗ ਹੈ ਕਿ ਸਮੱਸਿਆ ਉਦੋਂ ਨਹੀਂ ਵਾਪਰਦੀ ਜੇਕਰ, ਰਿਕਾਰਡਿੰਗ ਤੋਂ ਬਾਅਦ, ਤੁਸੀਂ ਫਲੱਸ਼ ਕਮਾਂਡ ਚਲਾਉਂਦੇ ਹੋ, ਜੋ ਕਿ ਮੇਮਸਟੋਰ ਨੂੰ ਡਿਸਕ 'ਤੇ ਰੀਸੈਟ ਕਰਦਾ ਹੈ, ਜਾਂ ਜੇਕਰ ਤੁਸੀਂ ਬਲਕਲੋਡ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਲੋਡ ਕਰਦੇ ਹੋ। ਹੇਠਾਂ ਦਿੱਤੀ ਸਾਰਣੀ ਦਰਸਾਉਂਦੀ ਹੈ ਕਿ ਮੈਮਸਟੋਰ ਤੋਂ ਵੱਡੇ (ਅਤੇ ਉਸੇ ਮਾਤਰਾ) ਡੇਟਾ ਲਈ ਪੁੱਛਗਿੱਛਾਂ ਦਾ ਨਤੀਜਾ ਮੰਦੀ ਦਾ ਕਾਰਨ ਬਣਦਾ ਹੈ। ਹਾਲਾਂਕਿ, ਚੰਕਸਾਈਜ਼ ਨੂੰ ਵਧਾ ਕੇ ਅਸੀਂ ਪ੍ਰੋਸੈਸਿੰਗ ਦੇ ਸਮੇਂ ਨੂੰ ਆਮ ਵਾਂਗ ਵਾਪਸ ਕਰ ਦਿੰਦੇ ਹਾਂ।

ਚੰਕਸਾਈਜ਼ ਨੂੰ ਵਧਾਉਣ ਤੋਂ ਇਲਾਵਾ, ਖੇਤਰ ਦੁਆਰਾ ਡੇਟਾ ਨੂੰ ਵੰਡਣਾ ਮਦਦ ਕਰਦਾ ਹੈ, ਯਾਨੀ. ਟੇਬਲ ਵੰਡਣਾ. ਇਸਦੇ ਨਤੀਜੇ ਵਜੋਂ ਹਰੇਕ ਖੇਤਰ ਵਿੱਚ ਘੱਟ ਬੇਨਤੀਆਂ ਆਉਂਦੀਆਂ ਹਨ ਅਤੇ ਜੇਕਰ ਉਹ ਇੱਕ ਸੈੱਲ ਵਿੱਚ ਫਿੱਟ ਹੁੰਦੀਆਂ ਹਨ, ਤਾਂ ਜਵਾਬ ਵਧੀਆ ਰਹਿੰਦਾ ਹੈ।

6. ਟੇਬਲ ਨੂੰ ਖੇਤਰਾਂ ਵਿੱਚ ਵੰਡਣ ਲਈ ਰਣਨੀਤੀ (ਵੰਡ ਕਰਨਾ)

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

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

1000001
1000002
...
1100003

ਕਿਉਂਕਿ ਕੁੰਜੀਆਂ ਨੂੰ ਇੱਕ ਬਾਈਟ ਐਰੇ ਵਜੋਂ ਸਟੋਰ ਕੀਤਾ ਜਾਂਦਾ ਹੈ, ਉਹ ਸਾਰੀਆਂ ਇੱਕੋ ਜਿਹੀਆਂ ਸ਼ੁਰੂ ਹੋਣਗੀਆਂ ਅਤੇ ਕੁੰਜੀਆਂ ਦੀ ਇਸ ਰੇਂਜ ਨੂੰ ਸਟੋਰ ਕਰਨ ਵਾਲੇ ਇੱਕੋ ਖੇਤਰ #1 ਨਾਲ ਸਬੰਧਤ ਹੋਣਗੀਆਂ। ਕਈ ਵਿਭਾਜਨ ਰਣਨੀਤੀਆਂ ਹਨ:

HexStringSplit - "00000000" => "FFFFFFFF" ਸੀਮਾ ਵਿੱਚ ਇੱਕ ਹੈਕਸਾਡੈਸੀਮਲ ਏਨਕੋਡ ਕੀਤੀ ਸਤਰ ਵਿੱਚ ਕੁੰਜੀ ਨੂੰ ਬਦਲਦਾ ਹੈ ਅਤੇ ਜ਼ੀਰੋ ਦੇ ਨਾਲ ਖੱਬੇ ਪਾਸੇ ਪੈਡਿੰਗ ਕਰਦਾ ਹੈ।

UniformSplit - "00" => "FF" ਰੇਂਜ ਵਿੱਚ ਹੈਕਸਾਡੈਸੀਮਲ ਏਨਕੋਡਿੰਗ ਅਤੇ ਜ਼ੀਰੋ ਦੇ ਨਾਲ ਸੱਜੇ ਪਾਸੇ ਪੈਡਿੰਗ ਨਾਲ ਕੁੰਜੀ ਨੂੰ ਇੱਕ ਬਾਈਟ ਐਰੇ ਵਿੱਚ ਬਦਲਦਾ ਹੈ।

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

ਹੈਸ਼ + ਰੋਕੀ

ਫਿਰ ਸਾਰਾ ਡਾਟਾ ਸਾਰੇ ਖੇਤਰਾਂ ਵਿੱਚ ਬਰਾਬਰ ਵੰਡਿਆ ਜਾਵੇਗਾ। ਪੜ੍ਹਦੇ ਸਮੇਂ, ਪਹਿਲੇ ਦੋ ਬਾਈਟਾਂ ਨੂੰ ਸਿਰਫ਼ ਰੱਦ ਕਰ ਦਿੱਤਾ ਜਾਂਦਾ ਹੈ ਅਤੇ ਅਸਲ ਕੁੰਜੀ ਰਹਿੰਦੀ ਹੈ। RS ਖੇਤਰ ਵਿੱਚ ਡੇਟਾ ਅਤੇ ਕੁੰਜੀਆਂ ਦੀ ਮਾਤਰਾ ਨੂੰ ਵੀ ਨਿਯੰਤਰਿਤ ਕਰਦਾ ਹੈ ਅਤੇ, ਜੇਕਰ ਸੀਮਾਵਾਂ ਨੂੰ ਪਾਰ ਕੀਤਾ ਜਾਂਦਾ ਹੈ, ਤਾਂ ਇਸਨੂੰ ਆਪਣੇ ਆਪ ਹਿੱਸਿਆਂ ਵਿੱਚ ਵੰਡਦਾ ਹੈ।

7. ਨੁਕਸ ਸਹਿਣਸ਼ੀਲਤਾ ਅਤੇ ਡਾਟਾ ਸਥਾਨ

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

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

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

ਟੈਸਟ 3 ਡਾਟਾ ਨੋਡਸ ਅਤੇ 4 RS (CPU Xeon E5-2680 v4 @ 2.40GHz * 64 ਥਰਿੱਡਾਂ) 'ਤੇ ਕੀਤਾ ਗਿਆ ਸੀ। HBase ਸੰਸਕਰਣ 1.2.0-cdh5.14.2

ਇਹ ਧਿਆਨ ਦੇਣ ਯੋਗ ਹੈ ਕਿ ਮੁੱਖ ਕੰਪੈਕਸ਼ਨ ਇੱਕ "ਲਾਈਵ" ਟੇਬਲ 'ਤੇ ਲਾਂਚ ਕੀਤਾ ਗਿਆ ਸੀ, ਜਿਸ ਵਿੱਚ ਡੇਟਾ ਨੂੰ ਸਰਗਰਮੀ ਨਾਲ ਲਿਖਿਆ ਅਤੇ ਪੜ੍ਹਿਆ ਗਿਆ ਸੀ। ਔਨਲਾਈਨ ਇੱਕ ਬਿਆਨ ਸੀ ਕਿ ਡੇਟਾ ਨੂੰ ਪੜ੍ਹਦੇ ਸਮੇਂ ਇਸ ਨਾਲ ਗਲਤ ਜਵਾਬ ਹੋ ਸਕਦਾ ਹੈ। ਜਾਂਚ ਕਰਨ ਲਈ, ਇੱਕ ਪ੍ਰਕਿਰਿਆ ਸ਼ੁਰੂ ਕੀਤੀ ਗਈ ਸੀ ਜਿਸ ਨੇ ਨਵਾਂ ਡੇਟਾ ਤਿਆਰ ਕੀਤਾ ਅਤੇ ਇਸਨੂੰ ਇੱਕ ਸਾਰਣੀ ਵਿੱਚ ਲਿਖਿਆ। ਜਿਸ ਤੋਂ ਬਾਅਦ ਮੈਂ ਤੁਰੰਤ ਪੜ੍ਹਿਆ ਅਤੇ ਜਾਂਚ ਕੀਤੀ ਕਿ ਕੀ ਨਤੀਜਾ ਮੁੱਲ ਲਿਖਿਆ ਗਿਆ ਸੀ ਨਾਲ ਮੇਲ ਖਾਂਦਾ ਹੈ. ਜਦੋਂ ਇਹ ਪ੍ਰਕਿਰਿਆ ਚੱਲ ਰਹੀ ਸੀ, ਮੇਜਰ ਕੰਪੈਕਸ਼ਨ ਲਗਭਗ 200 ਵਾਰ ਚਲਾਇਆ ਗਿਆ ਸੀ ਅਤੇ ਇੱਕ ਵੀ ਅਸਫਲਤਾ ਦਰਜ ਨਹੀਂ ਕੀਤੀ ਗਈ ਸੀ। ਸ਼ਾਇਦ ਇਹ ਸਮੱਸਿਆ ਬਹੁਤ ਘੱਟ ਅਤੇ ਸਿਰਫ ਉੱਚ ਲੋਡ ਦੇ ਦੌਰਾਨ ਦਿਖਾਈ ਦਿੰਦੀ ਹੈ, ਇਸ ਲਈ ਯੋਜਨਾ ਅਨੁਸਾਰ ਲਿਖਣ ਅਤੇ ਪੜ੍ਹਨ ਦੀਆਂ ਪ੍ਰਕਿਰਿਆਵਾਂ ਨੂੰ ਰੋਕਣਾ ਅਤੇ ਅਜਿਹੇ GC ਡਰਾਅਡਾਊਨ ਨੂੰ ਰੋਕਣ ਲਈ ਸਫਾਈ ਕਰਨਾ ਸੁਰੱਖਿਅਤ ਹੈ।

ਨਾਲ ਹੀ, ਮੁੱਖ ਕੰਪੈਕਸ਼ਨ ਮੇਮਸਟੋਰ ਦੀ ਸਥਿਤੀ ਨੂੰ ਪ੍ਰਭਾਵਤ ਨਹੀਂ ਕਰਦਾ ਹੈ; ਇਸਨੂੰ ਡਿਸਕ 'ਤੇ ਫਲੱਸ਼ ਕਰਨ ਅਤੇ ਇਸ ਨੂੰ ਸੰਕੁਚਿਤ ਕਰਨ ਲਈ, ਤੁਹਾਨੂੰ ਫਲੱਸ਼ (connection.getAdmin().flush(TableName.valueOf(tblName))) ਦੀ ਵਰਤੋਂ ਕਰਨ ਦੀ ਲੋੜ ਹੈ।

8. ਸੈਟਿੰਗਾਂ ਅਤੇ ਪ੍ਰਦਰਸ਼ਨ

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

• 10 ਥ੍ਰੈੱਡਾਂ ਨੂੰ ਇੱਕ ਕਤਾਰ ਵਿੱਚ 3 ਵਾਰ ਇੱਕੋ ਸਮੇਂ ਲਾਂਚ ਕੀਤਾ ਗਿਆ ਸੀ (ਆਓ ਇਸਨੂੰ ਥਰਿੱਡਾਂ ਦਾ ਇੱਕ ਬਲਾਕ ਕਹੀਏ)।
• ਇੱਕ ਬਲਾਕ ਵਿੱਚ ਸਾਰੇ ਥ੍ਰੈੱਡਾਂ ਦਾ ਓਪਰੇਟਿੰਗ ਸਮਾਂ ਔਸਤ ਕੀਤਾ ਗਿਆ ਸੀ ਅਤੇ ਬਲਾਕ ਦੇ ਸੰਚਾਲਨ ਦਾ ਅੰਤਮ ਨਤੀਜਾ ਸੀ।
• ਸਾਰੇ ਥਰਿੱਡ ਇੱਕੋ ਸਾਰਣੀ ਨਾਲ ਕੰਮ ਕਰਦੇ ਹਨ।
• ਥ੍ਰੈੱਡ ਬਲਾਕ ਦੀ ਹਰੇਕ ਸ਼ੁਰੂਆਤ ਤੋਂ ਪਹਿਲਾਂ, ਇੱਕ ਪ੍ਰਮੁੱਖ ਸੰਕੁਚਿਤ ਕੀਤਾ ਗਿਆ ਸੀ.
• ਹਰੇਕ ਬਲਾਕ ਨੇ ਹੇਠ ਲਿਖੀਆਂ ਕਾਰਵਾਈਆਂ ਵਿੱਚੋਂ ਸਿਰਫ਼ ਇੱਕ ਹੀ ਕੀਤਾ:

- ਪਾਓ
- ਪ੍ਰਾਪਤ ਕਰੋ
—Get+Put

• ਹਰੇਕ ਬਲਾਕ ਨੇ ਆਪਣੀ ਕਾਰਵਾਈ ਦੇ 50 ਦੁਹਰਾਓ ਕੀਤੇ।
• ਇੱਕ ਰਿਕਾਰਡ ਦਾ ਬਲਾਕ ਆਕਾਰ 100 ਬਾਈਟ, 1000 ਬਾਈਟ ਜਾਂ 10000 ਬਾਈਟ (ਬੇਤਰਤੀਬ) ਹੈ।
• ਬੇਨਤੀ ਕੀਤੀਆਂ ਕੁੰਜੀਆਂ (ਜਾਂ ਤਾਂ ਇੱਕ ਕੁੰਜੀ ਜਾਂ 10) ਦੇ ਨਾਲ ਬਲਾਕ ਲਾਂਚ ਕੀਤੇ ਗਏ ਸਨ।
• ਬਲਾਕ ਵੱਖ-ਵੱਖ ਟੇਬਲ ਸੈਟਿੰਗਾਂ ਦੇ ਤਹਿਤ ਚਲਾਏ ਗਏ ਸਨ। ਪੈਰਾਮੀਟਰ ਬਦਲੇ ਗਏ:

— BlockCache = ਚਾਲੂ ਜਾਂ ਬੰਦ
- ਬਲਾਕਸਾਈਜ਼ = 65 KB ਜਾਂ 16 KB
— ਭਾਗ = 1, 5 ਜਾਂ 30
— MSLAB = ਯੋਗ ਜਾਂ ਅਯੋਗ

ਇਸ ਲਈ ਬਲਾਕ ਇਸ ਤਰ੍ਹਾਂ ਦਿਖਦਾ ਹੈ:

a MSLAB ਮੋਡ ਚਾਲੂ/ਬੰਦ ਕੀਤਾ ਗਿਆ ਸੀ।
ਬੀ. ਇੱਕ ਸਾਰਣੀ ਬਣਾਈ ਗਈ ਸੀ ਜਿਸ ਲਈ ਹੇਠਾਂ ਦਿੱਤੇ ਮਾਪਦੰਡ ਸੈੱਟ ਕੀਤੇ ਗਏ ਸਨ: ਬਲਾਕਕੈਚ = ਸਹੀ/ਕੋਈ ਨਹੀਂ, ਬਲਾਕਸਾਈਜ਼ = 65/16 Kb, ਭਾਗ = 1/5/30।
c. ਕੰਪਰੈਸ਼ਨ GZ 'ਤੇ ਸੈੱਟ ਕੀਤਾ ਗਿਆ ਸੀ।
d. ਇਸ ਸਾਰਣੀ ਵਿੱਚ 10/1/10 ਬਾਈਟਸ ਦੇ ਰਿਕਾਰਡਾਂ ਦੇ ਨਾਲ 100/1000 ਪੁਟ/ਗੇਟ/ਗੇਟ+ਪੁਟ ਓਪਰੇਸ਼ਨ ਕਰਦੇ ਹੋਏ, ਇੱਕ ਕਤਾਰ ਵਿੱਚ 10000 ਸਵਾਲਾਂ (ਰੈਂਡਮ ਕੁੰਜੀਆਂ) ਕਰਦੇ ਹੋਏ 50 ਥ੍ਰੈੱਡ ਇੱਕੋ ਸਮੇਂ ਲਾਂਚ ਕੀਤੇ ਗਏ ਸਨ।
ਈ. ਪੁਆਇੰਟ ਡੀ ਨੂੰ ਤਿੰਨ ਵਾਰ ਦੁਹਰਾਇਆ ਗਿਆ ਸੀ।
f. ਸਾਰੇ ਥ੍ਰੈੱਡਾਂ ਦਾ ਓਪਰੇਟਿੰਗ ਸਮਾਂ ਔਸਤ ਕੀਤਾ ਗਿਆ ਸੀ।

ਸਾਰੇ ਸੰਭਵ ਸੰਜੋਗਾਂ ਦੀ ਜਾਂਚ ਕੀਤੀ ਗਈ। ਇਹ ਅਨੁਮਾਨ ਲਗਾਇਆ ਜਾ ਸਕਦਾ ਹੈ ਕਿ ਰਿਕਾਰਡ ਦਾ ਆਕਾਰ ਵਧਣ ਨਾਲ ਗਤੀ ਘਟੇਗੀ, ਜਾਂ ਕੈਚਿੰਗ ਨੂੰ ਅਯੋਗ ਕਰਨ ਨਾਲ ਸੁਸਤੀ ਆਵੇਗੀ। ਹਾਲਾਂਕਿ, ਟੀਚਾ ਹਰੇਕ ਪੈਰਾਮੀਟਰ ਦੇ ਪ੍ਰਭਾਵ ਦੀ ਡਿਗਰੀ ਅਤੇ ਮਹੱਤਤਾ ਨੂੰ ਸਮਝਣਾ ਸੀ, ਇਸਲਈ ਇਕੱਤਰ ਕੀਤੇ ਡੇਟਾ ਨੂੰ ਇੱਕ ਲੀਨੀਅਰ ਰਿਗਰੈਸ਼ਨ ਫੰਕਸ਼ਨ ਦੇ ਇਨਪੁਟ ਵਿੱਚ ਫੀਡ ਕੀਤਾ ਗਿਆ ਸੀ, ਜੋ ਟੀ-ਅੰਕੜਿਆਂ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਮਹੱਤਤਾ ਦਾ ਮੁਲਾਂਕਣ ਕਰਨਾ ਸੰਭਵ ਬਣਾਉਂਦਾ ਹੈ। ਹੇਠਾਂ ਪੁਟ ਓਪਰੇਸ਼ਨ ਕਰਨ ਵਾਲੇ ਬਲਾਕਾਂ ਦੇ ਨਤੀਜੇ ਹਨ। ਸੰਜੋਗਾਂ ਦਾ ਪੂਰਾ ਸੈੱਟ 2*2*3*2*3 = 144 ਵਿਕਲਪ + 72 tk। ਕੁਝ ਦੋ ਵਾਰ ਕੀਤੇ ਗਏ ਸਨ। ਇਸ ਲਈ, ਕੁੱਲ 216 ਦੌੜਾਂ:

ਟੈਸਟਿੰਗ ਇੱਕ ਮਿੰਨੀ-ਕਲੱਸਟਰ 'ਤੇ ਕੀਤੀ ਗਈ ਸੀ ਜਿਸ ਵਿੱਚ 3 ਡਾਟਾ ਨੋਡ ਅਤੇ 4 RS (CPU Xeon E5-2680 v4 @ 2.40GHz * 64 ਥ੍ਰੈੱਡਸ) ਸ਼ਾਮਲ ਸਨ। HBase ਸੰਸਕਰਣ 1.2.0-cdh5.14.2.

3.7 ਸਕਿੰਟਾਂ ਦੀ ਸਭ ਤੋਂ ਵੱਧ ਸੰਮਿਲਨ ਗਤੀ MSLAB ਮੋਡ ਨੂੰ ਬੰਦ ਕਰਕੇ, ਇੱਕ ਭਾਗ ਵਾਲੀ ਟੇਬਲ 'ਤੇ, ਬਲਾਕਕੈਚ ਸਮਰਥਿਤ, ਬਲਾਕਸਾਈਜ਼ = 16, 100 ਬਾਈਟਾਂ ਦੇ ਰਿਕਾਰਡ, ਪ੍ਰਤੀ ਪੈਕ 10 ਟੁਕੜੇ ਦੇ ਨਾਲ ਪ੍ਰਾਪਤ ਕੀਤੀ ਗਈ ਸੀ।
82.8 ਸਕਿੰਟ ਦੀ ਸਭ ਤੋਂ ਘੱਟ ਸੰਮਿਲਨ ਗਤੀ MSLAB ਮੋਡ ਸਮਰਥਿਤ, ਇੱਕ ਭਾਗ ਦੇ ਨਾਲ ਇੱਕ ਟੇਬਲ 'ਤੇ, ਬਲਾਕਕੈਚ ਸਮਰਥਿਤ, ਬਲਾਕਸਾਈਜ਼ = 16, 10000 ਬਾਈਟਸ ਦੇ ਰਿਕਾਰਡ, ਹਰੇਕ 1 ਦੇ ਨਾਲ ਪ੍ਰਾਪਤ ਕੀਤੀ ਗਈ ਸੀ।

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

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

ਆਉ ਹੁਣ Get blocks ਨੂੰ ਚਲਾਉਣ ਦੇ ਨਤੀਜਿਆਂ ਦਾ ਮੁਲਾਂਕਣ ਕਰੀਏ:

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

ਖੈਰ, ਅੰਤ ਵਿੱਚ, ਆਓ ਬਲਾਕ ਦੇ ਮਾਡਲ ਨੂੰ ਵੇਖੀਏ ਜਿਸਨੇ ਪਹਿਲਾਂ ਪ੍ਰਦਰਸ਼ਨ ਕੀਤਾ ਅਤੇ ਫਿਰ ਪਾਇਆ:

ਇੱਥੇ ਸਾਰੇ ਮਾਪਦੰਡ ਮਹੱਤਵਪੂਰਨ ਹਨ। ਅਤੇ ਨੇਤਾਵਾਂ ਦੇ ਨਤੀਜੇ:

9. ਲੋਡ ਟੈਸਟਿੰਗ

ਖੈਰ, ਅੰਤ ਵਿੱਚ ਅਸੀਂ ਇੱਕ ਘੱਟ ਜਾਂ ਘੱਟ ਵਿਨੀਤ ਲੋਡ ਲਾਂਚ ਕਰਾਂਗੇ, ਪਰ ਇਹ ਹਮੇਸ਼ਾਂ ਵਧੇਰੇ ਦਿਲਚਸਪ ਹੁੰਦਾ ਹੈ ਜਦੋਂ ਤੁਹਾਡੇ ਕੋਲ ਤੁਲਨਾ ਕਰਨ ਲਈ ਕੁਝ ਹੁੰਦਾ ਹੈ। DataStax ਦੀ ਵੈੱਬਸਾਈਟ 'ਤੇ, Cassandra ਦੇ ਮੁੱਖ ਡਿਵੈਲਪਰ, ਉੱਥੇ ਹੈ ਨਤੀਜੇ HBase ਸੰਸਕਰਣ 0.98.6-1 ਸਮੇਤ ਕਈ NoSQL ਸਟੋਰੇਜ ਦਾ NT। ਲੋਡਿੰਗ 40 ਥ੍ਰੈੱਡਾਂ, ਡਾਟਾ ਸਾਈਜ਼ 100 ਬਾਈਟਸ, SSD ਡਿਸਕਾਂ ਦੁਆਰਾ ਕੀਤੀ ਗਈ ਸੀ। ਰੀਡ-ਮੋਡੀਫਾਈ-ਰਾਈਟ ਓਪਰੇਸ਼ਨਾਂ ਦੀ ਜਾਂਚ ਦੇ ਨਤੀਜੇ ਹੇਠ ਦਿੱਤੇ ਨਤੀਜੇ ਦਿਖਾਉਂਦੇ ਹਨ।

ਜਿੱਥੋਂ ਤੱਕ ਮੈਂ ਸਮਝਦਾ ਹਾਂ, ਰੀਡਿੰਗ 100 ਰਿਕਾਰਡਾਂ ਦੇ ਬਲਾਕਾਂ ਵਿੱਚ ਕੀਤੀ ਗਈ ਸੀ ਅਤੇ 16 HBase ਨੋਡਾਂ ਲਈ, DataStax ਟੈਸਟ ਨੇ ਪ੍ਰਤੀ ਸਕਿੰਟ 10 ਹਜ਼ਾਰ ਓਪਰੇਸ਼ਨਾਂ ਦੀ ਕਾਰਗੁਜ਼ਾਰੀ ਦਿਖਾਈ।

ਇਹ ਖੁਸ਼ਕਿਸਮਤੀ ਵਾਲੀ ਗੱਲ ਹੈ ਕਿ ਸਾਡੇ ਕਲੱਸਟਰ ਵਿੱਚ ਵੀ 16 ਨੋਡ ਹਨ, ਪਰ ਇਹ ਬਹੁਤ "ਖੁਸ਼ਕਿਸਮਤ" ਨਹੀਂ ਹੈ ਕਿ ਹਰੇਕ ਵਿੱਚ 64 ਕੋਰ (ਥ੍ਰੈੱਡ) ਹਨ, ਜਦੋਂ ਕਿ ਡੇਟਾਸਟੈਕਸ ਟੈਸਟ ਵਿੱਚ ਸਿਰਫ 4 ਹਨ। ਦੂਜੇ ਪਾਸੇ, ਉਹਨਾਂ ਕੋਲ SSD ਡਰਾਈਵਾਂ ਹਨ, ਜਦੋਂ ਕਿ ਸਾਡੇ ਕੋਲ ਐਚ.ਡੀ.ਡੀ. ਜਾਂ ਇਸ ਤੋਂ ਵੱਧ ਲੋਡ ਦੌਰਾਨ HBase ਅਤੇ CPU ਦੀ ਵਰਤੋਂ ਦਾ ਨਵਾਂ ਸੰਸਕਰਣ ਅਮਲੀ ਤੌਰ 'ਤੇ ਮਹੱਤਵਪੂਰਨ ਤੌਰ 'ਤੇ (5-10 ਪ੍ਰਤੀਸ਼ਤ ਤੱਕ) ਨਹੀਂ ਵਧਿਆ। ਹਾਲਾਂਕਿ, ਆਓ ਇਸ ਸੰਰਚਨਾ ਦੀ ਵਰਤੋਂ ਸ਼ੁਰੂ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰੀਏ। ਡਿਫੌਲਟ ਟੇਬਲ ਸੈਟਿੰਗਾਂ, ਰੀਡਿੰਗ ਕੁੰਜੀ ਰੇਂਜ ਵਿੱਚ 0 ਤੋਂ 50 ਮਿਲੀਅਨ ਤੱਕ ਬੇਤਰਤੀਬੇ ਤੌਰ 'ਤੇ ਕੀਤੀ ਜਾਂਦੀ ਹੈ (ਅਰਥਾਤ, ਹਰ ਵਾਰ ਜ਼ਰੂਰੀ ਤੌਰ 'ਤੇ ਨਵਾਂ)। ਸਾਰਣੀ ਵਿੱਚ 50 ਮਿਲੀਅਨ ਰਿਕਾਰਡ ਹਨ, 64 ਭਾਗਾਂ ਵਿੱਚ ਵੰਡੇ ਗਏ ਹਨ। ਕੁੰਜੀਆਂ crc32 ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਹੈਸ਼ ਕੀਤੀਆਂ ਜਾਂਦੀਆਂ ਹਨ। ਸਾਰਣੀ ਸੈਟਿੰਗਾਂ ਪੂਰਵ-ਨਿਰਧਾਰਤ ਹਨ, MSLAB ਸਮਰਥਿਤ ਹੈ। 40 ਥ੍ਰੈੱਡਾਂ ਨੂੰ ਲਾਂਚ ਕਰਨਾ, ਹਰੇਕ ਥ੍ਰੈਡ 100 ਬੇਤਰਤੀਬ ਕੁੰਜੀਆਂ ਦਾ ਇੱਕ ਸੈੱਟ ਪੜ੍ਹਦਾ ਹੈ ਅਤੇ ਤੁਰੰਤ ਤਿਆਰ ਕੀਤੀਆਂ 100 ਬਾਈਟਾਂ ਨੂੰ ਇਹਨਾਂ ਕੁੰਜੀਆਂ 'ਤੇ ਵਾਪਸ ਲਿਖ ਦਿੰਦਾ ਹੈ।

ਸਟੈਂਡ: 16 ਡਾਟਾ ਨੋਡ ਅਤੇ 16 RS (CPU Xeon E5-2680 v4 @ 2.40GHz * 64 ਥ੍ਰੈੱਡਸ)। HBase ਸੰਸਕਰਣ 1.2.0-cdh5.14.2.

ਔਸਤ ਨਤੀਜਾ 40 ਹਜ਼ਾਰ ਓਪਰੇਸ਼ਨ ਪ੍ਰਤੀ ਸਕਿੰਟ ਦੇ ਨੇੜੇ ਹੈ, ਜੋ ਕਿ ਡਾਟਾਸਟੈਕਸ ਟੈਸਟ ਦੇ ਮੁਕਾਬਲੇ ਕਾਫ਼ੀ ਬਿਹਤਰ ਹੈ। ਹਾਲਾਂਕਿ, ਪ੍ਰਯੋਗਾਤਮਕ ਉਦੇਸ਼ਾਂ ਲਈ, ਤੁਸੀਂ ਸ਼ਰਤਾਂ ਨੂੰ ਥੋੜ੍ਹਾ ਬਦਲ ਸਕਦੇ ਹੋ. ਇਹ ਪੂਰੀ ਤਰ੍ਹਾਂ ਅਸੰਭਵ ਹੈ ਕਿ ਸਾਰਾ ਕੰਮ ਸਿਰਫ਼ ਇੱਕ ਮੇਜ਼ 'ਤੇ ਕੀਤਾ ਜਾਵੇਗਾ, ਅਤੇ ਸਿਰਫ਼ ਵਿਲੱਖਣ ਕੁੰਜੀਆਂ 'ਤੇ ਵੀ. ਚਲੋ ਇਹ ਮੰਨ ਲਓ ਕਿ ਇੱਥੇ ਇੱਕ ਖਾਸ "ਗਰਮ" ਕੁੰਜੀਆਂ ਦਾ ਸੈੱਟ ਹੈ ਜੋ ਮੁੱਖ ਲੋਡ ਬਣਾਉਂਦਾ ਹੈ। ਇਸ ਲਈ, ਆਉ 10 ਦੇ ਬੈਚਾਂ ਵਿੱਚ, 100 ਵੱਖ-ਵੱਖ ਟੇਬਲਾਂ ਵਿੱਚ ਅਤੇ ਬੇਨਤੀ ਕੀਤੀ ਕੁੰਜੀਆਂ ਦੀ ਰੇਂਜ ਨੂੰ 4 ਹਜ਼ਾਰ ਤੱਕ ਸੀਮਿਤ ਕਰਦੇ ਹੋਏ, ਵੱਡੇ ਰਿਕਾਰਡਾਂ (50 KB) ਦੇ ਨਾਲ ਇੱਕ ਲੋਡ ਬਣਾਉਣ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰੀਏ, ਹਰ ਇੱਕ ਥ੍ਰੈਡ ਪੜ੍ਹਦਾ ਹੈ 40 ਕੁੰਜੀਆਂ ਦਾ ਇੱਕ ਸੈੱਟ ਅਤੇ ਤੁਰੰਤ ਇਹਨਾਂ ਕੁੰਜੀਆਂ 'ਤੇ ਬੇਤਰਤੀਬ 100 KB ਲਿਖਦਾ ਹੈ।

ਸਟੈਂਡ: 16 ਡਾਟਾ ਨੋਡ ਅਤੇ 16 RS (CPU Xeon E5-2680 v4 @ 2.40GHz * 64 ਥ੍ਰੈੱਡਸ)। HBase ਸੰਸਕਰਣ 1.2.0-cdh5.14.2.

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

ਪੜ੍ਹਨਾ ਅਤੇ ਤੁਰੰਤ ਲਿਖਣਾ HBase ਲਈ ਸਭ ਤੋਂ ਮੁਸ਼ਕਲ ਕੰਮ ਦੇ ਦ੍ਰਿਸ਼ਾਂ ਵਿੱਚੋਂ ਇੱਕ ਹੈ। ਜੇਕਰ ਤੁਸੀਂ ਸਿਰਫ਼ ਛੋਟੀਆਂ ਪੁਟ ਬੇਨਤੀਆਂ ਕਰਦੇ ਹੋ, ਉਦਾਹਰਨ ਲਈ 100 ਬਾਈਟ, ਉਹਨਾਂ ਨੂੰ 10-50 ਹਜ਼ਾਰ ਟੁਕੜਿਆਂ ਦੇ ਪੈਕ ਵਿੱਚ ਜੋੜਦੇ ਹੋਏ, ਤੁਸੀਂ ਪ੍ਰਤੀ ਸਕਿੰਟ ਹਜ਼ਾਰਾਂ ਓਪਰੇਸ਼ਨ ਪ੍ਰਾਪਤ ਕਰ ਸਕਦੇ ਹੋ, ਅਤੇ ਸਥਿਤੀ ਸਿਰਫ਼-ਪੜ੍ਹਨ ਲਈ ਬੇਨਤੀਆਂ ਦੇ ਸਮਾਨ ਹੈ। ਇਹ ਧਿਆਨ ਦੇਣ ਯੋਗ ਹੈ ਕਿ ਨਤੀਜੇ ਡੇਟਾਸਟੈਕਸ ਦੁਆਰਾ ਪ੍ਰਾਪਤ ਕੀਤੇ ਗਏ ਨਤੀਜਿਆਂ ਨਾਲੋਂ ਬਹੁਤ ਵਧੀਆ ਹਨ, ਸਭ ਤੋਂ ਵੱਧ 50 ਹਜ਼ਾਰ ਦੇ ਬਲਾਕਾਂ ਵਿੱਚ ਬੇਨਤੀਆਂ ਦੇ ਕਾਰਨ.

ਸਟੈਂਡ: 16 ਡਾਟਾ ਨੋਡ ਅਤੇ 16 RS (CPU Xeon E5-2680 v4 @ 2.40GHz * 64 ਥ੍ਰੈੱਡਸ)। HBase ਸੰਸਕਰਣ 1.2.0-cdh5.14.2.

10. ਸਿੱਟਾ

ਇਹ ਸਿਸਟਮ ਕਾਫ਼ੀ ਲਚਕਦਾਰ ਢੰਗ ਨਾਲ ਕੌਂਫਿਗਰ ਕੀਤਾ ਗਿਆ ਹੈ, ਪਰ ਪੈਰਾਮੀਟਰਾਂ ਦੀ ਇੱਕ ਵੱਡੀ ਗਿਣਤੀ ਦਾ ਪ੍ਰਭਾਵ ਅਜੇ ਵੀ ਅਣਜਾਣ ਹੈ। ਉਹਨਾਂ ਵਿੱਚੋਂ ਕੁਝ ਦੀ ਜਾਂਚ ਕੀਤੀ ਗਈ ਸੀ, ਪਰ ਨਤੀਜੇ ਵਜੋਂ ਟੈਸਟ ਸੈੱਟ ਵਿੱਚ ਸ਼ਾਮਲ ਨਹੀਂ ਕੀਤੇ ਗਏ ਸਨ। ਉਦਾਹਰਨ ਲਈ, ਸ਼ੁਰੂਆਤੀ ਪ੍ਰਯੋਗਾਂ ਨੇ DATA_BLOCK_ENCODING ਵਰਗੇ ਪੈਰਾਮੀਟਰ ਦੀ ਮਾਮੂਲੀ ਮਹੱਤਤਾ ਦਿਖਾਈ, ਜੋ ਕਿ ਗੁਆਂਢੀ ਸੈੱਲਾਂ ਤੋਂ ਮੁੱਲਾਂ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਜਾਣਕਾਰੀ ਨੂੰ ਏਨਕੋਡ ਕਰਦਾ ਹੈ, ਜੋ ਕਿ ਬੇਤਰਤੀਬੇ ਤੌਰ 'ਤੇ ਤਿਆਰ ਕੀਤੇ ਡੇਟਾ ਲਈ ਸਮਝਣ ਯੋਗ ਹੈ। ਜੇ ਤੁਸੀਂ ਵੱਡੀ ਗਿਣਤੀ ਵਿੱਚ ਡੁਪਲੀਕੇਟ ਵਸਤੂਆਂ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹੋ, ਤਾਂ ਲਾਭ ਮਹੱਤਵਪੂਰਨ ਹੋ ਸਕਦਾ ਹੈ। ਆਮ ਤੌਰ 'ਤੇ, ਅਸੀਂ ਕਹਿ ਸਕਦੇ ਹਾਂ ਕਿ HBase ਇੱਕ ਕਾਫ਼ੀ ਗੰਭੀਰ ਅਤੇ ਚੰਗੀ ਤਰ੍ਹਾਂ ਸੋਚਿਆ-ਸਮਝਿਆ ਡਾਟਾਬੇਸ ਦਾ ਪ੍ਰਭਾਵ ਦਿੰਦਾ ਹੈ, ਜੋ ਡੇਟਾ ਦੇ ਵੱਡੇ ਬਲਾਕਾਂ ਦੇ ਨਾਲ ਓਪਰੇਸ਼ਨ ਕਰਨ ਵੇਲੇ ਕਾਫ਼ੀ ਲਾਭਕਾਰੀ ਹੋ ਸਕਦਾ ਹੈ। ਖਾਸ ਕਰਕੇ ਜੇ ਸਮੇਂ ਵਿੱਚ ਪੜ੍ਹਨ ਅਤੇ ਲਿਖਣ ਦੀਆਂ ਪ੍ਰਕਿਰਿਆਵਾਂ ਨੂੰ ਵੱਖ ਕਰਨਾ ਸੰਭਵ ਹੋਵੇ।

ਜੇ ਤੁਹਾਡੇ ਵਿਚਾਰ ਵਿੱਚ ਕੋਈ ਅਜਿਹੀ ਚੀਜ਼ ਹੈ ਜਿਸਦਾ ਖੁਲਾਸਾ ਕਾਫ਼ੀ ਨਹੀਂ ਹੈ, ਤਾਂ ਮੈਂ ਤੁਹਾਨੂੰ ਵਧੇਰੇ ਵਿਸਥਾਰ ਵਿੱਚ ਦੱਸਣ ਲਈ ਤਿਆਰ ਹਾਂ। ਅਸੀਂ ਤੁਹਾਨੂੰ ਆਪਣਾ ਅਨੁਭਵ ਸਾਂਝਾ ਕਰਨ ਜਾਂ ਚਰਚਾ ਕਰਨ ਲਈ ਸੱਦਾ ਦਿੰਦੇ ਹਾਂ ਜੇਕਰ ਤੁਸੀਂ ਕਿਸੇ ਚੀਜ਼ ਨਾਲ ਅਸਹਿਮਤ ਹੋ।

ਸਰੋਤ: www.habr.com