TL;DR: ನಾಲ್ಕು ವರ್ಷಗಳ ಹಿಂದೆ ನಾನು ಹೊಸ ಸರ್ವರ್ ಮಾನಿಟರಿಂಗ್ ಟೂಲ್‌ನ ಕಲ್ಪನೆಯೊಂದಿಗೆ Google ಅನ್ನು ತೊರೆದಿದ್ದೇನೆ. ಸಾಮಾನ್ಯವಾಗಿ ಪ್ರತ್ಯೇಕವಾದ ಕಾರ್ಯಗಳನ್ನು ಒಂದು ಸೇವೆಯಾಗಿ ಸಂಯೋಜಿಸುವುದು ಇದರ ಉದ್ದೇಶವಾಗಿತ್ತು ಸಂಗ್ರಹಣೆ ಮತ್ತು ಲಾಗ್ ವಿಶ್ಲೇಷಣೆ, ಮೆಟ್ರಿಕ್ಸ್ ಸಂಗ್ರಹ, ಎಚ್ಚರಿಕೆಗಳು ಮತ್ತು ಡ್ಯಾಶ್‌ಬೋರ್ಡ್‌ಗಳು. ಸೇವೆಯು ನಿಜವಾಗಿಯೂ ಇರಬೇಕು ಎಂಬುದು ಒಂದು ತತ್ವವಾಗಿದೆ ವೇಗವಾಗಿ, ಸುಲಭವಾದ, ಸಂವಾದಾತ್ಮಕ, ಆನಂದದಾಯಕ ಅನುಭವದೊಂದಿಗೆ devops ಅನ್ನು ಒದಗಿಸುವುದು. ಬಜೆಟ್‌ನೊಳಗೆ ಇರುವಾಗ ಸೆಕೆಂಡಿನ ಭಿನ್ನರಾಶಿಗಳಲ್ಲಿ ಮಲ್ಟಿ-ಗಿಗಾಬೈಟ್ ಡೇಟಾ ಸೆಟ್‌ಗಳನ್ನು ಪ್ರಕ್ರಿಯೆಗೊಳಿಸುವ ಅಗತ್ಯವಿದೆ. ಅಸ್ತಿತ್ವದಲ್ಲಿರುವ ಲಾಗ್ ಮ್ಯಾನೇಜ್‌ಮೆಂಟ್ ಪರಿಕರಗಳು ಸಾಮಾನ್ಯವಾಗಿ ನಿಧಾನವಾಗಿರುತ್ತವೆ ಮತ್ತು ಗೊಂದಲಮಯವಾಗಿರುತ್ತವೆ, ಆದ್ದರಿಂದ ನಾವು ಉತ್ತಮ ಸವಾಲನ್ನು ಎದುರಿಸುತ್ತಿದ್ದೇವೆ: ಬಳಕೆದಾರರಿಗೆ ಹೊಸ ಅನುಭವವನ್ನು ನೀಡಲು ಪರಿಕರವನ್ನು ಅಚ್ಚುಕಟ್ಟಾಗಿ ವಿನ್ಯಾಸಗೊಳಿಸುವುದು.

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

ಹಳೆಯ ಶಾಲೆಯ ಶಕ್ತಿ

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

ಆಧುನಿಕ ಸಂಸ್ಕಾರಕಗಳು ಸರಳವಾದ, ನೇರವಾದ ಕಾರ್ಯಾಚರಣೆಗಳಲ್ಲಿ ಅತ್ಯಂತ ವೇಗವಾಗಿವೆ ಎಂಬುದು ಪ್ರಮುಖ ಒಳನೋಟವಾಗಿತ್ತು. I/O ವೇಗ ಮತ್ತು ನೆಟ್‌ವರ್ಕ್ ಕಾರ್ಯಾಚರಣೆಗಳನ್ನು ಅವಲಂಬಿಸಿರುವ ಸಂಕೀರ್ಣ, ಬಹು-ಪದರದ ವ್ಯವಸ್ಥೆಗಳಲ್ಲಿ ಇದು ತಪ್ಪಿಸಿಕೊಳ್ಳುವುದು ಸುಲಭ, ಮತ್ತು ಅಂತಹ ವ್ಯವಸ್ಥೆಗಳು ಇಂದು ತುಂಬಾ ಸಾಮಾನ್ಯವಾಗಿದೆ. ಆದ್ದರಿಂದ ನಾವು ಪದರಗಳು ಮತ್ತು ಹೆಚ್ಚುವರಿ ಶಿಲಾಖಂಡರಾಶಿಗಳನ್ನು ಕಡಿಮೆ ಮಾಡುವ ವಿನ್ಯಾಸವನ್ನು ಅಭಿವೃದ್ಧಿಪಡಿಸಿದ್ದೇವೆ. ಸಮಾನಾಂತರವಾಗಿ ಬಹು ಪ್ರೊಸೆಸರ್‌ಗಳು ಮತ್ತು ಸರ್ವರ್‌ಗಳೊಂದಿಗೆ, ಹುಡುಕಾಟ ವೇಗವು ಸೆಕೆಂಡಿಗೆ 1 TB ತಲುಪುತ್ತದೆ.

ಈ ಲೇಖನದಿಂದ ಪ್ರಮುಖ ಟೇಕ್ಅವೇಗಳು:

• ಬ್ರೂಟ್-ಫೋರ್ಸ್ ಹುಡುಕಾಟವು ನೈಜ-ಪ್ರಪಂಚದ, ದೊಡ್ಡ-ಪ್ರಮಾಣದ ಸಮಸ್ಯೆಗಳನ್ನು ಪರಿಹರಿಸಲು ಕಾರ್ಯಸಾಧ್ಯವಾದ ವಿಧಾನವಾಗಿದೆ.
• ಬ್ರೂಟ್ ಫೋರ್ಸ್ ಒಂದು ವಿನ್ಯಾಸ ತಂತ್ರವಾಗಿದೆ, ಕೆಲಸ-ಮುಕ್ತ ಪರಿಹಾರವಲ್ಲ. ಯಾವುದೇ ತಂತ್ರದಂತೆ, ಇದು ಇತರರಿಗಿಂತ ಕೆಲವು ಸಮಸ್ಯೆಗಳಿಗೆ ಸೂಕ್ತವಾಗಿರುತ್ತದೆ ಮತ್ತು ಕಳಪೆಯಾಗಿ ಅಥವಾ ಉತ್ತಮವಾಗಿ ಕಾರ್ಯಗತಗೊಳಿಸಬಹುದು.
• ಬ್ರೂಟ್ ಫೋರ್ಸ್ ಸಾಧಿಸಲು ವಿಶೇಷವಾಗಿ ಒಳ್ಳೆಯದು ಅಚಲವಾದ ಉತ್ಪಾದಕತೆ.
• ವಿವೇಚನಾರಹಿತ ಶಕ್ತಿಯ ಪರಿಣಾಮಕಾರಿ ಬಳಕೆಗೆ ಕೋಡ್ ಅನ್ನು ಉತ್ತಮಗೊಳಿಸುವ ಮತ್ತು ಸರಿಯಾದ ಸಮಯದಲ್ಲಿ ಸಾಕಷ್ಟು ಸಂಪನ್ಮೂಲಗಳನ್ನು ಅನ್ವಯಿಸುವ ಅಗತ್ಯವಿದೆ. ನಿಮ್ಮ ಸರ್ವರ್‌ಗಳು ಹೆಚ್ಚಿನ ಬಳಕೆದಾರರಲ್ಲದ ಹೊರೆಯಲ್ಲಿದ್ದರೆ ಮತ್ತು ಬಳಕೆದಾರ ಕಾರ್ಯಾಚರಣೆಗಳು ಆದ್ಯತೆಯಾಗಿ ಉಳಿದಿದ್ದರೆ ಇದು ಸೂಕ್ತವಾಗಿದೆ.
• ಕಾರ್ಯಕ್ಷಮತೆಯು ಸಂಪೂರ್ಣ ವ್ಯವಸ್ಥೆಯ ವಿನ್ಯಾಸವನ್ನು ಅವಲಂಬಿಸಿರುತ್ತದೆ, ಕೇವಲ ಒಳಗಿನ ಲೂಪ್ ಅಲ್ಗಾರಿದಮ್ ಅಲ್ಲ.

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

ಬ್ರೂಟ್ ಫೋರ್ಸ್ ವಿಧಾನ

ಸಾಂಪ್ರದಾಯಿಕವಾಗಿ, ದೊಡ್ಡ ಡೇಟಾ ಸೆಟ್ ಅನ್ನು ಕೀವರ್ಡ್ ಇಂಡೆಕ್ಸ್ ಬಳಸಿ ಹುಡುಕಲಾಗುತ್ತದೆ. ಸರ್ವರ್ ಲಾಗ್‌ಗಳಿಗೆ ಅನ್ವಯಿಸಿದಾಗ, ಲಾಗ್‌ನಲ್ಲಿ ಪ್ರತಿ ಅನನ್ಯ ಪದವನ್ನು ಹುಡುಕುವುದು ಎಂದರ್ಥ. ಪ್ರತಿ ಪದಕ್ಕೂ, ನೀವು ಎಲ್ಲಾ ಸೇರ್ಪಡೆಗಳ ಪಟ್ಟಿಯನ್ನು ಮಾಡಬೇಕಾಗುತ್ತದೆ. ಈ ಪದದೊಂದಿಗೆ ಎಲ್ಲಾ ಸಂದೇಶಗಳನ್ನು ಹುಡುಕಲು ಇದು ಸುಲಭಗೊಳಿಸುತ್ತದೆ, ಉದಾಹರಣೆಗೆ 'ದೋಷ', 'ಫೈರ್‌ಫಾಕ್ಸ್' ಅಥವಾ "ಟ್ರಾನ್ಸಾಕ್ಷನ್_16851951" - ಕೇವಲ ಸೂಚ್ಯಂಕದಲ್ಲಿ ನೋಡಿ.

ನಾನು Google ನಲ್ಲಿ ಈ ವಿಧಾನವನ್ನು ಬಳಸಿದ್ದೇನೆ ಮತ್ತು ಅದು ಚೆನ್ನಾಗಿ ಕೆಲಸ ಮಾಡಿದೆ. ಆದರೆ Scalyr ನಲ್ಲಿ ನಾವು ದಾಖಲೆಗಳ ಬೈಟ್ ಅನ್ನು ಬೈಟ್ ಮೂಲಕ ಹುಡುಕುತ್ತೇವೆ.

ಏಕೆ? ಅಮೂರ್ತ ಕ್ರಮಾವಳಿಯ ದೃಷ್ಟಿಕೋನದಿಂದ, ಕೀವರ್ಡ್ ಸೂಚಿಕೆಗಳು ವಿವೇಚನಾರಹಿತ ಶಕ್ತಿ ಹುಡುಕಾಟಗಳಿಗಿಂತ ಹೆಚ್ಚು ಪರಿಣಾಮಕಾರಿಯಾಗಿರುತ್ತವೆ. ಆದಾಗ್ಯೂ, ನಾವು ಅಲ್ಗಾರಿದಮ್‌ಗಳನ್ನು ಮಾರಾಟ ಮಾಡುವುದಿಲ್ಲ, ನಾವು ಕಾರ್ಯಕ್ಷಮತೆಯನ್ನು ಮಾರಾಟ ಮಾಡುತ್ತೇವೆ. ಮತ್ತು ಕಾರ್ಯಕ್ಷಮತೆಯು ಅಲ್ಗಾರಿದಮ್‌ಗಳ ಬಗ್ಗೆ ಮಾತ್ರವಲ್ಲ, ಸಿಸ್ಟಮ್ಸ್ ಎಂಜಿನಿಯರಿಂಗ್ ಬಗ್ಗೆಯೂ ಆಗಿದೆ. ನಾವು ಎಲ್ಲವನ್ನೂ ಪರಿಗಣಿಸಬೇಕು: ಡೇಟಾದ ಪರಿಮಾಣ, ಹುಡುಕಾಟದ ಪ್ರಕಾರ, ಲಭ್ಯವಿರುವ ಹಾರ್ಡ್‌ವೇರ್ ಮತ್ತು ಸಾಫ್ಟ್‌ವೇರ್ ಸಂದರ್ಭ. ನಮ್ಮ ನಿರ್ದಿಷ್ಟ ಸಮಸ್ಯೆಗೆ, ಸೂಚ್ಯಂಕಕ್ಕಿಂತ 'grep' ನಂತಹವು ಹೆಚ್ಚು ಸೂಕ್ತವೆಂದು ನಾವು ನಿರ್ಧರಿಸಿದ್ದೇವೆ.

ಸೂಚ್ಯಂಕಗಳು ಉತ್ತಮವಾಗಿವೆ, ಆದರೆ ಅವುಗಳಿಗೆ ಮಿತಿಗಳಿವೆ. ಒಂದು ಪದವನ್ನು ಕಂಡುಹಿಡಿಯುವುದು ಸುಲಭ. ಆದರೆ 'googlebot' ಮತ್ತು '404' ನಂತಹ ಬಹು ಪದಗಳೊಂದಿಗೆ ಸಂದೇಶಗಳನ್ನು ಹುಡುಕುವುದು ಹೆಚ್ಚು ಕಷ್ಟಕರವಾಗಿದೆ. 'ಅನ್‌ಕ್ಯಾಟ್ ಎಕ್ಸೆಪ್ಶನ್' ನಂತಹ ಪದಗುಚ್ಛವನ್ನು ಹುಡುಕಲು ಹೆಚ್ಚು ತೊಡಕಿನ ಸೂಚ್ಯಂಕ ಅಗತ್ಯವಿರುತ್ತದೆ ಅದು ಆ ಪದದೊಂದಿಗೆ ಎಲ್ಲಾ ಸಂದೇಶಗಳನ್ನು ಮಾತ್ರವಲ್ಲದೆ ಪದದ ನಿರ್ದಿಷ್ಟ ಸ್ಥಳವನ್ನೂ ಸಹ ದಾಖಲಿಸುತ್ತದೆ.

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

ಇನ್ನೊಂದು ಸಮಸ್ಯೆ ಎಂದರೆ ವಿರಾಮಚಿಹ್ನೆ. ನೀವು ಎಲ್ಲಾ ವಿನಂತಿಗಳನ್ನು ಹುಡುಕಲು ಬಯಸುವಿರಾ 50.168.29.7? ಒಳಗೊಂಡಿರುವ ಲಾಗ್‌ಗಳನ್ನು ಡೀಬಗ್ ಮಾಡುವುದರ ಬಗ್ಗೆ ಏನು [error]? ಸಬ್‌ಸ್ಕ್ರಿಪ್ಟ್‌ಗಳು ಸಾಮಾನ್ಯವಾಗಿ ವಿರಾಮಚಿಹ್ನೆಯನ್ನು ಬಿಟ್ಟುಬಿಡುತ್ತವೆ.

ಅಂತಿಮವಾಗಿ, ಎಂಜಿನಿಯರ್‌ಗಳು ಶಕ್ತಿಯುತ ಸಾಧನಗಳನ್ನು ಪ್ರೀತಿಸುತ್ತಾರೆ ಮತ್ತು ಕೆಲವೊಮ್ಮೆ ಸಮಸ್ಯೆಯನ್ನು ನಿಯಮಿತ ಅಭಿವ್ಯಕ್ತಿಯೊಂದಿಗೆ ಮಾತ್ರ ಪರಿಹರಿಸಬಹುದು. ಕೀವರ್ಡ್ ಸೂಚ್ಯಂಕವು ಇದಕ್ಕೆ ಹೆಚ್ಚು ಸೂಕ್ತವಲ್ಲ.

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

ಕೀವರ್ಡ್ ಸೂಚ್ಯಂಕಗಳು ಸಹ ಸಾಕಷ್ಟು ಜಾಗವನ್ನು ತೆಗೆದುಕೊಳ್ಳುತ್ತವೆ ಮತ್ತು ಲಾಗ್ ಮ್ಯಾನೇಜ್ಮೆಂಟ್ ಸಿಸ್ಟಮ್ನಲ್ಲಿ ಸಂಗ್ರಹಣೆಯು ಒಂದು ಪ್ರಮುಖ ವೆಚ್ಚವಾಗಿದೆ.

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

ನೀವು ವಿವೇಚನಾರಹಿತ ಸಮಸ್ಯೆಯನ್ನು ಹೊಂದಿದ್ದರೆ ವಿವೇಚನಾರಹಿತ ಶಕ್ತಿ ಕೆಲಸ ಮಾಡುತ್ತದೆ (ಮತ್ತು ಸಾಕಷ್ಟು ಬಲ)

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

ನಮ್ಮ ಹುಡುಕಾಟ ಕೋಡ್ ಮೂಲತಃ ಸಾಕಷ್ಟು ದೊಡ್ಡ ಒಳ ಲೂಪ್ ಅನ್ನು ಹೊಂದಿತ್ತು. ನಾವು 4K ನಲ್ಲಿ ಪುಟಗಳಲ್ಲಿ ಸಂದೇಶಗಳನ್ನು ಸಂಗ್ರಹಿಸುತ್ತೇವೆ; ಪ್ರತಿ ಪುಟವು ಕೆಲವು ಸಂದೇಶಗಳನ್ನು (UTF-8 ನಲ್ಲಿ) ಮತ್ತು ಪ್ರತಿ ಸಂದೇಶಕ್ಕೆ ಮೆಟಾಡೇಟಾವನ್ನು ಹೊಂದಿರುತ್ತದೆ. ಮೆಟಾಡೇಟಾವು ಮೌಲ್ಯ, ಆಂತರಿಕ ಸಂದೇಶ ID ಮತ್ತು ಇತರ ಕ್ಷೇತ್ರಗಳ ಉದ್ದವನ್ನು ಎನ್ಕೋಡ್ ಮಾಡುವ ರಚನೆಯಾಗಿದೆ. ಹುಡುಕಾಟ ಚಕ್ರವು ಈ ರೀತಿ ಕಾಣುತ್ತದೆ:

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

(ಲಾಗ್‌ಗಳೊಂದಿಗೆ ನೇರವಾಗಿ ಕೆಲಸ ಮಾಡುವುದಕ್ಕಿಂತ ಹೆಚ್ಚಾಗಿ ನಾವು 4K ಪುಟಗಳು, ಪಠ್ಯ ಮತ್ತು ಮೆಟಾಡೇಟಾದೊಂದಿಗೆ ಈ ಸ್ವರೂಪದಲ್ಲಿ ಸಂದೇಶಗಳನ್ನು ಏಕೆ ಸಂಗ್ರಹಿಸುತ್ತೇವೆ ಎಂದು ನೀವು ಕೇಳಬಹುದು. ಅನೇಕ ಕಾರಣಗಳಿವೆ, ಆಂತರಿಕವಾಗಿ ಸ್ಕೇಲಿರ್ ಎಂಜಿನ್ ಒಂದು ವಿತರಿಸಿದ ಡೇಟಾಬೇಸ್‌ನಂತಿದೆ. ಫೈಲ್ ಸಿಸ್ಟಮ್, ಲಾಗ್ ಪಾರ್ಸಿಂಗ್ ನಂತರ ಮಾರ್ಜಿನ್‌ಗಳಲ್ಲಿ ಡಿಬಿಎಂಎಸ್-ಶೈಲಿಯ ಫಿಲ್ಟರ್‌ಗಳೊಂದಿಗೆ ಪಠ್ಯ ಹುಡುಕಾಟವನ್ನು ಸಂಯೋಜಿಸಲಾಗುತ್ತದೆ. ನಾವು ಏಕಕಾಲದಲ್ಲಿ ಸಾವಿರಾರು ಲಾಗ್‌ಗಳನ್ನು ಏಕಕಾಲದಲ್ಲಿ ಹುಡುಕಬಹುದು ಮತ್ತು ಸರಳ ಪಠ್ಯ ಫೈಲ್‌ಗಳು ನಮ್ಮ ವಹಿವಾಟು, ಪುನರಾವರ್ತಿತ, ವಿತರಿಸಿದ ಡೇಟಾ ನಿರ್ವಹಣೆಗೆ ಸೂಕ್ತವಲ್ಲ).

ಆರಂಭದಲ್ಲಿ, ಬ್ರೂಟ್ ಫೋರ್ಸ್ ಆಪ್ಟಿಮೈಸೇಶನ್‌ಗೆ ಅಂತಹ ಕೋಡ್ ತುಂಬಾ ಸೂಕ್ತವಲ್ಲ ಎಂದು ತೋರುತ್ತದೆ. "ನೈಜ ಕೆಲಸ" ರಲ್ಲಿ String.indexOf() CPU ಪ್ರೊಫೈಲ್‌ನಲ್ಲಿ ಸಹ ಪ್ರಾಬಲ್ಯ ಸಾಧಿಸಲಿಲ್ಲ. ಅಂದರೆ, ಈ ವಿಧಾನವನ್ನು ಸರಳೀಕರಿಸುವುದು ಗಮನಾರ್ಹ ಪರಿಣಾಮವನ್ನು ತರುವುದಿಲ್ಲ.

ಪ್ರತಿ ಪುಟದ ಆರಂಭದಲ್ಲಿ ನಾವು ಮೆಟಾಡೇಟಾವನ್ನು ಸಂಗ್ರಹಿಸುತ್ತೇವೆ ಮತ್ತು UTF-8 ನಲ್ಲಿನ ಎಲ್ಲಾ ಸಂದೇಶಗಳ ಪಠ್ಯವನ್ನು ಇನ್ನೊಂದು ತುದಿಯಲ್ಲಿ ಪ್ಯಾಕ್ ಮಾಡಲಾಗುತ್ತದೆ. ಇದರ ಪ್ರಯೋಜನವನ್ನು ಪಡೆದುಕೊಂಡು, ಇಡೀ ಪುಟವನ್ನು ಏಕಕಾಲದಲ್ಲಿ ಹುಡುಕಲು ನಾವು ಲೂಪ್ ಅನ್ನು ಪುನಃ ಬರೆದಿದ್ದೇವೆ:

ಈ ಆವೃತ್ತಿಯು ನೇರವಾಗಿ ವೀಕ್ಷಣೆಯಲ್ಲಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ raw byte[] ಮತ್ತು ಸಂಪೂರ್ಣ 4K ಪುಟದಾದ್ಯಂತ ಎಲ್ಲಾ ಸಂದೇಶಗಳನ್ನು ಏಕಕಾಲದಲ್ಲಿ ಹುಡುಕುತ್ತದೆ.

ಬ್ರೂಟ್ ಫೋರ್ಸ್ ವಿಧಾನಕ್ಕೆ ಆಪ್ಟಿಮೈಸ್ ಮಾಡಲು ಇದು ತುಂಬಾ ಸುಲಭವಾಗಿದೆ. ಆಂತರಿಕ ಹುಡುಕಾಟ ಲೂಪ್ ಅನ್ನು ಪ್ರತಿ ಪೋಸ್ಟ್‌ನಲ್ಲಿ ಪ್ರತ್ಯೇಕವಾಗಿ ಕರೆಯುವ ಬದಲು ಸಂಪೂರ್ಣ 4K ಪುಟಕ್ಕೆ ಏಕಕಾಲದಲ್ಲಿ ಕರೆಯಲಾಗುತ್ತದೆ. ಡೇಟಾ ನಕಲು ಇಲ್ಲ, ವಸ್ತುಗಳ ಹಂಚಿಕೆ ಇಲ್ಲ. ಮತ್ತು ಹೆಚ್ಚು ಸಂಕೀರ್ಣವಾದ ಮೆಟಾಡೇಟಾ ಕಾರ್ಯಾಚರಣೆಗಳನ್ನು ಫಲಿತಾಂಶವು ಧನಾತ್ಮಕವಾಗಿದ್ದಾಗ ಮಾತ್ರ ಕರೆಯಲಾಗುತ್ತದೆ, ಮತ್ತು ಪ್ರತಿ ಸಂದೇಶದಲ್ಲಿ ಅಲ್ಲ. ಈ ರೀತಿಯಾಗಿ ನಾವು ಒಂದು ಟನ್ ಓವರ್‌ಹೆಡ್ ಅನ್ನು ತೆಗೆದುಹಾಕಿದ್ದೇವೆ ಮತ್ತು ಉಳಿದ ಲೋಡ್ ಅನ್ನು ಸಣ್ಣ ಆಂತರಿಕ ಹುಡುಕಾಟ ಲೂಪ್‌ನಲ್ಲಿ ಕೇಂದ್ರೀಕರಿಸಲಾಗಿದೆ, ಇದು ಮತ್ತಷ್ಟು ಆಪ್ಟಿಮೈಸೇಶನ್‌ಗೆ ಸೂಕ್ತವಾಗಿರುತ್ತದೆ.

ನಮ್ಮ ನಿಜವಾದ ಹುಡುಕಾಟ ಅಲ್ಗಾರಿದಮ್ ಆಧರಿಸಿದೆ ಲಿಯೊನಿಡ್ ವೊಲ್ನಿಟ್ಸ್ಕಿಯ ಉತ್ತಮ ಕಲ್ಪನೆ. ಇದು ಬೋಯರ್-ಮೂರ್ ಅಲ್ಗಾರಿದಮ್ ಅನ್ನು ಹೋಲುತ್ತದೆ, ಪ್ರತಿ ಹಂತದಲ್ಲೂ ಸರಿಸುಮಾರು ಹುಡುಕಾಟ ಸ್ಟ್ರಿಂಗ್‌ನ ಉದ್ದವನ್ನು ಬಿಟ್ಟುಬಿಡುತ್ತದೆ. ಮುಖ್ಯ ವ್ಯತ್ಯಾಸವೆಂದರೆ ಅದು ತಪ್ಪು ಹೊಂದಾಣಿಕೆಗಳನ್ನು ಕಡಿಮೆ ಮಾಡಲು ಒಂದು ಸಮಯದಲ್ಲಿ ಎರಡು ಬೈಟ್‌ಗಳನ್ನು ಪರಿಶೀಲಿಸುತ್ತದೆ.

ನಮ್ಮ ಅನುಷ್ಠಾನಕ್ಕೆ ಪ್ರತಿ ಹುಡುಕಾಟಕ್ಕೆ 64K ಲುಕಪ್ ಟೇಬಲ್ ರಚಿಸುವ ಅಗತ್ಯವಿದೆ, ಆದರೆ ನಾವು ಹುಡುಕುತ್ತಿರುವ ಗಿಗಾಬೈಟ್ ಡೇಟಾಗೆ ಹೋಲಿಸಿದರೆ ಅದು ಏನೂ ಅಲ್ಲ. ಒಳಗಿನ ಲೂಪ್ ಒಂದೇ ಕೋರ್‌ನಲ್ಲಿ ಸೆಕೆಂಡಿಗೆ ಹಲವಾರು ಗಿಗಾಬೈಟ್‌ಗಳನ್ನು ಪ್ರಕ್ರಿಯೆಗೊಳಿಸುತ್ತದೆ. ಪ್ರಾಯೋಗಿಕವಾಗಿ, ಪ್ರತಿ ಕೋರ್ನಲ್ಲಿ ಸ್ಥಿರವಾದ ಕಾರ್ಯಕ್ಷಮತೆಯು ಸೆಕೆಂಡಿಗೆ ಸುಮಾರು 1,25 GB ಆಗಿದೆ, ಮತ್ತು ಸುಧಾರಣೆಗೆ ಅವಕಾಶವಿದೆ. ಒಳಗಿನ ಲೂಪ್‌ನ ಹೊರಗಿನ ಕೆಲವು ಓವರ್‌ಹೆಡ್ ಅನ್ನು ತೆಗೆದುಹಾಕಲು ಸಾಧ್ಯವಿದೆ, ಮತ್ತು ನಾವು ಜಾವಾ ಬದಲಿಗೆ C ಯಲ್ಲಿ ಒಳಗಿನ ಲೂಪ್ ಅನ್ನು ಪ್ರಯೋಗಿಸಲು ಯೋಜಿಸುತ್ತೇವೆ.

ನಾವು ಬಲವನ್ನು ಬಳಸುತ್ತೇವೆ

ಲಾಗ್ ಹುಡುಕಾಟವನ್ನು "ಸ್ಥೂಲವಾಗಿ" ಕಾರ್ಯಗತಗೊಳಿಸಬಹುದೆಂದು ನಾವು ಚರ್ಚಿಸಿದ್ದೇವೆ, ಆದರೆ ನಮ್ಮಲ್ಲಿ ಎಷ್ಟು "ಶಕ್ತಿ" ಇದೆ? ಸಾಕಷ್ಟು.

1 ಕೋರ್: ಸರಿಯಾಗಿ ಬಳಸಿದಾಗ, ಆಧುನಿಕ ಪ್ರೊಸೆಸರ್‌ನ ಒಂದು ಕೋರ್ ತನ್ನದೇ ಆದ ಬಲದಲ್ಲಿ ಸಾಕಷ್ಟು ಶಕ್ತಿಯುತವಾಗಿರುತ್ತದೆ.

8 ಕೋರ್ಗಳು: ನಾವು ಪ್ರಸ್ತುತ Amazon hi1.4xlarge ಮತ್ತು i2.4xlarge SSD ಸರ್ವರ್‌ಗಳಲ್ಲಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತಿದ್ದೇವೆ, ಪ್ರತಿಯೊಂದೂ 8 ಕೋರ್‌ಗಳನ್ನು (16 ಥ್ರೆಡ್‌ಗಳು) ಹೊಂದಿದೆ. ಮೇಲೆ ಹೇಳಿದಂತೆ, ಈ ಕೋರ್ಗಳು ಸಾಮಾನ್ಯವಾಗಿ ಹಿನ್ನೆಲೆ ಕಾರ್ಯಾಚರಣೆಗಳಲ್ಲಿ ಕಾರ್ಯನಿರತವಾಗಿವೆ. ಬಳಕೆದಾರರು ಹುಡುಕಾಟವನ್ನು ನಡೆಸಿದಾಗ, ಹಿನ್ನೆಲೆ ಕಾರ್ಯಾಚರಣೆಗಳನ್ನು ಅಮಾನತುಗೊಳಿಸಲಾಗುತ್ತದೆ, ಹುಡುಕಾಟಕ್ಕಾಗಿ ಎಲ್ಲಾ 8 ಕೋರ್ಗಳನ್ನು ಮುಕ್ತಗೊಳಿಸುತ್ತದೆ. ಹುಡುಕಾಟವು ಸಾಮಾನ್ಯವಾಗಿ ಸ್ಪ್ಲಿಟ್ ಸೆಕೆಂಡ್‌ನಲ್ಲಿ ಪೂರ್ಣಗೊಳ್ಳುತ್ತದೆ, ಅದರ ನಂತರ ಹಿನ್ನೆಲೆ ಕೆಲಸ ಪುನರಾರಂಭವಾಗುತ್ತದೆ (ಥ್ರೊಟ್ಲಿಂಗ್ ಪ್ರೋಗ್ರಾಂ ಹುಡುಕಾಟ ಪ್ರಶ್ನೆಗಳ ಬ್ಯಾರೇಜ್ ಪ್ರಮುಖ ಹಿನ್ನೆಲೆ ಕೆಲಸದಲ್ಲಿ ಹಸ್ತಕ್ಷೇಪ ಮಾಡುವುದಿಲ್ಲ ಎಂದು ಖಚಿತಪಡಿಸುತ್ತದೆ).

16 ಕೋರ್ಗಳು: ವಿಶ್ವಾಸಾರ್ಹತೆಗಾಗಿ, ನಾವು ಸರ್ವರ್‌ಗಳನ್ನು ಮಾಸ್ಟರ್/ಸ್ಲೇವ್ ಗುಂಪುಗಳಾಗಿ ಆಯೋಜಿಸುತ್ತೇವೆ. ಪ್ರತಿಯೊಬ್ಬ ಮಾಸ್ಟರ್ ತನ್ನ ಆಜ್ಞೆಯ ಅಡಿಯಲ್ಲಿ ಒಂದು SSD ಮತ್ತು ಒಂದು EBS ಸರ್ವರ್ ಅನ್ನು ಹೊಂದಿರುತ್ತದೆ. ಮುಖ್ಯ ಸರ್ವರ್ ಕ್ರ್ಯಾಶ್ ಆಗಿದ್ದರೆ, SSD ಸರ್ವರ್ ತಕ್ಷಣವೇ ಅದರ ಸ್ಥಾನವನ್ನು ತೆಗೆದುಕೊಳ್ಳುತ್ತದೆ. ಬಹುತೇಕ ಎಲ್ಲಾ ಸಮಯದಲ್ಲೂ, ಮಾಸ್ಟರ್ ಮತ್ತು ಸ್ಲೇವ್ ಉತ್ತಮವಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ, ಆದ್ದರಿಂದ ಪ್ರತಿ ಡೇಟಾ ಬ್ಲಾಕ್ ಅನ್ನು ಎರಡು ವಿಭಿನ್ನ ಸರ್ವರ್‌ಗಳಲ್ಲಿ ಹುಡುಕಬಹುದಾಗಿದೆ (ಇಬಿಎಸ್ ಸ್ಲೇವ್ ಸರ್ವರ್ ದುರ್ಬಲ ಪ್ರೊಸೆಸರ್ ಅನ್ನು ಹೊಂದಿದೆ, ಆದ್ದರಿಂದ ನಾವು ಅದನ್ನು ಪರಿಗಣಿಸುವುದಿಲ್ಲ). ನಾವು ಅವುಗಳ ನಡುವೆ ಕಾರ್ಯವನ್ನು ವಿಭಜಿಸುತ್ತೇವೆ, ಇದರಿಂದ ನಮಗೆ ಒಟ್ಟು 16 ಕೋರ್‌ಗಳು ಲಭ್ಯವಿವೆ.

ಅನೇಕ ಕೋರ್ಗಳು: ಸದ್ಯದಲ್ಲಿಯೇ, ನಾವು ಸರ್ವರ್‌ಗಳಾದ್ಯಂತ ಡೇಟಾವನ್ನು ವಿತರಿಸುತ್ತೇವೆ ಆದ್ದರಿಂದ ಅವರು ಎಲ್ಲಾ ಕ್ಷುಲ್ಲಕವಲ್ಲದ ವಿನಂತಿಯನ್ನು ಪ್ರಕ್ರಿಯೆಗೊಳಿಸಲು ಭಾಗವಹಿಸುತ್ತಾರೆ. ಪ್ರತಿ ಕೋರ್ ಕೆಲಸ ಮಾಡುತ್ತದೆ. [ಸೂಚನೆ: ನಾವು ಯೋಜನೆಯನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸಿದ್ದೇವೆ ಮತ್ತು ಹುಡುಕಾಟದ ವೇಗವನ್ನು 1 TB/s ಗೆ ಹೆಚ್ಚಿಸಿದ್ದೇವೆ, ಲೇಖನದ ಕೊನೆಯಲ್ಲಿ ಗಮನಿಸಿ ನೋಡಿ].

ಸರಳತೆಯು ವಿಶ್ವಾಸಾರ್ಹತೆಯನ್ನು ಖಾತ್ರಿಗೊಳಿಸುತ್ತದೆ

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

ಕೀವರ್ಡ್ ಸೂಚ್ಯಂಕವು ಕೆಲವೊಮ್ಮೆ ವಿಸ್ಮಯಕಾರಿಯಾಗಿ ವೇಗದ ಫಲಿತಾಂಶಗಳನ್ನು ನೀಡುತ್ತದೆ ಮತ್ತು ಇತರ ಬಾರಿ ಅದು ಮಾಡುವುದಿಲ್ಲ. ನೀವು 50 GB ಲಾಗ್‌ಗಳನ್ನು ಹೊಂದಿದ್ದೀರಿ ಎಂದು ಹೇಳೋಣ ಅದರಲ್ಲಿ 'customer_5987235982' ಪದವು ನಿಖರವಾಗಿ ಮೂರು ಬಾರಿ ಕಾಣಿಸಿಕೊಳ್ಳುತ್ತದೆ. ಈ ಪದದ ಹುಡುಕಾಟವು ಸೂಚ್ಯಂಕದಿಂದ ನೇರವಾಗಿ ಮೂರು ಸ್ಥಳಗಳನ್ನು ಎಣಿಕೆ ಮಾಡುತ್ತದೆ ಮತ್ತು ತಕ್ಷಣವೇ ಪೂರ್ಣಗೊಳ್ಳುತ್ತದೆ. ಆದರೆ ಸಂಕೀರ್ಣ ವೈಲ್ಡ್‌ಕಾರ್ಡ್ ಹುಡುಕಾಟಗಳು ಸಾವಿರಾರು ಕೀವರ್ಡ್‌ಗಳನ್ನು ಸ್ಕ್ಯಾನ್ ಮಾಡಬಹುದು ಮತ್ತು ದೀರ್ಘ ಸಮಯ ತೆಗೆದುಕೊಳ್ಳಬಹುದು.

ಮತ್ತೊಂದೆಡೆ, ವಿವೇಚನಾರಹಿತ ಶಕ್ತಿ ಹುಡುಕಾಟಗಳು ಯಾವುದೇ ಪ್ರಶ್ನೆಗೆ ಹೆಚ್ಚು ಅಥವಾ ಕಡಿಮೆ ಅದೇ ವೇಗದಲ್ಲಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತವೆ. ದೀರ್ಘ ಪದಗಳನ್ನು ಹುಡುಕುವುದು ಉತ್ತಮ, ಆದರೆ ಒಂದೇ ಅಕ್ಷರವನ್ನು ಹುಡುಕುವುದು ತುಂಬಾ ವೇಗವಾಗಿರುತ್ತದೆ.

ಬ್ರೂಟ್ ಫೋರ್ಸ್ ವಿಧಾನದ ಸರಳತೆ ಎಂದರೆ ಅದರ ಕಾರ್ಯಕ್ಷಮತೆಯು ಅದರ ಸೈದ್ಧಾಂತಿಕ ಗರಿಷ್ಠಕ್ಕೆ ಹತ್ತಿರದಲ್ಲಿದೆ. ಅನಿರೀಕ್ಷಿತ ಡಿಸ್ಕ್ ಓವರ್‌ಲೋಡ್‌ಗಳು, ಲಾಕ್ ವಿವಾದ, ಪಾಯಿಂಟರ್ ಚೇಸಿಂಗ್ ಮತ್ತು ವೈಫಲ್ಯಕ್ಕೆ ಸಾವಿರಾರು ಕಾರಣಗಳಿಗಾಗಿ ಕಡಿಮೆ ಆಯ್ಕೆಗಳಿವೆ. ನಮ್ಮ ಅತ್ಯಂತ ಜನನಿಬಿಡ ಸರ್ವರ್‌ನಲ್ಲಿ ಕಳೆದ ವಾರ Scalyr ಬಳಕೆದಾರರು ಮಾಡಿದ ವಿನಂತಿಗಳನ್ನು ನಾನು ನೋಡಿದೆ. 14 ಮನವಿಗಳು ಬಂದಿವೆ. ಅವುಗಳಲ್ಲಿ ನಿಖರವಾಗಿ ಎಂಟು ಒಂದಕ್ಕಿಂತ ಹೆಚ್ಚು ಸೆಕೆಂಡುಗಳನ್ನು ತೆಗೆದುಕೊಂಡಿತು; 000% 99 ಮಿಲಿಸೆಕೆಂಡ್‌ಗಳಲ್ಲಿ ಪೂರ್ಣಗೊಂಡಿದೆ (ನೀವು ಲಾಗ್ ವಿಶ್ಲೇಷಣಾ ಸಾಧನಗಳನ್ನು ಬಳಸದಿದ್ದರೆ, ನನ್ನನ್ನು ನಂಬಿರಿ: ಇದು ವೇಗವಾಗಿದೆ).

ಸೇವೆಯ ಸುಲಭ ಬಳಕೆಗಾಗಿ ಸ್ಥಿರ, ವಿಶ್ವಾಸಾರ್ಹ ಕಾರ್ಯಕ್ಷಮತೆ ಮುಖ್ಯವಾಗಿದೆ. ಇದು ನಿಯತಕಾಲಿಕವಾಗಿ ವಿಳಂಬವಾಗಿದ್ದರೆ, ಬಳಕೆದಾರರು ಅದನ್ನು ವಿಶ್ವಾಸಾರ್ಹವಲ್ಲ ಎಂದು ಗ್ರಹಿಸುತ್ತಾರೆ ಮತ್ತು ಅದನ್ನು ಬಳಸಲು ಹಿಂಜರಿಯುತ್ತಾರೆ.

ಲಾಗ್ ಹುಡುಕಾಟ ಕ್ರಿಯೆಯಲ್ಲಿದೆ

ಸ್ಕೇಲಿರ್ ಹುಡುಕಾಟವನ್ನು ಕ್ರಿಯೆಯಲ್ಲಿ ತೋರಿಸುವ ಕಿರು ಅನಿಮೇಷನ್ ಇಲ್ಲಿದೆ. ನಾವು ಪ್ರತಿ ಸಾರ್ವಜನಿಕ ಗಿಥಬ್ ರೆಪೊಸಿಟರಿಯಲ್ಲಿ ಪ್ರತಿ ಈವೆಂಟ್ ಅನ್ನು ಆಮದು ಮಾಡಿಕೊಳ್ಳುವ ಡೆಮೊ ಖಾತೆಯನ್ನು ನಾವು ಹೊಂದಿದ್ದೇವೆ. ಈ ಡೆಮೊದಲ್ಲಿ, ನಾನು ಒಂದು ವಾರದ ಮೌಲ್ಯದ ಡೇಟಾವನ್ನು ಪರಿಶೀಲಿಸುತ್ತೇನೆ: ಸರಿಸುಮಾರು 600 MB ಕಚ್ಚಾ ದಾಖಲೆಗಳು.

ನನ್ನ ಡೆಸ್ಕ್‌ಟಾಪ್‌ನಲ್ಲಿ (ಸರ್ವರ್‌ನಿಂದ ಸುಮಾರು 5000 ಕಿಲೋಮೀಟರ್) ವಿಶೇಷ ತಯಾರಿ ಇಲ್ಲದೆ ವೀಡಿಯೊವನ್ನು ಲೈವ್ ಆಗಿ ರೆಕಾರ್ಡ್ ಮಾಡಲಾಗಿದೆ. ನೀವು ನೋಡುವ ಕಾರ್ಯಕ್ಷಮತೆಯು ಹೆಚ್ಚಾಗಿ ಕಾರಣವಾಗಿದೆ ವೆಬ್ ಕ್ಲೈಂಟ್ ಆಪ್ಟಿಮೈಸೇಶನ್, ಹಾಗೆಯೇ ವೇಗದ ಮತ್ತು ವಿಶ್ವಾಸಾರ್ಹ ಬ್ಯಾಕೆಂಡ್. 'ಲೋಡಿಂಗ್' ಸೂಚಕವಿಲ್ಲದೆ ವಿರಾಮವಿದ್ದಾಗಲೆಲ್ಲಾ, ನಾನು ವಿರಾಮಗೊಳಿಸುತ್ತಿದ್ದೇನೆ ಆದ್ದರಿಂದ ನಾನು ಏನನ್ನು ಒತ್ತಲಿದ್ದೇನೆ ಎಂಬುದನ್ನು ನೀವು ಓದಬಹುದು.

ತೀರ್ಮಾನಕ್ಕೆ

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

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

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

ತಿದ್ದು: ಶೀರ್ಷಿಕೆ ಮತ್ತು ಪಠ್ಯವು ಕಳೆದ ಕೆಲವು ವರ್ಷಗಳಿಂದ ಕಾರ್ಯಕ್ಷಮತೆಯ ಹೆಚ್ಚಳವನ್ನು ಪ್ರತಿಬಿಂಬಿಸಲು "ಸೆಕೆಂಡಿಗೆ 20 GB ಯಲ್ಲಿ ಹುಡುಕಾಟ" ದಿಂದ "ಸೆಕೆಂಡಿಗೆ 1 TB ನಲ್ಲಿ ಹುಡುಕಿ" ಗೆ ಬದಲಾಗಿದೆ. ಈ ವೇಗದ ಹೆಚ್ಚಳವು ಪ್ರಾಥಮಿಕವಾಗಿ ನಮ್ಮ ಹೆಚ್ಚಿದ ಗ್ರಾಹಕರ ನೆಲೆಯನ್ನು ಪೂರೈಸಲು ನಾವು ಇಂದು ಹಾಕುತ್ತಿರುವ EC2 ಸರ್ವರ್‌ಗಳ ಪ್ರಕಾರ ಮತ್ತು ಸಂಖ್ಯೆಯಲ್ಲಿನ ಬದಲಾವಣೆಗಳಿಂದಾಗಿ. ಕಾರ್ಯಾಚರಣೆಯ ದಕ್ಷತೆಗೆ ಮತ್ತೊಂದು ನಾಟಕೀಯ ವರ್ಧಕವನ್ನು ಒದಗಿಸುವ ಬದಲಾವಣೆಗಳು ಶೀಘ್ರದಲ್ಲೇ ಬರಲಿವೆ ಮತ್ತು ಅವುಗಳನ್ನು ಹಂಚಿಕೊಳ್ಳಲು ನಾವು ಕಾಯಲು ಸಾಧ್ಯವಿಲ್ಲ.

ಮೂಲ: www.habr.com