ಪ್ರಮಾಣಿತ ಪಾಕವಿಧಾನಗಳನ್ನು ಹೇಗೆ ಬಳಸುವುದು ಎಂದು ಇತ್ತೀಚೆಗೆ ನಾನು ನಿಮಗೆ ಹೇಳಿದೆ PostgreSQL ಡೇಟಾಬೇಸ್‌ನಿಂದ. ಇಂದು ನಾವು ಹೇಗೆ ಮಾತನಾಡುತ್ತೇವೆ ರೆಕಾರ್ಡಿಂಗ್ ಅನ್ನು ಹೆಚ್ಚು ಪರಿಣಾಮಕಾರಿಯಾಗಿ ಮಾಡಬಹುದು ಸಂರಚನೆಯಲ್ಲಿ ಯಾವುದೇ "ತಿರುವುಗಳನ್ನು" ಬಳಸದೆ ಡೇಟಾಬೇಸ್‌ನಲ್ಲಿ - ಡೇಟಾ ಹರಿವುಗಳನ್ನು ಸರಿಯಾಗಿ ಸಂಘಟಿಸುವ ಮೂಲಕ.
#1. ವಿಭಾಗೀಕರಣ
ಹೇಗೆ ಮತ್ತು ಏಕೆ ಸಂಘಟಿಸಲು ಯೋಗ್ಯವಾಗಿದೆ ಎಂಬುದರ ಕುರಿತು ಲೇಖನ ಈಗಾಗಲೇ ಬಂದಿದೆ, ಇಲ್ಲಿ ನಾವು ನಮ್ಮೊಳಗೆ ಕೆಲವು ವಿಧಾನಗಳನ್ನು ಅನ್ವಯಿಸುವ ಅಭ್ಯಾಸದ ಬಗ್ಗೆ ಮಾತನಾಡುತ್ತೇವೆ .
"ಹಿಂದಿನ ದಿನಗಳ ಸಂಗತಿಗಳು..."
ಆರಂಭದಲ್ಲಿ, ಯಾವುದೇ MVP ಯಂತೆ, ನಮ್ಮ ಯೋಜನೆಯು ಸಾಕಷ್ಟು ಹಗುರವಾದ ಲೋಡ್‌ನಲ್ಲಿ ಪ್ರಾರಂಭವಾಯಿತು - ಹತ್ತು ಅತ್ಯಂತ ನಿರ್ಣಾಯಕ ಸರ್ವರ್‌ಗಳಿಗೆ ಮಾತ್ರ ಮೇಲ್ವಿಚಾರಣೆಯನ್ನು ನಡೆಸಲಾಯಿತು, ಎಲ್ಲಾ ಕೋಷ್ಟಕಗಳು ತುಲನಾತ್ಮಕವಾಗಿ ಸಾಂದ್ರವಾಗಿರುತ್ತವೆ ... ಆದರೆ ಸಮಯ ಕಳೆದಂತೆ, ಮಾನಿಟರ್ ಮಾಡಲಾದ ಹೋಸ್ಟ್‌ಗಳ ಸಂಖ್ಯೆಯು ಹೆಚ್ಚು ಹೆಚ್ಚು ಆಯಿತು. , ಮತ್ತು ಮತ್ತೊಮ್ಮೆ ನಾವು ಒಂದರಲ್ಲಿ ಏನನ್ನಾದರೂ ಮಾಡಲು ಪ್ರಯತ್ನಿಸಿದ್ದೇವೆ ಕೋಷ್ಟಕಗಳು 1.5TB ಗಾತ್ರದಲ್ಲಿ, ಹೀಗೆಯೇ ಬದುಕುವುದನ್ನು ಮುಂದುವರಿಸುವುದು ಸಾಧ್ಯವಿದ್ದರೂ, ಅದು ತುಂಬಾ ಅನಾನುಕೂಲವಾಗಿದೆ ಎಂದು ನಾವು ಅರಿತುಕೊಂಡೆವು.
ಸಮಯವು ಮಹಾಕಾವ್ಯದ ಸಮಯಗಳಂತೆಯೇ ಇತ್ತು, PostgreSQL 9.x ನ ವಿಭಿನ್ನ ಆವೃತ್ತಿಗಳು ಪ್ರಸ್ತುತವಾಗಿವೆ, ಆದ್ದರಿಂದ ಎಲ್ಲಾ ವಿಭಜನೆಯನ್ನು "ಹಸ್ತಚಾಲಿತವಾಗಿ" ಮಾಡಬೇಕಾಗಿತ್ತು - ಮೂಲಕ ಟೇಬಲ್ ಆನುವಂಶಿಕತೆ ಮತ್ತು ಪ್ರಚೋದಕಗಳು ಡೈನಾಮಿಕ್ ಜೊತೆ ರೂಟಿಂಗ್ EXECUTE.
ಪರಿಣಾಮವಾಗಿ ಪರಿಹಾರವು ಸಾರ್ವತ್ರಿಕವಾಗಿ ಹೊರಹೊಮ್ಮಿತು ಮತ್ತು ಅದನ್ನು ಎಲ್ಲಾ ಕೋಷ್ಟಕಗಳಿಗೆ ಅನುವಾದಿಸಬಹುದು:
- ಖಾಲಿ "ಹೆಡರ್" ಪೇರೆಂಟ್ ಟೇಬಲ್ ಅನ್ನು ಘೋಷಿಸಲಾಗಿದೆ, ಅದು ಎಲ್ಲವನ್ನೂ ವಿವರಿಸಿದೆ ಅಗತ್ಯ ಸೂಚ್ಯಂಕಗಳು ಮತ್ತು ಪ್ರಚೋದಕಗಳು.
- ಕ್ಲೈಂಟ್ನ ದೃಷ್ಟಿಕೋನದಿಂದ ದಾಖಲೆಯನ್ನು "ರೂಟ್" ಕೋಷ್ಟಕದಲ್ಲಿ ಮಾಡಲಾಗಿದೆ ಮತ್ತು ಆಂತರಿಕವಾಗಿ ಬಳಸಲಾಗಿದೆ ರೂಟಿಂಗ್ ಪ್ರಚೋದಕ
BEFORE INSERTದಾಖಲೆಯನ್ನು ಅಗತ್ಯವಿರುವ ವಿಭಾಗಕ್ಕೆ "ಭೌತಿಕವಾಗಿ" ಸೇರಿಸಲಾಯಿತು. ಇನ್ನೂ ಅಂತಹ ವಿಷಯವಿಲ್ಲದಿದ್ದರೆ, ನಾವು ವಿನಾಯಿತಿಯನ್ನು ಹೊಂದಿದ್ದೇವೆ ಮತ್ತು... - … ಬಳಸಿಕೊಂಡು ಪೋಷಕ ಕೋಷ್ಟಕದ ಟೆಂಪ್ಲೇಟ್ ಅನ್ನು ಆಧರಿಸಿ ರಚಿಸಲಾಗಿದೆ ಅಪೇಕ್ಷಿತ ದಿನಾಂಕದ ಮೇಲೆ ನಿರ್ಬಂಧದೊಂದಿಗೆ ವಿಭಾಗಆದ್ದರಿಂದ ಡೇಟಾವನ್ನು ಹಿಂಪಡೆಯಿದಾಗ, ಓದುವಿಕೆಯನ್ನು ಅದರಲ್ಲಿ ಮಾತ್ರ ನಿರ್ವಹಿಸಲಾಗುತ್ತದೆ.
PG10: ಮೊದಲ ಪ್ರಯತ್ನ
ಆದರೆ ಆನುವಂಶಿಕತೆಯ ಮೂಲಕ ವಿಭಜನೆಯು ಐತಿಹಾಸಿಕವಾಗಿ ಸಕ್ರಿಯ ಬರವಣಿಗೆ ಸ್ಟ್ರೀಮ್ ಅಥವಾ ಹೆಚ್ಚಿನ ಸಂಖ್ಯೆಯ ಮಕ್ಕಳ ವಿಭಾಗಗಳೊಂದಿಗೆ ವ್ಯವಹರಿಸಲು ಸೂಕ್ತವಾಗಿಲ್ಲ. ಉದಾಹರಣೆಗೆ, ಅಗತ್ಯವಿರುವ ವಿಭಾಗವನ್ನು ಆಯ್ಕೆ ಮಾಡುವ ಅಲ್ಗಾರಿದಮ್ ಅನ್ನು ನೀವು ನೆನಪಿಸಿಕೊಳ್ಳಬಹುದು ಚತುರ್ಭುಜ ಸಂಕೀರ್ಣತೆ, ಇದು 100+ ವಿಭಾಗಗಳೊಂದಿಗೆ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ, ಹೇಗೆ ಎಂದು ನೀವೇ ಅರ್ಥಮಾಡಿಕೊಂಡಿದ್ದೀರಿ...
PG10 ನಲ್ಲಿ ಈ ಪರಿಸ್ಥಿತಿಯು ಬೆಂಬಲವನ್ನು ಅಳವಡಿಸುವ ಮೂಲಕ ಹೆಚ್ಚು ಹೊಂದುವಂತೆ ಮಾಡಲಾಗಿದೆ . ಆದ್ದರಿಂದ, ಶೇಖರಣೆಯನ್ನು ಸ್ಥಳಾಂತರಿಸಿದ ನಂತರ ನಾವು ತಕ್ಷಣ ಅದನ್ನು ಅನ್ವಯಿಸಲು ಪ್ರಯತ್ನಿಸಿದ್ದೇವೆ, ಆದರೆ...
ಕೈಪಿಡಿಯನ್ನು ಅಗೆದ ನಂತರ ಅದು ಬದಲಾದಂತೆ, ಈ ಆವೃತ್ತಿಯಲ್ಲಿ ಸ್ಥಳೀಯವಾಗಿ ವಿಭಜಿಸಿದ ಟೇಬಲ್:
- ಸೂಚ್ಯಂಕ ವಿವರಣೆಯನ್ನು ಬೆಂಬಲಿಸುವುದಿಲ್ಲ
- ಅದರ ಮೇಲೆ ಪ್ರಚೋದಕಗಳನ್ನು ಬೆಂಬಲಿಸುವುದಿಲ್ಲ
- ಯಾರೊಬ್ಬರ "ವಂಶಸ್ಥರು" ಆಗಲು ಸಾಧ್ಯವಿಲ್ಲ
- ಬೆಂಬಲಿಸುವುದಿಲ್ಲ
INSERT ... ON CONFLICT - ಸ್ವಯಂಚಾಲಿತವಾಗಿ ವಿಭಾಗವನ್ನು ರಚಿಸಲು ಸಾಧ್ಯವಿಲ್ಲ
ಕುಂಟೆಯಿಂದ ಹಣೆಗೆ ನೋವಿನ ಹೊಡೆತವನ್ನು ಪಡೆದ ನಂತರ, ಅಪ್ಲಿಕೇಶನ್ ಅನ್ನು ಮಾರ್ಪಡಿಸದೆ ಮಾಡುವುದು ಅಸಾಧ್ಯವೆಂದು ನಾವು ಅರಿತುಕೊಂಡೆವು ಮತ್ತು ಹೆಚ್ಚಿನ ಸಂಶೋಧನೆಯನ್ನು ಆರು ತಿಂಗಳವರೆಗೆ ಮುಂದೂಡಿದ್ದೇವೆ.
PG10: ಎರಡನೇ ಅವಕಾಶ
ಆದ್ದರಿಂದ, ನಾವು ಉದ್ಭವಿಸಿದ ಸಮಸ್ಯೆಗಳನ್ನು ಒಂದೊಂದಾಗಿ ಪರಿಹರಿಸಲು ಪ್ರಾರಂಭಿಸಿದ್ದೇವೆ:
- ಏಕೆಂದರೆ ಪ್ರಚೋದಕಗಳು ಮತ್ತು
ON CONFLICTನಮಗೆ ಇನ್ನೂ ಅಲ್ಲಿ ಇಲ್ಲಿ ಅಗತ್ಯವಿದೆ ಎಂದು ನಾವು ಕಂಡುಕೊಂಡಿದ್ದೇವೆ, ಆದ್ದರಿಂದ ನಾವು ಅವುಗಳನ್ನು ಕೆಲಸ ಮಾಡಲು ಮಧ್ಯಂತರ ಹಂತವನ್ನು ಮಾಡಿದ್ದೇವೆ ಪ್ರಾಕ್ಸಿ ಟೇಬಲ್. - "ರೂಟಿಂಗ್" ತೊಡೆದುಹಾಕಿದೆ ಪ್ರಚೋದಕಗಳಲ್ಲಿ - ಅಂದರೆ, ಇಂದ
EXECUTE. - ಅವರು ಅದನ್ನು ಪ್ರತ್ಯೇಕವಾಗಿ ತೆಗೆದುಕೊಂಡರು ಎಲ್ಲಾ ಸೂಚಿಕೆಗಳೊಂದಿಗೆ ಟೆಂಪ್ಲೇಟ್ ಟೇಬಲ್ಆದ್ದರಿಂದ ಅವು ಪ್ರಾಕ್ಸಿ ಟೇಬಲ್‌ನಲ್ಲಿಯೂ ಇರುವುದಿಲ್ಲ.
ಅಂತಿಮವಾಗಿ, ಈ ಎಲ್ಲಾ ನಂತರ, ನಾವು ಮುಖ್ಯ ಟೇಬಲ್ ಅನ್ನು ಸ್ಥಳೀಯವಾಗಿ ವಿಂಗಡಿಸಿದ್ದೇವೆ. ಹೊಸ ವಿಭಾಗದ ರಚನೆಯನ್ನು ಇನ್ನೂ ಅಪ್ಲಿಕೇಶನ್‌ನ ಆತ್ಮಸಾಕ್ಷಿಗೆ ಬಿಡಲಾಗಿದೆ.
"ಗರಗಸ" ನಿಘಂಟುಗಳು
ಯಾವುದೇ ವಿಶ್ಲೇಷಣಾತ್ಮಕ ವ್ಯವಸ್ಥೆಯಲ್ಲಿರುವಂತೆ, ನಾವು ಸಹ ಹೊಂದಿದ್ದೇವೆ "ವಾಸ್ತವಗಳು" ಮತ್ತು "ಕಡಿತಗಳು" (ನಿಘಂಟುಗಳು). ನಮ್ಮ ಸಂದರ್ಭದಲ್ಲಿ, ಈ ಸಾಮರ್ಥ್ಯದಲ್ಲಿ ಅವರು ಕಾರ್ಯನಿರ್ವಹಿಸಿದರು, ಉದಾಹರಣೆಗೆ, ಇದೇ ರೀತಿಯ ನಿಧಾನ ಪ್ರಶ್ನೆಗಳು ಅಥವಾ ಪ್ರಶ್ನೆಯ ಪಠ್ಯ.
"ವಾಸ್ತವಗಳು" ಈಗಾಗಲೇ ದೀರ್ಘಕಾಲದವರೆಗೆ ದಿನದಿಂದ ವಿಭಾಗಿಸಲ್ಪಟ್ಟಿವೆ, ಆದ್ದರಿಂದ ನಾವು ಶಾಂತವಾಗಿ ಹಳತಾದ ವಿಭಾಗಗಳನ್ನು ಅಳಿಸಿದ್ದೇವೆ ಮತ್ತು ಅವು ನಮ್ಮನ್ನು ತೊಂದರೆಗೊಳಿಸಲಿಲ್ಲ (ಲಾಗ್ಗಳು!). ಆದರೆ ಡಿಕ್ಷನರಿಯಲ್ಲಿ ಸಮಸ್ಯೆ ಇತ್ತು...
ಅವುಗಳಲ್ಲಿ ಬಹಳಷ್ಟು ಇದ್ದವು ಎಂದು ಹೇಳಬಾರದು, ಆದರೆ ಸರಿಸುಮಾರು 100TB "ವಾಸ್ತವಗಳು" 2.5TB ನಿಘಂಟಿಗೆ ಕಾರಣವಾಯಿತು. ಅಂತಹ ಟೇಬಲ್‌ನಿಂದ ನೀವು ಯಾವುದನ್ನೂ ಅನುಕೂಲಕರವಾಗಿ ಅಳಿಸಲು ಸಾಧ್ಯವಿಲ್ಲ, ನೀವು ಅದನ್ನು ಸಾಕಷ್ಟು ಸಮಯದಲ್ಲಿ ಸಂಕುಚಿತಗೊಳಿಸಲಾಗುವುದಿಲ್ಲ ಮತ್ತು ಅದಕ್ಕೆ ಬರೆಯುವುದು ಕ್ರಮೇಣ ನಿಧಾನವಾಯಿತು.
ನಿಘಂಟಿನಂತೆ... ಅದರಲ್ಲಿ, ಪ್ರತಿ ನಮೂದನ್ನು ನಿಖರವಾಗಿ ಒಮ್ಮೆ ಪ್ರಸ್ತುತಪಡಿಸಬೇಕು ... ಮತ್ತು ಇದು ಸರಿಯಾಗಿದೆ, ಆದರೆ!.. ಯಾರೂ ನಮಗೆ ಹೊಂದುವುದನ್ನು ತಡೆಯುವುದಿಲ್ಲ ಪ್ರತಿ ದಿನ ಪ್ರತ್ಯೇಕ ನಿಘಂಟು! ಹೌದು, ಇದು ಒಂದು ನಿರ್ದಿಷ್ಟ ಪುನರಾವರ್ತನೆಯನ್ನು ತರುತ್ತದೆ, ಆದರೆ ಇದು ಅನುಮತಿಸುತ್ತದೆ:
- ವೇಗವಾಗಿ ಬರೆಯಿರಿ/ಓದಿ ಸಣ್ಣ ವಿಭಾಗದ ಗಾತ್ರದ ಕಾರಣ
- ಕಡಿಮೆ ಸ್ಮರಣೆಯನ್ನು ಬಳಸುತ್ತದೆ ಹೆಚ್ಚು ಕಾಂಪ್ಯಾಕ್ಟ್ ಇಂಡೆಕ್ಸ್‌ಗಳೊಂದಿಗೆ ಕೆಲಸ ಮಾಡುವ ಮೂಲಕ
- ಕಡಿಮೆ ಡೇಟಾವನ್ನು ಸಂಗ್ರಹಿಸಿ ಹಳೆಯದನ್ನು ತ್ವರಿತವಾಗಿ ತೆಗೆದುಹಾಕುವ ಸಾಮರ್ಥ್ಯದಿಂದಾಗಿ
ಕ್ರಮಗಳ ಸಂಪೂರ್ಣ ಸಂಕೀರ್ಣದ ಪರಿಣಾಮವಾಗಿ CPU ಲೋಡ್ ~30%, ಡಿಸ್ಕ್ ಲೋಡ್ ~50% ಕಡಿಮೆಯಾಗಿದೆ:
ಅದೇ ಸಮಯದಲ್ಲಿ, ನಾವು ಕಡಿಮೆ ಲೋಡ್‌ನೊಂದಿಗೆ ಡೇಟಾಬೇಸ್‌ನಲ್ಲಿ ಒಂದೇ ವಿಷಯವನ್ನು ಬರೆಯುವುದನ್ನು ಮುಂದುವರಿಸಿದ್ದೇವೆ.
#2. ಡೇಟಾಬೇಸ್ ಎವಲ್ಯೂಷನ್ ಮತ್ತು ರಿಫ್ಯಾಕ್ಟರಿಂಗ್
ಹಾಗಾಗಿ ನಮ್ಮಲ್ಲಿರುವುದರಲ್ಲಿ ನಾವು ನೆಲೆಸಿದ್ದೇವೆ ಪ್ರತಿ ದಿನ ತನ್ನದೇ ಆದ ವಿಭಾಗವನ್ನು ಹೊಂದಿದೆ ಡೇಟಾದೊಂದಿಗೆ. ವಾಸ್ತವವಾಗಿ, CHECK (dt = '2018-10-12'::date) — ಮತ್ತು ಒಂದು ವಿಭಜನಾ ಕೀ ಮತ್ತು ಒಂದು ನಿರ್ದಿಷ್ಟ ವಿಭಾಗದಲ್ಲಿ ಬೀಳಲು ದಾಖಲೆಯ ಸ್ಥಿತಿ ಇದೆ.
ನಮ್ಮ ಸೇವೆಯಲ್ಲಿನ ಎಲ್ಲಾ ವರದಿಗಳನ್ನು ನಿರ್ದಿಷ್ಟ ದಿನಾಂಕದ ಸಂದರ್ಭದಲ್ಲಿ ನಿರ್ಮಿಸಲಾಗಿರುವುದರಿಂದ, "ವಿಭಜನೆಯಾಗದ ಸಮಯಗಳಿಂದ" ಅವುಗಳಿಗೆ ಸೂಚ್ಯಂಕಗಳು ಎಲ್ಲಾ ಪ್ರಕಾರಗಳಾಗಿವೆ (ಸರ್ವರ್, ದಿನಾಂಕ, ಯೋಜನೆ ಟೆಂಪ್ಲೇಟ್), (ಸರ್ವರ್, ದಿನಾಂಕ, ಪ್ಲಾನ್ ನೋಡ್), (ದಿನಾಂಕ, ದೋಷ ವರ್ಗ, ಸರ್ವರ್), ...
ಆದರೆ ಈಗ ಅವರು ಎಲ್ಲಾ ವಿಭಾಗಗಳಲ್ಲಿ ವಾಸಿಸುತ್ತಿದ್ದಾರೆ ನಿಮ್ಮ ಪ್ರತಿಗಳು ಅಂತಹ ಪ್ರತಿಯೊಂದು ಸೂಚ್ಯಂಕ... ಮತ್ತು ಪ್ರತಿ ವಿಭಾಗದೊಳಗೆ ದಿನಾಂಕ ಸ್ಥಿರವಾಗಿರುತ್ತದೆ... ಈಗ ನಾವು ಅಂತಹ ಪ್ರತಿಯೊಂದು ಸೂಚ್ಯಂಕದಲ್ಲಿದ್ದೇವೆ ಎಂದು ಅದು ತಿರುಗುತ್ತದೆ ಸರಳವಾಗಿ ಸ್ಥಿರವನ್ನು ನಮೂದಿಸಿ ಕ್ಷೇತ್ರಗಳಲ್ಲಿ ಒಂದಾಗಿ, ಅದರ ಪರಿಮಾಣ ಮತ್ತು ಅದರ ಹುಡುಕಾಟ ಸಮಯ ಎರಡನ್ನೂ ಹೆಚ್ಚಿಸುತ್ತದೆ, ಆದರೆ ಯಾವುದೇ ಫಲಿತಾಂಶವನ್ನು ತರುವುದಿಲ್ಲ. ಅವರು ಕುಂಟೆಯನ್ನು ತಮ್ಮಷ್ಟಕ್ಕೆ ಬಿಟ್ಟರು, ಅಯ್ಯೋ...
ಆಪ್ಟಿಮೈಸೇಶನ್ ನಿರ್ದೇಶನವು ಸ್ಪಷ್ಟವಾಗಿದೆ - ಸರಳವಾಗಿದೆ ಎಲ್ಲಾ ಸೂಚಿಕೆಗಳಿಂದ ದಿನಾಂಕ ಕ್ಷೇತ್ರವನ್ನು ತೆಗೆದುಹಾಕಿ ವಿಭಜಿತ ಕೋಷ್ಟಕಗಳಲ್ಲಿ. ನಮ್ಮ ಸಂಪುಟಗಳನ್ನು ನೀಡಿದರೆ, ಲಾಭವು ಸುಮಾರು 1TB/ವಾರ!
ಈ ಟೆರಾಬೈಟ್ ಅನ್ನು ಇನ್ನೂ ಹೇಗಾದರೂ ರೆಕಾರ್ಡ್ ಮಾಡಬೇಕಾಗಿತ್ತು ಎಂಬುದನ್ನು ಈಗ ಗಮನಿಸೋಣ. ಅಂದರೆ ನಾವೂ ಕೂಡ ಡಿಸ್ಕ್ ಈಗ ಕಡಿಮೆ ಲೋಡ್ ಆಗಬೇಕು! ಈ ಚಿತ್ರವು ಶುಚಿಗೊಳಿಸುವಿಕೆಯಿಂದ ಪಡೆದ ಪರಿಣಾಮವನ್ನು ಸ್ಪಷ್ಟವಾಗಿ ತೋರಿಸುತ್ತದೆ, ಇದಕ್ಕಾಗಿ ನಾವು ಒಂದು ವಾರವನ್ನು ಮೀಸಲಿಟ್ಟಿದ್ದೇವೆ:
#3. ಗರಿಷ್ಠ ಲೋಡ್ ಅನ್ನು "ಹರಡುವುದು"
ಲೋಡ್ ಮಾಡಲಾದ ವ್ಯವಸ್ಥೆಗಳ ದೊಡ್ಡ ತೊಂದರೆಗಳಲ್ಲಿ ಒಂದಾಗಿದೆ ಅನಗತ್ಯ ಸಿಂಕ್ರೊನೈಸೇಶನ್ ಅಗತ್ಯವಿಲ್ಲದ ಕೆಲವು ಕಾರ್ಯಾಚರಣೆಗಳು. ಕೆಲವೊಮ್ಮೆ "ಅವರು ಗಮನಿಸದ ಕಾರಣ", ಕೆಲವೊಮ್ಮೆ "ಅದು ಸುಲಭವಾಗಿದೆ", ಆದರೆ ಬೇಗ ಅಥವಾ ನಂತರ ನೀವು ಅದನ್ನು ತೊಡೆದುಹಾಕಬೇಕು.
ಹಿಂದಿನ ಚಿತ್ರವನ್ನು ಜೂಮ್ ಮಾಡಿ ಮತ್ತು ನಮ್ಮಲ್ಲಿ ಡಿಸ್ಕ್ ಇದೆಯೇ ಎಂದು ನೋಡೋಣ ಡಬಲ್ ವೈಶಾಲ್ಯದೊಂದಿಗೆ ಲೋಡ್ ಅಡಿಯಲ್ಲಿ "ಪಂಪ್ಗಳು" ಪಕ್ಕದ ಮಾದರಿಗಳ ನಡುವೆ, ಅಂತಹ ಹಲವಾರು ಕಾರ್ಯಾಚರಣೆಗಳೊಂದಿಗೆ ಸ್ಪಷ್ಟವಾಗಿ "ಸಂಖ್ಯಾಶಾಸ್ತ್ರೀಯವಾಗಿ" ಸಂಭವಿಸಬಾರದು:
ಇದನ್ನು ಸಾಧಿಸಲು ಸಾಕಷ್ಟು ಸುಲಭ. ನಾವು ಈಗಾಗಲೇ ಮೇಲ್ವಿಚಾರಣೆ ಆರಂಭಿಸಿದ್ದೇವೆ ಸುಮಾರು 1000 ಸರ್ವರ್‌ಗಳು, ಪ್ರತಿಯೊಂದನ್ನು ಪ್ರತ್ಯೇಕ ತಾರ್ಕಿಕ ಥ್ರೆಡ್‌ನಿಂದ ಪ್ರಕ್ರಿಯೆಗೊಳಿಸಲಾಗುತ್ತದೆ ಮತ್ತು ಪ್ರತಿ ಥ್ರೆಡ್ ಒಂದು ನಿರ್ದಿಷ್ಟ ಆವರ್ತನದಲ್ಲಿ ಡೇಟಾಬೇಸ್‌ಗೆ ಕಳುಹಿಸಬೇಕಾದ ಸಂಗ್ರಹವಾದ ಮಾಹಿತಿಯನ್ನು ಮರುಹೊಂದಿಸುತ್ತದೆ, ಈ ರೀತಿ:
setInterval(sendToDB, interval)ಇಲ್ಲಿ ಸಮಸ್ಯೆ ನಿಖರವಾಗಿ ವಾಸ್ತವವಾಗಿ ಇರುತ್ತದೆ ಎಲ್ಲಾ ಎಳೆಗಳು ಸರಿಸುಮಾರು ಒಂದೇ ಸಮಯದಲ್ಲಿ ಪ್ರಾರಂಭವಾಗುತ್ತವೆ, ಆದ್ದರಿಂದ ಅವರು ಕಳುಹಿಸುವ ಸಮಯವು ಯಾವಾಗಲೂ "ಬಿಂದುವಿಗೆ" ಹೊಂದಿಕೆಯಾಗುತ್ತದೆ. ಓಹ್ #2...
ಅದೃಷ್ಟವಶಾತ್, ಇದನ್ನು ಸರಿಪಡಿಸಲು ತುಂಬಾ ಸುಲಭ, "ಯಾದೃಚ್ಛಿಕ" ರನ್-ಅಪ್ ಅನ್ನು ಸೇರಿಸುವುದು ಸಮಯಕ್ಕೆ:
setInterval(sendToDB, interval * (1 + 0.1 * (Math.random() - 0.5)))#4. ನಮಗೆ ಬೇಕಾದುದನ್ನು ನಾವು ಸಂಗ್ರಹಿಸುತ್ತೇವೆ
ಮೂರನೆಯ ಸಾಂಪ್ರದಾಯಿಕ ಹೈಲೋಡ್ ಸಮಸ್ಯೆ ಯಾವುದೇ ಸಂಗ್ರಹವಿಲ್ಲ ಅವನು ಎಲ್ಲಿದ್ದಾನೆ ಸಾಧ್ಯವೋ ಎಂದು.
ಉದಾಹರಣೆಗೆ, ಪ್ಲಾನ್ ನೋಡ್‌ಗಳ ವಿಷಯದಲ್ಲಿ ವಿಶ್ಲೇಷಿಸಲು ನಾವು ಸಾಧ್ಯವಾಗಿಸಿದೆವು (ಇವೆಲ್ಲವೂ Seq Scan on users), ಆದರೆ ತಕ್ಷಣವೇ ಅವರು ಬಹುಪಾಲು ಒಂದೇ ಎಂದು ಭಾವಿಸುತ್ತಾರೆ - ಅವರು ಮರೆತಿದ್ದಾರೆ.
ಇಲ್ಲ, ಸಹಜವಾಗಿ, ಡೇಟಾಬೇಸ್‌ಗೆ ಮತ್ತೆ ಏನನ್ನೂ ಬರೆಯಲಾಗಿಲ್ಲ, ಇದು ಪ್ರಚೋದಕವನ್ನು ಕಡಿತಗೊಳಿಸುತ್ತದೆ INSERT ... ON CONFLICT DO NOTHING. ಆದರೆ ಈ ಡೇಟಾವು ಇನ್ನೂ ಡೇಟಾಬೇಸ್ ಅನ್ನು ತಲುಪುತ್ತದೆ ಮತ್ತು ಇದು ಅನಗತ್ಯವಾಗಿದೆ ಸಂಘರ್ಷವನ್ನು ಪರಿಶೀಲಿಸಲು ಓದುವುದು ಮಾಡಲೇ ಬೇಕು. ಓಹ್ #3...
ಕ್ಯಾಶಿಂಗ್ ಅನ್ನು ಸಕ್ರಿಯಗೊಳಿಸುವ ಮೊದಲು/ನಂತರ ಡೇಟಾಬೇಸ್‌ಗೆ ಕಳುಹಿಸಲಾದ ದಾಖಲೆಗಳ ಸಂಖ್ಯೆಯಲ್ಲಿನ ವ್ಯತ್ಯಾಸವು ಸ್ಪಷ್ಟವಾಗಿದೆ:
ಮತ್ತು ಇದು ಶೇಖರಣಾ ಲೋಡ್‌ನಲ್ಲಿನ ಕುಸಿತವಾಗಿದೆ:
ಒಟ್ಟು
"ಟೆರಾಬೈಟ್-ಪರ್-ಡೇ" ಕೇವಲ ಭಯಾನಕ ಧ್ವನಿಸುತ್ತದೆ. ನೀವು ಎಲ್ಲವನ್ನೂ ಸರಿಯಾಗಿ ಮಾಡಿದರೆ, ಇದು ಕೇವಲ 2^40 ಬೈಟ್‌ಗಳು / 86400 ಸೆಕೆಂಡುಗಳು = ~12.5MB/sಡೆಸ್ಕ್‌ಟಾಪ್ IDE ಸ್ಕ್ರೂಗಳು ಸಹ ಹಿಡಿದಿವೆ. 🙂
ಆದರೆ ಗಂಭೀರವಾಗಿ, ದಿನದಲ್ಲಿ ಲೋಡ್ನ ಹತ್ತು ಪಟ್ಟು "ಓರೆಯಾಗಿ" ಸಹ, ನೀವು ಆಧುನಿಕ SSD ಗಳ ಸಾಮರ್ಥ್ಯಗಳನ್ನು ಸುಲಭವಾಗಿ ಪೂರೈಸಬಹುದು.
ಮೂಲ: www.habr.com