ಪ್ರೊಹೋಸ್ಟರ್ > Блог > ಆಡಳಿತ > ಎರಡು ಯಾಕೋಜುನ ಕದನ, ಅಥವಾ ಕಸ್ಸಂದ್ರ vs HBase. Sberbank ತಂಡದ ಅನುಭವ

ಎರಡು ಯಾಕೋಜುನ ಕದನ, ಅಥವಾ ಕಸ್ಸಂದ್ರ vs HBase. Sberbank ತಂಡದ ಅನುಭವ

ಇದು ತಮಾಷೆಯೂ ಅಲ್ಲ, ಈ ನಿರ್ದಿಷ್ಟ ಚಿತ್ರವು ಈ ಡೇಟಾಬೇಸ್‌ಗಳ ಸಾರವನ್ನು ಹೆಚ್ಚು ನಿಖರವಾಗಿ ಪ್ರತಿಬಿಂಬಿಸುತ್ತದೆ ಎಂದು ತೋರುತ್ತದೆ, ಮತ್ತು ಕೊನೆಯಲ್ಲಿ ಅದು ಏಕೆ ಸ್ಪಷ್ಟವಾಗುತ್ತದೆ:

ಎರಡು ಯಾಕೋಜುನ ಕದನ, ಅಥವಾ ಕಸ್ಸಂದ್ರ vs HBase. Sberbank ತಂಡದ ಅನುಭವ

DB-ಎಂಜಿನ್‌ಗಳ ಶ್ರೇಯಾಂಕದ ಪ್ರಕಾರ, ಎರಡು ಅತ್ಯಂತ ಜನಪ್ರಿಯ NoSQL ಸ್ತಂಭಾಕಾರದ ಡೇಟಾಬೇಸ್‌ಗಳೆಂದರೆ ಕಸ್ಸಂದ್ರ (ಇನ್ನು ಮುಂದೆ CS) ಮತ್ತು HBase (HB).

ಎರಡು ಯಾಕೋಜುನ ಕದನ, ಅಥವಾ ಕಸ್ಸಂದ್ರ vs HBase. Sberbank ತಂಡದ ಅನುಭವ

ವಿಧಿಯ ಇಚ್ಛೆಯಿಂದ, Sberbank ನಲ್ಲಿ ನಮ್ಮ ಡೇಟಾ ಲೋಡಿಂಗ್ ನಿರ್ವಹಣೆ ತಂಡವು ಈಗಾಗಲೇ ಹೊಂದಿದೆ давно ಮತ್ತು HB ಯೊಂದಿಗೆ ನಿಕಟವಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ. ಈ ಸಮಯದಲ್ಲಿ, ನಾವು ಅದರ ಸಾಮರ್ಥ್ಯ ಮತ್ತು ದೌರ್ಬಲ್ಯಗಳನ್ನು ಚೆನ್ನಾಗಿ ಅಧ್ಯಯನ ಮಾಡಿದ್ದೇವೆ ಮತ್ತು ಅದನ್ನು ಹೇಗೆ ಬೇಯಿಸುವುದು ಎಂದು ಕಲಿತಿದ್ದೇವೆ. ಹೇಗಾದರೂ, ಸಿಎಸ್ ರೂಪದಲ್ಲಿ ಪರ್ಯಾಯದ ಉಪಸ್ಥಿತಿಯು ಯಾವಾಗಲೂ ನಮ್ಮನ್ನು ಸ್ವಲ್ಪ ಸಂದೇಹದಿಂದ ಹಿಂಸಿಸುವಂತೆ ಒತ್ತಾಯಿಸುತ್ತದೆ: ನಾವು ಸರಿಯಾದ ಆಯ್ಕೆ ಮಾಡಿದ್ದೇವೆಯೇ? ಇದಲ್ಲದೆ, ಫಲಿತಾಂಶಗಳು ಹೋಲಿಕೆಗಳು, DataStax ನಿರ್ವಹಿಸಿದ, CS ಸುಲಭವಾಗಿ HB ಅನ್ನು ಬಹುತೇಕ ಕ್ರಶಿಂಗ್ ಸ್ಕೋರ್‌ನೊಂದಿಗೆ ಸೋಲಿಸುತ್ತದೆ ಎಂದು ಅವರು ಹೇಳಿದರು. ಮತ್ತೊಂದೆಡೆ, DataStax ಆಸಕ್ತ ಪಕ್ಷವಾಗಿದೆ ಮತ್ತು ಅದಕ್ಕಾಗಿ ನೀವು ಅವರ ಮಾತನ್ನು ತೆಗೆದುಕೊಳ್ಳಬಾರದು. ಪರೀಕ್ಷಾ ಪರಿಸ್ಥಿತಿಗಳ ಬಗ್ಗೆ ಕಡಿಮೆ ಪ್ರಮಾಣದ ಮಾಹಿತಿಯಿಂದ ನಾವು ಗೊಂದಲಕ್ಕೊಳಗಾಗಿದ್ದೇವೆ, ಆದ್ದರಿಂದ ನಾವು BigData NoSql ನ ರಾಜ ಯಾರು ಎಂದು ನಮ್ಮದೇ ಆದ ಮೇಲೆ ಕಂಡುಹಿಡಿಯಲು ನಿರ್ಧರಿಸಿದ್ದೇವೆ ಮತ್ತು ಪಡೆದ ಫಲಿತಾಂಶಗಳು ತುಂಬಾ ಆಸಕ್ತಿದಾಯಕವಾಗಿವೆ.

ಆದಾಗ್ಯೂ, ನಡೆಸಿದ ಪರೀಕ್ಷೆಗಳ ಫಲಿತಾಂಶಗಳಿಗೆ ತೆರಳುವ ಮೊದಲು, ಪರಿಸರ ಸಂರಚನೆಗಳ ಗಮನಾರ್ಹ ಅಂಶಗಳನ್ನು ವಿವರಿಸಲು ಇದು ಅವಶ್ಯಕವಾಗಿದೆ. ಡೇಟಾ ನಷ್ಟವನ್ನು ಅನುಮತಿಸುವ ಮೋಡ್‌ನಲ್ಲಿ ಸಿಎಸ್ ಅನ್ನು ಬಳಸಬಹುದು ಎಂಬುದು ಸತ್ಯ. ಆ. ಒಂದು ನಿರ್ದಿಷ್ಟ ಕೀಲಿಯ ಡೇಟಾಕ್ಕೆ ಕೇವಲ ಒಂದು ಸರ್ವರ್ (ನೋಡ್) ಜವಾಬ್ದಾರರಾಗಿರುವಾಗ ಮತ್ತು ಕೆಲವು ಕಾರಣಗಳಿಂದ ಅದು ವಿಫಲವಾದರೆ, ಈ ಕೀಲಿಯ ಮೌಲ್ಯವು ಕಳೆದುಹೋಗುತ್ತದೆ. ಅನೇಕ ಕಾರ್ಯಗಳಿಗೆ ಇದು ನಿರ್ಣಾಯಕವಲ್ಲ, ಆದರೆ ಬ್ಯಾಂಕಿಂಗ್ ವಲಯಕ್ಕೆ ಇದು ನಿಯಮಕ್ಕಿಂತ ಅಪವಾದವಾಗಿದೆ. ನಮ್ಮ ಸಂದರ್ಭದಲ್ಲಿ, ವಿಶ್ವಾಸಾರ್ಹ ಸಂಗ್ರಹಣೆಗಾಗಿ ಡೇಟಾದ ಹಲವಾರು ಪ್ರತಿಗಳನ್ನು ಹೊಂದಲು ಮುಖ್ಯವಾಗಿದೆ.

ಆದ್ದರಿಂದ, ಟ್ರಿಪಲ್ ರೆಪ್ಲಿಕೇಶನ್ ಮೋಡ್‌ನಲ್ಲಿ ಸಿಎಸ್ ಆಪರೇಟಿಂಗ್ ಮೋಡ್ ಅನ್ನು ಮಾತ್ರ ಪರಿಗಣಿಸಲಾಗಿದೆ, ಅಂದರೆ. ಕೇಸ್‌ಸ್ಪೇಸ್‌ನ ರಚನೆಯನ್ನು ಈ ಕೆಳಗಿನ ನಿಯತಾಂಕಗಳೊಂದಿಗೆ ಕೈಗೊಳ್ಳಲಾಯಿತು:

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 ಇದೇ ತತ್ವದ ಮೇಲೆ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ, ಅಂದರೆ. ಅಂತಹ ಹೋಲಿಕೆ ಹೆಚ್ಚು ನ್ಯಾಯೋಚಿತವಾಗಿರುತ್ತದೆ.

DataStax ತಮ್ಮ ಅಧ್ಯಯನದಲ್ಲಿ ವಿರುದ್ಧವಾಗಿದೆ ಎಂದು ಗಮನಿಸಬೇಕು, ಅವರು CS ಮತ್ತು HB ಎರಡಕ್ಕೂ RF = 1 ಅನ್ನು ಹೊಂದಿಸಿದ್ದಾರೆ (ಎರಡನೆಯದಕ್ಕೆ HDFS ಸೆಟ್ಟಿಂಗ್‌ಗಳನ್ನು ಬದಲಾಯಿಸುವ ಮೂಲಕ). ಇದು ನಿಜವಾಗಿಯೂ ಪ್ರಮುಖ ಅಂಶವಾಗಿದೆ ಏಕೆಂದರೆ ಈ ಸಂದರ್ಭದಲ್ಲಿ ಸಿಎಸ್ ಕಾರ್ಯಕ್ಷಮತೆಯ ಮೇಲೆ ಪ್ರಭಾವವು ದೊಡ್ಡದಾಗಿದೆ. ಉದಾಹರಣೆಗೆ, ಕೆಳಗಿನ ಚಿತ್ರವು CS ಗೆ ಡೇಟಾವನ್ನು ಲೋಡ್ ಮಾಡಲು ಅಗತ್ಯವಿರುವ ಸಮಯದ ಹೆಚ್ಚಳವನ್ನು ತೋರಿಸುತ್ತದೆ:

ಎರಡು ಯಾಕೋಜುನ ಕದನ, ಅಥವಾ ಕಸ್ಸಂದ್ರ vs HBase. Sberbank ತಂಡದ ಅನುಭವ

ಇಲ್ಲಿ ನಾವು ಈ ಕೆಳಗಿನವುಗಳನ್ನು ನೋಡುತ್ತೇವೆ: ಹೆಚ್ಚು ಸ್ಪರ್ಧಾತ್ಮಕ ಎಳೆಗಳು ಡೇಟಾವನ್ನು ಬರೆಯುತ್ತವೆ, ಅದು ಹೆಚ್ಚು ಸಮಯ ತೆಗೆದುಕೊಳ್ಳುತ್ತದೆ. ಇದು ಸ್ವಾಭಾವಿಕವಾಗಿದೆ, ಆದರೆ 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 ಅಡಚಣೆಯಾಗಿಲ್ಲ. ಆದಾಗ್ಯೂ, ಇಲ್ಲಿ ಅನೇಕ ಇತರ ಮೋಸಗಳಿವೆ, ಏಕೆಂದರೆ ನಮ್ಮ HB ಆವೃತ್ತಿಯನ್ನು ಸ್ವಲ್ಪಮಟ್ಟಿಗೆ ತೇಪೆ ಮತ್ತು ಟ್ವೀಕ್ ಮಾಡಲಾಗಿದೆ ಎಂದು ಗಮನಿಸಬೇಕು, ಪರಿಸರಗಳು ಸಂಪೂರ್ಣವಾಗಿ ವಿಭಿನ್ನವಾಗಿವೆ, ಇತ್ಯಾದಿ. ಸಿಎಸ್ ಅನ್ನು ಸರಿಯಾಗಿ ತಯಾರಿಸುವುದು ಹೇಗೆ ಎಂದು ನನಗೆ ತಿಳಿದಿಲ್ಲ ಮತ್ತು ಅದರೊಂದಿಗೆ ಕೆಲಸ ಮಾಡಲು ಇನ್ನೂ ಕೆಲವು ಪರಿಣಾಮಕಾರಿ ಮಾರ್ಗಗಳಿವೆ ಮತ್ತು ಕಾಮೆಂಟ್‌ಗಳಲ್ಲಿ ನಾವು ಕಂಡುಕೊಳ್ಳುತ್ತೇವೆ ಎಂದು ನಾನು ಭಾವಿಸುತ್ತೇನೆ. ಆದರೆ ಮೊದಲ ವಿಷಯಗಳು ಮೊದಲು.

ಎಲ್ಲಾ ಪರೀಕ್ಷೆಗಳನ್ನು 4 ಸರ್ವರ್‌ಗಳನ್ನು ಒಳಗೊಂಡಿರುವ ಹಾರ್ಡ್‌ವೇರ್ ಕ್ಲಸ್ಟರ್‌ನಲ್ಲಿ ನಡೆಸಲಾಯಿತು, ಪ್ರತಿಯೊಂದೂ ಕೆಳಗಿನ ಸಂರಚನೆಯೊಂದಿಗೆ:

CPU: Xeon E5-2680 v4 @ 2.40GHz 64 ಎಳೆಗಳು.
ಡಿಸ್ಕ್ಗಳು: 12 ತುಣುಕುಗಳು SATA HDD
ಜಾವಾ ಆವೃತ್ತಿ: 1.8.0_111

CS ಆವೃತ್ತಿ: 3.11.5

cassandra.yml ನಿಯತಾಂಕಗಳುಸಂಖ್ಯೆ_ಟೋಕನ್‌ಗಳು: 256
hinted_handoff_enabled: ನಿಜ
hinted_handoff_throttle_in_kb: 1024
max_hints_delivery_threads: 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
Authenticator: AllowAllAuthenticator
ಅಧಿಕೃತ: AllowAllAuthorizer
ಪಾತ್ರ_ನಿರ್ವಾಹಕ: ಕಸ್ಸಂದ್ರ ರೋಲ್ ಮ್ಯಾನೇಜರ್
ಪಾತ್ರಗಳು_ವ್ಯಾಲಿಡಿಟಿ_ಇನ್_ಎಂಎಸ್: 2000
ಅನುಮತಿಗಳು_ವ್ಯಾಲಿಡಿಟಿ_ಇನ್_ಎಂಎಸ್: 2000
credentials_validity_in_ms: 2000
ವಿಭಜಕ: org.apache.cassandra.dht.Murmur3Partitioner
ಡೇಟಾ_ಫೈಲ್_ಡೈರೆಕ್ಟರಿಗಳು:
- /data1/cassandra/data # ಪ್ರತಿಯೊಂದು ಡೇಟಾಎನ್ ಡೈರೆಕ್ಟರಿಯು ಪ್ರತ್ಯೇಕ ಡಿಸ್ಕ್ ಆಗಿದೆ
- /data2/cassandra/data
- /data3/cassandra/data
- /data4/cassandra/data
- /data5/cassandra/data
- /data6/cassandra/data
- /data7/cassandra/data
- /data8/cassandra/data
ಕಮಿಟ್‌ಲಾಗ್_ಡೈರೆಕ್ಟರಿ: /data9/cassandra/commitlog
cdc_enabled: ತಪ್ಪು
disk_failure_policy: ನಿಲ್ಲಿಸು
ಬದ್ಧ_ವೈಫಲ್ಯ_ನೀತಿ: ನಿಲ್ಲಿಸಿ
ಸಿದ್ಧಪಡಿಸಿದ_ಹೇಳಿಕೆಗಳು_cache_size_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
ಕಮಿಟ್ಲಾಗ್_ಸಿಂಕ್: ಆವರ್ತಕ
ಕಮಿಟ್ಲಾಗ್_ಸಿಂಕ್_ಪಿರಿಯಡ್_ಇನ್_ಎಂಎಸ್: 10000
ಕಮಿಟ್ಲಾಗ್_ಸೆಗ್ಮೆಂಟ್_ಸೈಜ್_ಇನ್_ಎಂಬಿ: 32
ಬೀಜ_ಒದಗಿಸುವವರು:
- ವರ್ಗ_ಹೆಸರು: org.apache.cassandra.locator.SimpleSeedProvider
ನಿಯತಾಂಕಗಳು:
- ಬೀಜಗಳು: "*,*"
ಏಕಕಾಲೀನ_ಓದುತ್ತದೆ: 256 # ಪ್ರಯತ್ನಿಸಿದೆ 64 - ಯಾವುದೇ ವ್ಯತ್ಯಾಸವನ್ನು ಗಮನಿಸಲಿಲ್ಲ
ಏಕಕಾಲೀನ_ಬರಹಗಳು: 256 # ಪ್ರಯತ್ನಿಸಿದೆ 64 - ಯಾವುದೇ ವ್ಯತ್ಯಾಸವನ್ನು ಗಮನಿಸಲಿಲ್ಲ
ಏಕಕಾಲೀನ_ಪ್ರತಿ_ಬರಹಗಳು: 256 # ಪ್ರಯತ್ನಿಸಿದೆ 64 - ಯಾವುದೇ ವ್ಯತ್ಯಾಸವನ್ನು ಗಮನಿಸಲಿಲ್ಲ
concurrent_materialized_view_writes: 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
ಪ್ರಾರಂಭ_ಸ್ಥಳೀಯ_ಸಾರಿಗೆ: ನಿಜ
ಸ್ಥಳೀಯ_ಸಾರಿಗೆ_ಪೋರ್ಟ್: 9042
start_rpc: ನಿಜ
rpc_address: *
rpc_port: 9160
rpc_keepalive: ನಿಜ
rpc_server_type: ಸಿಂಕ್
thrift_framed_transport_size_in_mb: 15
incremental_backups: ತಪ್ಪು
ಸ್ನ್ಯಾಪ್‌ಶಾಟ್_ಬಿಫೋರ್_ಕಾಂಪಕ್ಷನ್: ತಪ್ಪು
ಸ್ವಯಂ_ಸ್ನ್ಯಾಪ್‌ಶಾಟ್: ನಿಜ
column_index_size_in_kb: 64
column_index_cache_size_in_kb: 2
ಏಕಕಾಲೀನ_ಕಾಂಪ್ಯಾಕ್ಟರ್‌ಗಳು: 4
ಸಂಕುಚಿತ_ಥ್ರೂಪುಟ್_ಎಂಬಿ_ಪ್ರತಿ_ಸೆಕೆಂಡ್: 1600
sstable_preemptive_open_interval_in_mb: 50
ms ನಲ್ಲಿ_request_timeout_in_request: 100000
ವ್ಯಾಪ್ತಿಯ_request_timeout_in_ms: 200000
ರೈಟ್_ರಿಕ್ವೆಸ್ಟ್_ಟೈಮ್ಔಟ್_ಇನ್_ಎಂಎಸ್: 40000
ಕೌಂಟರ್_ರೈಟ್_ರಿಕ್ವೆಸ್ಟ್_ಟೈಮ್ ಔಟ್_ಇನ್_ಎಂಎಸ್: 100000
cas_contention_timeout_in_ms: 20000
ಮೊಟಕುಗೊಳಿಸಿ_request_timeout_in_ms: 60000
ರಿಕ್ವೆಸ್ಟ್_ಟೈಮ್ಔಟ್_ಇನ್_ಎಂಎಸ್: 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
ವಿನಂತಿ_ಶೆಡ್ಯೂಲರ್: org.apache.cassandra.scheduler.NoScheduler
server_encryption_options:
internode_encryption: ಯಾವುದೂ ಇಲ್ಲ
client_encryption_options:
ಸಕ್ರಿಯಗೊಳಿಸಲಾಗಿದೆ: ತಪ್ಪು
ಇಂಟರ್ನೋಡ್_ಸಂಕುಚನ: ಡಿಸಿ
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
ಸಂಕುಚಿತ_ದೊಡ್ಡ_ವಿಭಜನೆ_ಎಚ್ಚರಿಕೆ_ಥ್ರೆಶೋಲ್ಡ್_mb: 100
gc_warn_threshold_in_ms: 1000
back_pressure_enabled: ತಪ್ಪು
enable_materialized_views: true
enable_sasi_indexes: ನಿಜ

GC ಸೆಟ್ಟಿಂಗ್‌ಗಳು:

### CMS ಸೆಟ್ಟಿಂಗ್‌ಗಳು-XX:+UseParNewGC
-XX:+ConcMarkSweepGC ಬಳಸಿ
-XX:+CMSSparallelRemarkEnabled
-XX:SurvivorRatio=8
-XX:MaxTenuringThreshold=1
-XX:CMS ಆರಂಭಿಸುವ ಆಕ್ಯುಪೆನ್ಸಿ ಫ್ರ್ಯಾಕ್ಷನ್=75
-XX:+CMSಆಕ್ಯುಪೆನ್ಸಿಯನ್ನು ಪ್ರಾರಂಭಿಸುವುದು ಮಾತ್ರ ಬಳಸಿ
-XX:CMSWaitDuration=10000
-XX:+CMSSparallelInitialMarkEnabled
-XX:+CMSEdenChunksRecordAlways
-XX:+CMSClassUnloadingEnabled

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 ಅನ್ನು ಹೊರತುಪಡಿಸಿದ್ದೇವೆ, ಇದು RegionServer ನಲ್ಲಿ ಪ್ರದೇಶಗಳ ಸಂಖ್ಯೆ 1000 ಕ್ಕಿಂತ ಹೆಚ್ಚಿದ್ದಾಗ GC ಗೆ ಕಾರಣವಾಯಿತು)

ಡೀಫಾಲ್ಟ್ ಅಲ್ಲದ 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.compaction ಥ್ರೆಶೋಲ್ಡ್: 5
hbase.hstore.blockingStoreFiles: 200
hbase.hregion.majorcompanction: 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:CMS ಆರಂಭಿಸುವ ಆಕ್ಯುಪೆನ್ಸಿ ಫ್ರ್ಯಾಕ್ಷನ್ = 70 -XX:+CMS ಸಮಾನಾಂತರ ರಿಮಾರ್ಕ್ ಸಕ್ರಿಯಗೊಳಿಸಲಾಗಿದೆ -XX: ಕಾಯ್ದಿರಿಸಿದ ಕೋಡ್ ಕ್ಯಾಶ್‌ಸೈಜ್ = 256 ಮೀ
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
RegionServer ಗರಿಷ್ಠ ಲಾಗ್ ಗಾತ್ರ: 100 MiB
RegionServer ಗರಿಷ್ಠ ಲಾಗ್ ಫೈಲ್ ಬ್ಯಾಕಪ್‌ಗಳು: 5
HBase ಸಕ್ರಿಯ ಮಾಸ್ಟರ್ ಪತ್ತೆ ವಿಂಡೋ: 4 ನಿಮಿಷ(ಗಳು)
dfs.client.hedged.read.threadpool.size: 40
dfs.client.hedged.read.threshold.millis: 10 ಮಿಲಿಸೆಕೆಂಡ್(ಗಳು)
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.compact.small: 6
hbase.ipc.server.read.threadpool.size: 20
ರೀಜನ್ ಮೂವರ್ ಥ್ರೆಡ್‌ಗಳು: 6
ಬೈಟ್‌ಗಳಲ್ಲಿ ಕ್ಲೈಂಟ್ ಜಾವಾ ಹೀಪ್ ಗಾತ್ರ: 1 GiB
HBase REST ಸರ್ವರ್ ಡೀಫಾಲ್ಟ್ ಗುಂಪು: 3 GiB
HBase ಥ್ರಿಫ್ಟ್ ಸರ್ವರ್ ಡೀಫಾಲ್ಟ್ ಗುಂಪು: 3 GiB
ಬೈಟ್‌ಗಳಲ್ಲಿ HBase ಮಾಸ್ಟರ್‌ನ ಜಾವಾ ಹೀಪ್ ಗಾತ್ರ: 16 GiB
ಬೈಟ್‌ಗಳಲ್ಲಿ HBase RegionServer ನ ಜಾವಾ ಹೀಪ್ ಗಾತ್ರ: 32 GiB

+ಝೂಕೀಪರ್
maxClientCnxns: 601
ಗರಿಷ್ಠ ಅವಧಿ: 120000
ಕೋಷ್ಟಕಗಳನ್ನು ರಚಿಸುವುದು:
hbase org.apache.hadoop.hbase.util.RegionSplitter ns:t1 UniformSplit -c 64 -f cf
'ns:t1' ಅನ್ನು ಬದಲಿಸಿ, {NAME => 'cf', DATA_BLOCK_ENCODING => 'FAST_DIFF', COMPRESSION => 'GZ'}

ಇಲ್ಲಿ ಒಂದು ಪ್ರಮುಖ ಅಂಶವಿದೆ - ಡೇಟಾಸ್ಟಾಕ್ಸ್ ವಿವರಣೆಯು HB ಕೋಷ್ಟಕಗಳನ್ನು ರಚಿಸಲು ಎಷ್ಟು ಪ್ರದೇಶಗಳನ್ನು ಬಳಸಲಾಗಿದೆ ಎಂದು ಹೇಳುವುದಿಲ್ಲ, ಆದರೂ ಇದು ದೊಡ್ಡ ಸಂಪುಟಗಳಿಗೆ ನಿರ್ಣಾಯಕವಾಗಿದೆ. ಆದ್ದರಿಂದ, ಪರೀಕ್ಷೆಗಳಿಗೆ, ಪ್ರಮಾಣ = 64 ಅನ್ನು ಆಯ್ಕೆಮಾಡಲಾಗಿದೆ, ಇದು 640 GB ವರೆಗೆ ಸಂಗ್ರಹಿಸಲು ಅನುಮತಿಸುತ್ತದೆ, ಅಂದರೆ. ಮಧ್ಯಮ ಗಾತ್ರದ ಟೇಬಲ್.

ಪರೀಕ್ಷೆಯ ಸಮಯದಲ್ಲಿ, HBase 22 ಸಾವಿರ ಕೋಷ್ಟಕಗಳು ಮತ್ತು 67 ಸಾವಿರ ಪ್ರದೇಶಗಳನ್ನು ಹೊಂದಿತ್ತು (ಮೇಲೆ ತಿಳಿಸಲಾದ ಪ್ಯಾಚ್ ಇಲ್ಲದಿದ್ದರೆ ಇದು ಆವೃತ್ತಿ 1.2.0 ಗೆ ಮಾರಕವಾಗುತ್ತಿತ್ತು).

ಈಗ ಕೋಡ್‌ಗಾಗಿ. ನಿರ್ದಿಷ್ಟ ಡೇಟಾಬೇಸ್‌ಗೆ ಯಾವ ಸಂರಚನೆಗಳು ಹೆಚ್ಚು ಅನುಕೂಲಕರವಾಗಿವೆ ಎಂಬುದು ಸ್ಪಷ್ಟವಾಗಿಲ್ಲವಾದ್ದರಿಂದ, ಪರೀಕ್ಷೆಗಳನ್ನು ವಿವಿಧ ಸಂಯೋಜನೆಗಳಲ್ಲಿ ನಡೆಸಲಾಯಿತು. ಆ. ಕೆಲವು ಪರೀಕ್ಷೆಗಳಲ್ಲಿ, 4 ಕೋಷ್ಟಕಗಳನ್ನು ಏಕಕಾಲದಲ್ಲಿ ಲೋಡ್ ಮಾಡಲಾಗಿದೆ (ಎಲ್ಲಾ 4 ನೋಡ್‌ಗಳನ್ನು ಸಂಪರ್ಕಕ್ಕಾಗಿ ಬಳಸಲಾಗಿದೆ). ಇತರ ಪರೀಕ್ಷೆಗಳಲ್ಲಿ ನಾವು 8 ವಿಭಿನ್ನ ಕೋಷ್ಟಕಗಳೊಂದಿಗೆ ಕೆಲಸ ಮಾಡಿದ್ದೇವೆ. ಕೆಲವು ಸಂದರ್ಭಗಳಲ್ಲಿ, ಬ್ಯಾಚ್ ಗಾತ್ರ 100, ಇತರರಲ್ಲಿ 200 (ಬ್ಯಾಚ್ ಪ್ಯಾರಾಮೀಟರ್ - ಕೆಳಗಿನ ಕೋಡ್ ನೋಡಿ). ಮೌಲ್ಯದ ಡೇಟಾ ಗಾತ್ರವು 10 ಬೈಟ್‌ಗಳು ಅಥವಾ 100 ಬೈಟ್‌ಗಳು (dataSize). ಒಟ್ಟಾರೆಯಾಗಿ, ಪ್ರತಿ ಬಾರಿಯೂ ಪ್ರತಿ ಟೇಬಲ್‌ಗೆ 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);
}

ಈಗ ಅತ್ಯಂತ ಆಸಕ್ತಿದಾಯಕ ಭಾಗ - ಫಲಿತಾಂಶಗಳು:

ಎರಡು ಯಾಕೋಜುನ ಕದನ, ಅಥವಾ ಕಸ್ಸಂದ್ರ vs HBase. Sberbank ತಂಡದ ಅನುಭವ

ಗ್ರಾಫ್ ರೂಪದಲ್ಲಿ ಅದೇ ವಿಷಯ:

ಎರಡು ಯಾಕೋಜುನ ಕದನ, ಅಥವಾ ಕಸ್ಸಂದ್ರ vs HBase. Sberbank ತಂಡದ ಅನುಭವ

HB ಯ ಪ್ರಯೋಜನವು ತುಂಬಾ ಆಶ್ಚರ್ಯಕರವಾಗಿದೆ, CS ಸೆಟಪ್‌ನಲ್ಲಿ ಕೆಲವು ರೀತಿಯ ಅಡಚಣೆಯಿದೆ ಎಂಬ ಅನುಮಾನವಿದೆ. ಆದಾಗ್ಯೂ, ಗೂಗ್ಲಿಂಗ್ ಮತ್ತು ಅತ್ಯಂತ ಸ್ಪಷ್ಟವಾದ ನಿಯತಾಂಕಗಳಿಗಾಗಿ ಹುಡುಕುವುದು (concurrent_writes ಅಥವಾ memtable_heap_space_in_mb) ವಿಷಯಗಳನ್ನು ವೇಗಗೊಳಿಸಲಿಲ್ಲ. ಅದೇ ಸಮಯದಲ್ಲಿ, ಲಾಗ್ಗಳು ಸ್ವಚ್ಛವಾಗಿರುತ್ತವೆ ಮತ್ತು ಯಾವುದನ್ನಾದರೂ ಪ್ರತಿಜ್ಞೆ ಮಾಡಬೇಡಿ.

ಡೇಟಾವನ್ನು ನೋಡ್‌ಗಳಾದ್ಯಂತ ಸಮವಾಗಿ ವಿತರಿಸಲಾಗಿದೆ, ಎಲ್ಲಾ ನೋಡ್‌ಗಳ ಅಂಕಿಅಂಶಗಳು ಸರಿಸುಮಾರು ಒಂದೇ ಆಗಿವೆ.

ನೋಡ್‌ಗಳಲ್ಲಿ ಒಂದರಿಂದ ಟೇಬಲ್ ಅಂಕಿಅಂಶಗಳು ಹೇಗೆ ಕಾಣುತ್ತವೆಕೀಸ್ಪೇಸ್: ks
ಓದಿದ ಸಂಖ್ಯೆ: 9383707
ಸುಪ್ತತೆಯನ್ನು ಓದಿ: 0.04287025042448576 ms
ಬರೆಯುವ ಸಂಖ್ಯೆ: 15462012
ಸುಪ್ತತೆಯನ್ನು ಬರೆಯಿರಿ: 0.1350068438699957 ms
ಬಾಕಿ ಇರುವ ಫ್ಲಶ್‌ಗಳು: 0
ಕೋಷ್ಟಕ: ಟಿ 1
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 ಕಿಬಿ
ಕಂಪ್ರೆಷನ್ ಮೆಟಾಡೇಟಾ ಆಫ್ ಹೀಪ್ ಮೆಮೊರಿಯನ್ನು ಬಳಸಲಾಗಿದೆ: 19.45 ಕಿಬಿ
ಸಂಕುಚಿತ ವಿಭಜನೆಯ ಕನಿಷ್ಠ ಬೈಟ್‌ಗಳು: 36
ಸಂಕುಚಿತ ವಿಭಜನಾ ಗರಿಷ್ಠ ಬೈಟ್‌ಗಳು: 42
ಸಂಕುಚಿತ ವಿಭಜನೆಯ ಸರಾಸರಿ ಬೈಟ್‌ಗಳು: 42
ಪ್ರತಿ ಸ್ಲೈಸ್‌ಗೆ ಸರಾಸರಿ ಲೈವ್ ಸೆಲ್‌ಗಳು (ಕೊನೆಯ ಐದು ನಿಮಿಷಗಳು): NaN
ಪ್ರತಿ ಸ್ಲೈಸ್‌ಗೆ ಗರಿಷ್ಠ ಲೈವ್ ಸೆಲ್‌ಗಳು (ಕೊನೆಯ ಐದು ನಿಮಿಷಗಳು): 0
ಪ್ರತಿ ಸ್ಲೈಸ್‌ಗೆ ಸರಾಸರಿ ಗೋರಿಗಲ್ಲುಗಳು (ಕೊನೆಯ ಐದು ನಿಮಿಷಗಳು): NaN
ಪ್ರತಿ ಸ್ಲೈಸ್‌ಗೆ ಗರಿಷ್ಠ ಗೋರಿಗಲ್ಲುಗಳು (ಕೊನೆಯ ಐದು ನಿಮಿಷಗಳು): 0
ಕೈಬಿಡಲಾದ ರೂಪಾಂತರಗಳು: 0 ಬೈಟ್‌ಗಳು

ಬ್ಯಾಚ್‌ನ ಗಾತ್ರವನ್ನು ಕಡಿಮೆ ಮಾಡುವ ಪ್ರಯತ್ನವು (ಅದನ್ನು ಪ್ರತ್ಯೇಕವಾಗಿ ಕಳುಹಿಸುವುದು ಸಹ) ಯಾವುದೇ ಪರಿಣಾಮ ಬೀರಲಿಲ್ಲ, ಅದು ಕೆಟ್ಟದಾಯಿತು. ವಾಸ್ತವವಾಗಿ ಇದು ನಿಜವಾಗಿಯೂ ಸಿಎಸ್‌ಗೆ ಗರಿಷ್ಠ ಕಾರ್ಯಕ್ಷಮತೆಯಾಗಿದೆ, ಏಕೆಂದರೆ ಸಿಎಸ್‌ಗಾಗಿ ಪಡೆದ ಫಲಿತಾಂಶಗಳು ಡೇಟಾಸ್ಟಾಕ್ಸ್‌ಗಾಗಿ ಪಡೆದ ಫಲಿತಾಂಶಗಳಿಗೆ ಹೋಲುತ್ತವೆ - ಪ್ರತಿ ಸೆಕೆಂಡಿಗೆ ಸುಮಾರು ನೂರಾರು ಸಾವಿರ ಕಾರ್ಯಾಚರಣೆಗಳು. ಹೆಚ್ಚುವರಿಯಾಗಿ, ನಾವು ಸಂಪನ್ಮೂಲ ಬಳಕೆಯನ್ನು ನೋಡಿದರೆ, CS ಹೆಚ್ಚು CPU ಮತ್ತು ಡಿಸ್ಕ್ಗಳನ್ನು ಬಳಸುತ್ತದೆ ಎಂದು ನಾವು ನೋಡುತ್ತೇವೆ:

ಎರಡು ಯಾಕೋಜುನ ಕದನ, ಅಥವಾ ಕಸ್ಸಂದ್ರ vs HBase. Sberbank ತಂಡದ ಅನುಭವ
ಎರಡೂ ಡೇಟಾಬೇಸ್‌ಗಳಿಗಾಗಿ ಸತತವಾಗಿ ಎಲ್ಲಾ ಪರೀಕ್ಷೆಗಳ ರನ್ ಸಮಯದಲ್ಲಿ ಬಳಕೆಯನ್ನು ಅಂಕಿ ತೋರಿಸುತ್ತದೆ.

HB ಯ ಶಕ್ತಿಯುತ ಓದುವ ಪ್ರಯೋಜನದ ಬಗ್ಗೆ. ಎರಡೂ ಡೇಟಾಬೇಸ್‌ಗಳಿಗೆ, ಓದುವ ಸಮಯದಲ್ಲಿ ಡಿಸ್ಕ್ ಬಳಕೆಯು ತೀರಾ ಕಡಿಮೆಯಾಗಿದೆ ಎಂದು ಇಲ್ಲಿ ನೀವು ನೋಡಬಹುದು (ಓದುವ ಪರೀಕ್ಷೆಗಳು ಪ್ರತಿ ಡೇಟಾಬೇಸ್‌ಗೆ ಪರೀಕ್ಷಾ ಚಕ್ರದ ಅಂತಿಮ ಭಾಗವಾಗಿದೆ, ಉದಾಹರಣೆಗೆ CS ಗೆ ಇದು 15:20 ರಿಂದ 15:40 ವರೆಗೆ ಇರುತ್ತದೆ). HB ಯ ಸಂದರ್ಭದಲ್ಲಿ, ಕಾರಣ ಸ್ಪಷ್ಟವಾಗಿದೆ - ಹೆಚ್ಚಿನ ಡೇಟಾವು ಮೆಮೊರಿಯಲ್ಲಿ, ಮೆಮ್‌ಸ್ಟೋರ್‌ನಲ್ಲಿ ಸ್ಥಗಿತಗೊಳ್ಳುತ್ತದೆ ಮತ್ತು ಕೆಲವು ಬ್ಲಾಕ್‌ಕ್ಯಾಶ್‌ನಲ್ಲಿ ಸಂಗ್ರಹವಾಗುತ್ತದೆ. CS ಗೆ ಸಂಬಂಧಿಸಿದಂತೆ, ಇದು ಹೇಗೆ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ ಎಂಬುದು ಸ್ಪಷ್ಟವಾಗಿಲ್ಲ, ಆದರೆ ಡಿಸ್ಕ್ ಮರುಬಳಕೆಯು ಸಹ ಗೋಚರಿಸುವುದಿಲ್ಲ, ಆದರೆ ಒಂದು ವೇಳೆ, ಸಂಗ್ರಹವನ್ನು ಸಕ್ರಿಯಗೊಳಿಸಲು ಪ್ರಯತ್ನಿಸಲಾಗಿದೆ row_cache_size_in_mb = 2048 ಮತ್ತು ಸೆಟ್ ಕ್ಯಾಶಿಂಗ್ = {'ಕೀಗಳು': 'ಎಲ್ಲ', 'rows_per_partition': ' 2000000'}, ಆದರೆ ಅದು ಸ್ವಲ್ಪ ಕೆಟ್ಟದಾಗಿದೆ.

HB ಯಲ್ಲಿನ ಪ್ರದೇಶಗಳ ಸಂಖ್ಯೆಯ ಬಗ್ಗೆ ಮತ್ತೊಮ್ಮೆ ಒಂದು ಪ್ರಮುಖ ಅಂಶವನ್ನು ಉಲ್ಲೇಖಿಸುವುದು ಯೋಗ್ಯವಾಗಿದೆ. ನಮ್ಮ ಸಂದರ್ಭದಲ್ಲಿ, ಮೌಲ್ಯವನ್ನು 64 ಎಂದು ನಿರ್ದಿಷ್ಟಪಡಿಸಲಾಗಿದೆ. ನೀವು ಅದನ್ನು ಕಡಿಮೆ ಮಾಡಿದರೆ ಮತ್ತು ಅದನ್ನು ಸಮಾನವಾಗಿ ಮಾಡಿದರೆ, ಉದಾಹರಣೆಗೆ, 4, ನಂತರ ಓದುವಾಗ, ವೇಗವು 2 ಬಾರಿ ಇಳಿಯುತ್ತದೆ. ಕಾರಣವೆಂದರೆ ಮೆಮ್‌ಸ್ಟೋರ್ ವೇಗವಾಗಿ ತುಂಬುತ್ತದೆ ಮತ್ತು ಫೈಲ್‌ಗಳನ್ನು ಹೆಚ್ಚಾಗಿ ಫ್ಲಶ್ ಮಾಡಲಾಗುತ್ತದೆ ಮತ್ತು ಓದುವಾಗ, ಹೆಚ್ಚಿನ ಫೈಲ್‌ಗಳನ್ನು ಪ್ರಕ್ರಿಯೆಗೊಳಿಸಬೇಕಾಗುತ್ತದೆ, ಇದು HB ಗಾಗಿ ಹೆಚ್ಚು ಸಂಕೀರ್ಣವಾದ ಕಾರ್ಯಾಚರಣೆಯಾಗಿದೆ. ನೈಜ ಪರಿಸ್ಥಿತಿಗಳಲ್ಲಿ, ಪೂರ್ವವಿಭಜನೆ ಮತ್ತು ಸಂಕುಚಿತಗೊಳಿಸುವ ತಂತ್ರದ ಮೂಲಕ ಯೋಚಿಸುವ ಮೂಲಕ ಇದನ್ನು ಪರಿಗಣಿಸಬಹುದು; ನಿರ್ದಿಷ್ಟವಾಗಿ, ನಾವು ಕಸವನ್ನು ಸಂಗ್ರಹಿಸುವ ಮತ್ತು ಹಿನ್ನೆಲೆಯಲ್ಲಿ ನಿರಂತರವಾಗಿ HFiles ಅನ್ನು ಸಂಕುಚಿತಗೊಳಿಸುವ ಸ್ವಯಂ-ಬರಹದ ಉಪಯುಕ್ತತೆಯನ್ನು ಬಳಸುತ್ತೇವೆ. DataStax ಪರೀಕ್ಷೆಗಳಿಗೆ ಅವರು ಪ್ರತಿ ಟೇಬಲ್‌ಗೆ 1 ಪ್ರದೇಶವನ್ನು ಮಾತ್ರ ನಿಗದಿಪಡಿಸಿದ್ದಾರೆ (ಇದು ಸರಿಯಾಗಿಲ್ಲ) ಮತ್ತು ಇದು ಅವರ ಓದುವ ಪರೀಕ್ಷೆಗಳಲ್ಲಿ HB ಏಕೆ ಕೆಳಮಟ್ಟದಲ್ಲಿದೆ ಎಂಬುದನ್ನು ಸ್ವಲ್ಪಮಟ್ಟಿಗೆ ಸ್ಪಷ್ಟಪಡಿಸುತ್ತದೆ.

ಇದರಿಂದ ಈ ಕೆಳಗಿನ ಪ್ರಾಥಮಿಕ ತೀರ್ಮಾನಗಳನ್ನು ತೆಗೆದುಕೊಳ್ಳಲಾಗಿದೆ. ಪರೀಕ್ಷೆಯ ಸಮಯದಲ್ಲಿ ಯಾವುದೇ ಪ್ರಮುಖ ತಪ್ಪುಗಳನ್ನು ಮಾಡಲಾಗಿಲ್ಲ ಎಂದು ಊಹಿಸಿದರೆ, ನಂತರ ಕಸ್ಸಂದ್ರವು ಜೇಡಿಮಣ್ಣಿನ ಪಾದಗಳನ್ನು ಹೊಂದಿರುವ ಬೃಹದಾಕಾರದಂತೆ ಕಾಣುತ್ತದೆ. ಹೆಚ್ಚು ನಿಖರವಾಗಿ, ಅವಳು ಒಂದು ಕಾಲಿನ ಮೇಲೆ ಸಮತೋಲನ ಮಾಡುವಾಗ, ಲೇಖನದ ಆರಂಭದಲ್ಲಿ ಚಿತ್ರದಲ್ಲಿರುವಂತೆ, ಅವಳು ತುಲನಾತ್ಮಕವಾಗಿ ಉತ್ತಮ ಫಲಿತಾಂಶಗಳನ್ನು ತೋರಿಸುತ್ತಾಳೆ, ಆದರೆ ಅದೇ ಪರಿಸ್ಥಿತಿಗಳಲ್ಲಿ ಹೋರಾಟದಲ್ಲಿ ಅವಳು ಸಂಪೂರ್ಣವಾಗಿ ಕಳೆದುಕೊಳ್ಳುತ್ತಾಳೆ. ಅದೇ ಸಮಯದಲ್ಲಿ, ನಮ್ಮ ಹಾರ್ಡ್‌ವೇರ್‌ನಲ್ಲಿ ಕಡಿಮೆ ಸಿಪಿಯು ಬಳಕೆಯನ್ನು ಗಣನೆಗೆ ತೆಗೆದುಕೊಂಡು, ಪ್ರತಿ ಹೋಸ್ಟ್‌ಗೆ ಎರಡು ರೀಜನ್‌ಸರ್ವರ್ ಎಚ್‌ಬಿಗಳನ್ನು ನೆಡಲು ನಾವು ಕಲಿತಿದ್ದೇವೆ ಮತ್ತು ಆ ಮೂಲಕ ಕಾರ್ಯಕ್ಷಮತೆಯನ್ನು ದ್ವಿಗುಣಗೊಳಿಸಿದ್ದೇವೆ. ಆ. ಸಂಪನ್ಮೂಲಗಳ ಬಳಕೆಯನ್ನು ಗಣನೆಗೆ ತೆಗೆದುಕೊಂಡು, ಸಿಎಸ್‌ನ ಪರಿಸ್ಥಿತಿ ಇನ್ನಷ್ಟು ಶೋಚನೀಯವಾಗಿದೆ.

ಸಹಜವಾಗಿ, ಈ ಪರೀಕ್ಷೆಗಳು ಸಾಕಷ್ಟು ಸಂಶ್ಲೇಷಿತವಾಗಿವೆ ಮತ್ತು ಇಲ್ಲಿ ಬಳಸಲಾದ ಡೇಟಾದ ಪ್ರಮಾಣವು ತುಲನಾತ್ಮಕವಾಗಿ ಸಾಧಾರಣವಾಗಿದೆ. ನಾವು ಟೆರಾಬೈಟ್‌ಗಳಿಗೆ ಬದಲಾಯಿಸಿದರೆ, ಪರಿಸ್ಥಿತಿ ವಿಭಿನ್ನವಾಗಿರಬಹುದು, ಆದರೆ HB ಗಾಗಿ ನಾವು ಟೆರಾಬೈಟ್‌ಗಳನ್ನು ಲೋಡ್ ಮಾಡಬಹುದು, CS ಗೆ ಇದು ಸಮಸ್ಯಾತ್ಮಕವಾಗಿದೆ. ಡೀಫಾಲ್ಟ್‌ಗೆ ಹೋಲಿಸಿದರೆ ಪ್ರತಿಕ್ರಿಯೆಗಾಗಿ ಕಾಯುವ ನಿಯತಾಂಕಗಳನ್ನು ಈಗಾಗಲೇ ಹಲವಾರು ಬಾರಿ ಹೆಚ್ಚಿಸಲಾಗಿದ್ದರೂ, ಈ ಸಂಪುಟಗಳೊಂದಿಗೆ ಸಹ ಇದು ಸಾಮಾನ್ಯವಾಗಿ ಆಪರೇಷನ್‌ಟೈಮ್ಡ್‌ಔಟ್‌ಎಕ್ಸೆಪ್ಶನ್ ಅನ್ನು ಎಸೆದಿದೆ.

ಜಂಟಿ ಪ್ರಯತ್ನಗಳ ಮೂಲಕ ನಾವು CS ನ ಅಡಚಣೆಗಳನ್ನು ಕಂಡುಕೊಳ್ಳುತ್ತೇವೆ ಮತ್ತು ನಾವು ಅದನ್ನು ವೇಗಗೊಳಿಸಲು ಸಾಧ್ಯವಾದರೆ, ಪೋಸ್ಟ್‌ನ ಕೊನೆಯಲ್ಲಿ ನಾನು ಖಂಡಿತವಾಗಿಯೂ ಅಂತಿಮ ಫಲಿತಾಂಶಗಳ ಬಗ್ಗೆ ಮಾಹಿತಿಯನ್ನು ಸೇರಿಸುತ್ತೇನೆ ಎಂದು ನಾನು ಭಾವಿಸುತ್ತೇನೆ.

ಯುಪಿಡಿ: ಒಡನಾಡಿಗಳ ಸಲಹೆಗೆ ಧನ್ಯವಾದಗಳು, ನಾನು ಓದುವಿಕೆಯನ್ನು ವೇಗಗೊಳಿಸಲು ನಿರ್ವಹಿಸುತ್ತಿದ್ದೆ. ಆಗಿತ್ತು:
159 ಆಪ್‌ಗಳು (644 ಕೋಷ್ಟಕಗಳು, 4 ಸ್ಟ್ರೀಮ್‌ಗಳು, ಬ್ಯಾಚ್ 5).
ಸೇರಿಸಲಾಗಿದೆ:
.withLoadBalancingPolicy(ಹೊಸ TokenAwarePolicy(DCAwareRoundRobinPolicy.builder().build()))
ಮತ್ತು ನಾನು ಎಳೆಗಳ ಸಂಖ್ಯೆಯೊಂದಿಗೆ ಆಡಿದೆ. ಫಲಿತಾಂಶವು ಈ ಕೆಳಗಿನಂತಿರುತ್ತದೆ:
4 ಟೇಬಲ್‌ಗಳು, 100 ಥ್ರೆಡ್‌ಗಳು, ಬ್ಯಾಚ್ = 1 (ತುಂಡು ತುಂಡು): 301 ಆಪ್‌ಗಳು
4 ಕೋಷ್ಟಕಗಳು, 100 ಎಳೆಗಳು, ಬ್ಯಾಚ್ = 10: 447 ಆಪ್‌ಗಳು
4 ಕೋಷ್ಟಕಗಳು, 100 ಎಳೆಗಳು, ಬ್ಯಾಚ್ = 100: 625 ಆಪ್‌ಗಳು

ನಂತರ ನಾನು ಇತರ ಶ್ರುತಿ ಸಲಹೆಗಳನ್ನು ಅನ್ವಯಿಸುತ್ತೇನೆ, ಪೂರ್ಣ ಪರೀಕ್ಷಾ ಚಕ್ರವನ್ನು ರನ್ ಮಾಡುತ್ತೇನೆ ಮತ್ತು ಪೋಸ್ಟ್‌ನ ಕೊನೆಯಲ್ಲಿ ಫಲಿತಾಂಶಗಳನ್ನು ಸೇರಿಸುತ್ತೇನೆ.

ಮೂಲ: www.habr.com

ಕಾಮೆಂಟ್ ಅನ್ನು ಸೇರಿಸಿ