PostgreSQL ಪ್ರಶ್ನೆಗಳ ಬೃಹತ್ ಆಪ್ಟಿಮೈಸೇಶನ್. ಕಿರಿಲ್ ಬೊರೊವಿಕೋವ್ (ಟೆನ್ಸರ್)

ವರದಿಯು ಅನುಮತಿಸುವ ಕೆಲವು ವಿಧಾನಗಳನ್ನು ಪ್ರಸ್ತುತಪಡಿಸುತ್ತದೆ SQL ಪ್ರಶ್ನೆಗಳು ದಿನಕ್ಕೆ ಲಕ್ಷಾಂತರ ಇದ್ದಾಗ ಅವುಗಳ ಕಾರ್ಯಕ್ಷಮತೆಯನ್ನು ಮೇಲ್ವಿಚಾರಣೆ ಮಾಡಿ, ಮತ್ತು ನೂರಾರು ಮೇಲ್ವಿಚಾರಣೆ PostgreSQL ಸರ್ವರ್‌ಗಳಿವೆ.

ಅಂತಹ ಮಾಹಿತಿಯ ಪರಿಮಾಣವನ್ನು ಪರಿಣಾಮಕಾರಿಯಾಗಿ ಪ್ರಕ್ರಿಯೆಗೊಳಿಸಲು ಯಾವ ತಾಂತ್ರಿಕ ಪರಿಹಾರಗಳು ನಮಗೆ ಅವಕಾಶ ಮಾಡಿಕೊಡುತ್ತವೆ ಮತ್ತು ಇದು ಸಾಮಾನ್ಯ ಡೆವಲಪರ್‌ನ ಜೀವನವನ್ನು ಹೇಗೆ ಸುಲಭಗೊಳಿಸುತ್ತದೆ?

ಯಾರು ಆಸಕ್ತಿ ಹೊಂದಿದ್ದಾರೆ? ನಿರ್ದಿಷ್ಟ ಸಮಸ್ಯೆಗಳ ವಿಶ್ಲೇಷಣೆ ಮತ್ತು ವಿವಿಧ ಆಪ್ಟಿಮೈಸೇಶನ್ ತಂತ್ರಗಳು PostgreSQL ನಲ್ಲಿ SQL ಪ್ರಶ್ನೆಗಳು ಮತ್ತು ವಿಶಿಷ್ಟ DBA ಸಮಸ್ಯೆಗಳನ್ನು ಪರಿಹರಿಸುವುದು - ನೀವು ಸಹ ಮಾಡಬಹುದು ಲೇಖನಗಳ ಸರಣಿಯನ್ನು ಓದಿ ಈ ವಿಷಯದ ಮೇಲೆ.


ನನ್ನ ಹೆಸರು ಕಿರಿಲ್ ಬೊರೊವಿಕೋವ್, ನಾನು ಪ್ರತಿನಿಧಿಸುತ್ತೇನೆ ಟೆನ್ಸರ್ ಕಂಪನಿ. ನಿರ್ದಿಷ್ಟವಾಗಿ ಹೇಳುವುದಾದರೆ, ನಮ್ಮ ಕಂಪನಿಯಲ್ಲಿ ಡೇಟಾಬೇಸ್‌ಗಳೊಂದಿಗೆ ಕೆಲಸ ಮಾಡಲು ನಾನು ಪರಿಣತಿ ಹೊಂದಿದ್ದೇನೆ.

ಒಂದೇ ಪ್ರಶ್ನೆಯ ಕಾರ್ಯಕ್ಷಮತೆಯನ್ನು ನೀವು "ಬೇರ್ಪಡಿಸುವ" ಅಗತ್ಯವಿಲ್ಲದಿದ್ದಾಗ, ನಾವು ಪ್ರಶ್ನೆಗಳನ್ನು ಹೇಗೆ ಆಪ್ಟಿಮೈಜ್ ಮಾಡುತ್ತೇವೆ ಎಂದು ಇಂದು ನಾನು ನಿಮಗೆ ಹೇಳುತ್ತೇನೆ, ಆದರೆ ಸಮಸ್ಯೆಯನ್ನು ಸಾಮೂಹಿಕವಾಗಿ ಪರಿಹರಿಸಿ. ಲಕ್ಷಾಂತರ ವಿನಂತಿಗಳು ಇದ್ದಾಗ ಮತ್ತು ನೀವು ಕೆಲವನ್ನು ಕಂಡುಹಿಡಿಯಬೇಕು ಪರಿಹಾರದ ವಿಧಾನಗಳು ಈ ದೊಡ್ಡ ಸಮಸ್ಯೆ.

ಸಾಮಾನ್ಯವಾಗಿ, ನಮ್ಮ ಲಕ್ಷಾಂತರ ಕ್ಲೈಂಟ್‌ಗಳಿಗೆ ಟೆನ್ಸರ್ ಆಗಿದೆ VLSI ನಮ್ಮ ಅಪ್ಲಿಕೇಶನ್ ಆಗಿದೆ: ಕಾರ್ಪೊರೇಟ್ ಸಾಮಾಜಿಕ ನೆಟ್‌ವರ್ಕ್, ವೀಡಿಯೊ ಸಂವಹನಕ್ಕಾಗಿ ಪರಿಹಾರಗಳು, ಆಂತರಿಕ ಮತ್ತು ಬಾಹ್ಯ ಡಾಕ್ಯುಮೆಂಟ್ ಹರಿವಿಗಾಗಿ, ಲೆಕ್ಕಪತ್ರ ನಿರ್ವಹಣೆ ಮತ್ತು ಗೋದಾಮುಗಳಿಗೆ ಲೆಕ್ಕಪರಿಶೋಧಕ ವ್ಯವಸ್ಥೆಗಳು,... ಅಂದರೆ, ಸಂಯೋಜಿತ ವ್ಯವಹಾರ ನಿರ್ವಹಣೆಗಾಗಿ ಅಂತಹ “ಮೆಗಾ-ಸಂಯೋಜಿತ”, ಇದರಲ್ಲಿ 100 ಕ್ಕಿಂತ ಹೆಚ್ಚು ವಿಭಿನ್ನವಾಗಿವೆ ಆಂತರಿಕ ಯೋಜನೆಗಳು.

ಅವರೆಲ್ಲರೂ ಸಾಮಾನ್ಯವಾಗಿ ಕೆಲಸ ಮಾಡುತ್ತಾರೆ ಮತ್ತು ಅಭಿವೃದ್ಧಿ ಹೊಂದುತ್ತಾರೆ ಎಂದು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳಲು, ನಾವು ದೇಶಾದ್ಯಂತ 10 ಅಭಿವೃದ್ಧಿ ಕೇಂದ್ರಗಳನ್ನು ಹೊಂದಿದ್ದೇವೆ, ಅವುಗಳಲ್ಲಿ ಹೆಚ್ಚಿನವುಗಳಿವೆ 1000 ಡೆವಲಪರ್‌ಗಳು.

ನಾವು 2008 ರಿಂದ PostgreSQL ನೊಂದಿಗೆ ಕೆಲಸ ಮಾಡುತ್ತಿದ್ದೇವೆ ಮತ್ತು ನಾವು ಪ್ರಕ್ರಿಯೆಗೊಳಿಸುವುದರಲ್ಲಿ ಹೆಚ್ಚಿನ ಮೊತ್ತವನ್ನು ಸಂಗ್ರಹಿಸಿದ್ದೇವೆ - ಕ್ಲೈಂಟ್ ಡೇಟಾ, ಸಂಖ್ಯಾಶಾಸ್ತ್ರ, ವಿಶ್ಲೇಷಣಾತ್ಮಕ, ಬಾಹ್ಯ ಮಾಹಿತಿ ವ್ಯವಸ್ಥೆಗಳಿಂದ ಡೇಟಾ - 400TB ಗಿಂತ ಹೆಚ್ಚು. ಉತ್ಪಾದನೆಯಲ್ಲಿಯೇ ಸುಮಾರು 250 ಸರ್ವರ್‌ಗಳಿವೆ ಮತ್ತು ಒಟ್ಟಾರೆಯಾಗಿ ನಾವು ಮೇಲ್ವಿಚಾರಣೆ ಮಾಡುವ ಸುಮಾರು 1000 ಡೇಟಾಬೇಸ್ ಸರ್ವರ್‌ಗಳಿವೆ.

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

ಕೆಲವು DBMS ಗಳು ಸುಳಿವುಗಳನ್ನು ಸ್ವೀಕರಿಸುತ್ತವೆ: "ಇಲ್ಲ, ಈ ಎರಡು ಕೋಷ್ಟಕಗಳನ್ನು ಅಂತಹ ಮತ್ತು ಅಂತಹ ಸರದಿಯಲ್ಲಿ ಸಂಪರ್ಕಿಸಿ," ಆದರೆ PostgreSQL ಇದನ್ನು ಮಾಡಲು ಸಾಧ್ಯವಿಲ್ಲ. ಇದು ಪ್ರಮುಖ ಡೆವಲಪರ್‌ಗಳ ಪ್ರಜ್ಞಾಪೂರ್ವಕ ಸ್ಥಾನವಾಗಿದೆ: "ಕೆಲವು ರೀತಿಯ ಸುಳಿವುಗಳನ್ನು ಬಳಸಲು ಡೆವಲಪರ್‌ಗಳಿಗೆ ಅವಕಾಶ ನೀಡುವ ಬದಲು ನಾವು ಪ್ರಶ್ನೆ ಆಪ್ಟಿಮೈಜರ್ ಅನ್ನು ಪೂರ್ಣಗೊಳಿಸುತ್ತೇವೆ."

ಆದರೆ, PostgreSQL "ಹೊರಗೆ" ತನ್ನನ್ನು ತಾನೇ ನಿಯಂತ್ರಿಸಲು ಅನುಮತಿಸುವುದಿಲ್ಲ ಎಂಬ ವಾಸ್ತವದ ಹೊರತಾಗಿಯೂ, ಅದು ಸಂಪೂರ್ಣವಾಗಿ ಅನುಮತಿಸುತ್ತದೆ ಅವನೊಳಗೆ ಏನು ನಡೆಯುತ್ತಿದೆ ಎಂದು ನೋಡಿನಿಮ್ಮ ಪ್ರಶ್ನೆಯನ್ನು ನೀವು ಚಲಾಯಿಸಿದಾಗ ಮತ್ತು ಅದು ಎಲ್ಲಿ ಸಮಸ್ಯೆಗಳನ್ನು ಹೊಂದಿದೆ.

ಸಾಮಾನ್ಯವಾಗಿ, ಡೆವಲಪರ್ [DBA ಗೆ] ಸಾಮಾನ್ಯವಾಗಿ ಯಾವ ಕ್ಲಾಸಿಕ್ ಸಮಸ್ಯೆಗಳೊಂದಿಗೆ ಬರುತ್ತಾರೆ? "ಇಲ್ಲಿ ನಾವು ವಿನಂತಿಯನ್ನು ಪೂರೈಸಿದ್ದೇವೆ ಮತ್ತು ಎಲ್ಲವೂ ನಮ್ಮೊಂದಿಗೆ ನಿಧಾನವಾಗಿದೆ, ಎಲ್ಲವೂ ನೇತಾಡುತ್ತಿದೆ, ಏನೋ ನಡೆಯುತ್ತಿದೆ ... ಕೆಲವು ರೀತಿಯ ತೊಂದರೆ!”

ಕಾರಣಗಳು ಯಾವಾಗಲೂ ಒಂದೇ ಆಗಿರುತ್ತವೆ:

• ಅಸಮರ್ಥ ಪ್ರಶ್ನೆ ಅಲ್ಗಾರಿದಮ್
  ಡೆವಲಪರ್: "ಈಗ ನಾನು ಅವನಿಗೆ SQL ನಲ್ಲಿ 10 ಟೇಬಲ್‌ಗಳನ್ನು JOIN ಮೂಲಕ ನೀಡುತ್ತಿದ್ದೇನೆ..." - ಮತ್ತು ಅವನ ಪರಿಸ್ಥಿತಿಗಳು ಅದ್ಭುತವಾಗಿ "ಬಿಚ್ಚಿ" ಎಂದು ನಿರೀಕ್ಷಿಸುತ್ತದೆ ಮತ್ತು ಅವನು ಎಲ್ಲವನ್ನೂ ತ್ವರಿತವಾಗಿ ಪಡೆಯುತ್ತಾನೆ. ಆದರೆ ಪವಾಡಗಳು ಸಂಭವಿಸುವುದಿಲ್ಲ, ಮತ್ತು ಅಂತಹ ವ್ಯತ್ಯಾಸವನ್ನು ಹೊಂದಿರುವ ಯಾವುದೇ ವ್ಯವಸ್ಥೆಯು (ಒಂದರಿಂದ 10 ಕೋಷ್ಟಕಗಳು) ಯಾವಾಗಲೂ ಕೆಲವು ರೀತಿಯ ದೋಷವನ್ನು ನೀಡುತ್ತದೆ. [ಲೇಖನ]
• ಹಳೆಯ ಅಂಕಿಅಂಶಗಳು
  ಈ ಅಂಶವು ವಿಶೇಷವಾಗಿ PostgreSQL ಗೆ ಬಹಳ ಪ್ರಸ್ತುತವಾಗಿದೆ, ನೀವು ಸರ್ವರ್‌ನಲ್ಲಿ ದೊಡ್ಡ ಡೇಟಾಸೆಟ್ ಅನ್ನು "ಸುರಿಸಿದಾಗ", ವಿನಂತಿಯನ್ನು ಮಾಡಿ ಮತ್ತು ಅದು ನಿಮ್ಮ ಟ್ಯಾಬ್ಲೆಟ್ ಅನ್ನು "ಸೆಕ್ಸ್‌ಕಾನಿಟ್" ಮಾಡುತ್ತದೆ. ಏಕೆಂದರೆ ನಿನ್ನೆ ಅದರಲ್ಲಿ 10 ದಾಖಲೆಗಳಿವೆ, ಮತ್ತು ಇಂದು 10 ಮಿಲಿಯನ್ ಇವೆ, ಆದರೆ PostgreSQL ಗೆ ಇನ್ನೂ ಇದರ ಬಗ್ಗೆ ತಿಳಿದಿಲ್ಲ ಮತ್ತು ನಾವು ಅದರ ಬಗ್ಗೆ ಹೇಳಬೇಕಾಗಿದೆ. [ಲೇಖನ]
• ಸಂಪನ್ಮೂಲಗಳ ಮೇಲೆ "ಪ್ಲಗ್"
  ನೀವು ಸಾಕಷ್ಟು ಡಿಸ್ಕ್, ಮೆಮೊರಿ ಅಥವಾ ಪ್ರೊಸೆಸರ್ ಕಾರ್ಯಕ್ಷಮತೆಯನ್ನು ಹೊಂದಿರದ ದುರ್ಬಲ ಸರ್ವರ್‌ನಲ್ಲಿ ದೊಡ್ಡ ಮತ್ತು ಹೆಚ್ಚು ಲೋಡ್ ಮಾಡಲಾದ ಡೇಟಾಬೇಸ್ ಅನ್ನು ಸ್ಥಾಪಿಸಿದ್ದೀರಿ. ಮತ್ತು ಅಷ್ಟೆ... ಎಲ್ಲೋ ಒಂದು ಕಾರ್ಯಕ್ಷಮತೆಯ ಸೀಲಿಂಗ್ ಇದೆ, ಅದರ ಮೇಲೆ ನೀವು ಇನ್ನು ಮುಂದೆ ಜಿಗಿತವನ್ನು ಮಾಡಲಾಗುವುದಿಲ್ಲ.
• ತಡೆಯುವುದು
  ಇದು ಕಷ್ಟಕರವಾದ ಅಂಶವಾಗಿದೆ, ಆದರೆ ವಿವಿಧ ಮಾರ್ಪಡಿಸುವ ಪ್ರಶ್ನೆಗಳಿಗೆ ಅವು ಹೆಚ್ಚು ಪ್ರಸ್ತುತವಾಗಿವೆ (ಇನ್ಸರ್ಟ್, ಅಪ್‌ಡೇಟ್, ಡಿಲೀಟ್) - ಇದು ಪ್ರತ್ಯೇಕ ದೊಡ್ಡ ವಿಷಯವಾಗಿದೆ.

ಯೋಜನೆಯನ್ನು ಪಡೆಯಲಾಗುತ್ತಿದೆ

ಮತ್ತು ಎಲ್ಲದಕ್ಕೂ ನಾವು ಒಂದು ಯೋಜನೆ ಬೇಕು! ಸರ್ವರ್ ಒಳಗೆ ಏನಾಗುತ್ತಿದೆ ಎಂದು ನೋಡಬೇಕು.

PostgreSQL ಗಾಗಿ ಒಂದು ಕ್ವೆರಿ ಎಕ್ಸಿಕ್ಯೂಶನ್ ಪ್ಲಾನ್ ಎನ್ನುವುದು ಪಠ್ಯ ಪ್ರಾತಿನಿಧ್ಯದಲ್ಲಿ ಕ್ವೆರಿ ಎಕ್ಸಿಕ್ಯೂಶನ್ ಅಲ್ಗಾರಿದಮ್‌ನ ಒಂದು ವೃಕ್ಷವಾಗಿದೆ. ಇದು ನಿಖರವಾಗಿ ಅಲ್ಗಾರಿದಮ್ ಆಗಿದೆ, ಯೋಜಕರ ವಿಶ್ಲೇಷಣೆಯ ಪರಿಣಾಮವಾಗಿ, ಅತ್ಯಂತ ಪರಿಣಾಮಕಾರಿ ಎಂದು ಕಂಡುಬಂದಿದೆ.

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

ಪ್ರಶ್ನೆ ಯೋಜನೆಯನ್ನು ಪಡೆಯಲು, ಹೇಳಿಕೆಯನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸುವುದು ಸುಲಭವಾದ ಮಾರ್ಗವಾಗಿದೆ EXPLAIN. ಎಲ್ಲಾ ನೈಜ ಗುಣಲಕ್ಷಣಗಳೊಂದಿಗೆ ಪಡೆಯಲು, ಅಂದರೆ, ಆಧಾರದಲ್ಲಿ ಪ್ರಶ್ನೆಯನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸಲು - EXPLAIN (ANALYZE, BUFFERS) SELECT ....

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

ಸರ್ವರ್‌ನಲ್ಲಿ ವಿನಂತಿಯನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸಿದ ಕ್ಷಣದಲ್ಲಿ ನಿಖರವಾಗಿ ಏನಾಯಿತು ಎಂಬುದನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳಲು, ಸ್ಮಾರ್ಟ್ ಜನರು ಬರೆದಿದ್ದಾರೆ auto_explain ಮಾಡ್ಯೂಲ್. ಇದು ಬಹುತೇಕ ಎಲ್ಲಾ ಸಾಮಾನ್ಯ PostgreSQL ವಿತರಣೆಗಳಲ್ಲಿ ಇರುತ್ತದೆ ಮತ್ತು ಸಂರಚನಾ ಕಡತದಲ್ಲಿ ಸರಳವಾಗಿ ಸಕ್ರಿಯಗೊಳಿಸಬಹುದು.

ಕೆಲವು ವಿನಂತಿಯು ನೀವು ಹೇಳಿದ ಮಿತಿಗಿಂತ ಹೆಚ್ಚು ಕಾಲ ಚಾಲನೆಯಲ್ಲಿದೆ ಎಂದು ಅದು ಅರಿತುಕೊಂಡರೆ, ಅದು ಮಾಡುತ್ತದೆ ಈ ವಿನಂತಿಯ ಯೋಜನೆಯ "ಸ್ನ್ಯಾಪ್‌ಶಾಟ್" ಮತ್ತು ಅವುಗಳನ್ನು ಲಾಗ್‌ನಲ್ಲಿ ಒಟ್ಟಿಗೆ ಬರೆಯುತ್ತದೆ.

ಈಗ ಎಲ್ಲವೂ ಸರಿಯಾಗಿದೆ ಎಂದು ತೋರುತ್ತದೆ, ನಾವು ಲಾಗ್‌ಗೆ ಹೋಗಿ ಅಲ್ಲಿ ನೋಡುತ್ತೇವೆ ... [ಪಠ್ಯ ಪಾದದ ಬಟ್ಟೆ]. ಆದರೆ ನಾವು ಅದರ ಬಗ್ಗೆ ಏನನ್ನೂ ಹೇಳಲು ಸಾಧ್ಯವಿಲ್ಲ, ಇದು ಅತ್ಯುತ್ತಮವಾದ ಯೋಜನೆಯಾಗಿದೆ ಏಕೆಂದರೆ ಇದು ಕಾರ್ಯಗತಗೊಳಿಸಲು 11ms ತೆಗೆದುಕೊಂಡಿತು.

ಎಲ್ಲವೂ ಸರಿಯಾಗಿದೆ ಎಂದು ತೋರುತ್ತದೆ - ಆದರೆ ನಿಜವಾಗಿ ಏನಾಯಿತು ಎಂದು ಏನೂ ಸ್ಪಷ್ಟವಾಗಿಲ್ಲ. ಸಾಮಾನ್ಯ ಸಮಯವನ್ನು ಹೊರತುಪಡಿಸಿ, ನಾವು ನಿಜವಾಗಿಯೂ ಏನನ್ನೂ ನೋಡುವುದಿಲ್ಲ. ಏಕೆಂದರೆ ಸರಳ ಪಠ್ಯದ ಅಂತಹ "ಕುರಿಮರಿ" ಅನ್ನು ನೋಡುವುದು ಸಾಮಾನ್ಯವಾಗಿ ದೃಷ್ಟಿಗೋಚರವಾಗಿರುವುದಿಲ್ಲ.

ಆದರೆ ಇದು ಸ್ಪಷ್ಟವಾಗಿಲ್ಲದಿದ್ದರೂ, ಅನಾನುಕೂಲವಾಗಿದ್ದರೂ ಸಹ, ಹೆಚ್ಚು ಮೂಲಭೂತ ಸಮಸ್ಯೆಗಳಿವೆ:

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

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

ಆದರೆ ನಾವು 1000 ಡೆವಲಪರ್‌ಗಳನ್ನು ಹೊಂದಿದ್ದೇವೆ ಮತ್ತು ನೀವು ಪ್ರತಿಯೊಬ್ಬರಿಗೂ ಈ ಅನುಭವವನ್ನು ತಿಳಿಸಲು ಸಾಧ್ಯವಿಲ್ಲ. ನಾನು, ನೀವು, ಅವನಿಗೆ ತಿಳಿದಿದೆ, ಆದರೆ ಅಲ್ಲಿರುವ ಯಾರಿಗಾದರೂ ಇನ್ನು ಮುಂದೆ ತಿಳಿದಿಲ್ಲ. ಬಹುಶಃ ಅವನು ಕಲಿಯಬಹುದು, ಅಥವಾ ಇಲ್ಲದಿರಬಹುದು, ಆದರೆ ಅವನು ಈಗ ಕೆಲಸ ಮಾಡಬೇಕಾಗಿದೆ - ಮತ್ತು ಅವನು ಈ ಅನುಭವವನ್ನು ಎಲ್ಲಿ ಪಡೆಯುತ್ತಾನೆ?

ಯೋಜನೆ ದೃಶ್ಯೀಕರಣ

ಆದ್ದರಿಂದ, ಈ ಸಮಸ್ಯೆಗಳನ್ನು ಎದುರಿಸಲು ನಮಗೆ ಅಗತ್ಯವಿದೆ ಎಂದು ನಾವು ಅರಿತುಕೊಂಡಿದ್ದೇವೆ ಯೋಜನೆಯ ಉತ್ತಮ ದೃಶ್ಯೀಕರಣ. [ಲೇಖನ]

ನಾವು ಮೊದಲು "ಮಾರುಕಟ್ಟೆಯ ಮೂಲಕ" ಹೋಗಿದ್ದೇವೆ - ಅಸ್ತಿತ್ವದಲ್ಲಿದೆ ಎಂಬುದನ್ನು ನೋಡಲು ಇಂಟರ್ನೆಟ್ನಲ್ಲಿ ನೋಡೋಣ.

ಆದರೆ ಹೆಚ್ಚು ಅಥವಾ ಕಡಿಮೆ ಅಭಿವೃದ್ಧಿ ಹೊಂದುತ್ತಿರುವ ತುಲನಾತ್ಮಕವಾಗಿ ಕೆಲವೇ "ಲೈವ್" ಪರಿಹಾರಗಳಿವೆ ಎಂದು ಅದು ಬದಲಾಯಿತು - ಅಕ್ಷರಶಃ, ಕೇವಲ ಒಂದು: ವಿವರಿಸಿ.depesz.com ಹಬರ್ಟ್ ಲುಬಾಕ್ಜೆವ್ಸ್ಕಿ ಅವರಿಂದ. ನೀವು "ಫೀಡ್" ಕ್ಷೇತ್ರವನ್ನು ಯೋಜನೆಯ ಪಠ್ಯ ಪ್ರಾತಿನಿಧ್ಯವನ್ನು ನಮೂದಿಸಿದಾಗ, ಅದು ನಿಮಗೆ ಪಾರ್ಸ್ ಮಾಡಿದ ಡೇಟಾದೊಂದಿಗೆ ಟೇಬಲ್ ಅನ್ನು ತೋರಿಸುತ್ತದೆ:

• ನೋಡ್‌ನ ಸ್ವಂತ ಪ್ರಕ್ರಿಯೆಯ ಸಮಯ
• ಸಂಪೂರ್ಣ ಸಬ್ಟ್ರೀಗಾಗಿ ಒಟ್ಟು ಸಮಯ
• ಸಂಖ್ಯಾಶಾಸ್ತ್ರೀಯವಾಗಿ ನಿರೀಕ್ಷಿತ ದಾಖಲೆಗಳ ಸಂಖ್ಯೆಯನ್ನು ಮರುಪಡೆಯಲಾಗಿದೆ
• ನೋಡ್ ದೇಹವು ಸ್ವತಃ

ಈ ಸೇವೆಯು ಲಿಂಕ್‌ಗಳ ಆರ್ಕೈವ್ ಅನ್ನು ಹಂಚಿಕೊಳ್ಳುವ ಸಾಮರ್ಥ್ಯವನ್ನು ಸಹ ಹೊಂದಿದೆ. ನೀವು ನಿಮ್ಮ ಯೋಜನೆಯನ್ನು ಅಲ್ಲಿಗೆ ಎಸೆದಿದ್ದೀರಿ ಮತ್ತು ಹೇಳಿದರು: "ಹೇ, ವಾಸ್ಯಾ, ಇಲ್ಲಿ ಲಿಂಕ್ ಇದೆ, ಅಲ್ಲಿ ಏನೋ ತಪ್ಪಾಗಿದೆ."

ಆದರೆ ಸಣ್ಣ ಸಮಸ್ಯೆಗಳೂ ಇವೆ.

ಮೊದಲನೆಯದಾಗಿ, ಒಂದು ದೊಡ್ಡ ಪ್ರಮಾಣದ "ಕಾಪಿ-ಪೇಸ್ಟ್". ನೀವು ಲಾಗ್‌ನ ತುಂಡನ್ನು ತೆಗೆದುಕೊಂಡು, ಅದನ್ನು ಅಂಟಿಸಿ, ಮತ್ತು ಮತ್ತೆ, ಮತ್ತೆ.

ಎರಡನೆಯದಾಗಿ ಓದಿದ ಡೇಟಾದ ಪ್ರಮಾಣದ ವಿಶ್ಲೇಷಣೆ ಇಲ್ಲ - ಅದೇ ಬಫರ್ ಔಟ್ಪುಟ್ EXPLAIN (ANALYZE, BUFFERS), ನಾವು ಅದನ್ನು ಇಲ್ಲಿ ಕಾಣುವುದಿಲ್ಲ. ಅವುಗಳನ್ನು ಡಿಸ್ಅಸೆಂಬಲ್ ಮಾಡುವುದು, ಅರ್ಥಮಾಡಿಕೊಳ್ಳುವುದು ಮತ್ತು ಅವರೊಂದಿಗೆ ಕೆಲಸ ಮಾಡುವುದು ಹೇಗೆ ಎಂದು ಅವನಿಗೆ ತಿಳಿದಿಲ್ಲ. ನೀವು ಬಹಳಷ್ಟು ಡೇಟಾವನ್ನು ಓದುತ್ತಿರುವಾಗ ಮತ್ತು ನೀವು ಡಿಸ್ಕ್ ಮತ್ತು ಮೆಮೊರಿ ಸಂಗ್ರಹವನ್ನು ತಪ್ಪಾಗಿ ಹಂಚಿಕೆ ಮಾಡುತ್ತಿದ್ದೀರಿ ಎಂದು ತಿಳಿದುಕೊಂಡಾಗ, ಈ ಮಾಹಿತಿಯು ಬಹಳ ಮುಖ್ಯವಾಗಿದೆ.

ಮೂರನೆಯ ಋಣಾತ್ಮಕ ಅಂಶವೆಂದರೆ ಈ ಯೋಜನೆಯ ಅತ್ಯಂತ ದುರ್ಬಲ ಬೆಳವಣಿಗೆಯಾಗಿದೆ. ಕಮಿಟ್‌ಗಳು ತುಂಬಾ ಚಿಕ್ಕದಾಗಿದೆ, ಪ್ರತಿ ಆರು ತಿಂಗಳಿಗೊಮ್ಮೆ ಅದು ಒಳ್ಳೆಯದು ಮತ್ತು ಕೋಡ್ ಪರ್ಲ್‌ನಲ್ಲಿದ್ದರೆ.

ಆದರೆ ಇದೆಲ್ಲವೂ “ಸಾಹಿತ್ಯ”, ನಾವು ಹೇಗಾದರೂ ಇದರೊಂದಿಗೆ ಬದುಕಬಹುದು, ಆದರೆ ಈ ಸೇವೆಯಿಂದ ನಮ್ಮನ್ನು ದೂರವಿಡುವ ಒಂದು ವಿಷಯವಿದೆ. ಕಾಮನ್ ಟೇಬಲ್ ಎಕ್ಸ್‌ಪ್ರೆಶನ್ (CTE) ಮತ್ತು InitPlan/SubPlan ನಂತಹ ವಿವಿಧ ಡೈನಾಮಿಕ್ ನೋಡ್‌ಗಳ ವಿಶ್ಲೇಷಣೆಯಲ್ಲಿನ ದೋಷಗಳು ಇವು.

ಈ ಚಿತ್ರವನ್ನು ನೀವು ನಂಬಿದರೆ, ಪ್ರತಿಯೊಂದು ನೋಡ್‌ನ ಒಟ್ಟು ಕಾರ್ಯಗತಗೊಳಿಸುವ ಸಮಯವು ಸಂಪೂರ್ಣ ವಿನಂತಿಯ ಒಟ್ಟು ಕಾರ್ಯಗತಗೊಳಿಸುವ ಸಮಯಕ್ಕಿಂತ ಹೆಚ್ಚಾಗಿರುತ್ತದೆ. ಇದು ಸರಳವಾಗಿದೆ - ಈ CTE ಯ ಉತ್ಪಾದನೆಯ ಸಮಯವನ್ನು CTE ಸ್ಕ್ಯಾನ್ ನೋಡ್‌ನಿಂದ ಕಳೆಯಲಾಗಿಲ್ಲ. ಆದ್ದರಿಂದ, CTE ಸ್ಕ್ಯಾನ್ ಎಷ್ಟು ಸಮಯ ತೆಗೆದುಕೊಂಡಿತು ಎಂಬುದಕ್ಕೆ ಸರಿಯಾದ ಉತ್ತರ ನಮಗೆ ಇನ್ನು ಮುಂದೆ ತಿಳಿದಿಲ್ಲ.

ನಂತರ ನಾವು ನಮ್ಮದೇ ಆದದನ್ನು ಬರೆಯುವ ಸಮಯ ಎಂದು ಅರಿತುಕೊಂಡೆವು - ಹುರ್ರೇ! ಪ್ರತಿಯೊಬ್ಬ ಡೆವಲಪರ್ ಹೇಳುತ್ತಾರೆ: "ಈಗ ನಾವು ನಮ್ಮದೇ ಆದದನ್ನು ಬರೆಯುತ್ತೇವೆ, ಅದು ತುಂಬಾ ಸುಲಭವಾಗಿರುತ್ತದೆ!"

ನಾವು ವೆಬ್ ಸೇವೆಗಳಿಗೆ ವಿಶಿಷ್ಟವಾದ ಸ್ಟಾಕ್ ಅನ್ನು ತೆಗೆದುಕೊಂಡಿದ್ದೇವೆ: Node.js + ಎಕ್ಸ್‌ಪ್ರೆಸ್ ಆಧಾರಿತ ಕೋರ್, ಸುಂದರವಾದ ರೇಖಾಚಿತ್ರಗಳಿಗಾಗಿ ಬೂಟ್‌ಸ್ಟ್ರ್ಯಾಪ್ ಮತ್ತು D3.js ಅನ್ನು ಬಳಸಲಾಗಿದೆ. ಮತ್ತು ನಮ್ಮ ನಿರೀಕ್ಷೆಗಳನ್ನು ಸಂಪೂರ್ಣವಾಗಿ ಸಮರ್ಥಿಸಲಾಗಿದೆ - ನಾವು 2 ವಾರಗಳಲ್ಲಿ ಮೊದಲ ಮೂಲಮಾದರಿಯನ್ನು ಸ್ವೀಕರಿಸಿದ್ದೇವೆ:

• ಕಸ್ಟಮ್ ಯೋಜನೆ ಪಾರ್ಸರ್
  ಅಂದರೆ, ಈಗ ನಾವು PostgreSQL ನಿಂದ ರಚಿಸಲಾದ ಯಾವುದೇ ಯೋಜನೆಯನ್ನು ಪಾರ್ಸ್ ಮಾಡಬಹುದು.
• ಡೈನಾಮಿಕ್ ನೋಡ್ಗಳ ಸರಿಯಾದ ವಿಶ್ಲೇಷಣೆ - CTE ಸ್ಕ್ಯಾನ್, InitPlan, SubPlan
• ಬಫರ್ ವಿತರಣೆಯ ವಿಶ್ಲೇಷಣೆ - ಡೇಟಾ ಪುಟಗಳನ್ನು ಮೆಮೊರಿಯಿಂದ ಎಲ್ಲಿ ಓದಲಾಗುತ್ತದೆ, ಎಲ್ಲಿ ಸ್ಥಳೀಯ ಸಂಗ್ರಹದಿಂದ, ಎಲ್ಲಿ ಡಿಸ್ಕ್ನಿಂದ
• ಸ್ಪಷ್ಟತೆ ಸಿಕ್ಕಿತು
  ಆದ್ದರಿಂದ ಲಾಗ್‌ನಲ್ಲಿ ಇದೆಲ್ಲವನ್ನೂ "ಅಗೆಯಲು" ಅಲ್ಲ, ಆದರೆ ಚಿತ್ರದಲ್ಲಿ ಈಗಿನಿಂದಲೇ "ದುರ್ಬಲವಾದ ಲಿಂಕ್" ಅನ್ನು ನೋಡಲು.

ಸಿಂಟ್ಯಾಕ್ಸ್ ಹೈಲೈಟ್ ಮಾಡುವಿಕೆಯೊಂದಿಗೆ ನಾವು ಈ ರೀತಿಯದನ್ನು ಪಡೆದುಕೊಂಡಿದ್ದೇವೆ. ಆದರೆ ಸಾಮಾನ್ಯವಾಗಿ ನಮ್ಮ ಡೆವಲಪರ್‌ಗಳು ಇನ್ನು ಮುಂದೆ ಯೋಜನೆಯ ಸಂಪೂರ್ಣ ಪ್ರಾತಿನಿಧ್ಯದೊಂದಿಗೆ ಕೆಲಸ ಮಾಡುವುದಿಲ್ಲ, ಆದರೆ ಚಿಕ್ಕದರೊಂದಿಗೆ. ಎಲ್ಲಾ ನಂತರ, ನಾವು ಈಗಾಗಲೇ ಎಲ್ಲಾ ಸಂಖ್ಯೆಗಳನ್ನು ಪಾರ್ಸ್ ಮಾಡಿದ್ದೇವೆ ಮತ್ತು ಅವುಗಳನ್ನು ಎಡ ಮತ್ತು ಬಲಕ್ಕೆ ಎಸೆದಿದ್ದೇವೆ ಮತ್ತು ಮಧ್ಯದಲ್ಲಿ ನಾವು ಮೊದಲ ಸಾಲನ್ನು ಮಾತ್ರ ಬಿಟ್ಟಿದ್ದೇವೆ, ಅದು ಯಾವ ರೀತಿಯ ನೋಡ್ ಆಗಿದೆ: CTE ಸ್ಕ್ಯಾನ್, CTE ಪೀಳಿಗೆಯ ಅಥವಾ ಕೆಲವು ಚಿಹ್ನೆಗಳ ಪ್ರಕಾರ Seq ಸ್ಕ್ಯಾನ್.

ಇದು ನಾವು ಕರೆಯುವ ಸಂಕ್ಷಿಪ್ತ ಪ್ರಾತಿನಿಧ್ಯವಾಗಿದೆ ಯೋಜನೆ ಟೆಂಪ್ಲೇಟ್.

ಬೇರೆ ಏನು ಅನುಕೂಲಕರವಾಗಿರುತ್ತದೆ? ನಮ್ಮ ಒಟ್ಟು ಸಮಯದ ಯಾವ ಪಾಲನ್ನು ಯಾವ ನೋಡ್‌ಗೆ ನಿಗದಿಪಡಿಸಲಾಗಿದೆ ಎಂಬುದನ್ನು ನೋಡಲು ಅನುಕೂಲಕರವಾಗಿರುತ್ತದೆ - ಮತ್ತು ಅದನ್ನು ಬದಿಗೆ “ಅಂಟಿಸಿ” ಪೈ ಚಾರ್ಟ್.

ನಾವು ನೋಡ್ ಅನ್ನು ಸೂಚಿಸುತ್ತೇವೆ ಮತ್ತು ನೋಡುತ್ತೇವೆ - ಸೆಕ್ ಸ್ಕ್ಯಾನ್ ಒಟ್ಟು ಸಮಯದ ಕಾಲುಭಾಗಕ್ಕಿಂತ ಕಡಿಮೆ ಸಮಯವನ್ನು ತೆಗೆದುಕೊಂಡಿದೆ ಮತ್ತು ಉಳಿದ 3/4 ಅನ್ನು CTE ಸ್ಕ್ಯಾನ್ ತೆಗೆದುಕೊಂಡಿದೆ. ಭಯಾನಕ! ನಿಮ್ಮ ಪ್ರಶ್ನೆಗಳಲ್ಲಿ ನೀವು ಅವುಗಳನ್ನು ಸಕ್ರಿಯವಾಗಿ ಬಳಸಿದರೆ CTE ಸ್ಕ್ಯಾನ್‌ನ “ಬೆಂಕಿಯ ದರ” ಕುರಿತು ಇದು ಸಣ್ಣ ಟಿಪ್ಪಣಿಯಾಗಿದೆ. ಅವು ತುಂಬಾ ವೇಗವಾಗಿಲ್ಲ - ಸಾಮಾನ್ಯ ಟೇಬಲ್ ಸ್ಕ್ಯಾನಿಂಗ್‌ಗಿಂತ ಅವು ಕೆಳಮಟ್ಟದಲ್ಲಿರುತ್ತವೆ. [ಲೇಖನ] [ಲೇಖನ]

ಆದರೆ ಸಾಮಾನ್ಯವಾಗಿ ಅಂತಹ ರೇಖಾಚಿತ್ರಗಳು ಹೆಚ್ಚು ಆಸಕ್ತಿಕರವಾಗಿರುತ್ತವೆ, ಹೆಚ್ಚು ಸಂಕೀರ್ಣವಾಗಿರುತ್ತವೆ, ನಾವು ತಕ್ಷಣವೇ ಒಂದು ವಿಭಾಗದಲ್ಲಿ ಸೂಚಿಸಿದಾಗ ಮತ್ತು ನೋಡಿ, ಉದಾಹರಣೆಗೆ, ಕೆಲವು ಸೆಕ್ ಸ್ಕ್ಯಾನ್ ಅರ್ಧಕ್ಕಿಂತ ಹೆಚ್ಚು ಸಮಯ "ತಿನ್ನುತ್ತವೆ". ಇದಲ್ಲದೆ, ಒಳಗೆ ಕೆಲವು ರೀತಿಯ ಫಿಲ್ಟರ್ ಇತ್ತು, ಅದರ ಪ್ರಕಾರ ಬಹಳಷ್ಟು ದಾಖಲೆಗಳನ್ನು ತಿರಸ್ಕರಿಸಲಾಗಿದೆ ... ನೀವು ನೇರವಾಗಿ ಈ ಚಿತ್ರವನ್ನು ಡೆವಲಪರ್‌ಗೆ ಎಸೆಯಬಹುದು ಮತ್ತು ಹೀಗೆ ಹೇಳಬಹುದು: “ವಾಸ್ಯಾ, ಇಲ್ಲಿ ಎಲ್ಲವೂ ನಿಮಗೆ ಕೆಟ್ಟದಾಗಿದೆ! ಅದನ್ನು ಕಂಡುಹಿಡಿಯಿರಿ, ನೋಡಿ - ಏನೋ ತಪ್ಪಾಗಿದೆ!

ಸ್ವಾಭಾವಿಕವಾಗಿ, ಕೆಲವು "ಕುಂಟೆಗಳು" ಒಳಗೊಂಡಿವೆ.

ನಾವು ಕಂಡ ಮೊದಲ ವಿಷಯವೆಂದರೆ ಪೂರ್ಣಾಂಕದ ಸಮಸ್ಯೆ. ಯೋಜನೆಯಲ್ಲಿನ ಪ್ರತಿಯೊಂದು ನೋಡ್ನ ಸಮಯವನ್ನು 1 μs ನ ನಿಖರತೆಯೊಂದಿಗೆ ಸೂಚಿಸಲಾಗುತ್ತದೆ. ಮತ್ತು ನೋಡ್ ಚಕ್ರಗಳ ಸಂಖ್ಯೆಯು ಮೀರಿದಾಗ, ಉದಾಹರಣೆಗೆ, 1000 - ಮರಣದಂಡನೆಯ ನಂತರ PostgreSQL ಅನ್ನು "ನಿಖರತೆಯೊಳಗೆ" ವಿಂಗಡಿಸಲಾಗಿದೆ, ನಂತರ ಮತ್ತೆ ಲೆಕ್ಕಾಚಾರ ಮಾಡುವಾಗ ನಾವು "ಎಲ್ಲೋ 0.95ms ಮತ್ತು 1.05ms ನಡುವೆ" ಒಟ್ಟು ಸಮಯವನ್ನು ಪಡೆಯುತ್ತೇವೆ. ಎಣಿಕೆಯು ಮೈಕ್ರೊಸೆಕೆಂಡ್‌ಗಳಿಗೆ ಹೋದಾಗ, ಅದು ಸರಿ, ಆದರೆ ಅದು ಈಗಾಗಲೇ [ಮಿಲಿ]ಸೆಕೆಂಡ್‌ಗಳಾಗಿದ್ದಾಗ, "ಯಾರು ಎಷ್ಟು ಸೇವಿಸಿದ್ದಾರೆ" ಯೋಜನೆಯ ನೋಡ್‌ಗಳಿಗೆ ಸಂಪನ್ಮೂಲಗಳನ್ನು "ಬಿಚ್ಚಿ" ಮಾಡುವಾಗ ನೀವು ಈ ಮಾಹಿತಿಯನ್ನು ಗಣನೆಗೆ ತೆಗೆದುಕೊಳ್ಳಬೇಕಾಗುತ್ತದೆ.

ಎರಡನೆಯ ಅಂಶವು ಹೆಚ್ಚು ಸಂಕೀರ್ಣವಾಗಿದೆ, ಡೈನಾಮಿಕ್ ನೋಡ್‌ಗಳ ನಡುವೆ ಸಂಪನ್ಮೂಲಗಳ ವಿತರಣೆ (ಆ ಬಫರ್‌ಗಳು). ಇದು ನಮಗೆ ಮೂಲಮಾದರಿಯ ಮೊದಲ 2 ವಾರಗಳು ಮತ್ತು ಇನ್ನೊಂದು 4 ವಾರಗಳು ವೆಚ್ಚವಾಗುತ್ತದೆ.

ಈ ರೀತಿಯ ಸಮಸ್ಯೆಯನ್ನು ಪಡೆಯುವುದು ತುಂಬಾ ಸುಲಭ - ನಾವು CTE ಅನ್ನು ಮಾಡುತ್ತೇವೆ ಮತ್ತು ಅದರಲ್ಲಿ ಏನನ್ನಾದರೂ ಓದುತ್ತೇವೆ. ವಾಸ್ತವವಾಗಿ, PostgreSQL "ಸ್ಮಾರ್ಟ್" ಮತ್ತು ನೇರವಾಗಿ ಏನನ್ನೂ ಓದುವುದಿಲ್ಲ. ನಂತರ ನಾವು ಅದರಿಂದ ಮೊದಲ ದಾಖಲೆಯನ್ನು ತೆಗೆದುಕೊಳ್ಳುತ್ತೇವೆ ಮತ್ತು ಅದೇ CTE ಯಿಂದ ನೂರು ಮತ್ತು ಮೊದಲನೆಯದನ್ನು ತೆಗೆದುಕೊಳ್ಳುತ್ತೇವೆ.

ನಾವು ಯೋಜನೆಯನ್ನು ನೋಡುತ್ತೇವೆ ಮತ್ತು ಅರ್ಥಮಾಡಿಕೊಳ್ಳುತ್ತೇವೆ - ಇದು ವಿಚಿತ್ರವಾಗಿದೆ, ನಾವು Seq ಸ್ಕ್ಯಾನ್‌ನಲ್ಲಿ 3 ಬಫರ್‌ಗಳನ್ನು (ಡೇಟಾ ಪುಟಗಳು) "ಸೇವಿಸಲಾಗಿದೆ", CTE ಸ್ಕ್ಯಾನ್‌ನಲ್ಲಿ 1 ಹೆಚ್ಚು ಮತ್ತು ಎರಡನೇ CTE ಸ್ಕ್ಯಾನ್‌ನಲ್ಲಿ 2 ಹೆಚ್ಚು. ಅಂದರೆ, ನಾವು ಎಲ್ಲವನ್ನೂ ಸರಳವಾಗಿ ಒಟ್ಟುಗೂಡಿಸಿದರೆ, ನಾವು 6 ಅನ್ನು ಪಡೆಯುತ್ತೇವೆ, ಆದರೆ ಟ್ಯಾಬ್ಲೆಟ್ನಿಂದ ನಾವು 3 ಅನ್ನು ಮಾತ್ರ ಓದುತ್ತೇವೆ! CTE ಸ್ಕ್ಯಾನ್ ಎಲ್ಲಿಂದಲಾದರೂ ಏನನ್ನೂ ಓದುವುದಿಲ್ಲ, ಆದರೆ ಪ್ರಕ್ರಿಯೆಯ ಮೆಮೊರಿಯೊಂದಿಗೆ ನೇರವಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ. ಅಂದರೆ, ಇಲ್ಲಿ ಏನೋ ಸ್ಪಷ್ಟವಾಗಿ ತಪ್ಪಾಗಿದೆ!

ವಾಸ್ತವವಾಗಿ, Seq ಸ್ಕ್ಯಾನ್‌ನಿಂದ ವಿನಂತಿಸಲಾದ ಎಲ್ಲಾ 3 ಪುಟಗಳ ಡೇಟಾ ಇಲ್ಲಿದೆ, ಮೊದಲು 1 1 ನೇ CTE ಸ್ಕ್ಯಾನ್‌ಗೆ ಕೇಳಿದೆ, ಮತ್ತು ನಂತರ 2 ನೇ ಮತ್ತು 2 ಅನ್ನು ಅವನಿಗೆ ಓದಲಾಗಿದೆ. ಅಂದರೆ, ಒಟ್ಟು 3 ಪುಟಗಳನ್ನು ಓದಲಾಗಿದೆ ಡೇಟಾ, 6 ಅಲ್ಲ.

ಮತ್ತು ಈ ಚಿತ್ರವು ಯೋಜನೆಯನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸುವುದು ಇನ್ನು ಮುಂದೆ ಮರವಲ್ಲ, ಆದರೆ ಕೆಲವು ರೀತಿಯ ಅಸಿಕ್ಲಿಕ್ ಗ್ರಾಫ್ ಎಂದು ಅರ್ಥಮಾಡಿಕೊಳ್ಳಲು ನಮಗೆ ಕಾರಣವಾಯಿತು. ಮತ್ತು ನಾವು ಈ ರೀತಿಯ ರೇಖಾಚಿತ್ರವನ್ನು ಪಡೆದುಕೊಂಡಿದ್ದೇವೆ, ಇದರಿಂದಾಗಿ "ಮೊದಲು ಎಲ್ಲಿಂದ ಬಂದಿತು" ಎಂದು ನಾವು ಅರ್ಥಮಾಡಿಕೊಳ್ಳುತ್ತೇವೆ. ಅಂದರೆ, ಇಲ್ಲಿ ನಾವು pg_class ನಿಂದ CTE ಅನ್ನು ರಚಿಸಿದ್ದೇವೆ ಮತ್ತು ಅದನ್ನು ಎರಡು ಬಾರಿ ಕೇಳಿದ್ದೇವೆ ಮತ್ತು ನಾವು ಅದನ್ನು 2 ನೇ ಬಾರಿ ಕೇಳಿದಾಗ ನಮ್ಮ ಎಲ್ಲಾ ಸಮಯವನ್ನು ಶಾಖೆಯಲ್ಲಿ ಕಳೆದಿದ್ದೇವೆ. ಟ್ಯಾಬ್ಲೆಟ್‌ನಿಂದ 101 ನೇ ನಮೂದನ್ನು ಓದುವುದಕ್ಕಿಂತ 1 ನೇ ನಮೂದನ್ನು ಓದುವುದು ಹೆಚ್ಚು ದುಬಾರಿಯಾಗಿದೆ ಎಂಬುದು ಸ್ಪಷ್ಟವಾಗಿದೆ.

ಸ್ವಲ್ಪ ಹೊತ್ತು ಉಸಿರು ಬಿಟ್ಟೆವು. ಅವರು ಹೇಳಿದರು: “ಈಗ, ನಿಯೋ, ನಿಮಗೆ ಕುಂಗ್ ಫೂ ತಿಳಿದಿದೆ! ಈಗ ನಮ್ಮ ಅನುಭವವು ನಿಮ್ಮ ಪರದೆಯ ಮೇಲೆ ಸರಿಯಾಗಿದೆ. ಈಗ ನೀವು ಅದನ್ನು ಬಳಸಬಹುದು." [ಲೇಖನ]

ಲಾಗ್ ಬಲವರ್ಧನೆ

ನಮ್ಮ 1000 ಡೆವಲಪರ್‌ಗಳು ನೆಮ್ಮದಿಯ ನಿಟ್ಟುಸಿರು ಬಿಟ್ಟರು. ಆದರೆ ನಮ್ಮಲ್ಲಿ ನೂರಾರು "ಯುದ್ಧ" ಸರ್ವರ್‌ಗಳು ಮಾತ್ರ ಇವೆ ಎಂದು ನಾವು ಅರ್ಥಮಾಡಿಕೊಂಡಿದ್ದೇವೆ ಮತ್ತು ಡೆವಲಪರ್‌ಗಳ ಕಡೆಯಿಂದ ಈ ಎಲ್ಲಾ "ಕಾಪಿ-ಪೇಸ್ಟ್" ಎಲ್ಲಾ ಅನುಕೂಲಕರವಾಗಿಲ್ಲ. ಅದನ್ನು ನಾವೇ ಸಂಗ್ರಹಿಸಬೇಕು ಎಂದು ಅರಿವಾಯಿತು.

ಸಾಮಾನ್ಯವಾಗಿ, ಅಂಕಿಅಂಶಗಳನ್ನು ಸಂಗ್ರಹಿಸಬಹುದಾದ ಪ್ರಮಾಣಿತ ಮಾಡ್ಯೂಲ್ ಇದೆ, ಆದಾಗ್ಯೂ, ಇದನ್ನು ಸಂರಚನೆಯಲ್ಲಿ ಸಕ್ರಿಯಗೊಳಿಸಬೇಕಾಗಿದೆ - ಇದು ಮಾಡ್ಯೂಲ್ pg_stat_statements. ಆದರೆ ಅವನು ನಮಗೆ ಸರಿಹೊಂದುವುದಿಲ್ಲ.

ಮೊದಲನೆಯದಾಗಿ, ಇದು ಒಂದೇ ಡೇಟಾಬೇಸ್‌ನಲ್ಲಿ ವಿಭಿನ್ನ ಸ್ಕೀಮ್‌ಗಳನ್ನು ಬಳಸಿಕೊಂಡು ಅದೇ ಪ್ರಶ್ನೆಗಳಿಗೆ ನಿಯೋಜಿಸುತ್ತದೆ ವಿವಿಧ QueryIds. ಅಂದರೆ, ನೀವು ಮೊದಲು ಮಾಡಿದರೆ SET search_path = '01'; SELECT * FROM user LIMIT 1;ತದನಂತರ SET search_path = '02'; ಮತ್ತು ಅದೇ ವಿನಂತಿ, ನಂತರ ಈ ಮಾಡ್ಯೂಲ್‌ನ ಅಂಕಿಅಂಶಗಳು ವಿಭಿನ್ನ ದಾಖಲೆಗಳನ್ನು ಹೊಂದಿರುತ್ತವೆ ಮತ್ತು ಯೋಜನೆಗಳನ್ನು ಗಣನೆಗೆ ತೆಗೆದುಕೊಳ್ಳದೆಯೇ ಈ ವಿನಂತಿಯ ಪ್ರೊಫೈಲ್‌ನ ಸಂದರ್ಭದಲ್ಲಿ ನಿರ್ದಿಷ್ಟವಾಗಿ ಸಾಮಾನ್ಯ ಅಂಕಿಅಂಶಗಳನ್ನು ಸಂಗ್ರಹಿಸಲು ನನಗೆ ಸಾಧ್ಯವಾಗುವುದಿಲ್ಲ.

ಅದನ್ನು ಬಳಸದಂತೆ ನಮ್ಮನ್ನು ತಡೆದ ಎರಡನೇ ಅಂಶ ಯೋಜನೆಗಳ ಕೊರತೆ. ಅಂದರೆ, ಯಾವುದೇ ಯೋಜನೆ ಇಲ್ಲ, ವಿನಂತಿ ಮಾತ್ರ ಇದೆ. ಏನು ನಿಧಾನವಾಗುತ್ತಿದೆ ಎಂಬುದನ್ನು ನಾವು ನೋಡುತ್ತೇವೆ, ಆದರೆ ಏಕೆ ಎಂದು ನಮಗೆ ಅರ್ಥವಾಗುತ್ತಿಲ್ಲ. ಮತ್ತು ಇಲ್ಲಿ ನಾವು ವೇಗವಾಗಿ ಬದಲಾಗುತ್ತಿರುವ ಡೇಟಾಸೆಟ್‌ನ ಸಮಸ್ಯೆಗೆ ಹಿಂತಿರುಗುತ್ತೇವೆ.

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

ಆದ್ದರಿಂದ, ನಾವು ಕಾಪಿ-ಪೇಸ್ಟ್ ವಿರುದ್ಧ ಹೋರಾಡಲು ನಿರ್ಧರಿಸಿದ್ದೇವೆ ಮತ್ತು ಬರೆಯಲು ಪ್ರಾರಂಭಿಸಿದ್ದೇವೆ ಸಂಗ್ರಾಹಕ.

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

ನಾವು ಈಗಾಗಲೇ Node.js ನಲ್ಲಿ ಇಂಟರ್ಫೇಸ್ ಅನ್ನು ಬರೆಯಲು ಪ್ರಾರಂಭಿಸಿದ್ದರಿಂದ, ನಾವು ಅದರಲ್ಲಿ ಕಲೆಕ್ಟರ್ ಅನ್ನು ಬರೆಯುವುದನ್ನು ಮುಂದುವರಿಸಿದ್ದೇವೆ. ಮತ್ತು ಈ ತಂತ್ರಜ್ಞಾನವು ಸ್ವತಃ ಸಮರ್ಥಿಸಿಕೊಂಡಿದೆ, ಏಕೆಂದರೆ ದುರ್ಬಲವಾಗಿ ಫಾರ್ಮ್ಯಾಟ್ ಮಾಡಲಾದ ಪಠ್ಯ ಡೇಟಾದೊಂದಿಗೆ ಕೆಲಸ ಮಾಡಲು ಜಾವಾಸ್ಕ್ರಿಪ್ಟ್ ಅನ್ನು ಬಳಸಲು ತುಂಬಾ ಅನುಕೂಲಕರವಾಗಿದೆ, ಇದು ಲಾಗ್ ಆಗಿದೆ. ಮತ್ತು Node.js ಮೂಲಸೌಕರ್ಯವು ಬ್ಯಾಕೆಂಡ್ ಪ್ಲಾಟ್‌ಫಾರ್ಮ್ ಆಗಿ ನಿಮಗೆ ಸುಲಭವಾಗಿ ಮತ್ತು ಅನುಕೂಲಕರವಾಗಿ ನೆಟ್‌ವರ್ಕ್ ಸಂಪರ್ಕಗಳೊಂದಿಗೆ ಮತ್ತು ವಾಸ್ತವವಾಗಿ ಯಾವುದೇ ಡೇಟಾ ಸ್ಟ್ರೀಮ್‌ಗಳೊಂದಿಗೆ ಕೆಲಸ ಮಾಡಲು ಅನುಮತಿಸುತ್ತದೆ.

ಅಂತೆಯೇ, ನಾವು ಎರಡು ಸಂಪರ್ಕಗಳನ್ನು "ವಿಸ್ತರಿಸುತ್ತೇವೆ": ಮೊದಲನೆಯದು ಲಾಗ್ ಅನ್ನು "ಕೇಳಲು" ಮತ್ತು ಅದನ್ನು ನಮ್ಮ ಬಳಿಗೆ ಕೊಂಡೊಯ್ಯಲು, ಮತ್ತು ಎರಡನೆಯದು ನಿಯತಕಾಲಿಕವಾಗಿ ಬೇಸ್ ಅನ್ನು ಕೇಳಲು. "ಆದರೆ oid 123 ನೊಂದಿಗೆ ಚಿಹ್ನೆಯನ್ನು ನಿರ್ಬಂಧಿಸಲಾಗಿದೆ ಎಂದು ಲಾಗ್ ತೋರಿಸುತ್ತದೆ," ಆದರೆ ಇದು ಡೆವಲಪರ್‌ಗೆ ಏನನ್ನೂ ಅರ್ಥವಲ್ಲ, ಮತ್ತು ಡೇಟಾಬೇಸ್ ಅನ್ನು ಕೇಳಲು ಒಳ್ಳೆಯದು, "OID = 123 ಹೇಗಾದರೂ?" ಮತ್ತು ಆದ್ದರಿಂದ ನಾವು ನಿಯತಕಾಲಿಕವಾಗಿ ನಮ್ಮ ಬಗ್ಗೆ ನಮಗೆ ಇನ್ನೂ ತಿಳಿದಿಲ್ಲದ ಮೂಲವನ್ನು ಕೇಳುತ್ತೇವೆ.

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

ಇದೆಲ್ಲವನ್ನೂ ಸೇರಿಸಬೇಕಾಗಿದೆ, ಡೇಟಾ ಹರಿವು ದೊಡ್ಡದಾಗಿದೆ ಮತ್ತು ಸಕ್ರಿಯವಾಗಿದೆ. ವಾಸ್ತವವಾಗಿ, ನಾವು ಏನು ಮೇಲ್ವಿಚಾರಣೆ ಮಾಡುತ್ತೇವೆ, ನಾವು ಏನು ವ್ಯವಹರಿಸಬಹುದು, ನಾವು ಏನು ಬಳಸುತ್ತೇವೆ. ನಾವು PostgreSQL ಅನ್ನು ಡೇಟಾ ಸಂಗ್ರಹಣೆಯಾಗಿಯೂ ಬಳಸುತ್ತೇವೆ. ಮತ್ತು ಆಪರೇಟರ್‌ಗಿಂತ ಡೇಟಾವನ್ನು "ಸುರಿಯಲು" ಯಾವುದೂ ವೇಗವಾಗಿಲ್ಲ COPY ಇನ್ನು ಇಲ್ಲ.

ಆದರೆ ಸರಳವಾಗಿ "ಸುರಿಯುವುದು" ಡೇಟಾವನ್ನು ನಿಜವಾಗಿಯೂ ನಮ್ಮ ತಂತ್ರಜ್ಞಾನವಲ್ಲ. ಏಕೆಂದರೆ ನೀವು ನೂರು ಸರ್ವರ್‌ಗಳಲ್ಲಿ ಪ್ರತಿ ಸೆಕೆಂಡಿಗೆ ಸರಿಸುಮಾರು 50 ಸಾವಿರ ವಿನಂತಿಗಳನ್ನು ಹೊಂದಿದ್ದರೆ, ಇದು ದಿನಕ್ಕೆ 100-150GB ಲಾಗ್‌ಗಳನ್ನು ಉತ್ಪಾದಿಸುತ್ತದೆ. ಆದ್ದರಿಂದ, ನಾವು ಬೇಸ್ ಅನ್ನು ಎಚ್ಚರಿಕೆಯಿಂದ "ಕತ್ತರಿಸಬೇಕು".

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

ಎರಡನೆಯದಾಗಿ, ನಾವು ಕಲಿತಿದ್ದೇವೆ (ಬಲವಂತವಾಗಿ) ಬಳಸಿ ಬರೆಯಲು ತುಂಬಾ ವೇಗವಾಗಿ COPY. ಅಂದರೆ, ಕೇವಲ ಅಲ್ಲ COPYಏಕೆಂದರೆ ಅವನು ವೇಗವಾಗಿರುತ್ತಾನೆ INSERT, ಮತ್ತು ಇನ್ನೂ ವೇಗವಾಗಿ.

ಮೂರನೆಯ ಅಂಶ - ನಾನು ಮಾಡಬೇಕಾಗಿತ್ತು ಕ್ರಮವಾಗಿ ಪ್ರಚೋದಕಗಳನ್ನು ಮತ್ತು ವಿದೇಶಿ ಕೀಗಳನ್ನು ತ್ಯಜಿಸಿ. ಅಂದರೆ, ನಮಗೆ ಯಾವುದೇ ಉಲ್ಲೇಖಿತ ಸಮಗ್ರತೆ ಇಲ್ಲ. ಏಕೆಂದರೆ ನೀವು ಒಂದು ಜೋಡಿ ಎಫ್‌ಕೆಗಳನ್ನು ಹೊಂದಿರುವ ಟೇಬಲ್ ಹೊಂದಿದ್ದರೆ ಮತ್ತು ಡೇಟಾಬೇಸ್ ರಚನೆಯಲ್ಲಿ ನೀವು "ಇಲ್ಲಿ ಎಫ್‌ಕೆ ಉಲ್ಲೇಖಿಸಿದ ಲಾಗ್ ರೆಕಾರ್ಡ್ ಇದೆ, ಉದಾಹರಣೆಗೆ, ದಾಖಲೆಗಳ ಗುಂಪಿಗೆ" ಎಂದು ಹೇಳಿದರೆ, ನೀವು ಅದನ್ನು ಸೇರಿಸಿದಾಗ, ಪೋಸ್ಟ್‌ಗ್ರೆಎಸ್‌ಕ್ಯುಎಲ್ ಅದನ್ನು ತೆಗೆದುಕೊಳ್ಳುವುದು ಮತ್ತು ಅದನ್ನು ಪ್ರಾಮಾಣಿಕವಾಗಿ ಮಾಡುವುದು ಹೇಗೆ ಆದರೆ ಬೇರೆ ಏನೂ ಉಳಿದಿಲ್ಲ SELECT 1 FROM master_fk1_table WHERE ... ನೀವು ಸೇರಿಸಲು ಪ್ರಯತ್ನಿಸುತ್ತಿರುವ ಗುರುತಿಸುವಿಕೆಯೊಂದಿಗೆ - ಈ ದಾಖಲೆಯು ಅಲ್ಲಿ ಇದೆಯೇ ಎಂದು ಪರಿಶೀಲಿಸಲು, ನಿಮ್ಮ ಅಳವಡಿಕೆಯೊಂದಿಗೆ ನೀವು ಈ ವಿದೇಶಿ ಕೀಲಿಯನ್ನು "ಮುರಿಯುವುದಿಲ್ಲ".

ಟಾರ್ಗೆಟ್ ಟೇಬಲ್ ಮತ್ತು ಅದರ ಸೂಚಿಕೆಗಳಿಗೆ ಒಂದು ದಾಖಲೆಯ ಬದಲಿಗೆ, ಅದು ಉಲ್ಲೇಖಿಸುವ ಎಲ್ಲಾ ಕೋಷ್ಟಕಗಳಿಂದ ನಾವು ಓದುವ ಹೆಚ್ಚುವರಿ ಪ್ರಯೋಜನವನ್ನು ಪಡೆಯುತ್ತೇವೆ. ಆದರೆ ನಮಗೆ ಇದು ಅಗತ್ಯವಿಲ್ಲ - ನಮ್ಮ ಕಾರ್ಯವು ಸಾಧ್ಯವಾದಷ್ಟು ಮತ್ತು ಸಾಧ್ಯವಾದಷ್ಟು ಬೇಗ ಕಡಿಮೆ ಹೊರೆಯೊಂದಿಗೆ ರೆಕಾರ್ಡ್ ಮಾಡುವುದು. ಆದ್ದರಿಂದ FK - ಕೆಳಗೆ!

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

ನಿರ್ದಿಷ್ಟ ಹೋಸ್ಟ್ ಮೂಲಕ ಹಾದುಹೋದ ವಿನಂತಿಗಳ ಸಂಖ್ಯೆಯನ್ನು ನೀವು ಸರಳವಾಗಿ ಎಣಿಸುವ ಟೇಬಲ್ ಅನ್ನು ನೀವು ಹೊಂದಿರುವಿರಿ ಎಂದು ಈಗ ಊಹಿಸಿ: +1, +1, +1, ..., +1. ಮತ್ತು ನೀವು, ತಾತ್ವಿಕವಾಗಿ, ಇದು ಅಗತ್ಯವಿಲ್ಲ - ಇದು ಸಾಧ್ಯ ಸಂಗ್ರಾಹಕದಲ್ಲಿ ಮೆಮೊರಿಯಲ್ಲಿ ಮೊತ್ತ ಮತ್ತು ಒಂದೇ ಸಮಯದಲ್ಲಿ ಡೇಟಾಬೇಸ್‌ಗೆ ಕಳುಹಿಸಿ +10.

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

ಹ್ಯಾಶಿಂಗ್‌ನ ವಿಷಯದಲ್ಲೂ ಅಷ್ಟೇ. ಒಂದು ನಿರ್ದಿಷ್ಟ ವಿನಂತಿಯು ನಿಮಗೆ ಹಾರುತ್ತದೆ, ನೀವು ಡೇಟಾಬೇಸ್‌ನಲ್ಲಿ ನಿರ್ದಿಷ್ಟ ಗುರುತಿಸುವಿಕೆಯನ್ನು ಲೆಕ್ಕ ಹಾಕುತ್ತೀರಿ, ಅದನ್ನು ಡೇಟಾಬೇಸ್‌ಗೆ ಬರೆಯಿರಿ ಮತ್ತು ನಂತರ ಅದನ್ನು ಎಲ್ಲರಿಗೂ ತಿಳಿಸಿ. ರೆಕಾರ್ಡಿಂಗ್ ಸಮಯದಲ್ಲಿ, ಅದೇ ವಿಷಯವನ್ನು ರೆಕಾರ್ಡ್ ಮಾಡಲು ಬಯಸುವ ಎರಡನೇ ವ್ಯಕ್ತಿ ನಿಮ್ಮ ಬಳಿಗೆ ಬರುವವರೆಗೆ ಎಲ್ಲವೂ ಉತ್ತಮವಾಗಿರುತ್ತದೆ - ಮತ್ತು ನೀವು ನಿರ್ಬಂಧಿಸಲ್ಪಡುತ್ತೀರಿ ಮತ್ತು ಇದು ಈಗಾಗಲೇ ಕೆಟ್ಟದ್ದಾಗಿದೆ. ಆದ್ದರಿಂದ, ನೀವು ಕೆಲವು ID ಗಳ ಪೀಳಿಗೆಯನ್ನು ಕ್ಲೈಂಟ್‌ಗೆ ವರ್ಗಾಯಿಸಬಹುದಾದರೆ (ಡೇಟಾಬೇಸ್‌ಗೆ ಸಂಬಂಧಿಸಿದಂತೆ), ಇದನ್ನು ಮಾಡುವುದು ಉತ್ತಮ.

ಪಠ್ಯದಿಂದ MD5 ಅನ್ನು ಬಳಸಲು ನಮಗೆ ಇದು ಪರಿಪೂರ್ಣವಾಗಿದೆ - ವಿನಂತಿ, ಯೋಜನೆ, ಟೆಂಪ್ಲೇಟ್,... ನಾವು ಅದನ್ನು ಸಂಗ್ರಾಹಕ ಬದಿಯಲ್ಲಿ ಲೆಕ್ಕ ಹಾಕುತ್ತೇವೆ ಮತ್ತು ಡೇಟಾಬೇಸ್‌ಗೆ ಸಿದ್ಧವಾದ ID ಅನ್ನು "ಸುರಿಯುತ್ತೇವೆ". MD5 ನ ಉದ್ದ ಮತ್ತು ದೈನಂದಿನ ವಿಭಜನೆಯು ಸಂಭವನೀಯ ಘರ್ಷಣೆಗಳ ಬಗ್ಗೆ ಚಿಂತಿಸದಿರಲು ನಮಗೆ ಅನುಮತಿಸುತ್ತದೆ.

ಆದರೆ ಇದೆಲ್ಲವನ್ನೂ ತ್ವರಿತವಾಗಿ ರೆಕಾರ್ಡ್ ಮಾಡಲು, ನಾವು ರೆಕಾರ್ಡಿಂಗ್ ಕಾರ್ಯವಿಧಾನವನ್ನು ಮಾರ್ಪಡಿಸಬೇಕಾಗಿದೆ.

ನೀವು ಸಾಮಾನ್ಯವಾಗಿ ಡೇಟಾವನ್ನು ಹೇಗೆ ಬರೆಯುತ್ತೀರಿ? ನಾವು ಕೆಲವು ರೀತಿಯ ಡೇಟಾಸೆಟ್ ಅನ್ನು ಹೊಂದಿದ್ದೇವೆ, ನಾವು ಅದನ್ನು ಹಲವಾರು ಕೋಷ್ಟಕಗಳಾಗಿ ವಿಭಜಿಸುತ್ತೇವೆ ಮತ್ತು ನಂತರ ಅದನ್ನು ನಕಲಿಸಿ - ಮೊದಲನೆಯದಕ್ಕೆ, ನಂತರ ಎರಡನೆಯದಕ್ಕೆ, ಮೂರನೆಯದಕ್ಕೆ... ಇದು ಅನಾನುಕೂಲವಾಗಿದೆ, ಏಕೆಂದರೆ ನಾವು ಮೂರು ಹಂತಗಳಲ್ಲಿ ಒಂದು ಡೇಟಾ ಸ್ಟ್ರೀಮ್ ಅನ್ನು ಬರೆಯುತ್ತಿರುವಂತೆ ತೋರುತ್ತಿದೆ. ಅನುಕ್ರಮವಾಗಿ. ಅಹಿತಕರ. ಇದನ್ನು ವೇಗವಾಗಿ ಮಾಡಬಹುದೇ? ಮಾಡಬಹುದು!

ಇದನ್ನು ಮಾಡಲು, ಈ ಹರಿವುಗಳನ್ನು ಪರಸ್ಪರ ಸಮಾನಾಂತರವಾಗಿ ಕೊಳೆಯಲು ಸಾಕು. ನಾವು ದೋಷಗಳು, ವಿನಂತಿಗಳು, ಟೆಂಪ್ಲೇಟ್ಗಳು, ನಿರ್ಬಂಧಿಸುವಿಕೆಗಳು, ... ಪ್ರತ್ಯೇಕ ಥ್ರೆಡ್ಗಳಲ್ಲಿ ಹಾರಾಟವನ್ನು ಹೊಂದಿದ್ದೇವೆ ಎಂದು ಅದು ತಿರುಗುತ್ತದೆ - ಮತ್ತು ನಾವು ಎಲ್ಲವನ್ನೂ ಸಮಾನಾಂತರವಾಗಿ ಬರೆಯುತ್ತೇವೆ. ಇದಕ್ಕೆ ಸಾಕು ಪ್ರತಿ ಗುರಿಯ ಕೋಷ್ಟಕಕ್ಕಾಗಿ ಒಂದು ನಕಲು ಚಾನಲ್ ಅನ್ನು ನಿರಂತರವಾಗಿ ತೆರೆದಿಡಿ.

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

ಹೆಚ್ಚುವರಿಯಾಗಿ, ಅಂತಹ ಲೋಡ್ ಪ್ರೊಫೈಲ್‌ಗೆ, ಬ್ಯಾಚ್‌ಗಳಲ್ಲಿ ದಾಖಲೆಗಳನ್ನು ಸಂಗ್ರಹಿಸಿದಾಗ ಯಾವುದೇ ಒಟ್ಟುಗೂಡಿಸುವಿಕೆಯು ಕೆಟ್ಟದ್ದಾಗಿದೆ ಎಂದು ನಾವು ಕಂಡುಕೊಂಡಿದ್ದೇವೆ. ಕ್ಲಾಸಿಕ್ ದುಷ್ಟ INSERT ... VALUES ಮತ್ತು ಇನ್ನೂ 1000 ದಾಖಲೆಗಳು. ಏಕೆಂದರೆ ಆ ಸಮಯದಲ್ಲಿ ನೀವು ಮಾಧ್ಯಮದಲ್ಲಿ ಬರೆಯುವ ಉತ್ತುಂಗವನ್ನು ಹೊಂದಿದ್ದೀರಿ ಮತ್ತು ಡಿಸ್ಕ್‌ಗೆ ಏನನ್ನಾದರೂ ಬರೆಯಲು ಪ್ರಯತ್ನಿಸುತ್ತಿರುವ ಪ್ರತಿಯೊಬ್ಬರೂ ಕಾಯುತ್ತಿರುತ್ತಾರೆ.

ಅಂತಹ ವೈಪರೀತ್ಯಗಳನ್ನು ತೊಡೆದುಹಾಕಲು, ಏನನ್ನೂ ಒಟ್ಟುಗೂಡಿಸಬೇಡಿ, ಬಫರ್ ಮಾಡಬೇಡಿ. ಮತ್ತು ಡಿಸ್ಕ್ಗೆ ಬಫರಿಂಗ್ ಸಂಭವಿಸಿದಲ್ಲಿ (ಅದೃಷ್ಟವಶಾತ್, Node.js ನಲ್ಲಿನ ಸ್ಟ್ರೀಮ್ API ನಿಮಗೆ ಕಂಡುಹಿಡಿಯಲು ಅನುಮತಿಸುತ್ತದೆ) - ಈ ಸಂಪರ್ಕವನ್ನು ಮುಂದೂಡಿ. ನೀವು ಈವೆಂಟ್ ಅನ್ನು ಮತ್ತೆ ಉಚಿತ ಎಂದು ಸ್ವೀಕರಿಸಿದಾಗ, ಸಂಚಿತ ಸರದಿಯಿಂದ ಅದಕ್ಕೆ ಬರೆಯಿರಿ. ಮತ್ತು ಅದು ಕಾರ್ಯನಿರತವಾಗಿರುವಾಗ, ಪೂಲ್‌ನಿಂದ ಮುಂದಿನ ಉಚಿತವನ್ನು ತೆಗೆದುಕೊಂಡು ಅದಕ್ಕೆ ಬರೆಯಿರಿ.

ಡೇಟಾ ರೆಕಾರ್ಡಿಂಗ್‌ಗೆ ಈ ವಿಧಾನವನ್ನು ಪರಿಚಯಿಸುವ ಮೊದಲು, ನಾವು ಸರಿಸುಮಾರು 4K ರೈಟ್ ಆಪ್‌ಗಳನ್ನು ಹೊಂದಿದ್ದೇವೆ ಮತ್ತು ಈ ರೀತಿಯಲ್ಲಿ ನಾವು ಲೋಡ್ ಅನ್ನು 4 ಬಾರಿ ಕಡಿಮೆಗೊಳಿಸಿದ್ದೇವೆ. ಹೊಸ ಮಾನಿಟರ್ ಮಾಡಲಾದ ಡೇಟಾಬೇಸ್‌ಗಳಿಂದಾಗಿ ಈಗ ಅವರು ಮತ್ತೊಂದು 6 ಬಾರಿ ಬೆಳೆದಿದ್ದಾರೆ - 100MB/s ವರೆಗೆ. ಮತ್ತು ಈಗ ನಾವು ಕಳೆದ 3 ತಿಂಗಳುಗಳ ಲಾಗ್‌ಗಳನ್ನು ಸುಮಾರು 10-15TB ಪರಿಮಾಣದಲ್ಲಿ ಸಂಗ್ರಹಿಸುತ್ತೇವೆ, ಕೇವಲ ಮೂರು ತಿಂಗಳಲ್ಲಿ ಯಾವುದೇ ಡೆವಲಪರ್ ಯಾವುದೇ ಸಮಸ್ಯೆಯನ್ನು ಪರಿಹರಿಸಲು ಸಾಧ್ಯವಾಗುತ್ತದೆ ಎಂದು ಆಶಿಸುತ್ತೇವೆ.

ನಾವು ಸಮಸ್ಯೆಗಳನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳುತ್ತೇವೆ

ಆದರೆ ಈ ಎಲ್ಲಾ ಡೇಟಾವನ್ನು ಸರಳವಾಗಿ ಸಂಗ್ರಹಿಸುವುದು ಒಳ್ಳೆಯದು, ಉಪಯುಕ್ತ, ಸಂಬಂಧಿತ, ಆದರೆ ಸಾಕಾಗುವುದಿಲ್ಲ - ಅದನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳಬೇಕು. ಏಕೆಂದರೆ ಇವು ದಿನಕ್ಕೆ ಲಕ್ಷಾಂತರ ವಿಭಿನ್ನ ಯೋಜನೆಗಳಾಗಿವೆ.

ಆದರೆ ಲಕ್ಷಾಂತರ ಜನರು ನಿರ್ವಹಿಸಲಾಗದವರು, ನಾವು ಮೊದಲು "ಸಣ್ಣ" ಮಾಡಬೇಕು. ಮತ್ತು, ಮೊದಲನೆಯದಾಗಿ, ನೀವು ಈ "ಸಣ್ಣ" ವಿಷಯವನ್ನು ಹೇಗೆ ಸಂಘಟಿಸುತ್ತೀರಿ ಎಂಬುದನ್ನು ನೀವು ನಿರ್ಧರಿಸಬೇಕು.

ನಾವು ಮೂರು ಪ್ರಮುಖ ಅಂಶಗಳನ್ನು ಗುರುತಿಸಿದ್ದೇವೆ:

• ಯಾರು ಈ ವಿನಂತಿಯನ್ನು ಕಳುಹಿಸಲಾಗಿದೆ
  ಅಂದರೆ, ಯಾವ ಅಪ್ಲಿಕೇಶನ್‌ನಿಂದ ಅದು "ಆಗಮಿಸಿತು": ವೆಬ್ ಇಂಟರ್ಫೇಸ್, ಬ್ಯಾಕೆಂಡ್, ಪಾವತಿ ವ್ಯವಸ್ಥೆ ಅಥವಾ ಇನ್ನೇನಾದರೂ.
• ಅಲ್ಲಿ ಅದು ಸಂಭವಿಸಿತು
  ಯಾವ ನಿರ್ದಿಷ್ಟ ಸರ್ವರ್‌ನಲ್ಲಿ? ಏಕೆಂದರೆ ನೀವು ಒಂದು ಅಪ್ಲಿಕೇಶನ್ ಅಡಿಯಲ್ಲಿ ಹಲವಾರು ಸರ್ವರ್‌ಗಳನ್ನು ಹೊಂದಿದ್ದರೆ ಮತ್ತು ಇದ್ದಕ್ಕಿದ್ದಂತೆ ಒಂದು "ಸ್ಟುಪಿಡ್" ಆಗಿದ್ದರೆ (ಏಕೆಂದರೆ "ಡಿಸ್ಕ್ ಕೊಳೆತವಾಗಿದೆ", "ಮೆಮೊರಿ ಸೋರಿಕೆಯಾಗಿದೆ", ಕೆಲವು ಸಮಸ್ಯೆ), ನಂತರ ನೀವು ನಿರ್ದಿಷ್ಟವಾಗಿ ಸರ್ವರ್ ಅನ್ನು ಪರಿಹರಿಸಬೇಕಾಗಿದೆ.
• ಹೇಗೆ ಸಮಸ್ಯೆ ಒಂದು ರೀತಿಯಲ್ಲಿ ಅಥವಾ ಇನ್ನೊಂದು ರೀತಿಯಲ್ಲಿ ಸ್ವತಃ ಪ್ರಕಟವಾಗುತ್ತದೆ

"ಯಾರು" ನಮಗೆ ವಿನಂತಿಯನ್ನು ಕಳುಹಿಸಿದ್ದಾರೆ ಎಂಬುದನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳಲು, ನಾವು ಪ್ರಮಾಣಿತ ಸಾಧನವನ್ನು ಬಳಸುತ್ತೇವೆ - ಸೆಷನ್ ವೇರಿಯಬಲ್ ಅನ್ನು ಹೊಂದಿಸುವುದು: SET application_name = '{bl-host}:{bl-method}'; — ವಿನಂತಿಯು ಬರುವ ವ್ಯಾಪಾರ ಲಾಜಿಕ್ ಹೋಸ್ಟ್‌ನ ಹೆಸರನ್ನು ಮತ್ತು ಅದನ್ನು ಪ್ರಾರಂಭಿಸಿದ ವಿಧಾನ ಅಥವಾ ಅಪ್ಲಿಕೇಶನ್‌ನ ಹೆಸರನ್ನು ನಾವು ಕಳುಹಿಸುತ್ತೇವೆ.

ನಾವು ವಿನಂತಿಯ “ಮಾಲೀಕರನ್ನು” ರವಾನಿಸಿದ ನಂತರ, ಅದು ಲಾಗ್‌ಗೆ ಔಟ್‌ಪುಟ್ ಆಗಿರಬೇಕು - ಇದಕ್ಕಾಗಿ ನಾವು ವೇರಿಯಬಲ್ ಅನ್ನು ಕಾನ್ಫಿಗರ್ ಮಾಡುತ್ತೇವೆ log_line_prefix = ' %m [%p:%v] [%d] %r %a'. ಆಸಕ್ತರಿಗೆ, ಬಹುಶಃ ಕೈಪಿಡಿಯಲ್ಲಿ ನೋಡಿಇದೆಲ್ಲದರ ಅರ್ಥವೇನು. ನಾವು ಲಾಗ್‌ನಲ್ಲಿ ನೋಡುತ್ತೇವೆ ಎಂದು ಅದು ತಿರುಗುತ್ತದೆ:

• время
• ಪ್ರಕ್ರಿಯೆ ಮತ್ತು ವಹಿವಾಟು ಗುರುತಿಸುವಿಕೆಗಳು
• ಡೇಟಾಬೇಸ್ ಹೆಸರು
• ಈ ವಿನಂತಿಯನ್ನು ಕಳುಹಿಸಿದ ವ್ಯಕ್ತಿಯ IP
• ಮತ್ತು ವಿಧಾನದ ಹೆಸರು

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

ಹಾಗಾಗಿ ಕಟ್ ಇಲ್ಲಿದೆ "ಒಂದು ಸರ್ವರ್ - ಒಂದು ದಿನ" ಯಾವುದೇ ವಿಶ್ಲೇಷಣೆಗೆ ಇದು ನಮಗೆ ಸಾಕಾಗುತ್ತದೆ.

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

ನಾವು ನಿರ್ದಿಷ್ಟ ನಿದರ್ಶನಗಳಿಂದ ಟೆಂಪ್ಲೇಟ್‌ಗಳಿಗೆ ಸ್ಥಳಾಂತರಗೊಂಡಾಗ, ನಾವು ಏಕಕಾಲದಲ್ಲಿ ಎರಡು ಪ್ರಯೋಜನಗಳನ್ನು ಪಡೆದುಕೊಂಡಿದ್ದೇವೆ:

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

ಉಳಿದ ವಿಧಾನಗಳು ನಾವು ಯೋಜನೆಯಿಂದ ಹೊರತೆಗೆಯುವ ಸೂಚಕಗಳನ್ನು ಆಧರಿಸಿವೆ: ಅಂತಹ ಮಾದರಿಯು ಎಷ್ಟು ಬಾರಿ ಸಂಭವಿಸಿದೆ, ಒಟ್ಟು ಮತ್ತು ಸರಾಸರಿ ಸಮಯ, ಡಿಸ್ಕ್ನಿಂದ ಎಷ್ಟು ಡೇಟಾವನ್ನು ಓದಲಾಗಿದೆ ಮತ್ತು ಮೆಮೊರಿಯಿಂದ ಎಷ್ಟು ...

ಏಕೆಂದರೆ, ಉದಾಹರಣೆಗೆ, ನೀವು ಹೋಸ್ಟ್‌ಗಾಗಿ ಅನಾಲಿಟಿಕ್ಸ್ ಪುಟಕ್ಕೆ ಬರುತ್ತೀರಿ, ನೋಡಿ - ಡಿಸ್ಕ್‌ನಲ್ಲಿ ಏನಾದರೂ ಹೆಚ್ಚು ಓದಲು ಪ್ರಾರಂಭಿಸುತ್ತಿದೆ. ಸರ್ವರ್‌ನಲ್ಲಿರುವ ಡಿಸ್ಕ್ ಅದನ್ನು ನಿಭಾಯಿಸಲು ಸಾಧ್ಯವಿಲ್ಲ - ಅದನ್ನು ಯಾರು ಓದುತ್ತಾರೆ?

ಮತ್ತು ನೀವು ಯಾವುದೇ ಕಾಲಮ್‌ನಿಂದ ವಿಂಗಡಿಸಬಹುದು ಮತ್ತು ಇದೀಗ ನೀವು ಏನು ವ್ಯವಹರಿಸುತ್ತೀರಿ ಎಂಬುದನ್ನು ನಿರ್ಧರಿಸಬಹುದು - ಪ್ರೊಸೆಸರ್ ಅಥವಾ ಡಿಸ್ಕ್‌ನಲ್ಲಿನ ಲೋಡ್ ಅಥವಾ ಒಟ್ಟು ವಿನಂತಿಗಳ ಸಂಖ್ಯೆ... ನಾವು ಅದನ್ನು ವಿಂಗಡಿಸಿದ್ದೇವೆ, "ಟಾಪ್" ಅನ್ನು ನೋಡಿದ್ದೇವೆ, ಅದನ್ನು ಸರಿಪಡಿಸಿದ್ದೇವೆ ಮತ್ತು ಅಪ್ಲಿಕೇಶನ್‌ನ ಹೊಸ ಆವೃತ್ತಿಯನ್ನು ಹೊರತಂದಿದೆ.
[ವಿಡಿಯೋ ಉಪನ್ಯಾಸ]

ಮತ್ತು ತಕ್ಷಣವೇ ನೀವು ವಿನಂತಿಯಿಂದ ಒಂದೇ ಟೆಂಪ್ಲೇಟ್‌ನೊಂದಿಗೆ ಬರುವ ವಿವಿಧ ಅಪ್ಲಿಕೇಶನ್‌ಗಳನ್ನು ನೋಡಬಹುದು SELECT * FROM users WHERE login = 'Vasya'. ಮುಂಭಾಗ, ಬ್ಯಾಕೆಂಡ್, ಸಂಸ್ಕರಣೆ... ಮತ್ತು ಬಳಕೆದಾರನು ಅವನೊಂದಿಗೆ ಸಂವಹನ ನಡೆಸದಿದ್ದರೆ ಸಂಸ್ಕರಣೆಯು ಏಕೆ ಓದುತ್ತದೆ ಎಂದು ನೀವು ಆಶ್ಚರ್ಯ ಪಡುತ್ತೀರಿ.

ಇದಕ್ಕೆ ವಿರುದ್ಧವಾದ ಮಾರ್ಗವೆಂದರೆ ಅದು ಏನು ಮಾಡುತ್ತದೆ ಎಂಬುದನ್ನು ಅಪ್ಲಿಕೇಶನ್‌ನಿಂದ ತಕ್ಷಣವೇ ನೋಡುವುದು. ಉದಾಹರಣೆಗೆ, ಮುಂಭಾಗವು ಇದು, ಇದು, ಇದು, ಮತ್ತು ಇದು ಗಂಟೆಗೆ ಒಮ್ಮೆ (ಟೈಮ್ಲೈನ್ ​​ಸಹಾಯ ಮಾಡುತ್ತದೆ). ಮತ್ತು ಪ್ರಶ್ನೆ ತಕ್ಷಣವೇ ಉದ್ಭವಿಸುತ್ತದೆ: ಗಂಟೆಗೆ ಒಮ್ಮೆ ಏನನ್ನಾದರೂ ಮಾಡುವುದು ಮುಂಭಾಗದ ಕೆಲಸವಲ್ಲ ಎಂದು ತೋರುತ್ತದೆ ...

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

ನೀವು ಪ್ಲೇಟ್‌ನಲ್ಲಿ ಸೂಕ್ತವಾದ ಸೂಚ್ಯಂಕವನ್ನು ಹೊಂದಿಲ್ಲ, ನೀವು ಅದಕ್ಕೆ ವಿನಂತಿಯನ್ನು ಮಾಡುತ್ತೀರಿ, ಅದು ಸೂಚ್ಯಂಕದ ಹಿಂದೆ ಹಾರುತ್ತದೆ, ಸೆಕ್ ಸ್ಕ್ಯಾನ್‌ಗೆ ಬೀಳುತ್ತದೆ... ಒಂದನ್ನು ಹೊರತುಪಡಿಸಿ ನೀವು ಎಲ್ಲಾ ದಾಖಲೆಗಳನ್ನು ಫಿಲ್ಟರ್ ಮಾಡಿದ್ದೀರಿ. ನಿಮಗೆ ದಿನಕ್ಕೆ 100M ಫಿಲ್ಟರ್ ಮಾಡಿದ ದಾಖಲೆಗಳು ಏಕೆ ಬೇಕು? ಸೂಚ್ಯಂಕವನ್ನು ಸುತ್ತಿಕೊಳ್ಳುವುದು ಉತ್ತಮವಲ್ಲವೇ?

ಎಲ್ಲಾ ಪ್ಲಾನ್‌ಗಳನ್ನು ನೋಡ್ ಮೂಲಕ ವಿಶ್ಲೇಷಿಸಿದ ನಂತರ, ಪ್ಲಾನ್‌ಗಳಲ್ಲಿ ಕೆಲವು ವಿಶಿಷ್ಟ ರಚನೆಗಳು ಅನುಮಾನಾಸ್ಪದವಾಗಿ ಕಾಣುವ ಸಾಧ್ಯತೆಯಿದೆ ಎಂದು ನಾವು ಅರಿತುಕೊಂಡಿದ್ದೇವೆ. ಮತ್ತು ಡೆವಲಪರ್‌ಗೆ ಹೇಳುವುದು ಒಳ್ಳೆಯದು: “ಸ್ನೇಹಿತ, ಇಲ್ಲಿ ನೀವು ಮೊದಲು ಸೂಚ್ಯಂಕದಿಂದ ಓದುತ್ತೀರಿ, ನಂತರ ವಿಂಗಡಿಸಿ ಮತ್ತು ನಂತರ ಕತ್ತರಿಸಿ” - ನಿಯಮದಂತೆ, ಒಂದು ದಾಖಲೆ ಇದೆ.

ಪ್ರಶ್ನೆಗಳನ್ನು ಬರೆದ ಪ್ರತಿಯೊಬ್ಬರೂ ಬಹುಶಃ ಈ ಮಾದರಿಯನ್ನು ಎದುರಿಸಿದ್ದಾರೆ: “ವಾಸ್ಯಾಗೆ ಕೊನೆಯ ಆದೇಶವನ್ನು ನೀಡಿ, ಅದರ ದಿನಾಂಕ.” ಮತ್ತು ನೀವು ದಿನಾಂಕದ ಪ್ರಕಾರ ಸೂಚ್ಯಂಕವನ್ನು ಹೊಂದಿಲ್ಲದಿದ್ದರೆ ಅಥವಾ ನೀವು ಬಳಸಿದ ಸೂಚ್ಯಂಕದಲ್ಲಿ ಯಾವುದೇ ದಿನಾಂಕವಿಲ್ಲದಿದ್ದರೆ, ನೀವು ನಿಖರವಾಗಿ ಅದೇ "ಕುಂಟೆ" ಮೇಲೆ ಹೆಜ್ಜೆ .

ಆದರೆ ಇದು “ಕುಂಟೆ” ಎಂದು ನಮಗೆ ತಿಳಿದಿದೆ - ಆದ್ದರಿಂದ ಡೆವಲಪರ್ ಏನು ಮಾಡಬೇಕೆಂದು ತಕ್ಷಣ ಏಕೆ ಹೇಳಬಾರದು. ಅಂತೆಯೇ, ಈಗ ಯೋಜನೆಯನ್ನು ತೆರೆಯುವಾಗ, ನಮ್ಮ ಡೆವಲಪರ್ ತಕ್ಷಣ ಸುಳಿವುಗಳೊಂದಿಗೆ ಸುಂದರವಾದ ಚಿತ್ರವನ್ನು ನೋಡುತ್ತಾರೆ, ಅಲ್ಲಿ ಅವರು ತಕ್ಷಣವೇ ಅವನಿಗೆ ಹೇಳುತ್ತಾರೆ: "ನಿಮಗೆ ಇಲ್ಲಿ ಮತ್ತು ಅಲ್ಲಿ ಸಮಸ್ಯೆಗಳಿವೆ, ಆದರೆ ಅವುಗಳನ್ನು ಈ ರೀತಿಯಲ್ಲಿ ಮತ್ತು ಆ ರೀತಿಯಲ್ಲಿ ಪರಿಹರಿಸಲಾಗುತ್ತದೆ."

ಪರಿಣಾಮವಾಗಿ, ಆರಂಭದಲ್ಲಿ ಮತ್ತು ಈಗ ಸಮಸ್ಯೆಗಳನ್ನು ಪರಿಹರಿಸಲು ಅಗತ್ಯವಿರುವ ಅನುಭವದ ಪ್ರಮಾಣವು ಗಮನಾರ್ಹವಾಗಿ ಕುಸಿದಿದೆ. ಇದು ನಮ್ಮಲ್ಲಿರುವ ಸಾಧನವಾಗಿದೆ.

ಮೂಲ: www.habr.com