ಹೈಲೋಡ್++ ಮಾಸ್ಕೋ 2018, ಕಾಂಗ್ರೆಸ್ ಹಾಲ್. ನವೆಂಬರ್ 9, 15:00
ಸಾರಾಂಶಗಳು ಮತ್ತು ಪ್ರಸ್ತುತಿ:
ಯೂರಿ ನಸ್ರೆಟ್ಡಿನೋವ್ (VKontakte): ವರದಿಯು ನಮ್ಮ ಕಂಪನಿಯಲ್ಲಿ ಕ್ಲಿಕ್ಹೌಸ್ ಅನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸುವ ಅನುಭವದ ಬಗ್ಗೆ ಮಾತನಾಡುತ್ತದೆ - ನಮಗೆ ಅದು ಏಕೆ ಬೇಕು, ನಾವು ಎಷ್ಟು ಡೇಟಾವನ್ನು ಸಂಗ್ರಹಿಸುತ್ತೇವೆ, ನಾವು ಅದನ್ನು ಹೇಗೆ ಬರೆಯುತ್ತೇವೆ ಮತ್ತು ಹೀಗೆ.
Дополнительные:
ಯೂರಿ ನಸ್ರೆಟ್ಡಿನೋವ್: - ಎಲ್ಲರಿಗು ನಮಸ್ಖರ! ನನ್ನ ಹೆಸರು ಯೂರಿ ನಸ್ರೆಟ್ಡಿನೋವ್, ನಾನು ಈಗಾಗಲೇ ಪರಿಚಯಿಸಲ್ಪಟ್ಟಿದ್ದೇನೆ. ನಾನು VKontakte ನಲ್ಲಿ ಕೆಲಸ ಮಾಡುತ್ತೇನೆ. ನಮ್ಮ ಸರ್ವರ್ ಫ್ಲೀಟ್‌ನಿಂದ (ಹತ್ತಾರು ಸಾವಿರ) ನಾವು ಕ್ಲಿಕ್‌ಹೌಸ್‌ಗೆ ಡೇಟಾವನ್ನು ಹೇಗೆ ಸೇರಿಸುತ್ತೇವೆ ಎಂಬುದರ ಕುರಿತು ನಾನು ಮಾತನಾಡುತ್ತೇನೆ.
ದಾಖಲೆಗಳು ಯಾವುವು ಮತ್ತು ಅವುಗಳನ್ನು ಏಕೆ ಸಂಗ್ರಹಿಸಬೇಕು?
ನಾವು ನಿಮಗೆ ಏನು ಹೇಳುತ್ತೇವೆ: ನಾವು ಏನು ಮಾಡಿದ್ದೇವೆ, ನಮಗೆ "ಕ್ಲಿಕ್ಹೌಸ್" ಏಕೆ ಬೇಕು, ನಾವು ಅದನ್ನು ಏಕೆ ಆರಿಸಿದ್ದೇವೆ, ವಿಶೇಷವಾಗಿ ಏನನ್ನೂ ಕಾನ್ಫಿಗರ್ ಮಾಡದೆ ನೀವು ಯಾವ ರೀತಿಯ ಕಾರ್ಯಕ್ಷಮತೆಯನ್ನು ಪಡೆಯಬಹುದು. ಬಫರ್ ಕೋಷ್ಟಕಗಳ ಬಗ್ಗೆ, ನಾವು ಹೊಂದಿರುವ ಸಮಸ್ಯೆಗಳ ಬಗ್ಗೆ ಮತ್ತು ತೆರೆದ ಮೂಲದಿಂದ ನಾವು ಅಭಿವೃದ್ಧಿಪಡಿಸಿದ ನಮ್ಮ ಪರಿಹಾರಗಳ ಬಗ್ಗೆ ನಾನು ನಿಮಗೆ ಹೇಳುತ್ತೇನೆ - ಕಿಟನ್ಹೌಸ್ ಮತ್ತು ಲೈಟ್‌ಹೌಸ್.
ನಾವು ಏನನ್ನೂ ಏಕೆ ಮಾಡಬೇಕಾಗಿದೆ (VKontakte ನಲ್ಲಿ ಎಲ್ಲವೂ ಯಾವಾಗಲೂ ಒಳ್ಳೆಯದು, ಸರಿ?). ನಾವು ಡೀಬಗ್ ಲಾಗ್‌ಗಳನ್ನು ಸಂಗ್ರಹಿಸಲು ಬಯಸಿದ್ದೇವೆ (ಮತ್ತು ಅಲ್ಲಿ ನೂರಾರು ಟೆರಾಬೈಟ್‌ಗಳ ಡೇಟಾ ಇತ್ತು), ಬಹುಶಃ ಹೇಗಾದರೂ ಅಂಕಿಅಂಶಗಳನ್ನು ಲೆಕ್ಕಾಚಾರ ಮಾಡಲು ಹೆಚ್ಚು ಅನುಕೂಲಕರವಾಗಿರುತ್ತದೆ; ಮತ್ತು ನಾವು ಹತ್ತಾರು ಸಾವಿರ ಸರ್ವರ್‌ಗಳ ಸಮೂಹವನ್ನು ಹೊಂದಿದ್ದೇವೆ, ಇವುಗಳಿಂದ ಇದನ್ನು ಮಾಡಬೇಕಾಗಿದೆ.
ನಾವು ಏಕೆ ನಿರ್ಧರಿಸಿದ್ದೇವೆ? ಲಾಗ್‌ಗಳನ್ನು ಸಂಗ್ರಹಿಸಲು ನಾವು ಬಹುಶಃ ಪರಿಹಾರಗಳನ್ನು ಹೊಂದಿದ್ದೇವೆ. ಇಲ್ಲಿ - ಅಂತಹ ಸಾರ್ವಜನಿಕ "ಬ್ಯಾಕೆಂಡ್ ವಿಕೆ" ಇದೆ. ಅದಕ್ಕೆ ಚಂದಾದಾರರಾಗಲು ನಾನು ಹೆಚ್ಚು ಶಿಫಾರಸು ಮಾಡುತ್ತೇವೆ.
ದಾಖಲೆಗಳು ಯಾವುವು? ಇದು ಖಾಲಿ ಅರೇಗಳನ್ನು ಹಿಂದಿರುಗಿಸುವ ಎಂಜಿನ್ ಆಗಿದೆ. VK ಯಲ್ಲಿನ ಇಂಜಿನ್ಗಳನ್ನು ಇತರರು ಮೈಕ್ರೋಸರ್ವಿಸ್ ಎಂದು ಕರೆಯುತ್ತಾರೆ. ಮತ್ತು ಇಲ್ಲಿ ನಗುತ್ತಿರುವ ಸ್ಟಿಕ್ಕರ್ ಇದೆ (ಸಾಕಷ್ಟು ಇಷ್ಟಗಳು). ಅದು ಹೇಗೆ? ಸರಿ, ಮುಂದೆ ಕೇಳು!
ದಾಖಲೆಗಳನ್ನು ಸಂಗ್ರಹಿಸಲು ಏನು ಬಳಸಬಹುದು? ಹಡುಪನ್ನು ಹೇಳದೆ ಇರಲು ಸಾಧ್ಯವಿಲ್ಲ. ನಂತರ, ಉದಾಹರಣೆಗೆ, Rsyslog (ಈ ಲಾಗ್‌ಗಳನ್ನು ಫೈಲ್‌ಗಳಲ್ಲಿ ಸಂಗ್ರಹಿಸುವುದು). LSD. LSD ಎಂದರೆ ಯಾರಿಗೆ ಗೊತ್ತು? ಇಲ್ಲ, ಈ LSD ಅಲ್ಲ. ಕ್ರಮವಾಗಿ ಫೈಲ್ಗಳನ್ನು ಸಂಗ್ರಹಿಸಿ. ಸರಿ, ಕ್ಲಿಕ್ಹೌಸ್ ಒಂದು ವಿಚಿತ್ರ ಆಯ್ಕೆಯಾಗಿದೆ.
ಕ್ಲಿಕ್ಹೌಸ್ ಮತ್ತು ಸ್ಪರ್ಧಿಗಳು: ಅವಶ್ಯಕತೆಗಳು ಮತ್ತು ಅವಕಾಶಗಳು
ನಮಗೆ ಏನು ಬೇಕು? ಕಾರ್ಯಾಚರಣೆಯ ಬಗ್ಗೆ ನಾವು ಹೆಚ್ಚು ಚಿಂತಿಸಬೇಕಾಗಿಲ್ಲ ಎಂದು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳಲು ನಾವು ಬಯಸುತ್ತೇವೆ, ಇದರಿಂದ ಅದು ಬಾಕ್ಸ್‌ನಿಂದ ಹೊರಗೆ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ, ಮೇಲಾಗಿ ಕನಿಷ್ಠ ಕಾನ್ಫಿಗರೇಶನ್‌ನೊಂದಿಗೆ. ನಾವು ಬಹಳಷ್ಟು ಬರೆಯಲು ಬಯಸುತ್ತೇವೆ ಮತ್ತು ತ್ವರಿತವಾಗಿ ಬರೆಯುತ್ತೇವೆ. ಮತ್ತು ನಾವು ಅದನ್ನು ಎಲ್ಲಾ ರೀತಿಯ ತಿಂಗಳುಗಳು, ವರ್ಷಗಳು, ಅಂದರೆ ದೀರ್ಘಕಾಲದವರೆಗೆ ಇರಿಸಿಕೊಳ್ಳಲು ಬಯಸುತ್ತೇವೆ. ಅವರು ನಮ್ಮ ಬಳಿಗೆ ಬಂದು, "ಇಲ್ಲಿ ಯಾವುದೋ ಕೆಲಸ ಮಾಡುತ್ತಿಲ್ಲ" ಎಂದು ಹೇಳಿದ ಕೆಲವು ಸಮಸ್ಯೆಯನ್ನು ನಾವು ಅರ್ಥಮಾಡಿಕೊಳ್ಳಲು ಬಯಸಬಹುದು ಮತ್ತು ಅದು 3 ತಿಂಗಳ ಹಿಂದೆ), ಮತ್ತು 3 ತಿಂಗಳ ಹಿಂದೆ ಏನಾಯಿತು ಎಂದು ನೋಡಲು ನಾವು ಬಯಸುತ್ತೇವೆ " ಡೇಟಾ ಕಂಪ್ರೆಷನ್ - ಅದು ಏಕೆ ಪ್ಲಸ್ ಆಗಿರುತ್ತದೆ ಎಂಬುದು ಸ್ಪಷ್ಟವಾಗಿದೆ - ಏಕೆಂದರೆ ಅದು ತೆಗೆದುಕೊಳ್ಳುವ ಜಾಗವನ್ನು ಕಡಿಮೆ ಮಾಡುತ್ತದೆ.
ಮತ್ತು ನಮಗೆ ಅಂತಹ ಆಸಕ್ತಿದಾಯಕ ಅವಶ್ಯಕತೆಯಿದೆ: ನಾವು ಕೆಲವೊಮ್ಮೆ ಕೆಲವು ಆಜ್ಞೆಗಳ ಔಟ್ಪುಟ್ ಅನ್ನು ಬರೆಯುತ್ತೇವೆ (ಉದಾಹರಣೆಗೆ, ಲಾಗ್ಗಳು), ಇದು 4 ಕಿಲೋಬೈಟ್ಗಳಿಗಿಂತ ಹೆಚ್ಚು ಸುಲಭವಾಗಿರಬಹುದು. ಮತ್ತು ಈ ವಿಷಯವು UDP ಯ ಮೇಲೆ ಕಾರ್ಯನಿರ್ವಹಿಸಿದರೆ, ಅದು ಖರ್ಚು ಮಾಡುವ ಅಗತ್ಯವಿಲ್ಲ ... ಇದು ಸಂಪರ್ಕಕ್ಕಾಗಿ ಯಾವುದೇ "ಓವರ್ಹೆಡ್" ಅನ್ನು ಹೊಂದಿರುವುದಿಲ್ಲ ಮತ್ತು ಹೆಚ್ಚಿನ ಸಂಖ್ಯೆಯ ಸರ್ವರ್ಗಳಿಗೆ ಇದು ಪ್ಲಸ್ ಆಗಿರುತ್ತದೆ.
ಓಪನ್ ಸೋರ್ಸ್ ನಮಗೆ ಏನು ನೀಡುತ್ತದೆ ಎಂದು ನೋಡೋಣ. ಮೊದಲನೆಯದಾಗಿ, ನಾವು ಲಾಗ್ಸ್ ಎಂಜಿನ್ ಅನ್ನು ಹೊಂದಿದ್ದೇವೆ - ಇದು ನಮ್ಮ ಎಂಜಿನ್ ಆಗಿದೆ; ತಾತ್ವಿಕವಾಗಿ, ಅವನು ಎಲ್ಲವನ್ನೂ ಮಾಡಬಹುದು, ಅವನು ದೀರ್ಘ ಸಾಲುಗಳನ್ನು ಸಹ ಬರೆಯಬಹುದು. ಒಳ್ಳೆಯದು, ಇದು ಡೇಟಾವನ್ನು ಪಾರದರ್ಶಕವಾಗಿ ಸಂಕುಚಿತಗೊಳಿಸುವುದಿಲ್ಲ - ನಾವು ಬಯಸಿದರೆ ದೊಡ್ಡ ಕಾಲಮ್‌ಗಳನ್ನು ನಾವೇ ಸಂಕುಚಿತಗೊಳಿಸಬಹುದು ... ನಾವು, ಸಹಜವಾಗಿ, ಬಯಸುವುದಿಲ್ಲ (ಸಾಧ್ಯವಾದರೆ). ಒಂದೇ ಸಮಸ್ಯೆಯೆಂದರೆ, ಅವನು ತನ್ನ ಸ್ಮರಣೆಯಲ್ಲಿ ಸರಿಹೊಂದುವದನ್ನು ಮಾತ್ರ ನೀಡಬಹುದು; ಉಳಿದವುಗಳನ್ನು ಓದಲು, ನೀವು ಈ ಎಂಜಿನ್ನ ಬಿನ್ಲಾಗ್ ಅನ್ನು ಪಡೆಯಬೇಕು ಮತ್ತು ಅದರ ಪ್ರಕಾರ, ಇದು ಸಾಕಷ್ಟು ಸಮಯ ತೆಗೆದುಕೊಳ್ಳುತ್ತದೆ.
ಬೇರೆ ಯಾವ ಆಯ್ಕೆಗಳಿವೆ? ಉದಾಹರಣೆಗೆ, "ಹಡಪ್". ಕಾರ್ಯಾಚರಣೆಯ ಸುಲಭ... ಹಡಪ್ ಅನ್ನು ಹೊಂದಿಸುವುದು ಸುಲಭ ಎಂದು ಯಾರು ಭಾವಿಸುತ್ತಾರೆ? ಸಹಜವಾಗಿ, ರೆಕಾರ್ಡಿಂಗ್ನಲ್ಲಿ ಯಾವುದೇ ಸಮಸ್ಯೆಗಳಿಲ್ಲ. ಓದುವಾಗ, ಕೆಲವೊಮ್ಮೆ ಪ್ರಶ್ನೆಗಳು ಉದ್ಭವಿಸುತ್ತವೆ. ತಾತ್ವಿಕವಾಗಿ, ನಾನು ಬಹುಶಃ ಅಲ್ಲ ಎಂದು ಹೇಳುತ್ತೇನೆ, ವಿಶೇಷವಾಗಿ ಲಾಗ್ಗಳಿಗೆ. ದೀರ್ಘಾವಧಿಯ ಸಂಗ್ರಹಣೆ - ಸಹಜವಾಗಿ, ಹೌದು, ಡೇಟಾ ಕಂಪ್ರೆಷನ್ - ಹೌದು, ದೀರ್ಘ ತಂತಿಗಳು - ನೀವು ರೆಕಾರ್ಡ್ ಮಾಡಬಹುದು ಎಂಬುದು ಸ್ಪಷ್ಟವಾಗಿದೆ. ಆದರೆ ಹೆಚ್ಚಿನ ಸಂಖ್ಯೆಯ ಸರ್ವರ್‌ಗಳಿಂದ ರೆಕಾರ್ಡಿಂಗ್ ... ನೀವು ಇನ್ನೂ ನೀವೇ ಏನನ್ನಾದರೂ ಮಾಡಬೇಕು!
Rsyslog. ವಾಸ್ತವವಾಗಿ, ನಾವು ಅದನ್ನು ಬ್ಯಾಕ್‌ಅಪ್ ಆಯ್ಕೆಯಾಗಿ ಬಳಸಿದ್ದೇವೆ ಆದ್ದರಿಂದ ನಾವು ಅದನ್ನು ಬಿನ್ಲಾಗ್ ಅನ್ನು ಡಂಪ್ ಮಾಡದೆಯೇ ಓದಬಹುದು, ಆದರೆ ಇದು ದೀರ್ಘ ಸಾಲುಗಳನ್ನು ಬರೆಯಲು ಸಾಧ್ಯವಿಲ್ಲ; ತಾತ್ವಿಕವಾಗಿ, ಇದು 4 ಕಿಲೋಬೈಟ್ಗಳಿಗಿಂತ ಹೆಚ್ಚು ಬರೆಯಲು ಸಾಧ್ಯವಿಲ್ಲ. ಅದೇ ರೀತಿಯಲ್ಲಿ ಡೇಟಾ ಕಂಪ್ರೆಷನ್ ಅನ್ನು ನೀವೇ ಮಾಡಬೇಕು. ಓದುವಿಕೆ ಫೈಲ್‌ಗಳಿಂದ ಬರುತ್ತದೆ.
ನಂತರ LSD ಯ "ಬದುಷ್ಕಾ" ಅಭಿವೃದ್ಧಿ ಇದೆ. ಮೂಲಭೂತವಾಗಿ "Rsyslog" ನಂತೆಯೇ: ಇದು ಉದ್ದವಾದ ತಂತಿಗಳನ್ನು ಬೆಂಬಲಿಸುತ್ತದೆ, ಆದರೆ ಇದು UDP ಮೂಲಕ ಕೆಲಸ ಮಾಡಲು ಸಾಧ್ಯವಿಲ್ಲ ಮತ್ತು ವಾಸ್ತವವಾಗಿ, ಈ ಕಾರಣದಿಂದಾಗಿ, ದುರದೃಷ್ಟವಶಾತ್, ಬಹಳಷ್ಟು ವಿಷಯಗಳನ್ನು ಅಲ್ಲಿ ಪುನಃ ಬರೆಯಬೇಕಾಗಿದೆ. ಹತ್ತಾರು ಸಾವಿರ ಸರ್ವರ್‌ಗಳಿಂದ ರೆಕಾರ್ಡ್ ಮಾಡಲು ಸಾಧ್ಯವಾಗುವಂತೆ LSD ಅನ್ನು ಮರುವಿನ್ಯಾಸಗೊಳಿಸಬೇಕಾಗಿದೆ.
ಮತ್ತು ಇಲ್ಲಿ! ಒಂದು ತಮಾಷೆಯ ಆಯ್ಕೆಯು ElasticSearch ಆಗಿದೆ. ಹೇಗೆ ಹೇಳುವುದು? ಅವನು ಓದುವುದನ್ನು ಚೆನ್ನಾಗಿ ಮಾಡುತ್ತಿದ್ದಾನೆ, ಅಂದರೆ, ಅವನು ಬೇಗನೆ ಓದುತ್ತಾನೆ, ಆದರೆ ಬರವಣಿಗೆಯಲ್ಲಿ ಚೆನ್ನಾಗಿಲ್ಲ. ಮೊದಲನೆಯದಾಗಿ, ಇದು ಡೇಟಾವನ್ನು ಸಂಕುಚಿತಗೊಳಿಸಿದರೆ, ಅದು ತುಂಬಾ ದುರ್ಬಲವಾಗಿರುತ್ತದೆ. ಹೆಚ್ಚಾಗಿ, ಪೂರ್ಣ ಹುಡುಕಾಟಕ್ಕೆ ಮೂಲ ಪರಿಮಾಣಕ್ಕಿಂತ ದೊಡ್ಡ ಡೇಟಾ ರಚನೆಗಳು ಬೇಕಾಗುತ್ತವೆ. ಇದು ಕಾರ್ಯನಿರ್ವಹಿಸಲು ಕಷ್ಟ ಮತ್ತು ಅದರೊಂದಿಗೆ ಸಮಸ್ಯೆಗಳು ಹೆಚ್ಚಾಗಿ ಉದ್ಭವಿಸುತ್ತವೆ. ಮತ್ತು, ಮತ್ತೊಮ್ಮೆ, ಎಲಾಸ್ಟಿಕ್ನಲ್ಲಿ ರೆಕಾರ್ಡಿಂಗ್ - ನಾವು ಎಲ್ಲವನ್ನೂ ನಾವೇ ಮಾಡಬೇಕು.
ಇಲ್ಲಿ ಕ್ಲಿಕ್ಹೌಸ್ ಒಂದು ಆದರ್ಶ ಆಯ್ಕೆಯಾಗಿದೆ. ಒಂದೇ ವಿಷಯವೆಂದರೆ ಹತ್ತಾರು ಸರ್ವರ್‌ಗಳಿಂದ ರೆಕಾರ್ಡಿಂಗ್ ಸಮಸ್ಯೆಯಾಗಿದೆ. ಆದರೆ ಕನಿಷ್ಠ ಒಂದು ಸಮಸ್ಯೆ ಇದೆ, ನಾವು ಅದನ್ನು ಹೇಗಾದರೂ ಪರಿಹರಿಸಲು ಪ್ರಯತ್ನಿಸಬಹುದು. ಮತ್ತು ಉಳಿದ ವರದಿಯು ಈ ಸಮಸ್ಯೆಯ ಬಗ್ಗೆ. ಕ್ಲಿಕ್‌ಹೌಸ್‌ನಿಂದ ನೀವು ಯಾವ ರೀತಿಯ ಕಾರ್ಯಕ್ಷಮತೆಯನ್ನು ನಿರೀಕ್ಷಿಸಬಹುದು?
ನಾವು ಅದನ್ನು ಹೇಗೆ ಸೇರಿಸಲಿದ್ದೇವೆ? ವಿಲೀನ ಟ್ರೀ
ನಿಮ್ಮಲ್ಲಿ ಯಾರು "ಕ್ಲಿಕ್ಹೌಸ್" ಬಗ್ಗೆ ಕೇಳಿಲ್ಲ ಅಥವಾ ತಿಳಿದಿಲ್ಲ? ನಾನು ನಿಮಗೆ ಹೇಳಬೇಕಾಗಿದೆ, ಅಲ್ಲವೇ? ಅತ್ಯಂತ ವೇಗವಾಗಿ. ಅಲ್ಲಿ ಅಳವಡಿಕೆ - ಸೆಕೆಂಡಿಗೆ 1-2 ಗಿಗಾಬಿಟ್‌ಗಳು, ಸೆಕೆಂಡಿಗೆ 10 ಗಿಗಾಬಿಟ್‌ಗಳ ಸ್ಫೋಟಗಳು ಈ ಸಂರಚನೆಯನ್ನು ವಾಸ್ತವವಾಗಿ ತಡೆದುಕೊಳ್ಳಬಲ್ಲವು - ಎರಡು 6-ಕೋರ್ ಕ್ಸಿಯಾನ್‌ಗಳು (ಅಂದರೆ, ಅತ್ಯಂತ ಶಕ್ತಿಶಾಲಿಯೂ ಅಲ್ಲ), 256 ಗಿಗಾಬೈಟ್ RAM, 20 ಟೆರಾಬೈಟ್‌ಗಳು RAID ನಲ್ಲಿ (ಯಾರೂ ಕಾನ್ಫಿಗರ್ ಮಾಡಿಲ್ಲ, ಡೀಫಾಲ್ಟ್ ಸೆಟ್ಟಿಂಗ್‌ಗಳು). ಕ್ಲಿಕ್ಹೌಸ್ ಡೆವಲಪರ್ ಅಲೆಕ್ಸಿ ಮಿಲೋವಿಡೋವ್ ಬಹುಶಃ ಅಳುತ್ತಾ ಕುಳಿತಿದ್ದಾರೆ ಏಕೆಂದರೆ ನಾವು ಏನನ್ನೂ ಕಾನ್ಫಿಗರ್ ಮಾಡಿಲ್ಲ (ಎಲ್ಲವೂ ನಮಗೆ ಹಾಗೆ ಕೆಲಸ ಮಾಡಿದೆ). ಅಂತೆಯೇ, ಡೇಟಾವನ್ನು ಚೆನ್ನಾಗಿ ಸಂಕುಚಿತಗೊಳಿಸಿದರೆ ಪ್ರತಿ ಸೆಕೆಂಡಿಗೆ ಸುಮಾರು 6 ಬಿಲಿಯನ್ ಲೈನ್‌ಗಳ ಸ್ಕ್ಯಾನಿಂಗ್ ವೇಗವನ್ನು ಪಡೆಯಬಹುದು. ನೀವು ಪಠ್ಯ ಸ್ಟ್ರಿಂಗ್‌ನಲ್ಲಿ % ಅನ್ನು ಇಷ್ಟಪಟ್ಟರೆ - ಪ್ರತಿ ಸೆಕೆಂಡಿಗೆ 100 ಮಿಲಿಯನ್ ಸಾಲುಗಳು, ಅಂದರೆ, ಅದು ತುಂಬಾ ವೇಗವಾಗಿ ತೋರುತ್ತದೆ.
ನಾವು ಅದನ್ನು ಹೇಗೆ ಸೇರಿಸಲಿದ್ದೇವೆ? ಸರಿ, ವಿಕೆ ಪಿಎಚ್ಪಿ ಬಳಸುತ್ತದೆ ಎಂದು ನಿಮಗೆ ತಿಳಿದಿದೆ. ನಾವು ಪ್ರತಿ ಪಿಎಚ್ಪಿ ವರ್ಕರ್‌ನಿಂದ ಎಚ್‌ಟಿಟಿಪಿ ಮೂಲಕ "ಕ್ಲಿಕ್ಹೌಸ್" ಗೆ, ಪ್ರತಿ ದಾಖಲೆಗಾಗಿ ವಿಲೀನ ಟ್ರೀ ಟೇಬಲ್‌ಗೆ ಸೇರಿಸುತ್ತೇವೆ. ಈ ಯೋಜನೆಯ ಸಮಸ್ಯೆಯನ್ನು ಯಾರು ನೋಡುತ್ತಾರೆ? ಕೆಲವು ಕಾರಣಕ್ಕಾಗಿ, ಎಲ್ಲರೂ ತಮ್ಮ ಕೈಗಳನ್ನು ಎತ್ತಲಿಲ್ಲ. ನಾನು ನಿಮಗೆ ಹೇಳುತ್ತೇನೆ.
ಮೊದಲನೆಯದಾಗಿ, ಬಹಳಷ್ಟು ಸರ್ವರ್‌ಗಳಿವೆ - ಅದರ ಪ್ರಕಾರ, ಬಹಳಷ್ಟು ಸಂಪರ್ಕಗಳು (ಕೆಟ್ಟದ್ದು) ಇರುತ್ತದೆ. ನಂತರ ಪ್ರತಿ ಸೆಕೆಂಡಿಗೆ ಒಂದಕ್ಕಿಂತ ಹೆಚ್ಚು ಬಾರಿ ವಿಲೀನ ಟ್ರೀಗೆ ಡೇಟಾವನ್ನು ಸೇರಿಸುವುದು ಉತ್ತಮ. ಮತ್ತು ಏಕೆ ಎಂದು ಯಾರಿಗೆ ತಿಳಿದಿದೆ? ಸರಿ ಸರಿ. ನಾನು ಇದರ ಬಗ್ಗೆ ಸ್ವಲ್ಪ ಹೆಚ್ಚು ಹೇಳುತ್ತೇನೆ. ಮತ್ತೊಂದು ಕುತೂಹಲಕಾರಿ ಪ್ರಶ್ನೆಯೆಂದರೆ, ನಾವು ವಿಶ್ಲೇಷಣೆಗಳನ್ನು ಮಾಡುತ್ತಿಲ್ಲ, ನಾವು ಡೇಟಾವನ್ನು ಉತ್ಕೃಷ್ಟಗೊಳಿಸುವ ಅಗತ್ಯವಿಲ್ಲ, ನಮಗೆ ಮಧ್ಯಂತರ ಸರ್ವರ್‌ಗಳು ಅಗತ್ಯವಿಲ್ಲ, ನಾವು ನೇರವಾಗಿ "ಕ್ಲಿಕ್ಹೌಸ್" ಗೆ ಸೇರಿಸಲು ಬಯಸುತ್ತೇವೆ (ಆದ್ಯತೆ - ಹೆಚ್ಚು ನೇರವಾಗಿ, ಉತ್ತಮ).
ಅಂತೆಯೇ, MergeTree ನಲ್ಲಿ ಅಳವಡಿಕೆಯನ್ನು ಹೇಗೆ ಮಾಡಲಾಗುತ್ತದೆ? ಸೆಕೆಂಡಿಗೆ ಒಂದಕ್ಕಿಂತ ಹೆಚ್ಚು ಬಾರಿ ಅಥವಾ ಕಡಿಮೆ ಬಾರಿ ಅದರೊಳಗೆ ಸೇರಿಸುವುದು ಏಕೆ ಉತ್ತಮ? ಸತ್ಯವೆಂದರೆ “ಕ್ಲಿಕ್ಹೌಸ್” ಒಂದು ಸ್ತಂಭಾಕಾರದ ಡೇಟಾಬೇಸ್ ಮತ್ತು ಡೇಟಾವನ್ನು ಪ್ರಾಥಮಿಕ ಕೀಲಿಯ ಆರೋಹಣ ಕ್ರಮದಲ್ಲಿ ವಿಂಗಡಿಸುತ್ತದೆ ಮತ್ತು ನೀವು ಸೇರಿಸಿದಾಗ, ಡೇಟಾವನ್ನು ವಿಂಗಡಿಸಲಾದ ಕಾಲಮ್‌ಗಳ ಸಂಖ್ಯೆಗೆ ಸಮಾನವಾದ ಹಲವಾರು ಫೈಲ್ಗಳನ್ನು ರಚಿಸಲಾಗುತ್ತದೆ. ಪ್ರಾಥಮಿಕ ಕೀಲಿಯ ಆರೋಹಣ ಕ್ರಮದಲ್ಲಿ (ಪ್ರತ್ಯೇಕ ಡೈರೆಕ್ಟರಿಯನ್ನು ರಚಿಸಲಾಗಿದೆ, ಪ್ರತಿ ಇನ್ಸರ್ಟ್‌ಗಾಗಿ ಡಿಸ್ಕ್‌ನಲ್ಲಿರುವ ಫೈಲ್‌ಗಳ ಸೆಟ್). ನಂತರ ಮುಂದಿನ ಅಳವಡಿಕೆ ಬರುತ್ತದೆ, ಮತ್ತು ಹಿನ್ನೆಲೆಯಲ್ಲಿ ಅವುಗಳನ್ನು ದೊಡ್ಡ "ವಿಭಾಗಗಳಾಗಿ" ಸಂಯೋಜಿಸಲಾಗುತ್ತದೆ. ಡೇಟಾವನ್ನು ವಿಂಗಡಿಸಲಾಗಿರುವುದರಿಂದ, ಹೆಚ್ಚು ಮೆಮೊರಿಯನ್ನು ಸೇವಿಸದೆಯೇ ಎರಡು ವಿಂಗಡಿಸಲಾದ ಫೈಲ್ಗಳನ್ನು "ವಿಲೀನಗೊಳಿಸಲು" ಸಾಧ್ಯವಿದೆ.
ಆದರೆ, ನೀವು ಊಹಿಸಿದಂತೆ, ನೀವು ಪ್ರತಿ ಇನ್ಸರ್ಟ್ಗೆ 10 ಫೈಲ್ಗಳನ್ನು ಬರೆದರೆ, ನಂತರ ಕ್ಲಿಕ್ಹೌಸ್ (ಅಥವಾ ನಿಮ್ಮ ಸರ್ವರ್) ತ್ವರಿತವಾಗಿ ಕೊನೆಗೊಳ್ಳುತ್ತದೆ, ಆದ್ದರಿಂದ ದೊಡ್ಡ ಬ್ಯಾಚ್ಗಳಲ್ಲಿ ಸೇರಿಸಲು ಸೂಚಿಸಲಾಗುತ್ತದೆ. ಅದರಂತೆ, ನಾವು ಮೊದಲ ಯೋಜನೆಯನ್ನು ಉತ್ಪಾದನೆಗೆ ಪ್ರಾರಂಭಿಸಲಿಲ್ಲ. ನಾವು ತಕ್ಷಣವೇ ಒಂದನ್ನು ಪ್ರಾರಂಭಿಸಿದ್ದೇವೆ, ಇಲ್ಲಿ ಸಂಖ್ಯೆ 2 ಹೊಂದಿದೆ:
ಇಲ್ಲಿ ನಾವು ಪ್ರಾರಂಭಿಸಿದ ಸುಮಾರು ಸಾವಿರ ಸರ್ವರ್‌ಗಳಿವೆ ಎಂದು ಊಹಿಸಿ, ಕೇವಲ PHP ಇದೆ. ಮತ್ತು ಪ್ರತಿ ಸರ್ವರ್‌ನಲ್ಲಿ ನಮ್ಮ ಸ್ಥಳೀಯ ಏಜೆಂಟ್ ಇದೆ, ಅದನ್ನು ನಾವು "ಕಿಟನ್ಹೌಸ್" ಎಂದು ಕರೆಯುತ್ತೇವೆ, ಅದು "ಕ್ಲಿಕ್ಹೌಸ್" ನೊಂದಿಗೆ ಒಂದು ಸಂಪರ್ಕವನ್ನು ನಿರ್ವಹಿಸುತ್ತದೆ ಮತ್ತು ಪ್ರತಿ ಕೆಲವು ಸೆಕೆಂಡುಗಳಲ್ಲಿ ಡೇಟಾವನ್ನು ಸೇರಿಸುತ್ತದೆ. ಡೇಟಾವನ್ನು MergeTree ಗೆ ಸೇರಿಸುವುದಿಲ್ಲ, ಆದರೆ ಬಫರ್ ಟೇಬಲ್‌ಗೆ ಸೇರಿಸುತ್ತದೆ, ಇದು ತಕ್ಷಣವೇ MergeTree ಗೆ ನೇರವಾಗಿ ಸೇರಿಸುವುದನ್ನು ತಪ್ಪಿಸಲು ನಿಖರವಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ.
ಬಫರ್ ಕೋಷ್ಟಕಗಳೊಂದಿಗೆ ಕೆಲಸ ಮಾಡಿ
ಅದು ಏನು? ಬಫರ್ ಕೋಷ್ಟಕಗಳು ಛಿದ್ರಗೊಂಡ ಮೆಮೊರಿಯ ತುಣುಕು (ಅಂದರೆ, ಅದನ್ನು ಆಗಾಗ್ಗೆ ಸೇರಿಸಬಹುದು). ಅವು ಹಲವಾರು ತುಣುಕುಗಳನ್ನು ಒಳಗೊಂಡಿರುತ್ತವೆ, ಮತ್ತು ಪ್ರತಿಯೊಂದು ತುಣುಕುಗಳು ಸ್ವತಂತ್ರ ಬಫರ್ ಆಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತವೆ, ಮತ್ತು ಅವುಗಳನ್ನು ಸ್ವತಂತ್ರವಾಗಿ ತೊಳೆಯಲಾಗುತ್ತದೆ (ನೀವು ಬಫರ್ನಲ್ಲಿ ಅನೇಕ ತುಣುಕುಗಳನ್ನು ಹೊಂದಿದ್ದರೆ, ನಂತರ ಪ್ರತಿ ಸೆಕೆಂಡಿಗೆ ಅನೇಕ ಒಳಸೇರಿಸುವಿಕೆಗಳು ಇರುತ್ತವೆ). ಈ ಕೋಷ್ಟಕಗಳಿಂದ ಓದಲು ಸಾಧ್ಯವಿದೆ - ನಂತರ ನೀವು ಬಫರ್ ಮತ್ತು ಪೋಷಕ ಕೋಷ್ಟಕದ ವಿಷಯಗಳ ಒಕ್ಕೂಟವನ್ನು ಓದುತ್ತೀರಿ, ಆದರೆ ಈ ಕ್ಷಣದಲ್ಲಿ ಬರೆಯುವಿಕೆಯನ್ನು ನಿರ್ಬಂಧಿಸಲಾಗಿದೆ, ಆದ್ದರಿಂದ ಅಲ್ಲಿಂದ ಓದದಿರುವುದು ಉತ್ತಮ. ಮತ್ತು ಬಫರ್ ಕೋಷ್ಟಕಗಳು ಉತ್ತಮವಾದ ಕ್ಯೂಪಿಎಸ್ ಅನ್ನು ತೋರಿಸುತ್ತವೆ, ಅಂದರೆ, 3 ಸಾವಿರ ಕ್ಯೂಪಿಎಸ್ ವರೆಗೆ ಸೇರಿಸುವಾಗ ನಿಮಗೆ ಯಾವುದೇ ಸಮಸ್ಯೆಗಳಿಲ್ಲ. ಸರ್ವರ್ ಶಕ್ತಿಯನ್ನು ಕಳೆದುಕೊಂಡರೆ, ಡೇಟಾವನ್ನು ಕಳೆದುಕೊಳ್ಳಬಹುದು ಎಂಬುದು ಸ್ಪಷ್ಟವಾಗಿದೆ, ಏಕೆಂದರೆ ಅದನ್ನು ಮೆಮೊರಿಯಲ್ಲಿ ಮಾತ್ರ ಸಂಗ್ರಹಿಸಲಾಗಿದೆ.
ಅದೇ ಸಮಯದಲ್ಲಿ, ಬಫರ್ನೊಂದಿಗಿನ ಯೋಜನೆಯು ALTER ಅನ್ನು ಸಂಕೀರ್ಣಗೊಳಿಸುತ್ತದೆ, ಏಕೆಂದರೆ ನೀವು ಮೊದಲು ಹಳೆಯ ಬಫರ್ ಟೇಬಲ್ ಅನ್ನು ಹಳೆಯ ಸ್ಕೀಮ್ನೊಂದಿಗೆ ಬಿಡಬೇಕಾಗುತ್ತದೆ (ಡೇಟಾ ಎಲ್ಲಿಯೂ ಕಣ್ಮರೆಯಾಗುವುದಿಲ್ಲ, ಏಕೆಂದರೆ ಟೇಬಲ್ ಅಳಿಸುವ ಮೊದಲು ಅದನ್ನು ಫ್ಲಶ್ ಮಾಡಲಾಗುತ್ತದೆ). ನಂತರ ನೀವು ಅಗತ್ಯವಿರುವ ಟೇಬಲ್ ಅನ್ನು "ಮಾರ್ಪಡಿಸಿ" ಮತ್ತು ಮತ್ತೆ ಬಫರ್ ಟೇಬಲ್ ಅನ್ನು ರಚಿಸಿ. ಅಂತೆಯೇ, ಬಫರ್ ಟೇಬಲ್ ಇಲ್ಲದಿರುವಾಗ, ನಿಮ್ಮ ಡೇಟಾ ಎಲ್ಲಿಯೂ ಹರಿಯುವುದಿಲ್ಲ, ಆದರೆ ನೀವು ಕನಿಷ್ಟ ಸ್ಥಳೀಯವಾಗಿ ಡಿಸ್ಕ್ನಲ್ಲಿ ಅದನ್ನು ಹೊಂದಬಹುದು.
ಕಿಟನ್ಹೌಸ್ ಎಂದರೇನು ಮತ್ತು ಅದು ಹೇಗೆ ಕೆಲಸ ಮಾಡುತ್ತದೆ?
ಕಿಟನ್ಹೌಸ್ ಎಂದರೇನು? ಇದು ಪ್ರಾಕ್ಸಿ ಆಗಿದೆ. ಯಾವ ಭಾಷೆ ಊಹಿಸಿ? ನನ್ನ ವರದಿಯಲ್ಲಿ ನಾನು ಹೆಚ್ಚು ಪ್ರಚೋದನಕಾರಿ ವಿಷಯಗಳನ್ನು ಸಂಗ್ರಹಿಸಿದ್ದೇನೆ - “ಕ್ಲಿಕ್ಹೌಸ್”, ಹೋಗಿ, ಬಹುಶಃ ನಾನು ಬೇರೆ ಯಾವುದನ್ನಾದರೂ ನೆನಪಿಸಿಕೊಳ್ಳುತ್ತೇನೆ. ಹೌದು, ಇದನ್ನು Go ನಲ್ಲಿ ಬರೆಯಲಾಗಿದೆ, ಏಕೆಂದರೆ C ನಲ್ಲಿ ಹೇಗೆ ಬರೆಯಬೇಕೆಂದು ನನಗೆ ನಿಜವಾಗಿಯೂ ತಿಳಿದಿಲ್ಲ, ನಾನು ಬಯಸುವುದಿಲ್ಲ.
ಅಂತೆಯೇ, ಇದು ಪ್ರತಿ ಸರ್ವರ್ನೊಂದಿಗೆ ಸಂಪರ್ಕವನ್ನು ನಿರ್ವಹಿಸುತ್ತದೆ ಮತ್ತು ಮೆಮೊರಿಗೆ ಬರೆಯಬಹುದು. ಉದಾಹರಣೆಗೆ, ನಾವು ಕ್ಲಿಕ್‌ಹೌಸ್‌ಗೆ ದೋಷ ಲಾಗ್‌ಗಳನ್ನು ಬರೆದರೆ, ಕ್ಲಿಕ್‌ಹೌಸ್‌ಗೆ ಡೇಟಾವನ್ನು ಸೇರಿಸಲು ಸಮಯವಿಲ್ಲದಿದ್ದರೆ (ಎಲ್ಲಾ ನಂತರ, ಹೆಚ್ಚು ಬರೆಯಲ್ಪಟ್ಟಿದ್ದರೆ), ನಂತರ ನಾವು ಮೆಮೊರಿಯನ್ನು ಹಿಗ್ಗಿಸುವುದಿಲ್ಲ - ಉಳಿದವುಗಳನ್ನು ನಾವು ಸರಳವಾಗಿ ಎಸೆಯುತ್ತೇವೆ. ಏಕೆಂದರೆ ನಾವು ಪ್ರತಿ ಸೆಕೆಂಡಿಗೆ ಹಲವಾರು ಗಿಗಾಬಿಟ್‌ಗಳ ದೋಷಗಳನ್ನು ಬರೆದರೆ, ನಾವು ಬಹುಶಃ ಕೆಲವನ್ನು ಹೊರಹಾಕಬಹುದು. ಕಿಟನ್ಹೌಸ್ ಇದನ್ನು ಮಾಡಬಹುದು. ಜೊತೆಗೆ, ಇದು ವಿಶ್ವಾಸಾರ್ಹ ವಿತರಣೆಯನ್ನು ಮಾಡಬಹುದು, ಅಂದರೆ, ಸ್ಥಳೀಯ ಗಣಕದಲ್ಲಿ ಡಿಸ್ಕ್‌ಗೆ ಬರೆಯುವುದು ಮತ್ತು ಪ್ರತಿ ಬಾರಿ (ಅಲ್ಲಿ, ಪ್ರತಿ ಒಂದೆರಡು ಸೆಕೆಂಡುಗಳಿಗೊಮ್ಮೆ) ಈ ಫೈಲ್‌ನಿಂದ ಡೇಟಾವನ್ನು ತಲುಪಿಸಲು ಪ್ರಯತ್ನಿಸುತ್ತದೆ. ಮತ್ತು ಮೊದಲಿಗೆ ನಾವು ನಿಯಮಿತ ಮೌಲ್ಯಗಳ ಸ್ವರೂಪವನ್ನು ಬಳಸಿದ್ದೇವೆ - ಕೆಲವು ಬೈನರಿ ಫಾರ್ಮ್ಯಾಟ್ ಅಲ್ಲ, ಪಠ್ಯ ಸ್ವರೂಪ (ಸಾಮಾನ್ಯ SQL ನಂತೆ).
ಆದರೆ ನಂತರ ಇದು ಸಂಭವಿಸಿತು. ನಾವು ವಿಶ್ವಾಸಾರ್ಹ ವಿತರಣೆಯನ್ನು ಬಳಸಿದ್ದೇವೆ, ಲಾಗ್‌ಗಳನ್ನು ಬರೆದಿದ್ದೇವೆ, ನಂತರ ನಿರ್ಧರಿಸಿದ್ದೇವೆ (ಇದು ಷರತ್ತುಬದ್ಧ ಪರೀಕ್ಷಾ ಕ್ಲಸ್ಟರ್ ಆಗಿತ್ತು)... ಇದನ್ನು ಹಲವಾರು ಗಂಟೆಗಳ ಕಾಲ ಹೊರಹಾಕಲಾಯಿತು ಮತ್ತು ಮತ್ತೆ ತರಲಾಯಿತು, ಮತ್ತು ಒಂದು ಸಾವಿರ ಸರ್ವರ್‌ಗಳಿಂದ ಅಳವಡಿಕೆ ಪ್ರಾರಂಭವಾಯಿತು - ಕ್ಲಿಕ್ಹೌಸ್ ಇನ್ನೂ “ಥ್ರೆಡ್ ಆನ್ ಕನೆಕ್ಷನ್” - ಅದರ ಪ್ರಕಾರ, ಸಾವಿರ ಸಂಪರ್ಕಗಳಲ್ಲಿ, ಸಕ್ರಿಯ ಅಳವಡಿಕೆಯು ಸರ್ವರ್‌ನಲ್ಲಿ ಸುಮಾರು ಒಂದೂವರೆ ಸಾವಿರದ ಲೋಡ್ ಸರಾಸರಿಗೆ ಕಾರಣವಾಗುತ್ತದೆ. ಆಶ್ಚರ್ಯಕರವಾಗಿ, ಸರ್ವರ್ ವಿನಂತಿಗಳನ್ನು ಸ್ವೀಕರಿಸಿದೆ, ಆದರೆ ಸ್ವಲ್ಪ ಸಮಯದ ನಂತರ ಡೇಟಾವನ್ನು ಇನ್ನೂ ಸೇರಿಸಲಾಯಿತು; ಆದರೆ ಸರ್ವರ್‌ಗೆ ಅದನ್ನು ಪೂರೈಸುವುದು ತುಂಬಾ ಕಷ್ಟಕರವಾಗಿತ್ತು ...
nginx ಸೇರಿಸಿ
ಪ್ರತಿ ಸಂಪರ್ಕ ಮಾದರಿಗೆ ಥ್ರೆಡ್‌ಗೆ ಅಂತಹ ಪರಿಹಾರವು nginx ಆಗಿದೆ. ನಾವು ಕ್ಲಿಕ್‌ಹೌಸ್‌ನ ಮುಂದೆ nginx ಅನ್ನು ಸ್ಥಾಪಿಸಿದ್ದೇವೆ, ಅದೇ ಸಮಯದಲ್ಲಿ ಎರಡು ಪ್ರತಿಕೃತಿಗಳಿಗೆ ಸಮತೋಲನವನ್ನು ಹೊಂದಿಸಿದ್ದೇವೆ (ನಮ್ಮ ಇನ್ಸರ್ಟ್ ವೇಗವು 2 ಪಟ್ಟು ಹೆಚ್ಚಾಗಿದೆ, ಆದರೂ ಇದು ನಿಜವಲ್ಲ) ಮತ್ತು ಕ್ಲಿಕ್‌ಹೌಸ್‌ಗೆ ಸಂಪರ್ಕಗಳ ಸಂಖ್ಯೆಯನ್ನು ಸೀಮಿತಗೊಳಿಸಿದೆ ಅಪ್ಸ್ಟ್ರೀಮ್ ಮತ್ತು, ಅದರ ಪ್ರಕಾರ, ಹೆಚ್ಚು , 50 ಸಂಪರ್ಕಗಳಿಗಿಂತ ಹೆಚ್ಚು, ಸೇರಿಸುವಲ್ಲಿ ಯಾವುದೇ ಅರ್ಥವಿಲ್ಲ ಎಂದು ತೋರುತ್ತದೆ.
ಈ ಯೋಜನೆಯು ಸಾಮಾನ್ಯವಾಗಿ ಅನಾನುಕೂಲಗಳನ್ನು ಹೊಂದಿದೆ ಎಂದು ನಾವು ಅರಿತುಕೊಂಡಿದ್ದೇವೆ, ಏಕೆಂದರೆ ನಾವು ಇಲ್ಲಿ ಕೇವಲ ಒಂದು nginx ಅನ್ನು ಹೊಂದಿದ್ದೇವೆ. ಅಂತೆಯೇ, ಈ nginx ಕ್ರ್ಯಾಶ್ ಆಗಿದ್ದರೆ, ಪ್ರತಿಕೃತಿಗಳ ಉಪಸ್ಥಿತಿಯ ಹೊರತಾಗಿಯೂ, ನಾವು ಡೇಟಾವನ್ನು ಕಳೆದುಕೊಳ್ಳುತ್ತೇವೆ ಅಥವಾ ಕನಿಷ್ಠ ಎಲ್ಲಿಯೂ ಬರೆಯಬೇಡಿ. ಅದಕ್ಕಾಗಿಯೇ ನಾವು ನಮ್ಮದೇ ಆದ ಲೋಡ್ ಬ್ಯಾಲೆನ್ಸಿಂಗ್ ಮಾಡಿದ್ದೇವೆ. "ಕ್ಲಿಕ್ಹೌಸ್" ಇನ್ನೂ ಲಾಗ್ಗಳಿಗೆ ಸೂಕ್ತವಾಗಿದೆ ಎಂದು ನಾವು ಅರಿತುಕೊಂಡಿದ್ದೇವೆ ಮತ್ತು "ರಾಕ್ಷಸ" ಸಹ ತನ್ನ ದಾಖಲೆಗಳನ್ನು "ಕ್ಲಿಕ್ಹೌಸ್" ನಲ್ಲಿ ಬರೆಯಲು ಪ್ರಾರಂಭಿಸಿದನು - ತುಂಬಾ ಅನುಕೂಲಕರವಾಗಿದೆ, ಪ್ರಾಮಾಣಿಕವಾಗಿ. ನಾವು ಇನ್ನೂ ಇತರ "ರಾಕ್ಷಸರು" ಅದನ್ನು ಬಳಸುತ್ತೇವೆ.
ನಂತರ ನಾವು ಈ ಆಸಕ್ತಿದಾಯಕ ಸಮಸ್ಯೆಯನ್ನು ಕಂಡುಹಿಡಿದಿದ್ದೇವೆ: ನೀವು SQL ಮೋಡ್‌ನಲ್ಲಿ ಸೇರಿಸುವ ಪ್ರಮಾಣಿತವಲ್ಲದ ವಿಧಾನವನ್ನು ಬಳಸಿದರೆ, ಅದು ಪೂರ್ಣ ಪ್ರಮಾಣದ AST- ಆಧಾರಿತ SQL ಪಾರ್ಸರ್ ಅನ್ನು ಒತ್ತಾಯಿಸುತ್ತದೆ, ಇದು ಸಾಕಷ್ಟು ನಿಧಾನವಾಗಿರುತ್ತದೆ. ಅಂತೆಯೇ, ಇದು ಎಂದಿಗೂ ಸಂಭವಿಸುವುದಿಲ್ಲ ಎಂದು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳಲು ನಾವು ಸೆಟ್ಟಿಂಗ್‌ಗಳನ್ನು ಸೇರಿಸಿದ್ದೇವೆ. ನಾವು ಲೋಡ್ ಬ್ಯಾಲೆನ್ಸಿಂಗ್, ಆರೋಗ್ಯ ತಪಾಸಣೆಗಳನ್ನು ಮಾಡಿದ್ದೇವೆ, ಇದರಿಂದ ಒಬ್ಬರು ಸತ್ತರೆ, ನಾವು ಇನ್ನೂ ಡೇಟಾವನ್ನು ಬಿಡುತ್ತೇವೆ. ನಾವು ಈಗ ವಿಭಿನ್ನ ಕ್ಲಿಕ್ಹೌಸ್ ಕ್ಲಸ್ಟರ್‌ಗಳನ್ನು ಹೊಂದಲು ಅಗತ್ಯವಿರುವ ಸಾಕಷ್ಟು ಕೋಷ್ಟಕಗಳನ್ನು ಹೊಂದಿದ್ದೇವೆ. ಮತ್ತು ನಾವು ಇತರ ಬಳಕೆಗಳ ಬಗ್ಗೆ ಯೋಚಿಸಲು ಪ್ರಾರಂಭಿಸಿದ್ದೇವೆ - ಉದಾಹರಣೆಗೆ, ನಾವು nginx ಮಾಡ್ಯೂಲ್‌ಗಳಿಂದ ಲಾಗ್‌ಗಳನ್ನು ಬರೆಯಲು ಬಯಸಿದ್ದೇವೆ, ಆದರೆ ನಮ್ಮ RPC ಅನ್ನು ಹೇಗೆ ಸಂವಹನ ಮಾಡುವುದು ಎಂದು ಅವರಿಗೆ ತಿಳಿದಿಲ್ಲ. ಸರಿ, ಕನಿಷ್ಠ ಹೇಗಾದರೂ ಕಳುಹಿಸುವುದು ಹೇಗೆ ಎಂದು ನಾನು ಅವರಿಗೆ ಕಲಿಸಲು ಬಯಸುತ್ತೇನೆ - ಉದಾಹರಣೆಗೆ, ಯುಡಿಪಿ ಮೂಲಕ ಲೋಕಲ್ ಹೋಸ್ಟ್‌ನಲ್ಲಿ ಈವೆಂಟ್‌ಗಳನ್ನು ಸ್ವೀಕರಿಸಲು ಮತ್ತು ನಂತರ ಅವುಗಳನ್ನು ಕ್ಲಿಕ್‌ಹೌಸ್‌ಗೆ ಫಾರ್ವರ್ಡ್ ಮಾಡಲು.
ಪರಿಹಾರದಿಂದ ಒಂದು ಹೆಜ್ಜೆ ದೂರ
ಅಂತಿಮ ಯೋಜನೆಯು ಈ ರೀತಿ ಕಾಣಲಾರಂಭಿಸಿತು (ಈ ಸ್ಕೀಮ್‌ನ ನಾಲ್ಕನೇ ಆವೃತ್ತಿ): ಕ್ಲಿಕ್‌ಹೌಸ್‌ನ ಮುಂಭಾಗದಲ್ಲಿರುವ ಪ್ರತಿ ಸರ್ವರ್‌ನಲ್ಲಿ nginx (ಅದೇ ಸರ್ವರ್‌ನಲ್ಲಿ) ಇರುತ್ತದೆ ಮತ್ತು ಇದು 50 ರ ಸಂಪರ್ಕಗಳ ಸಂಖ್ಯೆಯ ಮಿತಿಯೊಂದಿಗೆ ಸ್ಥಳೀಯ ಹೋಸ್ಟ್‌ಗೆ ವಿನಂತಿಗಳನ್ನು ಪ್ರಾಕ್ಸಿ ಮಾಡುತ್ತದೆ. ತುಂಡುಗಳು. ಮತ್ತು ಈ ಯೋಜನೆಯು ಈಗಾಗಲೇ ಸಾಕಷ್ಟು ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತಿದೆ, ಅದರೊಂದಿಗೆ ಎಲ್ಲವೂ ಚೆನ್ನಾಗಿತ್ತು.
ಸುಮಾರು ಒಂದು ತಿಂಗಳ ಕಾಲ ನಾವು ಈ ರೀತಿ ಬದುಕಿದ್ದೇವೆ. ಪ್ರತಿಯೊಬ್ಬರೂ ಸಂತೋಷವಾಗಿದ್ದರು, ಅವರು ಕೋಷ್ಟಕಗಳನ್ನು ಸೇರಿಸಿದರು, ಅವರು ಸೇರಿಸಿದರು, ಅವರು ಸೇರಿಸಿದರು ... ಸಾಮಾನ್ಯವಾಗಿ, ನಾವು ಬಫರ್ ಕೋಷ್ಟಕಗಳನ್ನು ಸೇರಿಸಿದ ವಿಧಾನವು ತುಂಬಾ ಸೂಕ್ತವಲ್ಲ ಎಂದು ಅದು ಬದಲಾಯಿತು (ಅದನ್ನು ನಾವು ಹಾಗೆ ಇಡೋಣ). ನಾವು ಪ್ರತಿ ಕೋಷ್ಟಕದಲ್ಲಿ 16 ತುಣುಕುಗಳನ್ನು ಮತ್ತು ಒಂದೆರಡು ಸೆಕೆಂಡುಗಳ ಫ್ಲಾಶ್ ಮಧ್ಯಂತರವನ್ನು ಮಾಡಿದ್ದೇವೆ; ನಾವು 20 ಕೋಷ್ಟಕಗಳನ್ನು ಹೊಂದಿದ್ದೇವೆ ಮತ್ತು ಪ್ರತಿ ಟೇಬಲ್ ಪ್ರತಿ ಸೆಕೆಂಡಿಗೆ 8 ಒಳಸೇರಿಸುವಿಕೆಯನ್ನು ಸ್ವೀಕರಿಸಿದೆ - ಮತ್ತು ಈ ಹಂತದಲ್ಲಿ "ಕ್ಲಿಕ್ಹೌಸ್" ಪ್ರಾರಂಭವಾಯಿತು ... ದಾಖಲೆಗಳು ನಿಧಾನಗೊಳ್ಳಲು ಪ್ರಾರಂಭಿಸಿದವು. ಅವರು ಉತ್ತೀರ್ಣರಾಗಲಿಲ್ಲ ಮಾತ್ರವಲ್ಲ... ಪೂರ್ವನಿಯೋಜಿತವಾಗಿ, nginx ಅಂತಹ ಆಸಕ್ತಿದಾಯಕ ವಿಷಯವನ್ನು ಹೊಂದಿದ್ದು, ಸಂಪರ್ಕಗಳು ಅಪ್‌ಸ್ಟ್ರೀಮ್‌ನಲ್ಲಿ ಕೊನೆಗೊಂಡರೆ, ಅದು ಎಲ್ಲಾ ಹೊಸ ವಿನಂತಿಗಳಿಗೆ "502" ಅನ್ನು ಹಿಂತಿರುಗಿಸುತ್ತದೆ.
ಮತ್ತು ಇಲ್ಲಿ ನಾವು ಹೊಂದಿದ್ದೇವೆ (ನಾನು ಕ್ಲಿಕ್‌ಹೌಸ್‌ನಲ್ಲಿಯೇ ಲಾಗ್‌ಗಳನ್ನು ನೋಡಿದ್ದೇನೆ) ಸುಮಾರು ಅರ್ಧ ಶೇಕಡಾ ವಿನಂತಿಗಳು ವಿಫಲವಾಗಿವೆ. ಅಂತೆಯೇ, ಡಿಸ್ಕ್ ಬಳಕೆ ಹೆಚ್ಚಿತ್ತು, ಬಹಳಷ್ಟು ವಿಲೀನಗಳು ಇದ್ದವು. ಸರಿ, ನಾನು ಏನು ಮಾಡಿದೆ? ಸ್ವಾಭಾವಿಕವಾಗಿ, ನಿಖರವಾಗಿ ಸಂಪರ್ಕ ಮತ್ತು ಅಪ್ಸ್ಟ್ರೀಮ್ ಏಕೆ ಕೊನೆಗೊಂಡಿತು ಎಂಬುದನ್ನು ಕಂಡುಹಿಡಿಯಲು ನಾನು ತಲೆಕೆಡಿಸಿಕೊಳ್ಳಲಿಲ್ಲ.
nginx ಅನ್ನು ರಿವರ್ಸ್ ಪ್ರಾಕ್ಸಿಯೊಂದಿಗೆ ಬದಲಾಯಿಸಲಾಗುತ್ತಿದೆ
ಇದನ್ನು ನಾವೇ ನಿರ್ವಹಿಸಬೇಕು ಎಂದು ನಾನು ನಿರ್ಧರಿಸಿದೆ, ನಾವು ಅದನ್ನು nginx ಗೆ ಬಿಡುವ ಅಗತ್ಯವಿಲ್ಲ - ಕ್ಲಿಕ್‌ಹೌಸ್‌ನಲ್ಲಿ ಯಾವ ಕೋಷ್ಟಕಗಳಿವೆ ಎಂದು nginx ಗೆ ತಿಳಿದಿಲ್ಲ, ಮತ್ತು ನಾನು nginx ಅನ್ನು ರಿವರ್ಸ್ ಪ್ರಾಕ್ಸಿಯೊಂದಿಗೆ ಬದಲಾಯಿಸಿದೆ, ಅದನ್ನು ನಾನೇ ಬರೆದಿದ್ದೇನೆ.
ಅವನು ಏನು ಮಾಡುತ್ತಿದ್ದಾನೆ? ಇದು fasthttp ಲೈಬ್ರರಿ "goshnoy" ಅನ್ನು ಆಧರಿಸಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ, ಅಂದರೆ ವೇಗವಾಗಿ, ಬಹುತೇಕ nginx ನಂತೆ ವೇಗವಾಗಿ. ಕ್ಷಮಿಸಿ, ಇಗೊರ್, ನೀವು ಇಲ್ಲಿ ಉಪಸ್ಥಿತರಿದ್ದರೆ (ಗಮನಿಸಿ: ಇಗೊರ್ ಸೈಸೋವ್ ಅವರು nginx ವೆಬ್ ಸರ್ವರ್ ಅನ್ನು ರಚಿಸಿದ ರಷ್ಯಾದ ಪ್ರೋಗ್ರಾಮರ್). ಇದು ಯಾವ ರೀತಿಯ ಪ್ರಶ್ನೆಗಳು ಎಂಬುದನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳಬಹುದು - ಸೇರಿಸಿ ಅಥವಾ ಆಯ್ಕೆ ಮಾಡಿ - ಅದರ ಪ್ರಕಾರ, ಇದು ವಿಭಿನ್ನ ರೀತಿಯ ಪ್ರಶ್ನೆಗಳಿಗೆ ವಿಭಿನ್ನ ಸಂಪರ್ಕ ಪೂಲ್‌ಗಳನ್ನು ಹೊಂದಿದೆ.
ಅಂತೆಯೇ, ಅಳವಡಿಕೆ ವಿನಂತಿಗಳನ್ನು ಪೂರ್ಣಗೊಳಿಸಲು ನಮಗೆ ಸಮಯವಿಲ್ಲದಿದ್ದರೂ ಸಹ, "ಆಯ್ಕೆಗಳು" ಹಾದುಹೋಗುತ್ತವೆ ಮತ್ತು ಪ್ರತಿಯಾಗಿ. ಮತ್ತು ಇದು ಡೇಟಾವನ್ನು ಬಫರ್ ಕೋಷ್ಟಕಗಳಾಗಿ ಗುಂಪು ಮಾಡುತ್ತದೆ - ಸಣ್ಣ ಬಫರ್‌ನೊಂದಿಗೆ: ಯಾವುದೇ ದೋಷಗಳು, ಸಿಂಟ್ಯಾಕ್ಸ್ ದೋಷಗಳು ಮತ್ತು ಮುಂತಾದವುಗಳು ಇದ್ದಲ್ಲಿ - ಉಳಿದ ಡೇಟಾದ ಮೇಲೆ ಅವು ಹೆಚ್ಚು ಪರಿಣಾಮ ಬೀರುವುದಿಲ್ಲ, ಏಕೆಂದರೆ ನಾವು ಬಫರ್ ಕೋಷ್ಟಕಗಳಲ್ಲಿ ಸರಳವಾಗಿ ಸೇರಿಸಿದಾಗ, ನಾವು ಸಣ್ಣ "ಬಾಚಿ" ಹೊಂದಿತ್ತು, ಮತ್ತು ಎಲ್ಲಾ ಸಿಂಟ್ಯಾಕ್ಸ್ ದೋಷಗಳು ಈ ಸಣ್ಣ ತುಣುಕಿನ ಮೇಲೆ ಮಾತ್ರ ಪರಿಣಾಮ ಬೀರುತ್ತವೆ; ಮತ್ತು ಇಲ್ಲಿ ಅವರು ಈಗಾಗಲೇ ದೊಡ್ಡ ಬಫರ್ ಮೇಲೆ ಪರಿಣಾಮ ಬೀರುತ್ತಾರೆ. ಚಿಕ್ಕದು 1 ಮೆಗಾಬೈಟ್, ಅಂದರೆ ಅಷ್ಟು ಚಿಕ್ಕದಲ್ಲ.
ಸಿಂಕ್ರೊನೈಸೇಶನ್ ಅನ್ನು ಸೇರಿಸುವುದು ಮತ್ತು ಮೂಲಭೂತವಾಗಿ nginx ಅನ್ನು ಬದಲಾಯಿಸುವುದು, ಮೂಲಭೂತವಾಗಿ nginx ಮೊದಲು ಮಾಡಿದಂತೆಯೇ ಮಾಡುತ್ತದೆ - ಇದಕ್ಕಾಗಿ ನೀವು ಸ್ಥಳೀಯ "ಕಿಟನ್ಹೌಸ್" ಅನ್ನು ಬದಲಾಯಿಸುವ ಅಗತ್ಯವಿಲ್ಲ. ಮತ್ತು ಇದು fasthttp ಅನ್ನು ಬಳಸುವುದರಿಂದ, ಇದು ತುಂಬಾ ವೇಗವಾಗಿರುತ್ತದೆ - ರಿವರ್ಸ್ ಪ್ರಾಕ್ಸಿ ಮೂಲಕ ಸಿಂಗಲ್ ಇನ್ಸರ್ಟ್‌ಗಳಿಗಾಗಿ ನೀವು ಪ್ರತಿ ಸೆಕೆಂಡಿಗೆ 100 ಸಾವಿರಕ್ಕೂ ಹೆಚ್ಚು ವಿನಂತಿಗಳನ್ನು ಮಾಡಬಹುದು. ಸೈದ್ಧಾಂತಿಕವಾಗಿ, ನೀವು ಕಿಟನ್ಹೌಸ್ ರಿವರ್ಸ್ ಪ್ರಾಕ್ಸಿಗೆ ಒಂದು ಸಮಯದಲ್ಲಿ ಒಂದು ಸಾಲನ್ನು ಸೇರಿಸಬಹುದು, ಆದರೆ ನಾವು ಅದನ್ನು ಮಾಡುವುದಿಲ್ಲ.
ಯೋಜನೆಯು ಈ ರೀತಿ ಕಾಣಲಾರಂಭಿಸಿತು: “ಕಿಟನ್ಹೌಸ್”, ರಿವರ್ಸ್ ಪ್ರಾಕ್ಸಿ ಅನೇಕ ವಿನಂತಿಗಳನ್ನು ಕೋಷ್ಟಕಗಳಾಗಿ ಗುಂಪು ಮಾಡುತ್ತದೆ ಮತ್ತು ಪ್ರತಿಯಾಗಿ, ಬಫರ್ ಕೋಷ್ಟಕಗಳು ಅವುಗಳನ್ನು ಮುಖ್ಯವಾದವುಗಳಲ್ಲಿ ಸೇರಿಸುತ್ತವೆ.
ಕೊಲೆಗಾರ ತಾತ್ಕಾಲಿಕ ಪರಿಹಾರ, ಕಿಟನ್ ಶಾಶ್ವತ
ಇದು ಆಸಕ್ತಿದಾಯಕ ಸಮಸ್ಯೆಯಾಗಿದೆ... ನಿಮ್ಮಲ್ಲಿ ಯಾರಾದರೂ fasthttp ಬಳಸಿದ್ದೀರಾ? POST ವಿನಂತಿಗಳೊಂದಿಗೆ ಫಾಸ್ಟ್‌http ಅನ್ನು ಯಾರು ಬಳಸಿದ್ದಾರೆ? ಬಹುಶಃ, ಇದನ್ನು ನಿಜವಾಗಿಯೂ ಮಾಡಬಾರದು, ಏಕೆಂದರೆ ಇದು ವಿನಂತಿಯ ದೇಹವನ್ನು ಡಿಫಾಲ್ಟ್ ಆಗಿ ಬಫರ್ ಮಾಡುತ್ತದೆ ಮತ್ತು ನಮ್ಮ ಬಫರ್ ಗಾತ್ರವನ್ನು 16 ಮೆಗಾಬೈಟ್‌ಗಳಿಗೆ ಹೊಂದಿಸಲಾಗಿದೆ. ಅಳವಡಿಕೆಯು ಕೆಲವು ಹಂತದಲ್ಲಿ ಮುಂದುವರಿಯುವುದನ್ನು ನಿಲ್ಲಿಸಿತು, ಮತ್ತು ಎಲ್ಲಾ ಹತ್ತಾರು ಸಾವಿರ ಸರ್ವರ್‌ಗಳಿಂದ 16-ಮೆಗಾಬೈಟ್ ಭಾಗಗಳು ಬರಲಾರಂಭಿಸಿದವು, ಮತ್ತು ಕ್ಲಿಕ್‌ಹೌಸ್‌ಗೆ ಕಳುಹಿಸುವ ಮೊದಲು ಅವೆಲ್ಲವೂ ಮೆಮೊರಿಯಲ್ಲಿ ಬಫರ್ ಆಗಿದ್ದವು. ಅದರಂತೆ, ಮೆಮೊರಿ ಮುಗಿದುಹೋಯಿತು, ಔಟ್-ಆಫ್-ಮೆಮೊರಿ ಕಿಲ್ಲರ್ ಬಂದು ರಿವರ್ಸ್ ಪ್ರಾಕ್ಸಿಯನ್ನು ಕೊಂದನು (ಅಥವಾ "ಕ್ಲಿಕ್ಹೌಸ್", ಇದು ರಿವರ್ಸ್ ಪ್ರಾಕ್ಸಿಗಿಂತ ಸೈದ್ಧಾಂತಿಕವಾಗಿ "ತಿನ್ನಬಹುದು"). ಚಕ್ರವು ಪುನರಾವರ್ತನೆಯಾಯಿತು. ತುಂಬಾ ಆಹ್ಲಾದಕರ ಸಮಸ್ಯೆ ಅಲ್ಲ. ಹಲವಾರು ತಿಂಗಳುಗಳ ಕಾರ್ಯಾಚರಣೆಯ ನಂತರವೇ ನಾವು ಇದನ್ನು ಮುಗ್ಗರಿಸಿದ್ದೇವೆ.
ನಾನೇನು ಮಾಡಿಬಿಟ್ಟೆ? ಮತ್ತೆ, ನಿಖರವಾಗಿ ಏನಾಯಿತು ಎಂಬುದನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳಲು ನಾನು ನಿಜವಾಗಿಯೂ ಇಷ್ಟಪಡುವುದಿಲ್ಲ. ನೀವು ಮೆಮೊರಿಗೆ ಬಫರ್ ಮಾಡಬಾರದು ಎಂಬುದು ಬಹಳ ಸ್ಪಷ್ಟವಾಗಿದೆ ಎಂದು ನಾನು ಭಾವಿಸುತ್ತೇನೆ. ನಾನು ಪ್ರಯತ್ನಿಸಿದರೂ ಫಾಸ್ಟ್‌http ಅನ್ನು ಪ್ಯಾಚ್ ಮಾಡಲು ಸಾಧ್ಯವಾಗಲಿಲ್ಲ. ಆದರೆ ನಾನು ಅದನ್ನು ಮಾಡಲು ಒಂದು ಮಾರ್ಗವನ್ನು ಕಂಡುಕೊಂಡಿದ್ದೇನೆ ಇದರಿಂದ ಏನನ್ನೂ ಪ್ಯಾಚ್ ಮಾಡುವ ಅಗತ್ಯವಿಲ್ಲ, ಮತ್ತು ನಾನು HTTP ಯಲ್ಲಿ ನನ್ನದೇ ಆದ ವಿಧಾನವನ್ನು ಕಂಡುಕೊಂಡಿದ್ದೇನೆ - ನಾನು ಅದನ್ನು KITTEN ಎಂದು ಕರೆದಿದ್ದೇನೆ. ಸರಿ, ಇದು ತಾರ್ಕಿಕವಾಗಿದೆ - “ವಿಕೆ”, “ಕಿಟನ್”... ಇನ್ನೇನು?..
ಕಿಟನ್ ವಿಧಾನದೊಂದಿಗೆ ಸರ್ವರ್‌ಗೆ ವಿನಂತಿಯು ಬಂದರೆ, ಸರ್ವರ್ ತಾರ್ಕಿಕವಾಗಿ “ಮಿಯಾಂವ್” ಎಂದು ಪ್ರತಿಕ್ರಿಯಿಸಬೇಕು. ಅವನು ಇದಕ್ಕೆ ಪ್ರತಿಕ್ರಿಯಿಸಿದರೆ, ಅವನು ಈ ಪ್ರೋಟೋಕಾಲ್ ಅನ್ನು ಅರ್ಥಮಾಡಿಕೊಂಡಿದ್ದಾನೆ ಎಂದು ಪರಿಗಣಿಸಲಾಗುತ್ತದೆ, ಮತ್ತು ನಂತರ ನಾನು ಸಂಪರ್ಕವನ್ನು ಪ್ರತಿಬಂಧಿಸುತ್ತೇನೆ (fasthttp ಅಂತಹ ವಿಧಾನವನ್ನು ಹೊಂದಿದೆ), ಮತ್ತು ಸಂಪರ್ಕವು "ಕಚ್ಚಾ" ಮೋಡ್ಗೆ ಹೋಗುತ್ತದೆ. ನನಗೆ ಅದು ಏಕೆ ಬೇಕು? TCP ಸಂಪರ್ಕಗಳಿಂದ ಓದುವಿಕೆ ಹೇಗೆ ಸಂಭವಿಸುತ್ತದೆ ಎಂಬುದನ್ನು ನಾನು ನಿಯಂತ್ರಿಸಲು ಬಯಸುತ್ತೇನೆ. ಟಿಸಿಪಿ ಅದ್ಭುತವಾದ ಆಸ್ತಿಯನ್ನು ಹೊಂದಿದೆ: ಯಾರೂ ಇನ್ನೊಂದು ಕಡೆಯಿಂದ ಓದದಿದ್ದರೆ, ಬರಹವು ಕಾಯಲು ಪ್ರಾರಂಭಿಸುತ್ತದೆ, ಮತ್ತು ಸ್ಮರಣೆಯನ್ನು ವಿಶೇಷವಾಗಿ ಖರ್ಚು ಮಾಡಲಾಗುವುದಿಲ್ಲ.
ಮತ್ತು ಆದ್ದರಿಂದ ನಾನು ಒಂದು ಸಮಯದಲ್ಲಿ ಸುಮಾರು 50 ಕ್ಲೈಂಟ್‌ಗಳಿಂದ ಓದಿದ್ದೇನೆ (ಐವತ್ತರಿಂದ ಏಕೆಂದರೆ ಐವತ್ತು ಖಂಡಿತವಾಗಿಯೂ ಸಾಕಾಗಬೇಕು, ದರವು ಇನ್ನೊಂದು ಡಿಸಿಯಿಂದ ಬಂದರೂ ಸಹ) ... ಈ ವಿಧಾನದಿಂದ ಕನಿಷ್ಠ 20 ಬಾರಿ ಬಳಕೆ ಕಡಿಮೆಯಾಗಿದೆ, ಆದರೆ ನಾನು, ಪ್ರಾಮಾಣಿಕವಾಗಿ ಹೇಳುತ್ತೇನೆ , ನಾನು ನಿಖರವಾಗಿ ಯಾವ ಸಮಯವನ್ನು ಅಳೆಯಲು ಸಾಧ್ಯವಾಗಲಿಲ್ಲ, ಏಕೆಂದರೆ ಅದು ಈಗಾಗಲೇ ಅರ್ಥಹೀನವಾಗಿದೆ (ಇದು ಈಗಾಗಲೇ ದೋಷದ ಮಟ್ಟವನ್ನು ತಲುಪಿದೆ). ಪ್ರೋಟೋಕಾಲ್ ಬೈನರಿ ಆಗಿದೆ, ಅಂದರೆ, ಇದು ಟೇಬಲ್ ಹೆಸರು ಮತ್ತು ಡೇಟಾವನ್ನು ಒಳಗೊಂಡಿದೆ; ಯಾವುದೇ http ಹೆಡರ್ ಇಲ್ಲ, ಆದ್ದರಿಂದ ನಾನು ವೆಬ್ ಸಾಕೆಟ್ ಅನ್ನು ಬಳಸಲಿಲ್ಲ (ನಾನು ಬ್ರೌಸರ್‌ಗಳೊಂದಿಗೆ ಸಂವಹನ ಮಾಡುವ ಅಗತ್ಯವಿಲ್ಲ - ನಮ್ಮ ಅಗತ್ಯಗಳಿಗೆ ಸೂಕ್ತವಾದ ಪ್ರೋಟೋಕಾಲ್ ಅನ್ನು ನಾನು ಮಾಡಿದ್ದೇನೆ). ಮತ್ತು ಅವನೊಂದಿಗೆ ಎಲ್ಲವೂ ಚೆನ್ನಾಗಿತ್ತು.
ಬಫರ್ ಟೇಬಲ್ ದುಃಖವಾಗಿದೆ
ಇತ್ತೀಚೆಗೆ ನಾವು ಬಫರ್ ಕೋಷ್ಟಕಗಳ ಮತ್ತೊಂದು ಆಸಕ್ತಿದಾಯಕ ವೈಶಿಷ್ಟ್ಯವನ್ನು ನೋಡಿದ್ದೇವೆ. ಮತ್ತು ಈ ಸಮಸ್ಯೆಯು ಈಗಾಗಲೇ ಇತರರಿಗಿಂತ ಹೆಚ್ಚು ನೋವಿನಿಂದ ಕೂಡಿದೆ. ಈ ಪರಿಸ್ಥಿತಿಯನ್ನು ಊಹಿಸೋಣ: ನೀವು ಈಗಾಗಲೇ ಕ್ಲಿಕ್ಹೌಸ್ ಅನ್ನು ಸಕ್ರಿಯವಾಗಿ ಬಳಸುತ್ತಿರುವಿರಿ, ನೀವು ಡಜನ್ಗಟ್ಟಲೆ ಕ್ಲಿಕ್ಹೌಸ್ ಸರ್ವರ್ಗಳನ್ನು ಹೊಂದಿದ್ದೀರಿ ಮತ್ತು ನೀವು ಓದಲು ಬಹಳ ಸಮಯ ತೆಗೆದುಕೊಳ್ಳುವ ಕೆಲವು ವಿನಂತಿಗಳನ್ನು ಹೊಂದಿದ್ದೀರಿ (60 ಸೆಕೆಂಡುಗಳಿಗಿಂತ ಹೆಚ್ಚು ಎಂದು ಹೇಳೋಣ); ಮತ್ತು ನೀವು ಬಂದು ಈ ಕ್ಷಣದಲ್ಲಿ ಆಲ್ಟರ್ ಮಾಡಿ... ಈ ಮಧ್ಯೆ, "ಆಲ್ಟರ್" ಗಿಂತ ಮೊದಲು ಪ್ರಾರಂಭವಾದ "ಆಯ್ಕೆಗಳು" ಈ ಕೋಷ್ಟಕದಲ್ಲಿ ಸೇರಿಸಲಾಗುವುದಿಲ್ಲ, "ಆಲ್ಟರ್" ಪ್ರಾರಂಭವಾಗುವುದಿಲ್ಲ - ಬಹುಶಃ "ಕ್ಲಿಕ್ಹೌಸ್" ಹೇಗೆ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ ಎಂಬುದರ ಕೆಲವು ವೈಶಿಷ್ಟ್ಯಗಳು ಈ ಸ್ಥಳ. ಬಹುಶಃ ಇದನ್ನು ಸರಿಪಡಿಸಬಹುದೇ? ಅಥವಾ ಅದು ಸಾಧ್ಯವಿಲ್ಲವೇ?
ಸಾಮಾನ್ಯವಾಗಿ, ವಾಸ್ತವದಲ್ಲಿ ಇದು ಅಂತಹ ದೊಡ್ಡ ಸಮಸ್ಯೆ ಅಲ್ಲ ಎಂದು ಸ್ಪಷ್ಟವಾಗುತ್ತದೆ, ಆದರೆ ಬಫರ್ ಕೋಷ್ಟಕಗಳೊಂದಿಗೆ ಇದು ಹೆಚ್ಚು ನೋವಿನಿಂದ ಕೂಡಿದೆ. ಏಕೆಂದರೆ, ನಿಮ್ಮ “ಆಲ್ಟರ್” ಅವಧಿ ಮೀರಿದರೆ (ಮತ್ತು ಅದು ಮತ್ತೊಂದು ಹೋಸ್ಟ್‌ನಲ್ಲಿ ಸಮಯ ಮೀರಬಹುದು - ನಿಮ್ಮದಲ್ಲ, ಆದರೆ ಪ್ರತಿಕೃತಿಯಲ್ಲಿ, ಉದಾಹರಣೆಗೆ), ನಂತರ... ನೀವು ಬಫರ್ ಟೇಬಲ್ ಅನ್ನು ಅಳಿಸಿದ್ದೀರಿ, ನಿಮ್ಮ “ಆಲ್ಟರ್” ( ಅಥವಾ ಕೆಲವು ಹೋಸ್ಟ್) ಸಮಯ ಮೀರಿದೆ. ನಂತರ "ಆಲ್ಟರ್" ದೋಷ ಸಂಭವಿಸಿದೆ) - ಡೇಟಾವನ್ನು ಬರೆಯುವುದನ್ನು ಮುಂದುವರಿಸುವುದನ್ನು ನೀವು ಇನ್ನೂ ಖಚಿತಪಡಿಸಿಕೊಳ್ಳಬೇಕು: ನೀವು ಬಫರ್ ಕೋಷ್ಟಕಗಳನ್ನು ಹಿಂದಕ್ಕೆ ರಚಿಸುತ್ತೀರಿ (ಪೋಷಕ ಕೋಷ್ಟಕದಂತೆಯೇ ಅದೇ ಸ್ಕೀಮ್ ಪ್ರಕಾರ), ನಂತರ "ಆಲ್ಟರ್" ಮೂಲಕ ಹೋಗುತ್ತದೆ, ಎಲ್ಲಾ ನಂತರ ಕೊನೆಗೊಳ್ಳುತ್ತದೆ, ಮತ್ತು ಬಫರ್ ಪೋಷಕರಿಂದ ಸ್ಕೀಮಾದಲ್ಲಿ ಭಿನ್ನವಾಗಿರಲು ಪ್ರಾರಂಭಿಸುತ್ತದೆ. "ಆಲ್ಟರ್" ಏನೆಂಬುದನ್ನು ಅವಲಂಬಿಸಿ, ಇನ್ಸರ್ಟ್ ಇನ್ನು ಮುಂದೆ ಈ ಬಫರ್ ಟೇಬಲ್‌ಗೆ ಹೋಗುವುದಿಲ್ಲ - ಇದು ತುಂಬಾ ದುಃಖಕರವಾಗಿದೆ.
ಅಂತಹ ಚಿಹ್ನೆಯೂ ಇದೆ (ಬಹುಶಃ ಯಾರಾದರೂ ಅದನ್ನು ಗಮನಿಸಿರಬಹುದು) - ಕ್ಲಿಕ್‌ಹೌಸ್‌ನ ಹೊಸ ಆವೃತ್ತಿಗಳಲ್ಲಿ ಇದನ್ನು query_thread_log ಎಂದು ಕರೆಯಲಾಗುತ್ತದೆ. ಪೂರ್ವನಿಯೋಜಿತವಾಗಿ, ಕೆಲವು ಆವೃತ್ತಿಯಲ್ಲಿ ಒಂದು ಇತ್ತು. ಇಲ್ಲಿ ನಾವು ಒಂದೆರಡು ತಿಂಗಳುಗಳಲ್ಲಿ (840 ಗಿಗಾಬೈಟ್) 100 ಮಿಲಿಯನ್ ದಾಖಲೆಗಳನ್ನು ಸಂಗ್ರಹಿಸಿದ್ದೇವೆ. "ಇನ್ಸರ್ಟ್ಗಳು" ಅಲ್ಲಿ ಬರೆಯಲ್ಪಟ್ಟಿರುವುದು ಇದಕ್ಕೆ ಕಾರಣ (ಬಹುಶಃ, ಮೂಲಕ, ಅವುಗಳನ್ನು ಈಗ ಬರೆಯಲಾಗಿಲ್ಲ). ನಾನು ನಿಮಗೆ ಹೇಳಿದಂತೆ, ನಮ್ಮ "ಇನ್ಸರ್ಟ್ಗಳು" ಚಿಕ್ಕದಾಗಿದೆ - ನಾವು ಬಫರ್ ಕೋಷ್ಟಕಗಳಲ್ಲಿ ಬಹಳಷ್ಟು "ಇನ್ಸರ್ಟ್ಗಳನ್ನು" ಹೊಂದಿದ್ದೇವೆ. ಇದನ್ನು ನಿಷ್ಕ್ರಿಯಗೊಳಿಸಲಾಗಿದೆ ಎಂಬುದು ಸ್ಪಷ್ಟವಾಗಿದೆ - ನಮ್ಮ ಸರ್ವರ್‌ನಲ್ಲಿ ನಾನು ನೋಡಿದ್ದನ್ನು ನಾನು ನಿಮಗೆ ಹೇಳುತ್ತಿದ್ದೇನೆ. ಏಕೆ? ಬಫರ್ ಕೋಷ್ಟಕಗಳನ್ನು ಬಳಸುವುದರ ವಿರುದ್ಧ ಇದು ಮತ್ತೊಂದು ವಾದವಾಗಿದೆ! ಸ್ಪಾಟಿ ತುಂಬಾ ದುಃಖವಾಗಿದೆ.
ಈ ಹುಡುಗನ ಹೆಸರು ಸ್ಪಾಟಿ ಎಂದು ಯಾರಿಗೆ ಗೊತ್ತು? ವಿಕೆ ನೌಕರರು ಕೈ ಎತ್ತಿದರು. ಸರಿ.
"ಕಿಟ್ಟನ್‌ಹೌಸ್" ಯೋಜನೆಗಳ ಬಗ್ಗೆ
ಯೋಜನೆಗಳನ್ನು ಸಾಮಾನ್ಯವಾಗಿ ಹಂಚಿಕೊಳ್ಳಲಾಗುವುದಿಲ್ಲ, ಸರಿ? ಇದ್ದಕ್ಕಿದ್ದಂತೆ ನೀವು ಅವುಗಳನ್ನು ಪೂರೈಸುವುದಿಲ್ಲ ಮತ್ತು ಇತರ ಜನರ ದೃಷ್ಟಿಯಲ್ಲಿ ತುಂಬಾ ಚೆನ್ನಾಗಿ ಕಾಣುವುದಿಲ್ಲ. ಆದರೆ ನಾನು ಅಪಾಯವನ್ನು ತೆಗೆದುಕೊಳ್ಳುತ್ತೇನೆ! ನಾವು ಈ ಕೆಳಗಿನವುಗಳನ್ನು ಮಾಡಲು ಬಯಸುತ್ತೇವೆ: ಬಫರ್ ಕೋಷ್ಟಕಗಳು, ಇದು ನನಗೆ ತೋರುತ್ತದೆ, ಇನ್ನೂ ಊರುಗೋಲು ಮತ್ತು ನಾವು ಅಳವಡಿಕೆಯನ್ನು ಬಫರ್ ಮಾಡಬೇಕಾಗಿದೆ. ಆದರೆ ನಾವು ಇನ್ನೂ ಅದನ್ನು ಡಿಸ್ಕ್ನಲ್ಲಿ ಬಫರ್ ಮಾಡಲು ಬಯಸುವುದಿಲ್ಲ, ಆದ್ದರಿಂದ ನಾವು ಮೆಮೊರಿಯಲ್ಲಿ ಅಳವಡಿಕೆಯನ್ನು ಬಫರ್ ಮಾಡುತ್ತೇವೆ.
ಅಂತೆಯೇ, "ಇನ್ಸರ್ಟ್" ಮಾಡಿದಾಗ, ಅದು ಇನ್ನು ಮುಂದೆ ಸಿಂಕ್ರೊನಸ್ ಆಗಿರುವುದಿಲ್ಲ - ಇದು ಈಗಾಗಲೇ ಬಫರ್ ಟೇಬಲ್ ಆಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ, ಪೋಷಕ ಕೋಷ್ಟಕಕ್ಕೆ ಸೇರಿಸುತ್ತದೆ (ಸರಿ, ಒಂದು ದಿನ ನಂತರ) ಮತ್ತು ಪ್ರತ್ಯೇಕ ಚಾನಲ್ ಮೂಲಕ ವರದಿ ಮಾಡುತ್ತದೆ, ಅದು ಹಾದುಹೋಗಿದೆ ಹೊಂದಿಲ್ಲ.
ನಾನು ಸಿಂಕ್ರೊನಸ್ ಇನ್ಸರ್ಟ್ ಅನ್ನು ಏಕೆ ಬಿಡಬಾರದು? ಇದು ಹೆಚ್ಚು ಅನುಕೂಲಕರವಾಗಿದೆ. ಸತ್ಯವೆಂದರೆ ನೀವು 10 ಸಾವಿರ ಹೋಸ್ಟ್‌ಗಳಿಂದ ಸೇರಿಸಿದರೆ, ಎಲ್ಲವೂ ಉತ್ತಮವಾಗಿದೆ - ನೀವು ಪ್ರತಿ ಹೋಸ್ಟ್‌ನಿಂದ ಸ್ವಲ್ಪಮಟ್ಟಿಗೆ ಪಡೆಯುತ್ತೀರಿ, ನೀವು ಸೆಕೆಂಡಿಗೆ ಒಮ್ಮೆ ಸೇರಿಸಿ, ಎಲ್ಲವೂ ಉತ್ತಮವಾಗಿದೆ. ಆದರೆ ಈ ಯೋಜನೆಯು ಕೆಲಸ ಮಾಡಲು ನಾನು ಬಯಸುತ್ತೇನೆ, ಉದಾಹರಣೆಗೆ, ಎರಡು ಯಂತ್ರಗಳಿಂದ, ಇದರಿಂದ ನೀವು ಹೆಚ್ಚಿನ ವೇಗದಲ್ಲಿ ಡೌನ್‌ಲೋಡ್ ಮಾಡಬಹುದು - ಬಹುಶಃ ಕ್ಲಿಕ್‌ಹೌಸ್‌ನಿಂದ ಗರಿಷ್ಠವನ್ನು ಪಡೆಯದಿರಬಹುದು, ಆದರೆ ರಿವರ್ಸ್ ಪ್ರಾಕ್ಸಿ ಮೂಲಕ ಒಂದು ಯಂತ್ರದಿಂದ ಸೆಕೆಂಡಿಗೆ ಕನಿಷ್ಠ 100 ಮೆಗಾಬೈಟ್‌ಗಳನ್ನು ಬರೆಯಿರಿ - ಈ ಯೋಜನೆಯು ದೊಡ್ಡ ಮತ್ತು ಸಣ್ಣ ಎರಡೂ ಪ್ರಮಾಣಗಳಿಗೆ ಅಳೆಯಬೇಕು, ಆದ್ದರಿಂದ ನಾವು ಪ್ರತಿ ಅಳವಡಿಕೆಗೆ ಒಂದು ಸೆಕೆಂಡ್ ಕಾಯಲು ಸಾಧ್ಯವಿಲ್ಲ, ಆದ್ದರಿಂದ ಇದು ಅಸಮಕಾಲಿಕವಾಗಿರಬೇಕು. ಮತ್ತು ಅದೇ ರೀತಿಯಲ್ಲಿ, ಅಳವಡಿಕೆ ಪೂರ್ಣಗೊಂಡ ನಂತರ ಅಸಮಕಾಲಿಕ ದೃಢೀಕರಣಗಳು ಬರಬೇಕು. ಜಾರಿಯಾಗಿದೆಯೋ ಇಲ್ಲವೋ ತಿಳಿಯಲಿದೆ.
ಅತ್ಯಂತ ಮುಖ್ಯವಾದ ವಿಷಯವೆಂದರೆ ಈ ಯೋಜನೆಯಲ್ಲಿ ಅಳವಡಿಕೆ ನಡೆದಿದೆಯೇ ಅಥವಾ ಇಲ್ಲವೇ ಎಂದು ನಮಗೆ ಖಚಿತವಾಗಿ ತಿಳಿದಿದೆ. ಈ ಪರಿಸ್ಥಿತಿಯನ್ನು ಕಲ್ಪಿಸಿಕೊಳ್ಳಿ: ನೀವು ಬಫರ್ ಟೇಬಲ್ ಅನ್ನು ಹೊಂದಿದ್ದೀರಿ, ನೀವು ಅದರಲ್ಲಿ ಏನನ್ನಾದರೂ ಬರೆದಿದ್ದೀರಿ, ಮತ್ತು ನಂತರ, ಟೇಬಲ್ ಓದಲು ಮಾತ್ರ ಮೋಡ್ಗೆ ಹೋಯಿತು ಮತ್ತು ಬಫರ್ ಅನ್ನು ಫ್ಲಶ್ ಮಾಡಲು ಪ್ರಯತ್ನಿಸಿದೆ ಎಂದು ಹೇಳೋಣ. ಡೇಟಾ ಎಲ್ಲಿಗೆ ಹೋಗುತ್ತದೆ? ಅವರು ಬಫರ್ನಲ್ಲಿ ಉಳಿಯುತ್ತಾರೆ. ಆದರೆ ನಾವು ಇದನ್ನು ಖಚಿತವಾಗಿ ಹೇಳಲಾಗುವುದಿಲ್ಲ - ಯಾವುದಾದರೂ ದೋಷವಿದ್ದರೆ, ಅದರ ಕಾರಣದಿಂದಾಗಿ ಡೇಟಾವು ಬಫರ್ನಲ್ಲಿ ಉಳಿಯುವುದಿಲ್ಲ ... (ಅಲೆಕ್ಸಿ ಮಿಲೋವಿಡೋವ್, ಯಾಂಡೆಕ್ಸ್, ಕ್ಲಿಕ್ಹೌಸ್ ಡೆವಲಪರ್ ವಿಳಾಸಗಳು) ಅಥವಾ ಅದು ಉಳಿಯುತ್ತದೆಯೇ? ಯಾವಾಗಲೂ? ಎಲ್ಲವೂ ಚೆನ್ನಾಗಿರುತ್ತದೆ ಎಂದು ಅಲೆಕ್ಸಿ ನಮಗೆ ಮನವರಿಕೆ ಮಾಡುತ್ತಾರೆ. ಅವನನ್ನು ನಂಬದಿರಲು ನಮಗೆ ಯಾವುದೇ ಕಾರಣವಿಲ್ಲ. ಆದರೆ ಒಂದೇ: ನಾವು ಬಫರ್ ಕೋಷ್ಟಕಗಳನ್ನು ಬಳಸದಿದ್ದರೆ, ಅವರೊಂದಿಗೆ ಯಾವುದೇ ಸಮಸ್ಯೆಗಳಿಲ್ಲ. ಎರಡು ಪಟ್ಟು ಹೆಚ್ಚು ಕೋಷ್ಟಕಗಳನ್ನು ರಚಿಸುವುದು ಸಹ ಅನಾನುಕೂಲವಾಗಿದೆ, ಆದರೂ ತಾತ್ವಿಕವಾಗಿ ಯಾವುದೇ ದೊಡ್ಡ ಸಮಸ್ಯೆಗಳಿಲ್ಲ. ಇದು ಯೋಜನೆ.
ಓದುವ ಬಗ್ಗೆ ಮಾತನಾಡೋಣ
ಈಗ ಓದುವ ಬಗ್ಗೆ ಮಾತನಾಡೋಣ. ನಾವು ಇಲ್ಲಿ ನಮ್ಮ ಸ್ವಂತ ಸಾಧನವನ್ನು ಸಹ ಬರೆದಿದ್ದೇವೆ. ನಿಮ್ಮ ಸ್ವಂತ ಉಪಕರಣವನ್ನು ಇಲ್ಲಿ ಏಕೆ ಬರೆಯಬೇಕು ಎಂದು ತೋರುತ್ತದೆ?.. ಮತ್ತು ಟ್ಯಾಬಿಕ್ಸ್ ಅನ್ನು ಯಾರು ಬಳಸಿದರು? ಹೇಗಾದರೂ ಕೆಲವು ಜನರು ತಮ್ಮ ಕೈಗಳನ್ನು ಎತ್ತಿದರು ... ಮತ್ತು ಟ್ಯಾಬಿಕ್ಸ್ನ ಕಾರ್ಯಕ್ಷಮತೆಯಿಂದ ಯಾರು ತೃಪ್ತರಾಗಿದ್ದಾರೆ? ಒಳ್ಳೆಯದು, ನಾವು ಅದರಲ್ಲಿ ಸಂತೋಷವಾಗಿಲ್ಲ ಮತ್ತು ಡೇಟಾವನ್ನು ವೀಕ್ಷಿಸಲು ಇದು ತುಂಬಾ ಅನುಕೂಲಕರವಾಗಿಲ್ಲ. ಇದು ವಿಶ್ಲೇಷಣೆಗೆ ಉತ್ತಮವಾಗಿದೆ, ಆದರೆ ವೀಕ್ಷಣೆಗೆ ಇದು ಸ್ಪಷ್ಟವಾಗಿ ಆಪ್ಟಿಮೈಸ್ ಆಗಿಲ್ಲ. ಹಾಗಾಗಿ ನನ್ನದೇ ಆದ, ನನ್ನದೇ ಇಂಟರ್ಫೇಸ್ ಬರೆದೆ.
ಇದು ತುಂಬಾ ಸರಳವಾಗಿದೆ - ಇದು ಡೇಟಾವನ್ನು ಮಾತ್ರ ಓದಬಹುದು. ಅವನಿಗೆ ಗ್ರಾಫಿಕ್ಸ್ ತೋರಿಸಲು ತಿಳಿದಿಲ್ಲ, ಏನನ್ನೂ ಮಾಡಲು ತಿಳಿದಿಲ್ಲ. ಆದರೆ ಇದು ನಮಗೆ ಬೇಕಾದುದನ್ನು ತೋರಿಸುತ್ತದೆ: ಉದಾಹರಣೆಗೆ, ಕೋಷ್ಟಕದಲ್ಲಿ ಎಷ್ಟು ಸಾಲುಗಳಿವೆ, ಅದು ಎಷ್ಟು ಜಾಗವನ್ನು ತೆಗೆದುಕೊಳ್ಳುತ್ತದೆ (ಅದನ್ನು ಕಾಲಮ್ಗಳಾಗಿ ವಿಭಜಿಸದೆ), ಅಂದರೆ, ನಮಗೆ ಬೇಕಾಗಿರುವುದು ಮೂಲಭೂತ ಇಂಟರ್ಫೇಸ್.
ಮತ್ತು ಇದು ಸೀಕ್ವೆಲ್ ಪ್ರೊಗೆ ಹೋಲುತ್ತದೆ, ಆದರೆ Twitter ನ ಬೂಟ್‌ಸ್ಟ್ರ್ಯಾಪ್ ಮತ್ತು ಎರಡನೇ ಆವೃತ್ತಿಯಲ್ಲಿ ಮಾತ್ರ ತಯಾರಿಸಲಾಗುತ್ತದೆ. ನೀವು ಕೇಳುತ್ತೀರಿ: "ಯೂರಿ, ಎರಡನೇ ಆವೃತ್ತಿಯಲ್ಲಿ ಏಕೆ?" ಯಾವ ವರ್ಷ? 2018? ಸಾಮಾನ್ಯವಾಗಿ, ನಾನು ಇದನ್ನು "ಸ್ನಾಯು" (MySQL) ಗಾಗಿ ಬಹಳ ಹಿಂದೆಯೇ ಮಾಡಿದ್ದೇನೆ ಮತ್ತು ಅಲ್ಲಿನ ಪ್ರಶ್ನೆಗಳಲ್ಲಿ ಒಂದೆರಡು ಸಾಲುಗಳನ್ನು ಬದಲಾಯಿಸಿದ್ದೇನೆ ಮತ್ತು ಅದು "ಕ್ಲಿಕ್ಹೌಸ್" ಗಾಗಿ ಕೆಲಸ ಮಾಡಲು ಪ್ರಾರಂಭಿಸಿದೆ, ಇದಕ್ಕಾಗಿ ವಿಶೇಷ ಧನ್ಯವಾದಗಳು! ಏಕೆಂದರೆ ಪಾರ್ಸರ್ "ಸ್ನಾಯು" ಒಂದಕ್ಕೆ ಹೋಲುತ್ತದೆ, ಮತ್ತು ಪ್ರಶ್ನೆಗಳು ತುಂಬಾ ಹೋಲುತ್ತವೆ - ತುಂಬಾ ಅನುಕೂಲಕರವಾಗಿದೆ, ವಿಶೇಷವಾಗಿ ಮೊದಲಿಗೆ.
ಸರಿ, ಇದು ಟೇಬಲ್‌ಗಳನ್ನು ಫಿಲ್ಟರ್ ಮಾಡಬಹುದು, ಟೇಬಲ್‌ನ ರಚನೆ ಮತ್ತು ವಿಷಯಗಳನ್ನು ತೋರಿಸಬಹುದು, ವಿಂಗಡಿಸಲು, ಕಾಲಮ್‌ಗಳ ಮೂಲಕ ಫಿಲ್ಟರ್ ಮಾಡಲು ನಿಮಗೆ ಅನುಮತಿಸುತ್ತದೆ, ಫಲಿತಾಂಶಕ್ಕೆ ಕಾರಣವಾದ ಪ್ರಶ್ನೆಯನ್ನು ತೋರಿಸುತ್ತದೆ, ಪೀಡಿತ ಸಾಲುಗಳು (ಪರಿಣಾಮವಾಗಿ ಎಷ್ಟು), ಅಂದರೆ, ಡೇಟಾವನ್ನು ವೀಕ್ಷಿಸಲು ಮೂಲಭೂತ ವಿಷಯಗಳು. ಬಹಳ ವೇಗವಾಗಿ.
ಸಂಪಾದಕರೂ ಇದ್ದಾರೆ. ನಾನು ಟ್ಯಾಬಿಕ್ಸ್‌ನಿಂದ ಸಂಪೂರ್ಣ ಸಂಪಾದಕವನ್ನು ಕದಿಯಲು ಪ್ರಾಮಾಣಿಕವಾಗಿ ಪ್ರಯತ್ನಿಸಿದೆ, ಆದರೆ ನನಗೆ ಸಾಧ್ಯವಾಗಲಿಲ್ಲ. ಆದರೆ ಅದು ಹೇಗಾದರೂ ಕೆಲಸ ಮಾಡುತ್ತದೆ. ತಾತ್ವಿಕವಾಗಿ, ಅಷ್ಟೆ.
"ಕ್ಲಿಕ್ಹೌಸ್" ಡೆನ್ಸ್ಗೆ ಸೂಕ್ತವಾಗಿದೆ
ಕ್ಲಿಕ್ಹೌಸ್, ವಿವರಿಸಿದ ಎಲ್ಲಾ ಸಮಸ್ಯೆಗಳ ಹೊರತಾಗಿಯೂ, ಲಾಗ್ಗಳಿಗೆ ಸೂಕ್ತವಾಗಿರುತ್ತದೆ ಎಂದು ನಾನು ನಿಮಗೆ ಹೇಳಲು ಬಯಸುತ್ತೇನೆ. ಬಹು ಮುಖ್ಯವಾಗಿ, ಇದು ನಮ್ಮ ಸಮಸ್ಯೆಯನ್ನು ಪರಿಹರಿಸುತ್ತದೆ - ಇದು ತುಂಬಾ ವೇಗವಾಗಿರುತ್ತದೆ ಮತ್ತು ಕಾಲಮ್‌ಗಳ ಮೂಲಕ ಲಾಗ್‌ಗಳನ್ನು ಫಿಲ್ಟರ್ ಮಾಡಲು ನಿಮಗೆ ಅನುಮತಿಸುತ್ತದೆ. ತಾತ್ವಿಕವಾಗಿ, ಬಫರ್ ಕೋಷ್ಟಕಗಳು ಉತ್ತಮವಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸಲಿಲ್ಲ, ಆದರೆ ಸಾಮಾನ್ಯವಾಗಿ ಯಾರಿಗೂ ಏಕೆ ತಿಳಿದಿಲ್ಲ ... ಬಹುಶಃ ಈಗ ನಿಮಗೆ ಎಲ್ಲಿ ಸಮಸ್ಯೆಗಳಿವೆ ಎಂದು ನಿಮಗೆ ಚೆನ್ನಾಗಿ ತಿಳಿದಿದೆ.
TCP? ಸಾಮಾನ್ಯವಾಗಿ, ವಿಕೆ ಯಲ್ಲಿ ಯುಡಿಪಿ ಬಳಸುವುದು ವಾಡಿಕೆ. ಮತ್ತು ನಾನು TCP ಅನ್ನು ಬಳಸಿದಾಗ ... ಸಹಜವಾಗಿ, ಯಾರೂ ನನಗೆ ಹೇಳಲಿಲ್ಲ: "ಯೂರಿ, ನೀವು ಏನು ಮಾತನಾಡುತ್ತಿದ್ದೀರಿ! ನಿಮಗೆ ಸಾಧ್ಯವಿಲ್ಲ, ನಿಮಗೆ ಯುಡಿಪಿ ಅಗತ್ಯವಿದೆ. ಟಿಸಿಪಿ ಅಷ್ಟು ಭಯಾನಕವಲ್ಲ ಎಂದು ಅದು ಬದಲಾಯಿತು. ಒಂದೇ ವಿಷಯವೆಂದರೆ, ನೀವು ಬರೆಯುವ ಹತ್ತು ಸಾವಿರ ಸಕ್ರಿಯ ಸಂಯುಕ್ತಗಳನ್ನು ಹೊಂದಿದ್ದರೆ, ನೀವು ಅದನ್ನು ಸ್ವಲ್ಪ ಹೆಚ್ಚು ಎಚ್ಚರಿಕೆಯಿಂದ ಸಿದ್ಧಪಡಿಸಬೇಕು; ಆದರೆ ಇದು ಸಾಧ್ಯ, ಮತ್ತು ತುಂಬಾ ಸುಲಭ.
ಎಲ್ಲರೂ ನಮ್ಮ ಸಾರ್ವಜನಿಕ "VK ಬ್ಯಾಕೆಂಡ್" ಗೆ ಚಂದಾದಾರರಾಗಿದ್ದರೆ, ಹೈಲೋಡ್ ಸೈಬೀರಿಯಾದಲ್ಲಿ "ಕಿಟನ್ಹೌಸ್" ಮತ್ತು "ಲೈಟ್‌ಹೌಸ್" ಅನ್ನು ಪೋಸ್ಟ್ ಮಾಡುವುದಾಗಿ ನಾನು ಭರವಸೆ ನೀಡಿದ್ದೇನೆ... ಮತ್ತು ನಿಮಗೆ ತಿಳಿದಿದೆ, ಎಲ್ಲರೂ ಚಂದಾದಾರರಾಗಿಲ್ಲ... ಖಂಡಿತವಾಗಿ, ನೀವು ನಮ್ಮ ಚಂದಾದಾರರಾಗಬೇಕೆಂದು ನಾನು ಒತ್ತಾಯಿಸುವುದಿಲ್ಲ ಸಾರ್ವಜನಿಕ ನಿಮ್ಮಲ್ಲಿ ಇನ್ನೂ ಹಲವಾರು ಮಂದಿ ಇದ್ದಾರೆ, ಯಾರಾದರೂ ಮನನೊಂದಿರಬಹುದು, ಆದರೆ ಇನ್ನೂ, ದಯವಿಟ್ಟು ಚಂದಾದಾರರಾಗಿ (ಮತ್ತು ಇಲ್ಲಿ ನಾನು ಬೆಕ್ಕಿನಂತೆ ಕಣ್ಣುಗಳನ್ನು ಮಾಡಬೇಕು). ಅದು . ತುಂಬ ಧನ್ಯವಾದಗಳು! ಗಿಥಬ್ ನಮ್ಮದು . ಕ್ಲಿಕ್‌ಹೌಸ್‌ನೊಂದಿಗೆ ನಿಮ್ಮ ಕೂದಲು ಮೃದು ಮತ್ತು ರೇಷ್ಮೆಯಾಗಿರುತ್ತದೆ.
ಮುನ್ನಡೆ: - ಸ್ನೇಹಿತರೇ, ಈಗ ಪ್ರಶ್ನೆಗಳಿಗೆ. ನಾವು ಮೆಚ್ಚುಗೆಯ ಪ್ರಮಾಣಪತ್ರ ಮತ್ತು VHS ಕುರಿತು ನಿಮ್ಮ ವರದಿಯನ್ನು ಪ್ರಸ್ತುತಪಡಿಸಿದ ನಂತರ.
ಯೂರಿ ನಸ್ರೆಟ್ಡಿನೋವ್ (ಇನ್ನು ಮುಂದೆ YN ಎಂದು ಉಲ್ಲೇಖಿಸಲಾಗಿದೆ): - VHS ನಲ್ಲಿ ನನ್ನ ವರದಿಯು ಕೊನೆಗೊಂಡರೆ ಅದನ್ನು ಹೇಗೆ ರೆಕಾರ್ಡ್ ಮಾಡಲು ನಿಮಗೆ ಸಾಧ್ಯವಾಯಿತು?
ಮುನ್ನಡೆ: - "ಕ್ಲಿಕ್ಹೌಸ್" ಹೇಗೆ ಕೆಲಸ ಮಾಡುತ್ತದೆ ಅಥವಾ ಇಲ್ಲ ಎಂಬುದನ್ನು ನೀವು ಸಂಪೂರ್ಣವಾಗಿ ನಿರ್ಧರಿಸಲು ಸಾಧ್ಯವಿಲ್ಲ! ಸ್ನೇಹಿತರೇ, ಪ್ರಶ್ನೆಗಳಿಗೆ 5 ನಿಮಿಷಗಳು!
ಪ್ರಶ್ನೆಗಳು
ಪ್ರೇಕ್ಷಕರಿಂದ ಪ್ರಶ್ನೆ (ಇನ್ನು ಮುಂದೆ Q ಎಂದು ಉಲ್ಲೇಖಿಸಲಾಗಿದೆ): - ಶುಭ ಅಪರಾಹ್ನ. ವರದಿಗಾಗಿ ತುಂಬಾ ಧನ್ಯವಾದಗಳು. ನನಗೆ ಎರಡು ಪ್ರಶ್ನೆಗಳಿವೆ. ನಾನು ನಿಷ್ಪ್ರಯೋಜಕವಾದದ್ದನ್ನು ಪ್ರಾರಂಭಿಸುತ್ತೇನೆ: ರೇಖಾಚಿತ್ರಗಳಲ್ಲಿ (3, 4, 7...) "ಕಿಟನ್ಹೌಸ್" ಹೆಸರಿನಲ್ಲಿರುವ ಟಿ ಅಕ್ಷರಗಳ ಸಂಖ್ಯೆ ಬೆಕ್ಕುಗಳ ತೃಪ್ತಿಯ ಮೇಲೆ ಪರಿಣಾಮ ಬೀರುತ್ತದೆಯೇ?
YN: - ಯಾವುದರ ಪ್ರಮಾಣ?
Z: - ಅಕ್ಷರ ಟಿ. ಮೂರು ಟಿ ಗಳು ಇವೆ, ಎಲ್ಲೋ ಮೂರು ಟಿ.
YN: - ನಾನು ಅದನ್ನು ಸರಿಪಡಿಸಲಿಲ್ಲವೇ? ಸರಿ, ಖಂಡಿತ ಅದು ಮಾಡುತ್ತದೆ! ಇವು ವಿಭಿನ್ನ ಉತ್ಪನ್ನಗಳು - ಈ ಸಮಯದಲ್ಲಿ ನಾನು ನಿಮ್ಮನ್ನು ಮೋಸ ಮಾಡುತ್ತಿದ್ದೆ. ಸರಿ, ನಾನು ತಮಾಷೆ ಮಾಡುತ್ತಿದ್ದೇನೆ - ಪರವಾಗಿಲ್ಲ. ಆಹ್, ಇಲ್ಲಿಯೇ! ಇಲ್ಲ, ಅದೇ ವಿಷಯ, ನಾನು ಮುದ್ರಣದೋಷ ಮಾಡಿದ್ದೇನೆ.
Z: - ಧನ್ಯವಾದ. ಎರಡನೆಯ ಪ್ರಶ್ನೆ ಗಂಭೀರವಾಗಿದೆ. ನಾನು ಅರ್ಥಮಾಡಿಕೊಂಡಂತೆ, ಕ್ಲಿಕ್‌ಹೌಸ್‌ನಲ್ಲಿ, ಬಫರ್ ಕೋಷ್ಟಕಗಳು ಪ್ರತ್ಯೇಕವಾಗಿ ಮೆಮೊರಿಯಲ್ಲಿ ವಾಸಿಸುತ್ತವೆ, ಡಿಸ್ಕ್‌ಗೆ ಬಫರ್ ಆಗುವುದಿಲ್ಲ ಮತ್ತು ಅದರ ಪ್ರಕಾರ, ನಿರಂತರವಾಗಿರುವುದಿಲ್ಲ.
YN: - ಹೌದು.
Z: - ಮತ್ತು ಅದೇ ಸಮಯದಲ್ಲಿ, ನಿಮ್ಮ ಕ್ಲೈಂಟ್ ಡಿಸ್ಕ್‌ಗೆ ಬಫರ್ ಆಗುತ್ತದೆ, ಇದು ಇದೇ ಲಾಗ್‌ಗಳ ವಿತರಣೆಯ ಕೆಲವು ಗ್ಯಾರಂಟಿಯನ್ನು ಸೂಚಿಸುತ್ತದೆ. ಆದರೆ ಇದು ಕ್ಲಿಕ್‌ಹೌಸ್‌ನಲ್ಲಿ ಖಾತರಿಪಡಿಸುವುದಿಲ್ಲ. ಗ್ಯಾರಂಟಿಯನ್ನು ಹೇಗೆ ಕೈಗೊಳ್ಳಲಾಗುತ್ತದೆ ಎಂಬುದನ್ನು ವಿವರಿಸಿ, ಏನು ಕಾರಣ?.. ಇಲ್ಲಿ ಈ ಕಾರ್ಯವಿಧಾನವನ್ನು ಹೆಚ್ಚು ವಿವರವಾಗಿ ನೀಡಲಾಗಿದೆ
YN: - ಹೌದು, ಸೈದ್ಧಾಂತಿಕವಾಗಿ ಇಲ್ಲಿ ಯಾವುದೇ ವಿರೋಧಾಭಾಸಗಳಿಲ್ಲ, ಏಕೆಂದರೆ ಕ್ಲಿಕ್ಹೌಸ್ ಬಿದ್ದಾಗ, ನೀವು ಅದನ್ನು ಮಿಲಿಯನ್ ವಿಭಿನ್ನ ರೀತಿಯಲ್ಲಿ ಕಂಡುಹಿಡಿಯಬಹುದು. ಕ್ಲಿಕ್ಹೌಸ್ ಕ್ರ್ಯಾಶ್ ಆಗಿದ್ದರೆ (ಅದು ತಪ್ಪಾಗಿ ಕೊನೆಗೊಂಡರೆ), ನೀವು ಸ್ಥೂಲವಾಗಿ ಹೇಳುವುದಾದರೆ, ನೀವು ಬರೆದಿರುವ ನಿಮ್ಮ ಲಾಗ್‌ನ ಸ್ವಲ್ಪ ರಿವೈಂಡ್ ಮಾಡಬಹುದು ಮತ್ತು ಎಲ್ಲವೂ ಸರಿಯಾಗಿದ್ದ ಕ್ಷಣದಿಂದ ಪ್ರಾರಂಭಿಸಬಹುದು. ನೀವು ಒಂದು ನಿಮಿಷವನ್ನು ರಿವೈಂಡ್ ಮಾಡಿ ಎಂದು ಹೇಳೋಣ, ಅಂದರೆ, ನೀವು ಒಂದು ನಿಮಿಷದಲ್ಲಿ ಎಲ್ಲವನ್ನೂ ಫ್ಲಶ್ ಮಾಡಿದ್ದೀರಿ ಎಂದು ಪರಿಗಣಿಸಲಾಗುತ್ತದೆ.
Z: - ಅಂದರೆ, "ಕಿಟನ್ಹೌಸ್" ಕಿಟಕಿಯನ್ನು ಹೆಚ್ಚು ಕಾಲ ಹಿಡಿದಿಟ್ಟುಕೊಳ್ಳುತ್ತದೆ ಮತ್ತು ಬೀಳುವ ಸಂದರ್ಭದಲ್ಲಿ, ಅದನ್ನು ಗುರುತಿಸಬಹುದೇ ಮತ್ತು ರಿವೈಂಡ್ ಮಾಡಬಹುದೇ?
YN: - ಆದರೆ ಇದು ಸಿದ್ಧಾಂತದಲ್ಲಿದೆ. ಪ್ರಾಯೋಗಿಕವಾಗಿ, ನಾವು ಇದನ್ನು ಮಾಡುವುದಿಲ್ಲ, ಮತ್ತು ವಿಶ್ವಾಸಾರ್ಹ ವಿತರಣೆಯು ಶೂನ್ಯದಿಂದ ಅನಂತ ಸಮಯದವರೆಗೆ ಇರುತ್ತದೆ. ಆದರೆ ಸರಾಸರಿ ಒಂದು. ಕೆಲವು ಕಾರಣಗಳಿಗಾಗಿ ಕ್ಲಿಕ್ಹೌಸ್ ಕ್ರ್ಯಾಶ್ ಆಗಿದ್ದರೆ ಅಥವಾ ಸರ್ವರ್‌ಗಳು “ರೀಬೂಟ್” ಆಗಿದ್ದರೆ, ನಾವು ಸ್ವಲ್ಪ ಕಳೆದುಕೊಳ್ಳುತ್ತೇವೆ ಎಂದು ನಾವು ತೃಪ್ತರಾಗಿದ್ದೇವೆ. ಎಲ್ಲಾ ಇತರ ಸಂದರ್ಭಗಳಲ್ಲಿ, ಏನೂ ಆಗುವುದಿಲ್ಲ.
Z: - ನಮಸ್ಕಾರ. ವರದಿಯ ಪ್ರಾರಂಭದಿಂದಲೂ ನೀವು ನಿಜವಾಗಿಯೂ UDP ಅನ್ನು ಬಳಸುತ್ತಿದ್ದೀರಿ ಎಂದು ಮೊದಲಿನಿಂದಲೂ ನನಗೆ ತೋರುತ್ತದೆ. ನಿಮಗೆ http ಇದೆ, ಅದೆಲ್ಲವೂ ಇದೆ... ಮತ್ತು ನೀವು ವಿವರಿಸಿರುವ ಹೆಚ್ಚಿನ ಸಮಸ್ಯೆಗಳು, ನಾನು ಅರ್ಥಮಾಡಿಕೊಂಡಂತೆ, ಈ ನಿರ್ದಿಷ್ಟ ಪರಿಹಾರದಿಂದ ಉಂಟಾಗಿದೆ...
YN: - ನಾವು TCP ಅನ್ನು ಏನು ಬಳಸುತ್ತೇವೆ?
Z: - ಮೂಲಭೂತವಾಗಿ ಹೌದು.
YN: - ಇಲ್ಲ.
Z: - Fasthttp ನೊಂದಿಗೆ ನೀವು ಸಮಸ್ಯೆಗಳನ್ನು ಹೊಂದಿದ್ದೀರಿ, ಸಂಪರ್ಕದೊಂದಿಗೆ ನೀವು ಸಮಸ್ಯೆಗಳನ್ನು ಹೊಂದಿದ್ದೀರಿ. ನೀವು ಕೇವಲ UDP ಅನ್ನು ಬಳಸಿದ್ದರೆ ನೀವು ಸ್ವಲ್ಪ ಸಮಯವನ್ನು ಉಳಿಸುತ್ತೀರಿ. ಸರಿ, ದೀರ್ಘ ಸಂದೇಶಗಳು ಅಥವಾ ಇನ್ನೇನಾದರೂ ಸಮಸ್ಯೆಗಳಿರಬಹುದು...
YN: - ಯಾವುದರೊಂದಿಗೆ?
Z: – ದೀರ್ಘ ಸಂದೇಶಗಳೊಂದಿಗೆ, ಇದು MTU ಗೆ ಹೊಂದಿಕೆಯಾಗದ ಕಾರಣ, ಬೇರೆ ಯಾವುದೋ... ಸರಿ, ಅವರದೇ ಆದ ಸಮಸ್ಯೆಗಳಿರಬಹುದು. ಪ್ರಶ್ನೆ: ಯುಡಿಪಿ ಏಕೆ ಅಲ್ಲ?
YN: - TCP/IP ಅನ್ನು ಅಭಿವೃದ್ಧಿಪಡಿಸಿದ ಲೇಖಕರು ನನಗಿಂತ ಹೆಚ್ಚು ಬುದ್ಧಿವಂತರು ಮತ್ತು ಪ್ಯಾಕೆಟ್‌ಗಳನ್ನು ಹೇಗೆ ಧಾರಾವಾಹಿ ಮಾಡಬೇಕೆಂದು ನನಗಿಂತ ಚೆನ್ನಾಗಿ ತಿಳಿದಿದ್ದಾರೆ (ಆದ್ದರಿಂದ ಅವರು ಹೋಗುತ್ತಾರೆ), ಅದೇ ಸಮಯದಲ್ಲಿ ಕಳುಹಿಸುವ ವಿಂಡೋವನ್ನು ಹೊಂದಿಸಿ, ನೆಟ್‌ವರ್ಕ್ ಅನ್ನು ಓವರ್‌ಲೋಡ್ ಮಾಡಬೇಡಿ, ಯಾವುದರ ಬಗ್ಗೆ ಪ್ರತಿಕ್ರಿಯೆ ನೀಡಿ ಓದಲಾಗಿಲ್ಲ, ಇನ್ನೊಂದು ಬದಿಯಲ್ಲಿ ಲೆಕ್ಕವಿಲ್ಲ ... ಈ ಎಲ್ಲಾ ಸಮಸ್ಯೆಗಳು, ನನ್ನ ಅಭಿಪ್ರಾಯದಲ್ಲಿ, UDP ಯಲ್ಲಿ ಅಸ್ತಿತ್ವದಲ್ಲಿವೆ, ಅದೇ ವಿಷಯವನ್ನು ಸ್ವತಃ ಕಾರ್ಯಗತಗೊಳಿಸಲು ಮತ್ತು ಹೆಚ್ಚಾಗಿ ನಾನು ಈಗಾಗಲೇ ಬರೆದಿದ್ದಕ್ಕಿಂತ ಹೆಚ್ಚಿನ ಕೋಡ್ ಅನ್ನು ನಾನು ಬರೆಯಬೇಕಾಗಿದೆ. ಕಳಪೆಯಾಗಿ. ಸಿ ಯಲ್ಲಿ ಬರೆಯುವುದು ನನಗೆ ಇಷ್ಟವಿಲ್ಲ, ಅಲ್ಲಿ ಬಿಡಿ...
Z: - ಕೇವಲ ಅನುಕೂಲಕರ! ಸರಿ ಕಳುಹಿಸಲಾಗಿದೆ ಮತ್ತು ಯಾವುದಕ್ಕೂ ಕಾಯಬೇಡಿ - ಇದು ಸಂಪೂರ್ಣವಾಗಿ ಅಸಮಕಾಲಿಕವಾಗಿದೆ. ಎಲ್ಲವೂ ಸರಿಯಾಗಿದೆ ಎಂದು ನೋಟಿಫಿಕೇಶನ್ ಹಿಂತಿರುಗಿತು - ಅಂದರೆ ಅದು ಬಂದಿತು; ಅದು ಬರದಿದ್ದರೆ, ಅದು ಕೆಟ್ಟದು ಎಂದು ಅರ್ಥ.
YN: - ನನಗೆ ಎರಡೂ ಬೇಕು - ವಿತರಣೆಯ ಗ್ಯಾರಂಟಿ ಮತ್ತು ವಿತರಣೆಯ ಖಾತರಿಯಿಲ್ಲದೆ ಎರಡನ್ನೂ ಕಳುಹಿಸಲು ನನಗೆ ಸಾಧ್ಯವಾಗುತ್ತದೆ. ಇವು ಎರಡು ವಿಭಿನ್ನ ಸನ್ನಿವೇಶಗಳಾಗಿವೆ. ನಾನು ಕೆಲವು ಲಾಗ್‌ಗಳನ್ನು ಕಳೆದುಕೊಳ್ಳಬಾರದು ಅಥವಾ ಕಾರಣದೊಳಗೆ ಅವುಗಳನ್ನು ಕಳೆದುಕೊಳ್ಳಬಾರದು.
Z: - ನಾನು ಸಮಯವನ್ನು ವ್ಯರ್ಥ ಮಾಡುವುದಿಲ್ಲ. ಈ ಬಗ್ಗೆ ಹೆಚ್ಚು ಚರ್ಚೆಯಾಗಬೇಕಿದೆ. ಧನ್ಯವಾದ.
ಮುನ್ನಡೆ: - ಯಾರಿಗೆ ಪ್ರಶ್ನೆಗಳಿವೆ - ಆಕಾಶಕ್ಕೆ ಕೈಗಳು!
Z: - ಹಲೋ, ನಾನು ಸಶಾ. ವರದಿಯ ಮಧ್ಯದಲ್ಲಿ ಎಲ್ಲೋ ಒಂದು ಭಾವನೆ ಕಾಣಿಸಿಕೊಂಡಿತು, ಟಿಸಿಪಿ ಜೊತೆಗೆ, ಸಿದ್ಧ ಪರಿಹಾರವನ್ನು ಬಳಸಲು ಸಾಧ್ಯವಿದೆ - ಕೆಲವು ರೀತಿಯ ಕಾಫ್ಕಾ.
YN: - ಸರಿ ... ನಾನು ಮಧ್ಯಂತರ ಸರ್ವರ್ಗಳನ್ನು ಬಳಸಲು ಬಯಸುವುದಿಲ್ಲ ಎಂದು ನಾನು ನಿಮಗೆ ಹೇಳಿದೆ, ಏಕೆಂದರೆ ... ಕಾಫ್ಕಾದಲ್ಲಿ, ನಾವು ಹತ್ತು ಸಾವಿರ ಹೋಸ್ಟ್ಗಳನ್ನು ಹೊಂದಿದ್ದೇವೆ ಎಂದು ತಿರುಗುತ್ತದೆ; ವಾಸ್ತವವಾಗಿ, ನಾವು ಹೆಚ್ಚು ಹೊಂದಿದ್ದೇವೆ - ಹತ್ತಾರು ಆತಿಥೇಯರು. ಯಾವುದೇ ಪ್ರಾಕ್ಸಿಗಳಿಲ್ಲದೆ ಕಾಫ್ಕಾದೊಂದಿಗೆ ಮಾಡುವುದು ನೋವಿನಿಂದ ಕೂಡಿದೆ. ಜೊತೆಗೆ, ಮುಖ್ಯವಾಗಿ, ಇದು ಇನ್ನೂ "ಸುಪ್ತತೆ" ನೀಡುತ್ತದೆ, ನೀವು ಹೊಂದಿರಬೇಕಾದ ಹೆಚ್ಚುವರಿ ಹೋಸ್ಟ್ಗಳನ್ನು ನೀಡುತ್ತದೆ. ಆದರೆ ನಾನು ಅವುಗಳನ್ನು ಹೊಂದಲು ಬಯಸುವುದಿಲ್ಲ - ನನಗೆ ಬೇಕು ...
Z: "ಆದರೆ ಕೊನೆಯಲ್ಲಿ ಅದು ಹೇಗಾದರೂ ತಿರುಗಿತು."
YN: - ಇಲ್ಲ, ಯಾವುದೇ ಹೋಸ್ಟ್‌ಗಳಿಲ್ಲ! ಇದೆಲ್ಲವೂ ಕ್ಲಿಕ್ಹೌಸ್ ಹೋಸ್ಟ್‌ಗಳಲ್ಲಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ.
Z: - ಸರಿ, ಮತ್ತು "ಕಿಟನ್ಹೌಸ್", ಇದು ಹಿಮ್ಮುಖವಾಗಿದೆ - ಅವನು ಎಲ್ಲಿ ವಾಸಿಸುತ್ತಾನೆ?
YN: - ಕ್ಲಿಕ್ಹೌಸ್ ಹೋಸ್ಟ್‌ನಲ್ಲಿ, ಅದು ಡಿಸ್ಕ್‌ಗೆ ಏನನ್ನೂ ಬರೆಯುವುದಿಲ್ಲ.
Z: - ನಾವು ಊಹಿಸೋಣ.
ಮುನ್ನಡೆ: - ನೀವು ತೃಪ್ತರಾಗಿದ್ದೀರಾ? ನಾವು ನಿಮಗೆ ಸಂಬಳ ನೀಡಬಹುದೇ?
Z: - ಹೌದು, ನೀನು ಮಾಡಬಹುದು. ವಾಸ್ತವವಾಗಿ, ಅದೇ ವಿಷಯವನ್ನು ಪಡೆಯುವ ಸಲುವಾಗಿ ಸಾಕಷ್ಟು ಊರುಗೋಲುಗಳಿವೆ, ಮತ್ತು ಈಗ - TCP ವಿಷಯದ ಹಿಂದಿನ ಉತ್ತರವು ನನ್ನ ಅಭಿಪ್ರಾಯದಲ್ಲಿ, ಈ ಪರಿಸ್ಥಿತಿಯನ್ನು ವಿರೋಧಿಸುತ್ತದೆ. ಕಡಿಮೆ ಸಮಯದಲ್ಲಿ ನನ್ನ ಮೊಣಕಾಲುಗಳ ಮೇಲೆ ಎಲ್ಲವನ್ನೂ ಮಾಡಬಹುದಿತ್ತು ಎಂದು ಅನಿಸುತ್ತದೆ.
YN: - ಮತ್ತು ನಾನು ಕಾಫ್ಕಾವನ್ನು ಏಕೆ ಬಳಸಲು ಬಯಸಲಿಲ್ಲ, ಏಕೆಂದರೆ ಕ್ಲಿಕ್ಹೌಸ್ ಟೆಲಿಗ್ರಾಮ್ ಚಾಟ್‌ನಲ್ಲಿ ಸಾಕಷ್ಟು ದೂರುಗಳಿವೆ, ಉದಾಹರಣೆಗೆ, ಕಾಫ್ಕಾದಿಂದ ಸಂದೇಶಗಳು ಕಳೆದುಹೋಗಿವೆ. ಕಾಫ್ಕಾದಿಂದಲೇ ಅಲ್ಲ, ಆದರೆ ಕಾಫ್ಕಾ ಮತ್ತು ಕ್ಲಿಕ್‌ಹೌಸ್‌ನ ಏಕೀಕರಣದಲ್ಲಿ; ಅಥವಾ ಯಾವುದೋ ಅಲ್ಲಿ ಸಂಪರ್ಕ ಹೊಂದಿಲ್ಲ. ಸ್ಥೂಲವಾಗಿ ಹೇಳುವುದಾದರೆ, ಕಾಫ್ಕಾಗೆ ಕ್ಲೈಂಟ್ ಅನ್ನು ಬರೆಯುವುದು ಅವಶ್ಯಕ. ಸರಳ ಅಥವಾ ಹೆಚ್ಚು ವಿಶ್ವಾಸಾರ್ಹ ಪರಿಹಾರವಿದೆ ಎಂದು ನಾನು ಭಾವಿಸುವುದಿಲ್ಲ.
Z: - ಹೇಳಿ, ನೀವು ಯಾವುದೇ ಸರತಿ ಸಾಲುಗಳನ್ನು ಅಥವಾ ಕೆಲವು ರೀತಿಯ ಸಾಮಾನ್ಯ ಬಸ್ ಅನ್ನು ಏಕೆ ಪ್ರಯತ್ನಿಸಲಿಲ್ಲ? ಅಸಮಕಾಲಿಕತೆಯೊಂದಿಗೆ ನೀವು ಲಾಗ್‌ಗಳನ್ನು ಸರದಿಯ ಮೂಲಕ ಕಳುಹಿಸಬಹುದು ಮತ್ತು ಸರದಿಯ ಮೂಲಕ ಅಸಮಕಾಲಿಕವಾಗಿ ಪ್ರತಿಕ್ರಿಯೆಯನ್ನು ಪಡೆಯಬಹುದು ಎಂದು ನೀವು ಹೇಳುತ್ತಿದ್ದೀರಾ?
YN: - ದಯವಿಟ್ಟು ಯಾವ ಸಾಲುಗಳನ್ನು ಬಳಸಬಹುದೆಂದು ಸೂಚಿಸಿ?
Z: - ಯಾವುದೇ, ಅವರು ಕ್ರಮದಲ್ಲಿದ್ದಾರೆ ಎಂಬ ಖಾತರಿಯಿಲ್ಲದೆ. ಕೆಲವು ರೀತಿಯ ರೆಡಿಸ್, RMQ...
YN: - ಕ್ಲಿಕ್ಹೌಸ್ ಅನ್ನು ಹೊರತೆಗೆಯುವ ಒಂದು ಹೋಸ್ಟ್‌ನಲ್ಲಿ (ಹಲವಾರು ಸರ್ವರ್‌ಗಳ ಅರ್ಥದಲ್ಲಿ) ಸಹ ರೆಡಿಸ್ ಅಂತಹ ಅಳವಡಿಕೆಯ ಪರಿಮಾಣವನ್ನು ಎಳೆಯಲು ಸಾಧ್ಯವಾಗುವುದಿಲ್ಲ ಎಂಬ ಭಾವನೆ ನನ್ನಲ್ಲಿದೆ. ನಾನು ಇದನ್ನು ಯಾವುದೇ ಪುರಾವೆಗಳೊಂದಿಗೆ ಬ್ಯಾಕಪ್ ಮಾಡಲು ಸಾಧ್ಯವಿಲ್ಲ (ನಾನು ಅದನ್ನು ಬೆಂಚ್‌ಮಾರ್ಕ್ ಮಾಡಿಲ್ಲ), ಆದರೆ ರೆಡಿಸ್ ಇಲ್ಲಿ ಉತ್ತಮ ಪರಿಹಾರವಲ್ಲ ಎಂದು ನನಗೆ ತೋರುತ್ತದೆ. ತಾತ್ವಿಕವಾಗಿ, ಈ ವ್ಯವಸ್ಥೆಯನ್ನು ಸುಧಾರಿತ ಸಂದೇಶ ಕ್ಯೂ ಎಂದು ಪರಿಗಣಿಸಬಹುದು, ಆದರೆ ಇದು "ಕ್ಲಿಕ್ಹೌಸ್" ಗೆ ಮಾತ್ರ ಅನುಗುಣವಾಗಿರುತ್ತದೆ.
ಮುನ್ನಡೆ: - ಯೂರಿ, ತುಂಬಾ ಧನ್ಯವಾದಗಳು. ಪ್ರಶ್ನೆಗಳು ಮತ್ತು ಉತ್ತರಗಳನ್ನು ಇಲ್ಲಿಗೆ ಕೊನೆಗೊಳಿಸಲು ನಾನು ಪ್ರಸ್ತಾಪಿಸುತ್ತೇನೆ ಮತ್ತು ಪ್ರಶ್ನೆಯನ್ನು ಕೇಳಿದವರಲ್ಲಿ ಯಾರಿಗೆ ನಾವು ಪುಸ್ತಕವನ್ನು ನೀಡುತ್ತೇವೆ ಎಂದು ಹೇಳುತ್ತೇನೆ.
YN: - ಪ್ರಶ್ನೆಯನ್ನು ಕೇಳಿದ ಮೊದಲ ವ್ಯಕ್ತಿಗೆ ನಾನು ಪುಸ್ತಕವನ್ನು ನೀಡಲು ಬಯಸುತ್ತೇನೆ.
ಮುನ್ನಡೆ: - ಅದ್ಭುತ! ಗ್ರೇಟ್! ಅದ್ಭುತ! ತುಂಬಾ ಧನ್ಯವಾದಗಳು!
ಕೆಲವು ಜಾಹೀರಾತುಗಳು 🙂
ನಮ್ಮೊಂದಿಗೆ ಇರುವುದಕ್ಕೆ ಧನ್ಯವಾದಗಳು. ನೀವು ನಮ್ಮ ಲೇಖನಗಳನ್ನು ಇಷ್ಟಪಡುತ್ತೀರಾ? ಹೆಚ್ಚು ಆಸಕ್ತಿದಾಯಕ ವಿಷಯವನ್ನು ನೋಡಲು ಬಯಸುವಿರಾ? ಆರ್ಡರ್ ಮಾಡುವ ಮೂಲಕ ಅಥವಾ ಸ್ನೇಹಿತರಿಗೆ ಶಿಫಾರಸು ಮಾಡುವ ಮೂಲಕ ನಮ್ಮನ್ನು ಬೆಂಬಲಿಸಿ, , ಪ್ರವೇಶ ಮಟ್ಟದ ಸರ್ವರ್‌ಗಳ ಅನನ್ಯ ಅನಲಾಗ್, ಇದನ್ನು ನಿಮಗಾಗಿ ನಾವು ಕಂಡುಹಿಡಿದಿದ್ದೇವೆ: (RAID1 ಮತ್ತು RAID10, 24 ಕೋರ್‌ಗಳವರೆಗೆ ಮತ್ತು 40GB DDR4 ವರೆಗೆ ಲಭ್ಯವಿದೆ).
ಆಮ್‌ಸ್ಟರ್‌ಡ್ಯಾಮ್‌ನಲ್ಲಿರುವ Equinix Tier IV ಡೇಟಾ ಸೆಂಟರ್‌ನಲ್ಲಿ Dell R730xd 2x ಅಗ್ಗವಾಗಿದೆಯೇ? ಇಲ್ಲಿ ಮಾತ್ರ ನೆದರ್ಲ್ಯಾಂಡ್ಸ್ನಲ್ಲಿ! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - $99 ರಿಂದ! ಬಗ್ಗೆ ಓದು
ಮೂಲ: www.habr.com