ಬಿಲ್ಡರ್‌ಗಳಿಗಾಗಿ B2B ಸೇವೆಯ ಉದಾಹರಣೆಯನ್ನು ಬಳಸಿಕೊಂಡು ಡೇಟಾಬೇಸ್ ಪ್ರಶ್ನೆಗಳನ್ನು ಆಪ್ಟಿಮೈಜ್ ಮಾಡುವುದು

ಹೆಚ್ಚು ಉತ್ಪಾದಕ ಸರ್ವರ್‌ಗೆ ಚಲಿಸದೆ ಡೇಟಾಬೇಸ್‌ಗೆ ಪ್ರಶ್ನೆಗಳ ಸಂಖ್ಯೆಯನ್ನು 10 ಪಟ್ಟು ಹೆಚ್ಚಿಸುವುದು ಮತ್ತು ಸಿಸ್ಟಮ್ ಕಾರ್ಯವನ್ನು ನಿರ್ವಹಿಸುವುದು ಹೇಗೆ? ನಮ್ಮ ಡೇಟಾಬೇಸ್‌ನ ಕಾರ್ಯಕ್ಷಮತೆಯ ಕುಸಿತದೊಂದಿಗೆ ನಾವು ಹೇಗೆ ವ್ಯವಹರಿಸಿದ್ದೇವೆ, ಸಾಧ್ಯವಾದಷ್ಟು ಬಳಕೆದಾರರಿಗೆ ಸೇವೆ ಸಲ್ಲಿಸಲು SQL ಪ್ರಶ್ನೆಗಳನ್ನು ಹೇಗೆ ಆಪ್ಟಿಮೈಸ್ ಮಾಡಿದ್ದೇವೆ ಮತ್ತು ಕಂಪ್ಯೂಟಿಂಗ್ ಸಂಪನ್ಮೂಲಗಳ ವೆಚ್ಚವನ್ನು ಹೆಚ್ಚಿಸುವುದಿಲ್ಲ ಎಂದು ನಾನು ನಿಮಗೆ ಹೇಳುತ್ತೇನೆ.

ನಿರ್ಮಾಣ ಕಂಪನಿಗಳಲ್ಲಿ ವ್ಯವಹಾರ ಪ್ರಕ್ರಿಯೆಗಳನ್ನು ನಿರ್ವಹಿಸಲು ನಾನು ಸೇವೆಯನ್ನು ಮಾಡುತ್ತೇನೆ. ಸುಮಾರು 3 ಸಾವಿರ ಕಂಪನಿಗಳು ನಮ್ಮೊಂದಿಗೆ ಕೆಲಸ ಮಾಡುತ್ತಿವೆ. 10 ಸಾವಿರಕ್ಕೂ ಹೆಚ್ಚು ಜನರು ಪ್ರತಿದಿನ 4-10 ಗಂಟೆಗಳ ಕಾಲ ನಮ್ಮ ವ್ಯವಸ್ಥೆಯೊಂದಿಗೆ ಕೆಲಸ ಮಾಡುತ್ತಾರೆ. ಇದು ಯೋಜನೆ, ಅಧಿಸೂಚನೆ, ಎಚ್ಚರಿಕೆ, ಮೌಲ್ಯೀಕರಣದ ವಿವಿಧ ಸಮಸ್ಯೆಗಳನ್ನು ಪರಿಹರಿಸುತ್ತದೆ... ನಾವು PostgreSQL 9.6 ಅನ್ನು ಬಳಸುತ್ತೇವೆ. ನಾವು ಡೇಟಾಬೇಸ್‌ನಲ್ಲಿ ಸುಮಾರು 300 ಕೋಷ್ಟಕಗಳನ್ನು ಹೊಂದಿದ್ದೇವೆ ಮತ್ತು ಪ್ರತಿದಿನ 200 ಮಿಲಿಯನ್ ಪ್ರಶ್ನೆಗಳನ್ನು (10 ಸಾವಿರ ವಿಭಿನ್ನವಾದವುಗಳು) ಸ್ವೀಕರಿಸುತ್ತೇವೆ. ನಾವು ಪ್ರತಿ ಸೆಕೆಂಡಿಗೆ ಸರಾಸರಿ 3-4 ಸಾವಿರ ವಿನಂತಿಗಳನ್ನು ಹೊಂದಿದ್ದೇವೆ, ಅತ್ಯಂತ ಸಕ್ರಿಯ ಕ್ಷಣಗಳಲ್ಲಿ ಸೆಕೆಂಡಿಗೆ 10 ಸಾವಿರಕ್ಕೂ ಹೆಚ್ಚು ವಿನಂತಿಗಳು. ಹೆಚ್ಚಿನ ಪ್ರಶ್ನೆಗಳು OLAP. ಕಡಿಮೆ ಸೇರ್ಪಡೆಗಳು, ಮಾರ್ಪಾಡುಗಳು ಮತ್ತು ಅಳಿಸುವಿಕೆಗಳು ಇವೆ, ಅಂದರೆ OLTP ಲೋಡ್ ತುಲನಾತ್ಮಕವಾಗಿ ಹಗುರವಾಗಿರುತ್ತದೆ. ನಾನು ಈ ಎಲ್ಲಾ ಸಂಖ್ಯೆಗಳನ್ನು ಒದಗಿಸಿದ್ದೇನೆ ಇದರಿಂದ ನೀವು ನಮ್ಮ ಯೋಜನೆಯ ಪ್ರಮಾಣವನ್ನು ನಿರ್ಣಯಿಸಬಹುದು ಮತ್ತು ನಮ್ಮ ಅನುಭವವು ನಿಮಗೆ ಎಷ್ಟು ಉಪಯುಕ್ತವಾಗಿದೆ ಎಂಬುದನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳಬಹುದು.

ಚಿತ್ರ ಒಂದು. ಭಾವಗೀತಾತ್ಮಕ

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

ಚಿತ್ರ ಎರಡು. ಸಂಖ್ಯಾಶಾಸ್ತ್ರೀಯ

ಆದ್ದರಿಂದ ನಾವು ದಿನಕ್ಕೆ ಸುಮಾರು 10 ಸಾವಿರ ವಿಭಿನ್ನ ಪ್ರಶ್ನೆಗಳನ್ನು ನಮ್ಮ ಡೇಟಾಬೇಸ್‌ನಲ್ಲಿ ಕಾರ್ಯಗತಗೊಳಿಸುತ್ತೇವೆ. ಈ 10 ಸಾವಿರದಲ್ಲಿ, 2-3 ಎಂಎಸ್ ಸರಾಸರಿ ಮರಣದಂಡನೆ ಸಮಯದೊಂದಿಗೆ 0.1-0.3 ಮಿಲಿಯನ್ ಬಾರಿ ಕಾರ್ಯಗತಗೊಳಿಸಲಾದ ರಾಕ್ಷಸರಿದ್ದಾರೆ ಮತ್ತು ದಿನಕ್ಕೆ 30 ಬಾರಿ ಎಂದು ಕರೆಯಲ್ಪಡುವ 100 ಸೆಕೆಂಡುಗಳ ಸರಾಸರಿ ಎಕ್ಸಿಕ್ಯೂಶನ್ ಸಮಯದೊಂದಿಗೆ ಪ್ರಶ್ನೆಗಳಿವೆ.

ಎಲ್ಲಾ 10 ಸಾವಿರ ಪ್ರಶ್ನೆಗಳನ್ನು ಆಪ್ಟಿಮೈಸ್ ಮಾಡಲು ಸಾಧ್ಯವಾಗಲಿಲ್ಲ, ಆದ್ದರಿಂದ ಡೇಟಾಬೇಸ್ನ ಕಾರ್ಯಕ್ಷಮತೆಯನ್ನು ಸರಿಯಾಗಿ ಸುಧಾರಿಸಲು ನಮ್ಮ ಪ್ರಯತ್ನಗಳನ್ನು ಎಲ್ಲಿ ನಿರ್ದೇಶಿಸಬೇಕೆಂದು ನಾವು ನಿರ್ಧರಿಸಿದ್ದೇವೆ. ಹಲವಾರು ಪುನರಾವರ್ತನೆಗಳ ನಂತರ, ನಾವು ವಿನಂತಿಗಳನ್ನು ವಿಧಗಳಾಗಿ ವಿಂಗಡಿಸಲು ಪ್ರಾರಂಭಿಸಿದ್ದೇವೆ.

ಟಾಪ್ ವಿನಂತಿಗಳು

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

ಎಲ್ಲಾ ಕಂಪನಿಗಳ ಸಾಮಾನ್ಯ ಅಭ್ಯಾಸವೆಂದರೆ TOP ವಿನಂತಿಗಳೊಂದಿಗೆ ಕೆಲಸ ಮಾಡುವುದು. ಅವುಗಳಲ್ಲಿ ಕೆಲವು ಇವೆ; ಒಂದು ಪ್ರಶ್ನೆಯನ್ನು ಸಹ ಉತ್ತಮಗೊಳಿಸುವುದರಿಂದ 5-10% ಸಂಪನ್ಮೂಲಗಳನ್ನು ಮುಕ್ತಗೊಳಿಸಬಹುದು. ಆದಾಗ್ಯೂ, ಪ್ರಾಜೆಕ್ಟ್ ಪಕ್ವವಾದಂತೆ, TOP ಪ್ರಶ್ನೆಗಳನ್ನು ಆಪ್ಟಿಮೈಜ್ ಮಾಡುವುದು ಹೆಚ್ಚು ಕ್ಷುಲ್ಲಕವಲ್ಲದ ಕಾರ್ಯವಾಗುತ್ತದೆ. ಎಲ್ಲಾ ಸರಳ ವಿಧಾನಗಳನ್ನು ಈಗಾಗಲೇ ಕೆಲಸ ಮಾಡಲಾಗಿದೆ, ಮತ್ತು ಅತ್ಯಂತ "ಭಾರೀ" ವಿನಂತಿಯು "ಕೇವಲ" 3-5% ಸಂಪನ್ಮೂಲಗಳನ್ನು ತೆಗೆದುಕೊಳ್ಳುತ್ತದೆ. ಒಟ್ಟಾರೆಯಾಗಿ TOP ಪ್ರಶ್ನೆಗಳು 30-40% ಕ್ಕಿಂತ ಕಡಿಮೆ ಸಮಯವನ್ನು ತೆಗೆದುಕೊಂಡರೆ, ಆಗ ನೀವು ಅವುಗಳನ್ನು ತ್ವರಿತವಾಗಿ ಕೆಲಸ ಮಾಡಲು ಈಗಾಗಲೇ ಪ್ರಯತ್ನಗಳನ್ನು ಮಾಡಿದ್ದೀರಿ ಮತ್ತು ಮುಂದಿನ ಗುಂಪಿನಿಂದ ಪ್ರಶ್ನೆಗಳನ್ನು ಆಪ್ಟಿಮೈಜ್ ಮಾಡಲು ಇದು ಸಮಯವಾಗಿದೆ.
ಈ ಗುಂಪಿನಲ್ಲಿ ಎಷ್ಟು ಉನ್ನತ ಪ್ರಶ್ನೆಗಳನ್ನು ಸೇರಿಸಬೇಕು ಎಂಬ ಪ್ರಶ್ನೆಗೆ ಉತ್ತರಿಸಲು ಇದು ಉಳಿದಿದೆ. ನಾನು ಸಾಮಾನ್ಯವಾಗಿ ಕನಿಷ್ಠ 10 ಅನ್ನು ತೆಗೆದುಕೊಳ್ಳುತ್ತೇನೆ, ಆದರೆ 20 ಕ್ಕಿಂತ ಹೆಚ್ಚಿಲ್ಲ. TOP ಗುಂಪಿನಲ್ಲಿ ಮೊದಲ ಮತ್ತು ಕೊನೆಯ ಸಮಯವು 10 ಪಟ್ಟು ಹೆಚ್ಚು ಭಿನ್ನವಾಗಿರುವುದಿಲ್ಲ ಎಂದು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳಲು ನಾನು ಪ್ರಯತ್ನಿಸುತ್ತೇನೆ. ಅಂದರೆ, ಪ್ರಶ್ನೆ ಕಾರ್ಯಗತಗೊಳಿಸುವ ಸಮಯವು 1 ನೇ ಸ್ಥಾನದಿಂದ 10 ನೇ ಸ್ಥಾನಕ್ಕೆ ತೀವ್ರವಾಗಿ ಇಳಿದರೆ, ನಾನು TOP-10 ಅನ್ನು ತೆಗೆದುಕೊಳ್ಳುತ್ತೇನೆ, ಡ್ರಾಪ್ ಹೆಚ್ಚು ಕ್ರಮೇಣವಾಗಿದ್ದರೆ, ನಾನು ಗುಂಪಿನ ಗಾತ್ರವನ್ನು 15 ಅಥವಾ 20 ಕ್ಕೆ ಹೆಚ್ಚಿಸುತ್ತೇನೆ.

ಮಧ್ಯಮ ರೈತರು

ಇವೆಲ್ಲವೂ ಕೊನೆಯ 5-10% ಹೊರತುಪಡಿಸಿ, TOP ನಂತರ ತಕ್ಷಣವೇ ಬರುವ ವಿನಂತಿಗಳಾಗಿವೆ. ಸಾಮಾನ್ಯವಾಗಿ, ಈ ಪ್ರಶ್ನೆಗಳನ್ನು ಉತ್ತಮಗೊಳಿಸುವಲ್ಲಿ ಸರ್ವರ್ ಕಾರ್ಯಕ್ಷಮತೆಯನ್ನು ಹೆಚ್ಚಿಸುವ ಅವಕಾಶವಿದೆ. ಈ ವಿನಂತಿಗಳು 80% ವರೆಗೆ ತೂಗಬಹುದು. ಆದರೆ ಅವರ ಪಾಲು 50% ಮೀರಿದ್ದರೂ ಸಹ, ಅವುಗಳನ್ನು ಹೆಚ್ಚು ಎಚ್ಚರಿಕೆಯಿಂದ ನೋಡುವ ಸಮಯ.

ಬಾಲ

ಹೇಳಿದಂತೆ, ಈ ಪ್ರಶ್ನೆಗಳು ಕೊನೆಯಲ್ಲಿ ಬರುತ್ತವೆ ಮತ್ತು 5-10% ಸಮಯವನ್ನು ತೆಗೆದುಕೊಳ್ಳುತ್ತವೆ. ನೀವು ಸ್ವಯಂಚಾಲಿತ ಪ್ರಶ್ನೆ ವಿಶ್ಲೇಷಣಾ ಸಾಧನಗಳನ್ನು ಬಳಸದಿದ್ದರೆ ಮಾತ್ರ ನೀವು ಅವುಗಳನ್ನು ಮರೆತುಬಿಡಬಹುದು, ನಂತರ ಅವುಗಳನ್ನು ಉತ್ತಮಗೊಳಿಸುವುದು ಸಹ ಅಗ್ಗವಾಗಿದೆ.

ಪ್ರತಿ ಗುಂಪನ್ನು ಹೇಗೆ ಮೌಲ್ಯಮಾಪನ ಮಾಡುವುದು?

PostgreSQL ಗಾಗಿ ಅಂತಹ ಮೌಲ್ಯಮಾಪನವನ್ನು ಮಾಡಲು ಸಹಾಯ ಮಾಡುವ SQL ಪ್ರಶ್ನೆಯನ್ನು ನಾನು ಬಳಸುತ್ತೇನೆ (ಇತರ ಅನೇಕ DBMS ಗಳಿಗೆ ಇದೇ ರೀತಿಯ ಪ್ರಶ್ನೆಯನ್ನು ಬರೆಯಬಹುದು ಎಂದು ನನಗೆ ಖಾತ್ರಿಯಿದೆ)

TOP-MEDIUM-TAIL ಗುಂಪುಗಳ ಗಾತ್ರವನ್ನು ಅಂದಾಜು ಮಾಡಲು SQL ಪ್ರಶ್ನೆ

SELECT sum(time_top) AS sum_top, sum(time_medium) AS sum_medium, sum(time_tail) AS sum_tail
FROM
(
  SELECT CASE WHEN rn <= 20              THEN tt_percent ELSE 0 END AS time_top,
         CASE WHEN rn > 20 AND rn <= 800 THEN tt_percent ELSE 0 END AS time_medium,
         CASE WHEN rn > 800              THEN tt_percent ELSE 0 END AS time_tail
  FROM (
    SELECT total_time / (SELECT sum(total_time) FROM pg_stat_statements) * 100 AS tt_percent, query,
    ROW_NUMBER () OVER (ORDER BY total_time DESC) AS rn
    FROM pg_stat_statements
    ORDER BY total_time DESC
  ) AS t
)
AS ts

ಪ್ರಶ್ನೆಯ ಫಲಿತಾಂಶವು ಮೂರು ಕಾಲಮ್‌ಗಳಾಗಿದ್ದು, ಪ್ರತಿಯೊಂದೂ ಈ ಗುಂಪಿನಿಂದ ಪ್ರಶ್ನೆಗಳನ್ನು ಪ್ರಕ್ರಿಯೆಗೊಳಿಸಲು ತೆಗೆದುಕೊಳ್ಳುವ ಶೇಕಡಾವಾರು ಸಮಯವನ್ನು ಒಳಗೊಂಡಿರುತ್ತದೆ. ವಿನಂತಿಯ ಒಳಗೆ ಎರಡು ಸಂಖ್ಯೆಗಳಿವೆ (ನನ್ನ ಸಂದರ್ಭದಲ್ಲಿ ಇದು 20 ಮತ್ತು 800) ಒಂದು ಗುಂಪಿನಿಂದ ಇನ್ನೊಂದು ಗುಂಪಿನಿಂದ ವಿನಂತಿಗಳನ್ನು ಪ್ರತ್ಯೇಕಿಸುತ್ತದೆ.

ಆಪ್ಟಿಮೈಸೇಶನ್ ಕೆಲಸ ಪ್ರಾರಂಭವಾದ ಸಮಯದಲ್ಲಿ ಮತ್ತು ಈಗ ವಿನಂತಿಗಳ ಷೇರುಗಳನ್ನು ಸ್ಥೂಲವಾಗಿ ಹೋಲಿಸುವುದು ಹೀಗೆ.

TOP ವಿನಂತಿಗಳ ಪಾಲು ತೀವ್ರವಾಗಿ ಕಡಿಮೆಯಾಗಿದೆ ಎಂದು ರೇಖಾಚಿತ್ರವು ತೋರಿಸುತ್ತದೆ, ಆದರೆ "ಮಧ್ಯಮ ರೈತರು" ಹೆಚ್ಚಾಗಿದೆ.
ಮೊದಲಿಗೆ, TOP ವಿನಂತಿಗಳು ಘೋರ ಪ್ರಮಾದಗಳನ್ನು ಒಳಗೊಂಡಿತ್ತು. ಕಾಲಾನಂತರದಲ್ಲಿ, ಬಾಲ್ಯದ ಕಾಯಿಲೆಗಳು ಕಣ್ಮರೆಯಾಯಿತು, TOP ವಿನಂತಿಗಳ ಪಾಲು ಕಡಿಮೆಯಾಯಿತು ಮತ್ತು ಕಷ್ಟಕರವಾದ ವಿನಂತಿಗಳನ್ನು ವೇಗಗೊಳಿಸಲು ಹೆಚ್ಚು ಹೆಚ್ಚು ಪ್ರಯತ್ನಗಳನ್ನು ಮಾಡಬೇಕಾಗಿತ್ತು.

ವಿನಂತಿಗಳ ಪಠ್ಯವನ್ನು ಪಡೆಯಲು ನಾವು ಈ ಕೆಳಗಿನ ವಿನಂತಿಯನ್ನು ಬಳಸುತ್ತೇವೆ

SELECT * FROM (
  SELECT ROW_NUMBER () OVER (ORDER BY total_time DESC) AS rn, total_time / (SELECT sum(total_time) FROM pg_stat_statements) * 100 AS tt_percent, query
  FROM pg_stat_statements
  ORDER BY total_time DESC
) AS T
WHERE
rn <= 20 -- TOP
-- rn > 20 AND rn <= 800 -- MEDIUM
-- rn > 800  -- TAIL

TOP ಪ್ರಶ್ನೆಗಳನ್ನು ವೇಗಗೊಳಿಸಲು ನಮಗೆ ಸಹಾಯ ಮಾಡಿದ ಸಾಮಾನ್ಯವಾಗಿ ಬಳಸುವ ತಂತ್ರಗಳ ಪಟ್ಟಿ ಇಲ್ಲಿದೆ:

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

ಕೆಲವೊಮ್ಮೆ ಬದಲಾವಣೆಗಳು ಪ್ರಭಾವಶಾಲಿ ಮರುವಿನ್ಯಾಸಕ್ಕೆ ಅನುಗುಣವಾಗಿರುತ್ತವೆ, ಆದರೆ ಅವು ಸಿಸ್ಟಮ್ ಲೋಡ್ನ 5-10% ಅನ್ನು ಒದಗಿಸಿದವು ಮತ್ತು ಸಮರ್ಥಿಸಲ್ಪಟ್ಟವು. ಕಾಲಾನಂತರದಲ್ಲಿ, ನಿಷ್ಕಾಸವು ಚಿಕ್ಕದಾಗಿದೆ ಮತ್ತು ಚಿಕ್ಕದಾಗಿದೆ, ಮತ್ತು ಹೆಚ್ಚು ಹೆಚ್ಚು ಗಂಭೀರವಾದ ಮರುವಿನ್ಯಾಸ ಅಗತ್ಯವಿತ್ತು.

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

• COUNT ಮತ್ತು ಪೂರ್ಣ ಟೇಬಲ್ ಸ್ಕ್ಯಾನ್ ಅನ್ನು ಬಳಸಿಕೊಂಡು ದಾಖಲೆಗಳ ಉಪಸ್ಥಿತಿಯನ್ನು ಪರಿಶೀಲಿಸುವ ಬದಲು, EXISTS ಅನ್ನು ಬಳಸಲು ಪ್ರಾರಂಭಿಸಿತು
• DISTINCT ಅನ್ನು ತೊಡೆದುಹಾಕಲಾಗಿದೆ (ಯಾವುದೇ ಸಾಮಾನ್ಯ ಪಾಕವಿಧಾನವಿಲ್ಲ, ಆದರೆ ಕೆಲವೊಮ್ಮೆ ನೀವು ವಿನಂತಿಯನ್ನು 10-100 ಬಾರಿ ವೇಗಗೊಳಿಸುವ ಮೂಲಕ ಅದನ್ನು ಸುಲಭವಾಗಿ ತೊಡೆದುಹಾಕಬಹುದು).

  ಉದಾಹರಣೆಗೆ, ದೊಡ್ಡ ಡೆಲಿವರಿ ಟೇಬಲ್‌ನಿಂದ ಎಲ್ಲಾ ಡ್ರೈವರ್‌ಗಳನ್ನು ಆಯ್ಕೆ ಮಾಡುವ ಪ್ರಶ್ನೆಯ ಬದಲಿಗೆ (ಡೆಲಿವರಿ)

  SELECT DISTINCT P.ID, P.FIRST_NAME, P.LAST_NAME
  FROM DELIVERY D JOIN PERSON P ON D.DRIVER_ID = P.ID
  

  ತುಲನಾತ್ಮಕವಾಗಿ ಸಣ್ಣ ಟೇಬಲ್ ವ್ಯಕ್ತಿ ಮೇಲೆ ಪ್ರಶ್ನೆಯನ್ನು ಮಾಡಿದೆ

  SELECT P.ID, P.FIRST_NAME, P.LAST_NAME
  FROM PERSON
  WHERE EXISTS(SELECT D.ID FROM DELIVERY WHERE D.DRIVER_ID = P.ID)
  

  ನಾವು ಪರಸ್ಪರ ಸಂಬಂಧಿತ ಉಪಪ್ರಶ್ನೆಯನ್ನು ಬಳಸಿದ್ದೇವೆ ಎಂದು ತೋರುತ್ತದೆ, ಆದರೆ ಇದು 10 ಪಟ್ಟು ಹೆಚ್ಚು ವೇಗವನ್ನು ನೀಡುತ್ತದೆ.

• ಅನೇಕ ಸಂದರ್ಭಗಳಲ್ಲಿ, COUNT ಅನ್ನು ಸಂಪೂರ್ಣವಾಗಿ ಕೈಬಿಡಲಾಗಿದೆ ಮತ್ತು
  ಅಂದಾಜು ಮೌಲ್ಯದ ಲೆಕ್ಕಾಚಾರದಿಂದ ಬದಲಾಯಿಸಲಾಗಿದೆ
• вместо

  UPPER(s) LIKE JOHN%’ 
  

  ಬಳಕೆ

  s ILIKE “John%”
  

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

ಪರಿಣಾಮವಾಗಿ, ನಾವು ಈಗ ಮೂರು ವರ್ಷಗಳಿಂದ ಅದೇ ಹಾರ್ಡ್‌ವೇರ್‌ನಲ್ಲಿ ಕೆಲಸ ಮಾಡುತ್ತಿದ್ದೇವೆ. ಸರಾಸರಿ ದೈನಂದಿನ ಲೋಡ್ ಸುಮಾರು 30%, ಗರಿಷ್ಠಗಳಲ್ಲಿ ಇದು 70% ತಲುಪುತ್ತದೆ. ವಿನಂತಿಗಳ ಸಂಖ್ಯೆ, ಹಾಗೆಯೇ ಬಳಕೆದಾರರ ಸಂಖ್ಯೆಯು ಸರಿಸುಮಾರು 10 ಪಟ್ಟು ಹೆಚ್ಚಾಗಿದೆ. ಮತ್ತು ಟಾಪ್-ಮೀಡಿಯಂ ವಿನಂತಿಗಳ ಇದೇ ಗುಂಪುಗಳ ನಿರಂತರ ಮೇಲ್ವಿಚಾರಣೆಗೆ ಈ ಎಲ್ಲಾ ಧನ್ಯವಾದಗಳು. TOP ಗುಂಪಿನಲ್ಲಿ ಹೊಸ ವಿನಂತಿಯು ಕಾಣಿಸಿಕೊಂಡ ತಕ್ಷಣ, ನಾವು ಅದನ್ನು ತಕ್ಷಣವೇ ವಿಶ್ಲೇಷಿಸುತ್ತೇವೆ ಮತ್ತು ಅದನ್ನು ವೇಗಗೊಳಿಸಲು ಪ್ರಯತ್ನಿಸುತ್ತೇವೆ. ಪ್ರಶ್ನೆ ವಿಶ್ಲೇಷಣೆ ಸ್ಕ್ರಿಪ್ಟ್‌ಗಳನ್ನು ಬಳಸಿಕೊಂಡು ನಾವು ವಾರಕ್ಕೊಮ್ಮೆ MEDIUM ಗುಂಪನ್ನು ಪರಿಶೀಲಿಸುತ್ತೇವೆ. ಆಪ್ಟಿಮೈಜ್ ಮಾಡುವುದು ಹೇಗೆ ಎಂದು ನಮಗೆ ಈಗಾಗಲೇ ತಿಳಿದಿರುವ ಹೊಸ ಪ್ರಶ್ನೆಗಳನ್ನು ನಾವು ಕಂಡರೆ, ನಾವು ಅವುಗಳನ್ನು ತ್ವರಿತವಾಗಿ ಬದಲಾಯಿಸುತ್ತೇವೆ. ಕೆಲವೊಮ್ಮೆ ಹಲವಾರು ಪ್ರಶ್ನೆಗಳಿಗೆ ಏಕಕಾಲದಲ್ಲಿ ಅನ್ವಯಿಸಬಹುದಾದ ಹೊಸ ಆಪ್ಟಿಮೈಸೇಶನ್ ವಿಧಾನಗಳನ್ನು ನಾವು ಕಂಡುಕೊಳ್ಳುತ್ತೇವೆ.

ನಮ್ಮ ಮುನ್ಸೂಚನೆಗಳ ಪ್ರಕಾರ, ಪ್ರಸ್ತುತ ಸರ್ವರ್ ಬಳಕೆದಾರರ ಸಂಖ್ಯೆಯಲ್ಲಿ ಮತ್ತೊಂದು 3-5 ಪಟ್ಟು ಹೆಚ್ಚಳವನ್ನು ತಡೆದುಕೊಳ್ಳುತ್ತದೆ. ನಿಜ, ನಮ್ಮ ಸ್ಲೀವ್ ಇನ್ನೂ ಒಂದು ಏಸ್ ಅಪ್ ಅನ್ನು ನಾವು ಹೊಂದಿದ್ದೇವೆ - ಶಿಫಾರಸು ಮಾಡಿದಂತೆ ನಾವು ಇನ್ನೂ SELECT ಪ್ರಶ್ನೆಗಳನ್ನು ಕನ್ನಡಿಗೆ ವರ್ಗಾಯಿಸಿಲ್ಲ. ಆದರೆ ನಾವು ಇದನ್ನು ಪ್ರಜ್ಞಾಪೂರ್ವಕವಾಗಿ ಮಾಡುವುದಿಲ್ಲ, ಏಕೆಂದರೆ "ಹೆವಿ ಫಿರಂಗಿ" ಅನ್ನು ಆನ್ ಮಾಡುವ ಮೊದಲು "ಸ್ಮಾರ್ಟ್" ಆಪ್ಟಿಮೈಸೇಶನ್ನ ಸಾಧ್ಯತೆಗಳನ್ನು ನಾವು ಮೊದಲು ಸಂಪೂರ್ಣವಾಗಿ ಖಾಲಿ ಮಾಡಲು ಬಯಸುತ್ತೇವೆ.
ಮಾಡಿದ ಕೆಲಸದ ವಿಮರ್ಶಾತ್ಮಕ ನೋಟವು ಲಂಬ ಸ್ಕೇಲಿಂಗ್ ಅನ್ನು ಬಳಸುವುದನ್ನು ಸೂಚಿಸಬಹುದು. ತಜ್ಞರ ಸಮಯವನ್ನು ವ್ಯರ್ಥ ಮಾಡುವ ಬದಲು ಹೆಚ್ಚು ಶಕ್ತಿಶಾಲಿ ಸರ್ವರ್ ಅನ್ನು ಖರೀದಿಸಿ. ಸರ್ವರ್‌ಗೆ ಹೆಚ್ಚು ವೆಚ್ಚವಾಗದಿರಬಹುದು, ವಿಶೇಷವಾಗಿ ನಾವು ಇನ್ನೂ ಲಂಬ ಸ್ಕೇಲಿಂಗ್‌ನ ಮಿತಿಗಳನ್ನು ದಣಿದಿಲ್ಲದ ಕಾರಣ. ಆದರೆ, ಮನವಿಗಳ ಸಂಖ್ಯೆ ಮಾತ್ರ 10 ಪಟ್ಟು ಹೆಚ್ಚಾಗಿದೆ. ಹಲವಾರು ವರ್ಷಗಳ ಅವಧಿಯಲ್ಲಿ, ಸಿಸ್ಟಮ್ನ ಕ್ರಿಯಾತ್ಮಕತೆಯು ಹೆಚ್ಚಾಗಿದೆ ಮತ್ತು ಈಗ ಹೆಚ್ಚಿನ ರೀತಿಯ ವಿನಂತಿಗಳಿವೆ. ಹಿಡಿದಿಟ್ಟುಕೊಳ್ಳುವಿಕೆಗೆ ಧನ್ಯವಾದಗಳು, ಅಸ್ತಿತ್ವದಲ್ಲಿರುವ ಕಾರ್ಯವನ್ನು ಕಡಿಮೆ ವಿನಂತಿಗಳಲ್ಲಿ ಮತ್ತು ಹೆಚ್ಚು ಪರಿಣಾಮಕಾರಿ ವಿನಂತಿಗಳಲ್ಲಿ ನಿರ್ವಹಿಸಲಾಗುತ್ತದೆ. ನಿಜವಾದ ವೇಗವರ್ಧಕ ಗುಣಾಂಕವನ್ನು ಪಡೆಯಲು ನೀವು ಸುರಕ್ಷಿತವಾಗಿ ಇನ್ನೊಂದು 5 ರಿಂದ ಗುಣಿಸಬಹುದು ಎಂದರ್ಥ. ಆದ್ದರಿಂದ, ಅತ್ಯಂತ ಸಂಪ್ರದಾಯವಾದಿ ಅಂದಾಜಿನ ಪ್ರಕಾರ, ವೇಗವರ್ಧನೆಯು 50 ಪಟ್ಟು ಅಥವಾ ಅದಕ್ಕಿಂತ ಹೆಚ್ಚು ಎಂದು ನಾವು ಹೇಳಬಹುದು. ಸರ್ವರ್ ಅನ್ನು ಲಂಬವಾಗಿ ಸ್ವಿಂಗ್ ಮಾಡಲು 50 ಪಟ್ಟು ಹೆಚ್ಚು ವೆಚ್ಚವಾಗುತ್ತದೆ. ವಿಶೇಷವಾಗಿ ಒಮ್ಮೆ ಆಪ್ಟಿಮೈಸೇಶನ್ ಅನ್ನು ಕೈಗೊಂಡರೆ ಅದು ಸಾರ್ವಕಾಲಿಕ ಕೆಲಸ ಮಾಡುತ್ತದೆ ಮತ್ತು ಬಾಡಿಗೆ ಸರ್ವರ್‌ನ ಬಿಲ್ ಪ್ರತಿ ತಿಂಗಳು ಬರುತ್ತದೆ.

ಮೂಲ: www.habr.com