ಆತ್ಮೀಯ ಅಳಿಸು. ನಿಕೊಲಾಯ್ ಸಮೊಖ್ವಾಲೋವ್ (Postgres.ai)

ದೂರದ ಭವಿಷ್ಯದಲ್ಲಿ, ಅನಗತ್ಯ ಡೇಟಾವನ್ನು ಸ್ವಯಂಚಾಲಿತವಾಗಿ ತೆಗೆದುಹಾಕುವುದು DBMS [1] ನ ಪ್ರಮುಖ ಕಾರ್ಯಗಳಲ್ಲಿ ಒಂದಾಗಿದೆ. ಈ ಮಧ್ಯೆ, ಕಡಿಮೆ ವೆಚ್ಚದ ಶೇಖರಣಾ ವ್ಯವಸ್ಥೆಗಳಿಗೆ ಅನಗತ್ಯ ಡೇಟಾವನ್ನು ಅಳಿಸಲು ಅಥವಾ ಸರಿಸಲು ನಾವೇ ಕಾಳಜಿ ವಹಿಸಬೇಕು. ನೀವು ಕೆಲವು ಮಿಲಿಯನ್ ಸಾಲುಗಳನ್ನು ಅಳಿಸಲು ನಿರ್ಧರಿಸಿದ್ದೀರಿ ಎಂದು ಹೇಳೋಣ. ಸಾಕಷ್ಟು ಸರಳವಾದ ಕಾರ್ಯ, ವಿಶೇಷವಾಗಿ ಸ್ಥಿತಿಯನ್ನು ತಿಳಿದಿದ್ದರೆ ಮತ್ತು ಸೂಕ್ತವಾದ ಸೂಚ್ಯಂಕವಿದೆ. "ಟೇಬಲ್ 1 ರಿಂದ ಅಳಿಸಿ ಎಲ್ಲಿ col1 = :ಮೌಲ್ಯ" - ಯಾವುದು ಸರಳವಾಗಿರಬಹುದು, ಸರಿ?

ವೀಡಿಯೊ:

• ನಾನು ಮೊದಲ ವರ್ಷದಿಂದ ಅಂದರೆ 2007 ರಿಂದ ಹೈಲೋಡ್ ಕಾರ್ಯಕ್ರಮ ಸಮಿತಿಯಲ್ಲಿದ್ದೇನೆ.

• ಮತ್ತು ನಾನು 2005 ರಿಂದ ಪೋಸ್ಟ್‌ಗ್ರೆಸ್‌ನೊಂದಿಗೆ ಇದ್ದೇನೆ. ಅನೇಕ ಯೋಜನೆಗಳಲ್ಲಿ ಬಳಸಲಾಗಿದೆ.

• 2007 ರಿಂದ RuPostges ಜೊತೆಗೆ ಗುಂಪು.

• ನಾವು Meetup ನಲ್ಲಿ 2100+ ಭಾಗವಹಿಸುವವರಿಗೆ ಬೆಳೆದಿದ್ದೇವೆ. ನ್ಯೂಯಾರ್ಕ್ ನಂತರ ಇದು ಜಗತ್ತಿನಲ್ಲಿ ಎರಡನೇ ಸ್ಥಾನದಲ್ಲಿದೆ, ದೀರ್ಘಕಾಲದವರೆಗೆ ಸ್ಯಾನ್ ಫ್ರಾನ್ಸಿಸ್ಕೊದಿಂದ ಹಿಂದಿಕ್ಕಲಾಗಿದೆ.

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

https://postgres.ai/ ನನ್ನ ಕಂಪನಿಯಾಗಿದೆ. ನಾವು ಅಭಿವೃದ್ಧಿಯ ಮಂದಗತಿಯನ್ನು ತೊಡೆದುಹಾಕುವ ಕಾರ್ಯಗಳನ್ನು ಸ್ವಯಂಚಾಲಿತಗೊಳಿಸುವ ವ್ಯವಹಾರದಲ್ಲಿದ್ದೇವೆ.

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

https://www.seagate.com/files/www-content/our-story/trends/files/idc-seagate-dataage-whitepaper.pdf

ನಾನು ಇತ್ತೀಚೆಗೆ ಲಾಸ್ ಏಂಜಲೀಸ್‌ನ VLDB ಯಲ್ಲಿದ್ದೆ. ದತ್ತಸಂಚಯಗಳ ಕುರಿತಾದ ಅತಿ ದೊಡ್ಡ ಸಮ್ಮೇಳನ ಇದಾಗಿದೆ. ಮತ್ತು ಭವಿಷ್ಯದಲ್ಲಿ DBMS ಕೇವಲ ಸಂಗ್ರಹಿಸುವುದಿಲ್ಲ, ಆದರೆ ಸ್ವಯಂಚಾಲಿತವಾಗಿ ಡೇಟಾವನ್ನು ಅಳಿಸುತ್ತದೆ ಎಂಬ ವರದಿ ಇತ್ತು. ಇದು ಹೊಸ ವಿಷಯ.

ಝೆಟಾಬೈಟ್‌ಗಳ ಜಗತ್ತಿನಲ್ಲಿ ಹೆಚ್ಚು ಹೆಚ್ಚು ಡೇಟಾ ಇದೆ - ಅದು 1 ಪೆಟಾಬೈಟ್‌ಗಳು. ಮತ್ತು ಈಗ ನಾವು ಪ್ರಪಂಚದಲ್ಲಿ 000 ಜೆಟ್ಟಾಬೈಟ್‌ಗಳಿಗಿಂತ ಹೆಚ್ಚು ಡೇಟಾವನ್ನು ಸಂಗ್ರಹಿಸಿದ್ದೇವೆ ಎಂದು ಈಗಾಗಲೇ ಅಂದಾಜಿಸಲಾಗಿದೆ. ಮತ್ತು ಅವುಗಳಲ್ಲಿ ಹೆಚ್ಚು ಹೆಚ್ಚು ಇವೆ.

https://vldb2019.github.io/files/VLDB19-keynote-2-slides.pdf

ಮತ್ತು ಅದರೊಂದಿಗೆ ಏನು ಮಾಡಬೇಕು? ನಿಸ್ಸಂಶಯವಾಗಿ ಅದನ್ನು ತೆಗೆದುಹಾಕಬೇಕಾಗಿದೆ. ಈ ಕುತೂಹಲಕಾರಿ ವರದಿಯ ಲಿಂಕ್ ಇಲ್ಲಿದೆ. ಆದರೆ ಇದುವರೆಗೆ ಡಿಬಿಎಂಎಸ್‌ನಲ್ಲಿ ಇದು ಜಾರಿಯಾಗಿಲ್ಲ.

ಹಣವನ್ನು ಎಣಿಸುವವರು ಎರಡು ವಿಷಯಗಳನ್ನು ಬಯಸುತ್ತಾರೆ. ನಾವು ಅಳಿಸಬೇಕೆಂದು ಅವರು ಬಯಸುತ್ತಾರೆ, ಆದ್ದರಿಂದ ತಾಂತ್ರಿಕವಾಗಿ ನಾವು ಅದನ್ನು ಮಾಡಲು ಸಾಧ್ಯವಾಗುತ್ತದೆ.

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

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

ಸಾಮಾನ್ಯವಾಗಿ, ಕಾರ್ಯವು ನಿರ್ದಿಷ್ಟ ವಸ್ತುಗಳ ಅಳಿಸುವಿಕೆಯನ್ನು ಸ್ವಯಂಚಾಲಿತಗೊಳಿಸುವುದು, ಕೆಲವು ಕೋಷ್ಟಕದಲ್ಲಿ ನಿರ್ದಿಷ್ಟ ಸಾಲುಗಳು.

ಮತ್ತು ನಾವು ಅಂತಹ ವಿನಂತಿಯನ್ನು ಹೊಂದಿದ್ದೇವೆ, ಅದನ್ನು ನಾವು ಇಂದು ಮಾತನಾಡುತ್ತೇವೆ, ಅಂದರೆ, ಕಸ ತೆಗೆಯುವ ಬಗ್ಗೆ.

ಇದನ್ನು ಮಾಡಲು ನಾವು ಅನುಭವಿ ಡೆವಲಪರ್ ಅನ್ನು ಕೇಳಿದ್ದೇವೆ. ಅವರು ಈ ವಿನಂತಿಯನ್ನು ತೆಗೆದುಕೊಂಡರು, ಅದನ್ನು ಸ್ವತಃ ಪರಿಶೀಲಿಸಿದರು - ಎಲ್ಲವೂ ಕೆಲಸ ಮಾಡುತ್ತದೆ. ವೇದಿಕೆಯಲ್ಲಿ ಪರೀಕ್ಷಿಸಲಾಗಿದೆ - ಎಲ್ಲವೂ ಉತ್ತಮವಾಗಿದೆ. ಸುತ್ತಿಕೊಂಡಿದೆ - ಎಲ್ಲವೂ ಕೆಲಸ ಮಾಡುತ್ತದೆ. ದಿನಕ್ಕೆ ಒಮ್ಮೆ ನಾವು ಅದನ್ನು ಓಡಿಸುತ್ತೇವೆ - ಎಲ್ಲವೂ ಉತ್ತಮವಾಗಿದೆ.

ಡೇಟಾಬೇಸ್ ಬೆಳೆಯುತ್ತದೆ ಮತ್ತು ಬೆಳೆಯುತ್ತದೆ. ಡೈಲಿ ಡಿಲೀಟ್ ಸ್ವಲ್ಪ ನಿಧಾನವಾಗಿ ಕೆಲಸ ಮಾಡಲು ಪ್ರಾರಂಭಿಸುತ್ತದೆ.

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

ಕೆಲವು ತಿಂಗಳ ನಂತರ ಅವರು ನೆನಪಿಸಿಕೊಂಡರು. ಮತ್ತು ಆ ಡೆವಲಪರ್ ತ್ಯಜಿಸಿದರು ಅಥವಾ ಬೇರೆ ಯಾವುದೋ ಕಾರ್ಯದಲ್ಲಿ ನಿರತರಾಗಿದ್ದಾರೆ, ಅದನ್ನು ಹಿಂದಿರುಗಿಸಲು ಮತ್ತೊಬ್ಬರಿಗೆ ಸೂಚಿಸಿದರು.

ಅವರು ದೇವ್‌ನಲ್ಲಿ, ಸ್ಟೇಜಿಂಗ್‌ನಲ್ಲಿ ಪರಿಶೀಲಿಸಿದರು - ಎಲ್ಲವೂ ಸರಿಯಾಗಿದೆ. ನೈಸರ್ಗಿಕವಾಗಿ, ನೀವು ಇನ್ನೂ ಸಂಗ್ರಹವಾದದ್ದನ್ನು ಸ್ವಚ್ಛಗೊಳಿಸಬೇಕಾಗಿದೆ. ಅವರು ಎಲ್ಲವನ್ನೂ ಪರಿಶೀಲಿಸಿದರು.

ಮುಂದೆ ಏನಾಗುತ್ತದೆ? ನಂತರ ಎಲ್ಲವೂ ನಮಗೆ ಬೀಳುತ್ತದೆ. ಅದು ಬೀಳುತ್ತದೆ ಆದ್ದರಿಂದ ಒಂದು ಹಂತದಲ್ಲಿ ಎಲ್ಲವೂ ಕೆಳಗೆ ಬೀಳುತ್ತದೆ. ಎಲ್ಲರೂ ಆಘಾತದಲ್ಲಿದ್ದಾರೆ, ಏನಾಗುತ್ತಿದೆ ಎಂದು ಯಾರಿಗೂ ಅರ್ಥವಾಗುತ್ತಿಲ್ಲ. ತದನಂತರ ವಿಷಯವು ಈ ಅಳಿಸುವಿಕೆಯಲ್ಲಿದೆ ಎಂದು ತಿರುಗುತ್ತದೆ.

ಏನೋ ತಪ್ಪಾಗಿದೆ? ಏನು ತಪ್ಪಾಗಿರಬಹುದು ಎಂಬುದರ ಪಟ್ಟಿ ಇಲ್ಲಿದೆ. ಇವುಗಳಲ್ಲಿ ಯಾವುದು ಮುಖ್ಯ?

• ಉದಾಹರಣೆಗೆ, ಯಾವುದೇ ವಿಮರ್ಶೆ ಇಲ್ಲ, ಅಂದರೆ ಡಿಬಿಎ ತಜ್ಞರು ಅದನ್ನು ನೋಡಲಿಲ್ಲ. ಅನುಭವಿ ಕಣ್ಣಿನಿಂದ ಅವರು ತಕ್ಷಣವೇ ಸಮಸ್ಯೆಯನ್ನು ಕಂಡುಕೊಳ್ಳುತ್ತಾರೆ, ಜೊತೆಗೆ, ಅವರು ಉತ್ಪನ್ನಕ್ಕೆ ಪ್ರವೇಶವನ್ನು ಹೊಂದಿದ್ದಾರೆ, ಅಲ್ಲಿ ಹಲವಾರು ಮಿಲಿಯನ್ ಸಾಲುಗಳು ಸಂಗ್ರಹವಾಗಿವೆ.

• ಬಹುಶಃ ಅವರು ಏನಾದರೂ ತಪ್ಪಾಗಿ ಪರಿಶೀಲಿಸಿದ್ದಾರೆ.

• ಬಹುಶಃ ಹಾರ್ಡ್‌ವೇರ್ ಹಳೆಯದಾಗಿದೆ ಮತ್ತು ನೀವು ಈ ಬೇಸ್ ಅನ್ನು ಅಪ್‌ಗ್ರೇಡ್ ಮಾಡಬೇಕಾಗುತ್ತದೆ.

• ಅಥವಾ ಡೇಟಾಬೇಸ್‌ನಲ್ಲಿಯೇ ಏನೋ ತಪ್ಪಾಗಿದೆ ಮತ್ತು ನಾವು ಪೋಸ್ಟ್‌ಗ್ರೆಸ್‌ನಿಂದ MySQL ಗೆ ಚಲಿಸಬೇಕಾಗುತ್ತದೆ.

• ಅಥವಾ ಕಾರ್ಯಾಚರಣೆಯಲ್ಲಿ ಏನಾದರೂ ತಪ್ಪಿರಬಹುದು.

• ಬಹುಶಃ ಕೆಲಸದ ಸಂಘಟನೆಯಲ್ಲಿ ಕೆಲವು ತಪ್ಪುಗಳಿವೆ ಮತ್ತು ನೀವು ಯಾರನ್ನಾದರೂ ವಜಾ ಮಾಡಬೇಕೇ ಮತ್ತು ಉತ್ತಮ ಜನರನ್ನು ನೇಮಿಸಿಕೊಳ್ಳಬೇಕೇ?

ಡಿಬಿಎ ಚೆಕ್ ಇರಲಿಲ್ಲ. ಡಿಬಿಎ ಇದ್ದರೆ, ಅವರು ಈ ಹಲವಾರು ಮಿಲಿಯನ್ ಸಾಲುಗಳನ್ನು ನೋಡುತ್ತಾರೆ ಮತ್ತು ಯಾವುದೇ ಪ್ರಯೋಗಗಳಿಲ್ಲದೆ ಅವರು ಹೀಗೆ ಹೇಳುತ್ತಾರೆ: "ಅವರು ಹಾಗೆ ಮಾಡುವುದಿಲ್ಲ." ಈ ಕೋಡ್ GitLab, GitHub ನಲ್ಲಿದ್ದರೆ ಮತ್ತು ಕೋಡ್ ಪರಿಶೀಲನೆ ಪ್ರಕ್ರಿಯೆ ಇರುತ್ತದೆ ಮತ್ತು DBA ಯ ಅನುಮೋದನೆಯಿಲ್ಲದೆ ಈ ಕಾರ್ಯಾಚರಣೆಯು ಪ್ರಾಡ್‌ನಲ್ಲಿ ನಡೆಯುತ್ತದೆ ಎಂದು ಭಾವಿಸೋಣ, ನಂತರ ನಿಸ್ಸಂಶಯವಾಗಿ DBA ಹೇಳುತ್ತದೆ: “ಇದನ್ನು ಮಾಡಲಾಗುವುದಿಲ್ಲ. ”

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

http://bit.ly/nancy-hl2018-2

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

ನಮ್ಮ ಪರೀಕ್ಷೆಗಳು ದುರ್ಬಲವಾಗಿವೆ ಎಂದು ನಾವು ಅರ್ಥಮಾಡಿಕೊಂಡಿದ್ದೇವೆ, ಅಂದರೆ ನಿರ್ಮಿಸಲಾದ ಪ್ರಕ್ರಿಯೆಯು ಸಮಸ್ಯೆಗಳನ್ನು ಹಿಡಿಯುವುದಿಲ್ಲ. ಸಮರ್ಪಕವಾದ DB ಪ್ರಯೋಗವನ್ನು ನಡೆಸಲಾಗಿಲ್ಲ.

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

ಬಹುಶಃ ನಮ್ಮ ಉಪಕರಣಗಳು ಕೆಟ್ಟದಾಗಿದೆ? ನೀವು ನೋಡಿದರೆ, ನಂತರ ಸುಪ್ತತೆ ಹಾರಿತು. ಬಳಕೆ 100% ಎಂದು ನಾವು ನೋಡಿದ್ದೇವೆ. ಸಹಜವಾಗಿ, ಇವು ಆಧುನಿಕ NVMe ಡ್ರೈವ್‌ಗಳಾಗಿದ್ದರೆ, ಅದು ಬಹುಶಃ ನಮಗೆ ಹೆಚ್ಚು ಸುಲಭವಾಗಿರುತ್ತದೆ. ಮತ್ತು ಬಹುಶಃ ನಾವು ಅದರಿಂದ ತ್ಯಜಿಸುವುದಿಲ್ಲ.

ನೀವು ಮೋಡಗಳನ್ನು ಹೊಂದಿದ್ದರೆ, ಅಲ್ಲಿ ನವೀಕರಣವನ್ನು ಸುಲಭವಾಗಿ ಮಾಡಲಾಗುತ್ತದೆ. ಹೊಸ ಹಾರ್ಡ್‌ವೇರ್‌ನಲ್ಲಿ ಹೊಸ ಪ್ರತಿಕೃತಿಗಳನ್ನು ಹೆಚ್ಚಿಸಿದೆ. ಬದಲಾಯಿಸು. ಮತ್ತು ಎಲ್ಲಾ ಚೆನ್ನಾಗಿದೆ. ಬಹಳ ಸುಲಭ.

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

ಚೆಕ್ಪಾಯಿಂಟ್ ಎಂದರೇನು? ಇದು ಯಾವುದೇ DBMS ನಲ್ಲಿದೆ. ನೀವು ಮೆಮೊರಿಯಲ್ಲಿ ಡೇಟಾವನ್ನು ಬದಲಾಯಿಸಿದಾಗ, ಅದನ್ನು ತಕ್ಷಣವೇ ಡಿಸ್ಕ್ಗೆ ಬರೆಯಲಾಗುವುದಿಲ್ಲ. ಡೇಟಾ ಬದಲಾಗಿದೆ ಎಂಬ ಮಾಹಿತಿಯನ್ನು ಮೊದಲು ಬರೆಯುವ ಲಾಗ್‌ಗೆ ಬರೆಯಲಾಗುತ್ತದೆ. ಮತ್ತು ಕೆಲವು ಹಂತದಲ್ಲಿ, ನೈಜ ಪುಟಗಳನ್ನು ಡಿಸ್ಕ್‌ಗೆ ಡಂಪ್ ಮಾಡುವ ಸಮಯ ಎಂದು DBMS ನಿರ್ಧರಿಸುತ್ತದೆ, ಇದರಿಂದಾಗಿ ನಾವು ವೈಫಲ್ಯವನ್ನು ಹೊಂದಿದ್ದರೆ, ನಾವು ಕಡಿಮೆ REDO ಅನ್ನು ಮಾಡಬಹುದು. ಇದು ಒಂದು ಆಟಿಕೆ ಹಾಗೆ. ನಾವು ಕೊಲ್ಲಲ್ಪಟ್ಟರೆ, ನಾವು ಕೊನೆಯ ಚೆಕ್‌ಪಾಯಿಂಟ್‌ನಿಂದ ಆಟವನ್ನು ಪ್ರಾರಂಭಿಸುತ್ತೇವೆ. ಮತ್ತು ಎಲ್ಲಾ DBMS ಇದನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸುತ್ತದೆ.

ಪೋಸ್ಟ್‌ಗ್ರೆಸ್‌ನಲ್ಲಿನ ಸೆಟ್ಟಿಂಗ್‌ಗಳು ಹಿಂದುಳಿದಿವೆ. ಅವುಗಳನ್ನು 10-15 ವರ್ಷ ವಯಸ್ಸಿನ ಡೇಟಾ ಮತ್ತು ವಹಿವಾಟುಗಳಿಗಾಗಿ ವಿನ್ಯಾಸಗೊಳಿಸಲಾಗಿದೆ. ಮತ್ತು ಚೆಕ್ಪಾಯಿಂಟ್ ಇದಕ್ಕೆ ಹೊರತಾಗಿಲ್ಲ.

ನಮ್ಮ Postgres ಚೆಕ್-ಅಪ್ ವರದಿಯ ಮಾಹಿತಿ ಇಲ್ಲಿದೆ, ಅಂದರೆ ಸ್ವಯಂಚಾಲಿತ ಆರೋಗ್ಯ ತಪಾಸಣೆ. ಮತ್ತು ಹಲವಾರು ಟೆರಾಬೈಟ್‌ಗಳ ಕೆಲವು ಡೇಟಾಬೇಸ್ ಇಲ್ಲಿದೆ. ಮತ್ತು ಸುಮಾರು 90% ಪ್ರಕರಣಗಳಲ್ಲಿ ಬಲವಂತದ ಚೆಕ್ಪಾಯಿಂಟ್ಗಳನ್ನು ಚೆನ್ನಾಗಿ ನೋಡಬಹುದು.

ಅದರ ಅರ್ಥವೇನು? ಅಲ್ಲಿ ಎರಡು ಸೆಟ್ಟಿಂಗ್‌ಗಳಿವೆ. ಚೆಕ್‌ಪಾಯಿಂಟ್ ಸಮಯ ಮೀರುವ ಮೂಲಕ ಬರಬಹುದು, ಉದಾಹರಣೆಗೆ, 10 ನಿಮಿಷಗಳಲ್ಲಿ. ಅಥವಾ ಸಾಕಷ್ಟು ಡೇಟಾ ತುಂಬಿದಾಗ ಅದು ಬರಬಹುದು.

ಮತ್ತು ಪೂರ್ವನಿಯೋಜಿತವಾಗಿ max_wal_saze ಅನ್ನು 1 ಗಿಗಾಬೈಟ್‌ಗೆ ಹೊಂದಿಸಲಾಗಿದೆ. ವಾಸ್ತವವಾಗಿ, ಇದು 300-400 ಮೆಗಾಬೈಟ್‌ಗಳ ನಂತರ ಪೋಸ್ಟ್‌ಗ್ರೆಸ್‌ನಲ್ಲಿ ನಿಜವಾಗಿಯೂ ಸಂಭವಿಸುತ್ತದೆ. ನೀವು ತುಂಬಾ ಡೇಟಾವನ್ನು ಬದಲಾಯಿಸಿದ್ದೀರಿ ಮತ್ತು ನಿಮ್ಮ ಚೆಕ್‌ಪಾಯಿಂಟ್ ಸಂಭವಿಸುತ್ತದೆ.

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

ಮತ್ತು ಇದು ಕಡಿಮೆ ಆಗಾಗ್ಗೆ ಬರುತ್ತದೆ ಎಂದು ನಾವು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳಬೇಕು. ಅಂದರೆ, ನಾವು max_wal_size ಅನ್ನು ಹೆಚ್ಚಿಸಬಹುದು. ಮತ್ತು ಇದು ಕಡಿಮೆ ಬಾರಿ ಬರುತ್ತದೆ.

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

ಅದರಂತೆ, ನಾವು ಡೇಟಾಬೇಸ್‌ಗಳಲ್ಲಿ ಎರಡು ಸರಣಿಯ ಪ್ರಯೋಗಗಳನ್ನು ಮಾಡುತ್ತಿದ್ದೇವೆ.

ಮೊದಲ ಸರಣಿ - ನಾವು max_wal_size ಅನ್ನು ಬದಲಾಯಿಸುತ್ತೇವೆ. ಮತ್ತು ನಾವು ಬೃಹತ್ ಕಾರ್ಯಾಚರಣೆಯನ್ನು ಮಾಡುತ್ತಿದ್ದೇವೆ. ಮೊದಲಿಗೆ, ನಾವು 1 ಗಿಗಾಬೈಟ್ನ ಡೀಫಾಲ್ಟ್ ಸೆಟ್ಟಿಂಗ್ನಲ್ಲಿ ಮಾಡುತ್ತೇವೆ. ಮತ್ತು ನಾವು ಲಕ್ಷಾಂತರ ಸಾಲುಗಳ ಬೃಹತ್ ಅಳಿಸುವಿಕೆಯನ್ನು ಮಾಡುತ್ತೇವೆ.

ಇದು ನಮಗೆ ಎಷ್ಟು ಕಷ್ಟ ಎಂದು ನೀವು ನೋಡಬಹುದು. ಡಿಸ್ಕ್ IO ತುಂಬಾ ಕೆಟ್ಟದಾಗಿದೆ ಎಂದು ನಾವು ನೋಡುತ್ತೇವೆ. ನಾವು ಎಷ್ಟು WAL ಗಳನ್ನು ರಚಿಸಿದ್ದೇವೆ ಎಂಬುದನ್ನು ನಾವು ನೋಡುತ್ತೇವೆ, ಏಕೆಂದರೆ ಇದು ಬಹಳ ಮುಖ್ಯವಾಗಿದೆ. ಎಷ್ಟು ಬಾರಿ ಚೆಕ್‌ಪಾಯಿಂಟ್ ಆಗಿದೆ ಎಂದು ನೋಡೋಣ. ಮತ್ತು ಅದು ಒಳ್ಳೆಯದಲ್ಲ ಎಂದು ನಾವು ನೋಡುತ್ತೇವೆ.

ಮುಂದೆ ನಾವು max_wal_size ಅನ್ನು ಹೆಚ್ಚಿಸುತ್ತೇವೆ. ನಾವು ಪುನರಾವರ್ತಿಸುತ್ತೇವೆ. ನಾವು ಹೆಚ್ಚಿಸುತ್ತೇವೆ, ಪುನರಾವರ್ತಿಸುತ್ತೇವೆ. ಮತ್ತು ಹಲವು ಬಾರಿ. ತಾತ್ವಿಕವಾಗಿ, 10 ಅಂಕಗಳು ಒಳ್ಳೆಯದು, ಅಲ್ಲಿ 1, 2, 4, 8 ಗಿಗಾಬೈಟ್ಗಳು. ಮತ್ತು ನಾವು ನಿರ್ದಿಷ್ಟ ವ್ಯವಸ್ಥೆಯ ನಡವಳಿಕೆಯನ್ನು ನೋಡುತ್ತೇವೆ. ಇಲ್ಲಿ ಉಪಕರಣಗಳು ಪ್ರಾಡ್‌ನಲ್ಲಿರುವಂತೆ ಇರಬೇಕು ಎಂಬುದು ಸ್ಪಷ್ಟವಾಗಿದೆ. ನೀವು ಅದೇ ಡಿಸ್ಕ್‌ಗಳು, ಅದೇ ಪ್ರಮಾಣದ ಮೆಮೊರಿ ಮತ್ತು ಅದೇ ಪೋಸ್ಟ್‌ಗ್ರೆಸ್ ಸೆಟ್ಟಿಂಗ್‌ಗಳನ್ನು ಹೊಂದಿರಬೇಕು.

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

ರಷ್ಯನ್ ಭಾಷೆಯಲ್ಲಿ ಚೆಕ್ಪಾಯಿಂಟ್ಗಳು ಚೆಕ್ಪಾಯಿಂಟ್ಗಳಾಗಿವೆ.

ಉದಾಹರಣೆ: ಸೂಚ್ಯಂಕದಿಂದ ಹಲವಾರು ಮಿಲಿಯನ್ ಸಾಲುಗಳನ್ನು ಅಳಿಸಿ, ಸಾಲುಗಳು ಪುಟಗಳಾದ್ಯಂತ "ಚದುರಿಹೋಗಿವೆ".

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

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

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

ಮತ್ತು ಅಲ್ಲಿ 64 ಗಿಗಾಬೈಟ್‌ಗಳು ಸಂಪೂರ್ಣವಾಗಿ ಉತ್ತಮವಾಗಿವೆ ಎಂದು ನೋಡಬಹುದು. ಈಗಾಗಲೇ ಹಲ್ಲುಗಳನ್ನು ಉಚ್ಚರಿಸಲಾಗುತ್ತದೆ, ಇತರ ಕಾರ್ಯಾಚರಣೆಗಳನ್ನು ಬದುಕಲು ಮತ್ತು ಡಿಸ್ಕ್ನೊಂದಿಗೆ ಏನನ್ನಾದರೂ ಮಾಡಲು ಹೆಚ್ಚಿನ ಅವಕಾಶಗಳಿವೆ.

ಅದು ಯಾಕೆ?

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

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

ಮತ್ತು ನಾವು ಚೆಕ್ಪಾಯಿಂಟ್ ಅನ್ನು ಹಲವು ಬಾರಿ ಉಳಿಸಲು ಒತ್ತಾಯಿಸುತ್ತೇವೆ. ಅವನಿಗೆ ಅನಗತ್ಯ ಕಾರ್ಯಾಚರಣೆಗಳು ಹೇಗೆ ಆಗುತ್ತವೆ.

ಆದರೆ ಇಷ್ಟೇ ಅಲ್ಲ. ಪೋಸ್ಟ್‌ಗ್ರೆಸ್‌ನಲ್ಲಿ ಪುಟಗಳು 8 ಕಿಲೋಬೈಟ್‌ಗಳು ಮತ್ತು ಲಿನಕ್ಸ್‌ನಲ್ಲಿ 4 ಕಿಲೋಬೈಟ್‌ಗಳು. ಮತ್ತು full_page_writes ಸೆಟ್ಟಿಂಗ್ ಇದೆ. ಇದನ್ನು ಪೂರ್ವನಿಯೋಜಿತವಾಗಿ ಸಕ್ರಿಯಗೊಳಿಸಲಾಗಿದೆ. ಮತ್ತು ಇದು ಸರಿಯಾಗಿದೆ, ಏಕೆಂದರೆ ನಾವು ಅದನ್ನು ಆಫ್ ಮಾಡಿದರೆ, ಅದು ಕ್ರ್ಯಾಶ್ ಆಗಿದ್ದರೆ ಪುಟದ ಅರ್ಧದಷ್ಟು ಮಾತ್ರ ಉಳಿಸುವ ಅಪಾಯವಿದೆ.

ಫಾರ್ವರ್ಡ್ ಲಾಗ್‌ನ WAL ಗೆ ಬರೆಯುವ ನಡವಳಿಕೆಯು ನಾವು ಚೆಕ್‌ಪಾಯಿಂಟ್ ಅನ್ನು ಹೊಂದಿರುವಾಗ ಮತ್ತು ನಾವು ಮೊದಲ ಬಾರಿಗೆ ಪುಟವನ್ನು ಬದಲಾಯಿಸಿದಾಗ, ಸಂಪೂರ್ಣ ಪುಟ, ಅಂದರೆ, ಎಲ್ಲಾ 8 ಕಿಲೋಬೈಟ್‌ಗಳು, ಫಾರ್ವರ್ಡ್ ಲಾಗ್‌ಗೆ ಸೇರುತ್ತವೆ, ಆದರೂ ನಾವು ಮಾತ್ರ ಬದಲಾಯಿಸಿದ್ದೇವೆ ಲೈನ್, ಇದು 100 ಬೈಟ್‌ಗಳಷ್ಟು ತೂಗುತ್ತದೆ. ಮತ್ತು ನಾವು ಸಂಪೂರ್ಣ ಪುಟವನ್ನು ಬರೆಯಬೇಕಾಗಿದೆ.

ನಂತರದ ಬದಲಾವಣೆಗಳಲ್ಲಿ ನಿರ್ದಿಷ್ಟ ಟ್ಯೂಪಲ್ ಮಾತ್ರ ಇರುತ್ತದೆ, ಆದರೆ ಮೊದಲ ಬಾರಿಗೆ ನಾವು ಎಲ್ಲವನ್ನೂ ಬರೆಯುತ್ತೇವೆ.

ಮತ್ತು, ಅದರ ಪ್ರಕಾರ, ಚೆಕ್ಪಾಯಿಂಟ್ ಮತ್ತೆ ಸಂಭವಿಸಿದಲ್ಲಿ, ನಂತರ ನಾವು ಮೊದಲಿನಿಂದ ಎಲ್ಲವನ್ನೂ ಮತ್ತೆ ಪ್ರಾರಂಭಿಸಬೇಕು ಮತ್ತು ಇಡೀ ಪುಟವನ್ನು ತಳ್ಳಬೇಕು. ಆಗಾಗ್ಗೆ ಚೆಕ್‌ಪಾಯಿಂಟ್‌ಗಳೊಂದಿಗೆ, ನಾವು ಅದೇ ಪುಟಗಳ ಮೂಲಕ ನಡೆದಾಗ, full_page_writes = ಆನ್ ಆಗಿರಬಹುದು, ಅಂದರೆ ನಾವು ಹೆಚ್ಚು WAL ಅನ್ನು ರಚಿಸುತ್ತೇವೆ. ಹೆಚ್ಚಿನದನ್ನು ಪ್ರತಿಕೃತಿಗಳಿಗೆ, ಆರ್ಕೈವ್‌ಗೆ, ಡಿಸ್ಕ್‌ಗೆ ಕಳುಹಿಸಲಾಗುತ್ತದೆ.

ಮತ್ತು, ಅದರ ಪ್ರಕಾರ, ನಾವು ಎರಡು ಪುನರಾವರ್ತನೆಗಳನ್ನು ಹೊಂದಿದ್ದೇವೆ.

ನಾವು max_wal_size ಅನ್ನು ಹೆಚ್ಚಿಸಿದರೆ, ಚೆಕ್‌ಪಾಯಿಂಟ್ ಮತ್ತು ವಾಲ್ ರೈಟರ್ ಎರಡಕ್ಕೂ ನಾವು ಅದನ್ನು ಸುಲಭಗೊಳಿಸುತ್ತೇವೆ ಎಂದು ಅದು ತಿರುಗುತ್ತದೆ. ಮತ್ತು ಅದು ಅದ್ಭುತವಾಗಿದೆ.

ಟೆರಾಬೈಟ್ ಹಾಕಿಕೊಂಡು ಬದುಕೋಣ. ಅದರಲ್ಲಿ ಕೆಟ್ಟದ್ದೇನಿದೆ? ಇದು ಕೆಟ್ಟದು, ಏಕೆಂದರೆ ವೈಫಲ್ಯದ ಸಂದರ್ಭದಲ್ಲಿ, ನಾವು ಗಂಟೆಗಳವರೆಗೆ ಏರುತ್ತೇವೆ, ಏಕೆಂದರೆ ಚೆಕ್ಪಾಯಿಂಟ್ ಬಹಳ ಹಿಂದೆಯೇ ಇತ್ತು ಮತ್ತು ಈಗಾಗಲೇ ಬಹಳಷ್ಟು ಬದಲಾಗಿದೆ. ಮತ್ತು ನಾವು ಈ ಎಲ್ಲಾ REDO ಮಾಡಬೇಕಾಗಿದೆ. ಮತ್ತು ಆದ್ದರಿಂದ ನಾವು ಎರಡನೇ ಸರಣಿಯ ಪ್ರಯೋಗಗಳನ್ನು ಮಾಡುತ್ತೇವೆ.

ನಾವು ಕಾರ್ಯಾಚರಣೆಯನ್ನು ಮಾಡುತ್ತೇವೆ ಮತ್ತು ಚೆಕ್‌ಪಾಯಿಂಟ್ ಯಾವಾಗ ಪೂರ್ಣಗೊಳ್ಳಲಿದೆ ಎಂದು ನೋಡುತ್ತೇವೆ, ನಾವು ಉದ್ದೇಶಪೂರ್ವಕವಾಗಿ -9 ಪೋಸ್ಟ್‌ಗ್ರೆಸ್ ಅನ್ನು ಕೊಲ್ಲುತ್ತೇವೆ.

ಮತ್ತು ಅದರ ನಂತರ ನಾವು ಅದನ್ನು ಮತ್ತೆ ಪ್ರಾರಂಭಿಸುತ್ತೇವೆ ಮತ್ತು ಈ ಉಪಕರಣದಲ್ಲಿ ಅದು ಎಷ್ಟು ಸಮಯದವರೆಗೆ ಏರುತ್ತದೆ ಎಂಬುದನ್ನು ನೋಡಿ, ಅಂದರೆ ಈ ಕೆಟ್ಟ ಪರಿಸ್ಥಿತಿಯಲ್ಲಿ ಅದು ಎಷ್ಟು ಮರುಕಳಿಸಲ್ಪಡುತ್ತದೆ.

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

ನಾವು ಅಂತಹ ಪರಿಸ್ಥಿತಿಯನ್ನು ವಿಭಿನ್ನ max_wal_size ಗಾತ್ರಗಳಿಗೆ ಅಳೆಯುತ್ತೇವೆ ಮತ್ತು max_wal_size 64 ಗಿಗಾಬೈಟ್‌ಗಳಾಗಿದ್ದರೆ, ಎರಡು ಕೆಟ್ಟ ಸಂದರ್ಭದಲ್ಲಿ ನಾವು 10 ನಿಮಿಷಗಳ ಕಾಲ ಏರುತ್ತೇವೆ ಎಂದು ಅರ್ಥಮಾಡಿಕೊಳ್ಳುತ್ತೇವೆ. ಮತ್ತು ಅದು ನಮಗೆ ಸರಿಹೊಂದುತ್ತದೆಯೋ ಇಲ್ಲವೋ ಎಂದು ನಾವು ಯೋಚಿಸುತ್ತೇವೆ. ಇದು ವ್ಯಾಪಾರದ ಪ್ರಶ್ನೆ. ವ್ಯಾಪಾರ ನಿರ್ಧಾರಗಳಿಗೆ ಜವಾಬ್ದಾರರಾಗಿರುವವರಿಗೆ ನಾವು ಈ ಚಿತ್ರವನ್ನು ತೋರಿಸಬೇಕು ಮತ್ತು "ಸಮಸ್ಯೆಯ ಸಂದರ್ಭದಲ್ಲಿ ನಾವು ಎಷ್ಟು ದಿನ ಮಲಗಬಹುದು? ನಾವು 3-5 ನಿಮಿಷಗಳ ಕಾಲ ಕೆಟ್ಟ ಪರಿಸ್ಥಿತಿಯಲ್ಲಿ ಮಲಗಬಹುದೇ? ಮತ್ತು ನೀವು ನಿರ್ಧಾರ ತೆಗೆದುಕೊಳ್ಳಿ.

ಮತ್ತು ಇಲ್ಲಿ ಒಂದು ಆಸಕ್ತಿದಾಯಕ ಅಂಶವಿದೆ. ಸಮ್ಮೇಳನದಲ್ಲಿ ಪತ್ರೋನಿ ಬಗ್ಗೆ ನಾವು ಒಂದೆರಡು ವರದಿಗಳನ್ನು ಹೊಂದಿದ್ದೇವೆ. ಮತ್ತು ಬಹುಶಃ ನೀವು ಅದನ್ನು ಬಳಸುತ್ತಿರುವಿರಿ. ಪೋಸ್ಟ್‌ಗ್ರೆಸ್‌ಗೆ ಇದು ಸ್ವಯಂ ವಿಫಲವಾಗಿದೆ. GitLab ಮತ್ತು Data Egret ಈ ಕುರಿತು ಮಾತನಾಡಿದರು.

ಮತ್ತು ನೀವು 30 ಸೆಕೆಂಡುಗಳಲ್ಲಿ ಬರುವ ಆಟೋಫೈಲೋವರ್ ಹೊಂದಿದ್ದರೆ, ನಾವು 10 ನಿಮಿಷಗಳ ಕಾಲ ಮಲಗಬಹುದೇ? ಏಕೆಂದರೆ ಈ ಹೊತ್ತಿಗೆ ನಾವು ಪ್ರತಿಕೃತಿಗೆ ಬದಲಾಯಿಸುತ್ತೇವೆ ಮತ್ತು ಎಲ್ಲವೂ ಚೆನ್ನಾಗಿರುತ್ತದೆ. ಇದು ಒಂದು ಪ್ರಮುಖ ಅಂಶವಾಗಿದೆ. ನನಗೆ ಸ್ಪಷ್ಟ ಉತ್ತರ ಗೊತ್ತಿಲ್ಲ. ಈ ವಿಷಯವು ಕ್ರ್ಯಾಶ್ ಚೇತರಿಕೆಯ ಸುತ್ತ ಮಾತ್ರವಲ್ಲ ಎಂದು ನಾನು ಭಾವಿಸುತ್ತೇನೆ.

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

ನಾವು ಆಟೋಫೇಲೋವರ್ ಹೊಂದಿದ್ದರೂ ಸಹ ನಾನು ಇನ್ನೂ ಹೆಚ್ಚು ದೂರ ಹೋಗುವುದಿಲ್ಲ. ನಿಯಮದಂತೆ, 64, 100 ಗಿಗಾಬೈಟ್‌ಗಳಂತಹ ಮೌಲ್ಯಗಳು ಉತ್ತಮ ಮೌಲ್ಯಗಳಾಗಿವೆ. ಕೆಲವೊಮ್ಮೆ ಕಡಿಮೆ ಆಯ್ಕೆ ಮಾಡುವುದು ಸಹ ಯೋಗ್ಯವಾಗಿದೆ. ಸಾಮಾನ್ಯವಾಗಿ, ಇದು ಸೂಕ್ಷ್ಮ ವಿಜ್ಞಾನವಾಗಿದೆ.

ಪುನರಾವರ್ತನೆಗಳನ್ನು ಮಾಡಲು, ಉದಾಹರಣೆಗೆ, max_wal_size =1, 8, ನೀವು ಸಾಮೂಹಿಕ ಕಾರ್ಯಾಚರಣೆಯನ್ನು ಹಲವು ಬಾರಿ ಪುನರಾವರ್ತಿಸಬೇಕಾಗುತ್ತದೆ. ನೀವು ಅದನ್ನು ಮಾಡಿದ್ದೀರಿ. ಮತ್ತು ಅದೇ ಆಧಾರದ ಮೇಲೆ ನೀವು ಅದನ್ನು ಮತ್ತೆ ಮಾಡಲು ಬಯಸುತ್ತೀರಿ, ಆದರೆ ನೀವು ಈಗಾಗಲೇ ಎಲ್ಲವನ್ನೂ ಅಳಿಸಿದ್ದೀರಿ. ಏನ್ ಮಾಡೋದು?

ನಮ್ಮ ಪರಿಹಾರದ ಬಗ್ಗೆ ನಾನು ನಂತರ ಮಾತನಾಡುತ್ತೇನೆ, ಅಂತಹ ಸಂದರ್ಭಗಳಲ್ಲಿ ಪುನರಾವರ್ತಿಸಲು ನಾವು ಏನು ಮಾಡುತ್ತೇವೆ. ಮತ್ತು ಇದು ಅತ್ಯಂತ ಸರಿಯಾದ ವಿಧಾನವಾಗಿದೆ.

ಆದರೆ ಈ ಸಂದರ್ಭದಲ್ಲಿ ನಾವು ಅದೃಷ್ಟವಂತರು. ಇಲ್ಲಿ "ಆರಂಭ, ಅಳಿಸು, ರೋಲ್‌ಬ್ಯಾಕ್" ಎಂದು ಹೇಳಿದರೆ, ನಾವು ಅಳಿಸುವಿಕೆಯನ್ನು ಪುನರಾವರ್ತಿಸಬಹುದು. ಅಂದರೆ, ನಾವೇ ಅದನ್ನು ರದ್ದುಗೊಳಿಸಿದರೆ, ನಾವು ಅದನ್ನು ಪುನರಾವರ್ತಿಸಬಹುದು. ಮತ್ತು ಭೌತಿಕವಾಗಿ ನಿಮ್ಮ ಬಳಿ ಡೇಟಾ ಒಂದೇ ಸ್ಥಳದಲ್ಲಿ ಇರುತ್ತದೆ. ನೀವು ಯಾವುದೇ ಉಬ್ಬು ಪಡೆಯುವುದಿಲ್ಲ. ಅಂತಹ DELETE ಗಳ ಮೇಲೆ ನೀವು ಪುನರಾವರ್ತಿಸಬಹುದು.

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

ನಾವು ಒಂದು ಕಾಲಮ್ "i" ನೊಂದಿಗೆ ಪ್ಲೇಟ್ ಅನ್ನು ತಯಾರಿಸಿದ್ದೇವೆ. Postgres ಯುಟಿಲಿಟಿ ಕಾಲಮ್‌ಗಳನ್ನು ಹೊಂದಿದೆ. ನಿರ್ದಿಷ್ಟವಾಗಿ ಕೇಳದ ಹೊರತು ಅವು ಅಗೋಚರವಾಗಿರುತ್ತವೆ. ಅವುಗಳೆಂದರೆ: ctid, xmid, xmax.

Ctid ಒಂದು ಭೌತಿಕ ವಿಳಾಸವಾಗಿದೆ. ಶೂನ್ಯ ಪುಟ, ಪುಟದಲ್ಲಿ ಮೊದಲ ಟುಪಲ್.

ರೂಲ್‌ಬ್ಯಾಕ್ ನಂತರ ಟುಪಲ್ ಅದೇ ಸ್ಥಳದಲ್ಲಿ ಉಳಿದಿದೆ ಎಂದು ನೋಡಬಹುದು. ಅಂದರೆ, ನಾವು ಮತ್ತೆ ಪ್ರಯತ್ನಿಸಬಹುದು, ಅದು ಅದೇ ರೀತಿಯಲ್ಲಿ ವರ್ತಿಸುತ್ತದೆ. ಇದು ಮುಖ್ಯ ವಿಷಯ.

Xmax ಟುಪಲ್ನ ಸಾವಿನ ಸಮಯ. ಅದನ್ನು ಸ್ಟ್ಯಾಂಪ್ ಮಾಡಲಾಗಿದೆ, ಆದರೆ ವಹಿವಾಟನ್ನು ರೋಲ್ ಬ್ಯಾಕ್ ಮಾಡಲಾಗಿದೆ ಎಂದು ಪೋಸ್ಟ್‌ಗ್ರೆಸ್‌ಗೆ ತಿಳಿದಿದೆ, ಆದ್ದರಿಂದ ಅದು 0 ಆಗಿದ್ದರೆ ಅಥವಾ ಅದು ರೋಲ್ಡ್ ಬ್ಯಾಕ್ ವಹಿವಾಟಾಗಿದ್ದರೂ ಪರವಾಗಿಲ್ಲ. DELETE ಮೂಲಕ ಪುನರಾವರ್ತಿಸಲು ಮತ್ತು ಸಿಸ್ಟಮ್ ನಡವಳಿಕೆಯ ಬೃಹತ್ ಕಾರ್ಯಾಚರಣೆಗಳನ್ನು ಪರಿಶೀಲಿಸಲು ಸಾಧ್ಯವಿದೆ ಎಂದು ಇದು ಸೂಚಿಸುತ್ತದೆ. ನೀವು ಬಡವರಿಗಾಗಿ ಡೇಟಾಬೇಸ್ ಲ್ಯಾಬ್‌ಗಳನ್ನು ಮಾಡಬಹುದು.

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

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

ಮುರಿಯುವುದು ಏಕೆ ಮುಖ್ಯ?

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

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

https://postgres.ai/products/joe/

ಇದು ಆಸಕ್ತಿದಾಯಕವಾಗಿದೆ. ಡೆವಲಪರ್‌ಗಳು ಕೇಳುವುದನ್ನು ನಾನು ಆಗಾಗ್ಗೆ ನೋಡುತ್ತೇನೆ: "ನಾನು ಯಾವ ಪ್ಯಾಕ್ ಗಾತ್ರವನ್ನು ಆರಿಸಬೇಕು?".

ದೊಡ್ಡ ಬಂಡಲ್ ಗಾತ್ರ, ವಹಿವಾಟಿನ ಓವರ್ಹೆಡ್ ಚಿಕ್ಕದಾಗಿದೆ, ಅಂದರೆ, ವಹಿವಾಟಿನಿಂದ ಹೆಚ್ಚುವರಿ ಓವರ್ಹೆಡ್ ಎಂಬುದು ಸ್ಪಷ್ಟವಾಗಿದೆ. ಆದರೆ ಅದೇ ಸಮಯದಲ್ಲಿ, ಈ ವಹಿವಾಟಿನ ಸಮಯ ಹೆಚ್ಚಾಗುತ್ತದೆ.

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

ಒಂದು ಸೆಕೆಂಡ್ ಏಕೆ? ವಿವರಣೆಯು ತುಂಬಾ ಸರಳವಾಗಿದೆ ಮತ್ತು ಎಲ್ಲರಿಗೂ ಅರ್ಥವಾಗುವಂತಹದ್ದಾಗಿದೆ, ತಾಂತ್ರಿಕವಲ್ಲದ ಜನರು ಸಹ. ನಾವು ಪ್ರತಿಕ್ರಿಯೆಯನ್ನು ನೋಡುತ್ತೇವೆ. 50 ಮಿಲಿಸೆಕೆಂಡುಗಳನ್ನು ತೆಗೆದುಕೊಳ್ಳೋಣ. ಏನಾದರೂ ಬದಲಾಗಿದ್ದರೆ, ನಮ್ಮ ಕಣ್ಣು ಪ್ರತಿಕ್ರಿಯಿಸುತ್ತದೆ. ಕಡಿಮೆ ಇದ್ದರೆ, ನಂತರ ಹೆಚ್ಚು ಕಷ್ಟ. 100 ಮಿಲಿಸೆಕೆಂಡ್‌ಗಳ ನಂತರ ಏನಾದರೂ ಪ್ರತಿಕ್ರಿಯಿಸಿದರೆ, ಉದಾಹರಣೆಗೆ, ನೀವು ಮೌಸ್ ಅನ್ನು ಕ್ಲಿಕ್ ಮಾಡಿದ್ದೀರಿ ಮತ್ತು 100 ಮಿಲಿಸೆಕೆಂಡ್‌ಗಳ ನಂತರ ಅದು ನಿಮಗೆ ಉತ್ತರಿಸಿದರೆ, ನೀವು ಈಗಾಗಲೇ ಈ ಸ್ವಲ್ಪ ವಿಳಂಬವನ್ನು ಅನುಭವಿಸುತ್ತೀರಿ. ಒಂದು ಸೆಕೆಂಡ್ ಅನ್ನು ಈಗಾಗಲೇ ಬ್ರೇಕ್ ಎಂದು ಗ್ರಹಿಸಲಾಗಿದೆ.

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

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

ಅಂದಹಾಗೆ, ನಾನು ಮಾತನಾಡುತ್ತಿರುವ ಎಲ್ಲವೂ ಅಳಿಸುವಿಕೆಯ ಬಗ್ಗೆ ಮಾತ್ರವಲ್ಲ. ನೀವು ಊಹಿಸಿದಂತೆ, ಇವು ಡೇಟಾದ ಯಾವುದೇ ಬೃಹತ್ ಕಾರ್ಯಾಚರಣೆಗಳಾಗಿವೆ.

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

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

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

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

https://docs.gitlab.com/ee/development/background_migrations.html

ವಿಭಜನೆಯ ತಂತ್ರಗಳು ಯಾವುವು? ಪ್ಯಾಕ್‌ನಲ್ಲಿ ಡೆವಲಪರ್‌ಗಳು ಬಳಸುತ್ತಿರುವ 3 ವಿಭಿನ್ನ ವಿಭಜನಾ ತಂತ್ರಗಳನ್ನು ನಾನು ನೋಡುತ್ತೇನೆ.

ಮೊದಲನೆಯದು ತುಂಬಾ ಸರಳವಾಗಿದೆ. ನಮ್ಮ ಬಳಿ ಸಂಖ್ಯಾ ಐಡಿ ಇದೆ. ಮತ್ತು ಅದನ್ನು ವಿಭಿನ್ನ ಮಧ್ಯಂತರಗಳಾಗಿ ವಿಭಜಿಸೋಣ ಮತ್ತು ಅದರೊಂದಿಗೆ ಕೆಲಸ ಮಾಡೋಣ. ತೊಂದರೆಯು ಸ್ಪಷ್ಟವಾಗಿದೆ. ಮೊದಲ ವಿಭಾಗದಲ್ಲಿ, ನಾವು 100 ಸಾಲುಗಳ ನೈಜ ಕಸವನ್ನು ಹೊಂದಿರಬಹುದು, ಎರಡನೆಯ 5 ಸಾಲುಗಳಲ್ಲಿ ಅಥವಾ ಇಲ್ಲವೇ ಇಲ್ಲ, ಅಥವಾ ಎಲ್ಲಾ 1 ಸಾಲುಗಳು ಕಸವಾಗಿ ಹೊರಹೊಮ್ಮುತ್ತವೆ. ತುಂಬಾ ಅಸಮ ಕೆಲಸ, ಆದರೆ ಅದನ್ನು ಮುರಿಯುವುದು ಸುಲಭ. ಅವರು ಗರಿಷ್ಠ ಐಡಿ ತೆಗೆದುಕೊಂಡು ಅದನ್ನು ಒಡೆದು ಹಾಕಿದರು. ಇದು ನಿಷ್ಕಪಟ ವಿಧಾನವಾಗಿದೆ.

ಎರಡನೆಯ ತಂತ್ರವು ಸಮತೋಲಿತ ವಿಧಾನವಾಗಿದೆ. ಇದನ್ನು Gitlab ನಲ್ಲಿ ಬಳಸಲಾಗುತ್ತದೆ. ಅವರು ಟೇಬಲ್ ತೆಗೆದುಕೊಂಡು ಸ್ಕ್ಯಾನ್ ಮಾಡಿದರು. ID ಪ್ಯಾಕ್‌ಗಳ ಗಡಿಗಳನ್ನು ನಾವು ಕಂಡುಕೊಂಡಿದ್ದೇವೆ ಆದ್ದರಿಂದ ಪ್ರತಿ ಪ್ಯಾಕ್ ನಿಖರವಾಗಿ 10 ದಾಖಲೆಗಳನ್ನು ಹೊಂದಿದೆ. ಮತ್ತು ಅವುಗಳನ್ನು ಸರದಿಯಲ್ಲಿ ಇರಿಸಿ. ತದನಂತರ ನಾವು ಪ್ರಕ್ರಿಯೆಗೊಳಿಸುತ್ತೇವೆ. ನೀವು ಇದನ್ನು ಬಹು ಎಳೆಗಳಲ್ಲಿ ಮಾಡಬಹುದು.

ಮೊದಲ ತಂತ್ರದಲ್ಲಿ, ಮೂಲಕ, ನೀವು ಇದನ್ನು ಹಲವಾರು ಎಳೆಗಳಲ್ಲಿ ಮಾಡಬಹುದು. ಇದು ಕಷ್ಟವಲ್ಲ.

https://medium.com/@samokhvalov/how-partial-indexes-affect-update-performance-in-postgres-d05e0052abc

ಆದರೆ ತಂಪಾದ ಮತ್ತು ಉತ್ತಮವಾದ ವಿಧಾನವಿದೆ. ಇದು ಮೂರನೇ ತಂತ್ರ. ಮತ್ತು ಸಾಧ್ಯವಾದಾಗ, ಅದನ್ನು ಆಯ್ಕೆ ಮಾಡುವುದು ಉತ್ತಮ. ವಿಶೇಷ ಸೂಚ್ಯಂಕದ ಆಧಾರದ ಮೇಲೆ ನಾವು ಇದನ್ನು ಮಾಡುತ್ತೇವೆ. ಈ ಸಂದರ್ಭದಲ್ಲಿ, ನಮ್ಮ ಕಸದ ಸ್ಥಿತಿ ಮತ್ತು ID ಪ್ರಕಾರ ಇದು ಹೆಚ್ಚಾಗಿ ಸೂಚ್ಯಂಕವಾಗಿರುತ್ತದೆ. ನಾವು ID ಅನ್ನು ಸೇರಿಸುತ್ತೇವೆ ಆದ್ದರಿಂದ ಇದು ಸೂಚ್ಯಂಕ ಮಾತ್ರ ಸ್ಕ್ಯಾನ್ ಆಗಿರುವುದರಿಂದ ನಾವು ರಾಶಿಗೆ ಹೋಗುವುದಿಲ್ಲ.

ಸಾಮಾನ್ಯವಾಗಿ, ಸೂಚ್ಯಂಕ ಮಾತ್ರ ಸ್ಕ್ಯಾನ್ ಸೂಚ್ಯಂಕ ಸ್ಕ್ಯಾನ್‌ಗಿಂತ ವೇಗವಾಗಿರುತ್ತದೆ.

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

ನಮಗೆ ಅದು ಏಕೆ ಬೇಕು? ಇದನ್ನೇ ನಾವು ಮತ್ತೆ ವರದಿ ಮಾಡಬೇಕಾಗಿದೆ. ನಾವು ಈಗ ವಾಸ್ತವವಾಗಿ ಹಲವು ಸಾಲುಗಳನ್ನು ಅಳಿಸಿದ್ದೇವೆ. ಮತ್ತು ನಾವು ID ಯಿಂದ ಅಥವಾ ಈ ರೀತಿಯ ಮೂಲಕ ರಚಿಸಲಾದ_at ಮೂಲಕ ಗಡಿಗಳನ್ನು ಹೊಂದಿದ್ದೇವೆ. ನೀವು ನಿಮಿಷ, ಗರಿಷ್ಠ ಮಾಡಬಹುದು. ಬೇರೆ ಏನಾದರೂ ಮಾಡಬಹುದು. ನೀವು ಇಲ್ಲಿ ಬಹಳಷ್ಟು ಸ್ಟಫ್ ಮಾಡಬಹುದು. ಮತ್ತು ಮೇಲ್ವಿಚಾರಣೆಗೆ ಇದು ತುಂಬಾ ಅನುಕೂಲಕರವಾಗಿದೆ.

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

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

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

ದೀರ್ಘ ವಹಿವಾಟುಗಳು https://gitlab.com/snippets/1890447

ನಿರ್ಬಂಧಿಸಿದ ಆಟೋವ್ಯಾಕ್ಯೂಮ್ - https://gitlab.com/snippets/1889668

ತಡೆಯುವ ಸಮಸ್ಯೆ - https://gitlab.com/snippets/1890428

ತಪ್ಪು #5 ದೊಡ್ಡದು. ಆಕ್ಮೀಟರ್‌ನಿಂದ ನಿಕೋಲಾಯ್ ಪೋಸ್ಟ್‌ಗ್ರೆಸ್ ಮಾನಿಟರಿಂಗ್ ಕುರಿತು ಮಾತನಾಡಿದರು. ಐಡಿಯಲ್ ಪೋಸ್ಟ್‌ಗ್ರೆಸ್ ಮಾನಿಟರಿಂಗ್, ದುರದೃಷ್ಟವಶಾತ್, ಅಸ್ತಿತ್ವದಲ್ಲಿಲ್ಲ. ಕೆಲವರು ಹತ್ತಿರವಾಗಿದ್ದಾರೆ, ಕೆಲವರು ದೂರದಲ್ಲಿದ್ದಾರೆ. Okmeter ಪರಿಪೂರ್ಣವಾಗಲು ಸಾಕಷ್ಟು ಹತ್ತಿರದಲ್ಲಿದೆ, ಆದರೆ ಬಹಳಷ್ಟು ಕಾಣೆಯಾಗಿದೆ ಮತ್ತು ಸೇರಿಸಬೇಕಾಗಿದೆ. ಇದಕ್ಕಾಗಿ ನೀವು ಸಿದ್ಧರಾಗಿರಬೇಕು.

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

ದೊಡ್ಡ IO ಇದ್ದರೆ, ಇದು ಒಳ್ಳೆಯದಲ್ಲ ಎಂಬುದು ಸ್ಪಷ್ಟವಾಗುತ್ತದೆ.

ದೀರ್ಘ ವಹಿವಾಟು ಕೂಡ. OLTP ಯಲ್ಲಿ ದೀರ್ಘ ವಹಿವಾಟುಗಳನ್ನು ಅನುಮತಿಸಬಾರದು. ಮತ್ತು ಈ ತುಣುಕನ್ನು ತೆಗೆದುಕೊಳ್ಳಲು ಮತ್ತು ಈಗಾಗಲೇ ದೀರ್ಘ ವಹಿವಾಟುಗಳ ಕೆಲವು ಟ್ರ್ಯಾಕಿಂಗ್ ಮಾಡಲು ನಿಮಗೆ ಅನುಮತಿಸುವ ತುಣುಕಿನ ಲಿಂಕ್ ಇಲ್ಲಿದೆ.

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

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

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

ಕೆಲವೊಮ್ಮೆ ಈ ಎಲ್ಲಾ ದೋಷಗಳು ಮೊತ್ತದಲ್ಲಿ ಸಂಭವಿಸುತ್ತವೆ.

ನನ್ನ ಅಭಿಪ್ರಾಯದಲ್ಲಿ, ಇಲ್ಲಿ ಮುಖ್ಯ ತಪ್ಪು ಸಾಂಸ್ಥಿಕವಾಗಿದೆ. ಇದು ಸಾಂಸ್ಥಿಕವಾಗಿದೆ, ಏಕೆಂದರೆ ತಂತ್ರವು ಎಳೆಯುವುದಿಲ್ಲ. ಇದು ಸಂಖ್ಯೆ 2 - ಅವರು ತಪ್ಪಾದ ಸ್ಥಳದಲ್ಲಿ ಪರಿಶೀಲಿಸಿದ್ದಾರೆ.

ನಾವು ತಪ್ಪಾದ ಸ್ಥಳದಲ್ಲಿ ಪರಿಶೀಲಿಸಿದ್ದೇವೆ, ಏಕೆಂದರೆ ನಾವು ಪ್ರೊಡಕ್ಷನ್ ಕ್ಲೋನ್ ಅನ್ನು ಹೊಂದಿಲ್ಲ, ಅದನ್ನು ಪರಿಶೀಲಿಸಲು ಸುಲಭವಾಗಿದೆ. ಡೆವಲಪರ್‌ಗೆ ಉತ್ಪಾದನೆಗೆ ಪ್ರವೇಶ ಇಲ್ಲದಿರಬಹುದು.

ಮತ್ತು ನಾವು ಅಲ್ಲಿ ಪರಿಶೀಲಿಸಲಿಲ್ಲ. ಅಲ್ಲಿ ಪರಿಶೀಲಿಸಿದ್ದರೆ ನಾವೇ ನೋಡುತ್ತಿದ್ದೆವು. ಡೆವಲಪರ್ ಅವರು ಉತ್ತಮ ಪರಿಸರದಲ್ಲಿ ಅದನ್ನು ಪರಿಶೀಲಿಸಿದರೆ DBA ಇಲ್ಲದೆಯೂ ಸಹ ಎಲ್ಲವನ್ನೂ ನೋಡಿದ್ದಾರೆ, ಅಲ್ಲಿ ಅದೇ ಪ್ರಮಾಣದ ಡೇಟಾ ಮತ್ತು ಒಂದೇ ಸ್ಥಳವಿದೆ. ಈ ಎಲ್ಲ ಅಧಃಪತನವನ್ನು ಕಂಡು ನಾಚಿಕೆಪಡುತ್ತಿದ್ದನು.

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

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

ನಾವು ಮಾಡುತ್ತಿರುವುದು ಓಪನ್ ಸೋರ್ಸ್. ಇದನ್ನು GitLab ನಲ್ಲಿ ಪೋಸ್ಟ್ ಮಾಡಲಾಗಿದೆ. ಮತ್ತು DBA ಇಲ್ಲದೆಯೂ ಜನರು ಪರಿಶೀಲಿಸುವಂತೆ ನಾವು ಅದನ್ನು ಮಾಡುತ್ತೇವೆ. ನಾವು ಡೇಟಾಬೇಸ್ ಲ್ಯಾಬ್ ಅನ್ನು ಮಾಡುತ್ತಿದ್ದೇವೆ, ಅಂದರೆ, ಜೋ ಪ್ರಸ್ತುತ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತಿರುವ ಮೂಲ ಘಟಕವನ್ನು ನಾವು ಕರೆಯುತ್ತೇವೆ. ಮತ್ತು ನೀವು ಉತ್ಪಾದನೆಯ ನಕಲನ್ನು ಪಡೆದುಕೊಳ್ಳಬಹುದು. ಈಗ ಜೋ ಫಾರ್ ಸ್ಲಾಕ್‌ನ ಅನುಷ್ಠಾನವಿದೆ, ನೀವು ಅಲ್ಲಿ ಹೇಳಬಹುದು: “ಅಂತಹ ಮತ್ತು ಅಂತಹ ವಿನಂತಿಯನ್ನು ವಿವರಿಸಿ” ಮತ್ತು ನಿಮ್ಮ ಡೇಟಾಬೇಸ್‌ನ ನಕಲು ತಕ್ಷಣವೇ ಫಲಿತಾಂಶವನ್ನು ಪಡೆಯಿರಿ. ನೀವು ಅಲ್ಲಿ ಅಳಿಸಬಹುದು ಮತ್ತು ಯಾರೂ ಅದನ್ನು ಗಮನಿಸುವುದಿಲ್ಲ.

ನೀವು 10 ಟೆರಾಬೈಟ್‌ಗಳನ್ನು ಹೊಂದಿದ್ದೀರಿ ಎಂದು ಹೇಳೋಣ, ನಾವು ಡೇಟಾಬೇಸ್ ಲ್ಯಾಬ್ ಅನ್ನು 10 ಟೆರಾಬೈಟ್‌ಗಳನ್ನು ಸಹ ಮಾಡುತ್ತೇವೆ. ಮತ್ತು ಏಕಕಾಲದಲ್ಲಿ 10 ಟೆರಾಬೈಟ್ ಡೇಟಾಬೇಸ್‌ಗಳೊಂದಿಗೆ, 10 ಡೆವಲಪರ್‌ಗಳು ಏಕಕಾಲದಲ್ಲಿ ಕೆಲಸ ಮಾಡಬಹುದು. ಪ್ರತಿಯೊಬ್ಬರೂ ತಮಗೆ ಬೇಕಾದುದನ್ನು ಮಾಡಬಹುದು. ಅಳಿಸಬಹುದು, ಬಿಡಬಹುದು, ಇತ್ಯಾದಿ. ಅದು ಅಂತಹ ಫ್ಯಾಂಟಸಿ. ನಾವು ನಾಳೆ ಈ ಬಗ್ಗೆ ಮಾತನಾಡುತ್ತೇವೆ.

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

ಉದಾಹರಣೆ: 5 ಟೆರಾಬೈಟ್ ಡೇಟಾಬೇಸ್, 30 ಸೆಕೆಂಡುಗಳಿಗಿಂತ ಕಡಿಮೆ ಅವಧಿಯಲ್ಲಿ ನಕಲನ್ನು ಪಡೆಯುವುದು. ಮತ್ತು ಇದು ಗಾತ್ರದ ಮೇಲೆ ಅವಲಂಬಿತವಾಗಿಲ್ಲ, ಅಂದರೆ, ಎಷ್ಟು ಟೆರಾಬೈಟ್ಗಳು ಅಪ್ರಸ್ತುತವಾಗುತ್ತದೆ.

ಇಂದು ನೀವು ಹೋಗಬಹುದು postgres.ai ಮತ್ತು ನಮ್ಮ ಉಪಕರಣಗಳನ್ನು ಅಗೆಯಿರಿ. ಅಲ್ಲಿ ಏನಿದೆ ಎಂಬುದನ್ನು ನೋಡಲು ನೀವು ನೋಂದಾಯಿಸಿಕೊಳ್ಳಬಹುದು. ನೀವು ಈ ಬೋಟ್ ಅನ್ನು ಸ್ಥಾಪಿಸಬಹುದು. ಇದು ಉಚಿತ. ಬರೆಯಿರಿ.

ಪ್ರಶ್ನೆಗಳು

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

ಇದು ತುಂಬಾ ಒಳ್ಳೆಯ ವಿಧಾನ ಮತ್ತು ಉತ್ತಮ ಕಾರ್ಯವಾಗಿದೆ. ಇದು pg_repack ಏನು ಮಾಡುತ್ತದೆ ಎಂಬುದಕ್ಕೆ ಹೋಲುತ್ತದೆ, ನೀವು ID ಗಳನ್ನು 4 ಬೈಟ್‌ಗಳನ್ನು ಮಾಡಿದಾಗ ನೀವು ಏನು ಮಾಡಬೇಕು ಎಂಬುದನ್ನು ಇದು ಹೋಲುತ್ತದೆ. ಹಲವಾರು ಚೌಕಟ್ಟುಗಳು ಇದನ್ನು ಕೆಲವು ವರ್ಷಗಳ ಹಿಂದೆ ಮಾಡಿತು, ಮತ್ತು ಕೇವಲ ಪ್ಲೇಟ್‌ಗಳು ಬೆಳೆದಿವೆ ಮತ್ತು ಅವುಗಳನ್ನು 8 ಬೈಟ್‌ಗಳಾಗಿ ಪರಿವರ್ತಿಸಬೇಕಾಗಿದೆ.

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

ನೀವು GitHub ನಲ್ಲಿ pg_repack ಅನ್ನು ನೋಡಿದರೆ, ಅಲ್ಲಿ, ID ಯನ್ನು int 4 ರಿಂದ int 8 ಗೆ ಪರಿವರ್ತಿಸುವ ಕಾರ್ಯವಿದ್ದಾಗ, pg_repack ಅನ್ನು ಬಳಸುವ ಆಲೋಚನೆ ಇತ್ತು. ಇದು ಸಹ ಸಾಧ್ಯ, ಆದರೆ ಇದು ಸ್ವಲ್ಪ ಹ್ಯಾಕ್ ಆಗಿದೆ, ಆದರೆ ಇದು ಇದಕ್ಕಾಗಿಯೂ ಕೆಲಸ ಮಾಡುತ್ತದೆ. pg_repack ಬಳಸುವ ಪ್ರಚೋದಕದಲ್ಲಿ ನೀವು ಮಧ್ಯಪ್ರವೇಶಿಸಬಹುದು ಮತ್ತು ಅಲ್ಲಿ ಹೇಳಬಹುದು: "ನಮಗೆ ಈ ಡೇಟಾ ಅಗತ್ಯವಿಲ್ಲ", ಅಂದರೆ ನಮಗೆ ಬೇಕಾದುದನ್ನು ಮಾತ್ರ ನಾವು ವರ್ಗಾಯಿಸುತ್ತೇವೆ. ತದನಂತರ ಅವನು ಸ್ವಿಚ್ ಮಾಡುತ್ತಾನೆ ಮತ್ತು ಅಷ್ಟೆ.

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

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

ನಾನು MySQL ಪ್ರಪಂಚದಿಂದ ಸ್ವಲ್ಪಮಟ್ಟಿಗೆ ಮನುಷ್ಯ, ಆದ್ದರಿಂದ ನಾನು ಕೇಳಲು ಬಂದಿದ್ದೇನೆ. ಮತ್ತು ನಾವು ಈ ವಿಧಾನವನ್ನು ಬಳಸುತ್ತೇವೆ.

ಆದರೆ ಅದು ನಮ್ಮಲ್ಲಿ 90% ಇದ್ದರೆ ಮಾತ್ರ. ನಮ್ಮಲ್ಲಿ 5% ಇದ್ದರೆ, ಅದನ್ನು ಬಳಸುವುದು ತುಂಬಾ ಒಳ್ಳೆಯದಲ್ಲ.

ವರದಿಗಾಗಿ ಧನ್ಯವಾದಗಳು! ಉತ್ಪನ್ನದ ಸಂಪೂರ್ಣ ನಕಲನ್ನು ಮಾಡಲು ಯಾವುದೇ ಸಂಪನ್ಮೂಲಗಳಿಲ್ಲದಿದ್ದರೆ, ಲೋಡ್ ಅಥವಾ ಗಾತ್ರವನ್ನು ಲೆಕ್ಕಾಚಾರ ಮಾಡಲು ಯಾವುದೇ ಅಲ್ಗಾರಿದಮ್ ಅಥವಾ ಸೂತ್ರವಿದೆಯೇ?

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

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

ಒಂದು ವಹಿವಾಟಿನಲ್ಲಿ ಅನೇಕ ದಾಖಲೆಗಳನ್ನು ಅಳಿಸಲು ಅಥವಾ ನವೀಕರಿಸಲು ನಾವು SQL ನಲ್ಲಿ ಹೇಳಿದ್ದರೆ, ನಂತರ ಪೋಸ್ಟ್‌ಗ್ರೆಸ್ ಅದನ್ನು ಅಲ್ಲಿ ಹೇಗೆ ವಿತರಿಸಬಹುದು? ನಾವು ಕಾರ್ಯಾಚರಣೆಗಳಲ್ಲಿ ದೈಹಿಕವಾಗಿ ಸೀಮಿತರಾಗಿದ್ದೇವೆ. ನಾವು ಇನ್ನೂ ದೀರ್ಘಕಾಲ ಮಾಡುತ್ತೇವೆ. ಮತ್ತು ನಾವು ಈ ಸಮಯದಲ್ಲಿ ಲಾಕ್ ಮಾಡುತ್ತೇವೆ, ಇತ್ಯಾದಿ.

ಸೂಚ್ಯಂಕಗಳೊಂದಿಗೆ ಮುಗಿದಿದೆ.

ಅದೇ ಚೆಕ್‌ಪಾಯಿಂಟ್ ಟ್ಯೂನಿಂಗ್ ಅನ್ನು ಸ್ವಯಂಚಾಲಿತಗೊಳಿಸಬಹುದೆಂದು ನಾನು ಊಹಿಸಬಹುದು. ಎಂದಾದರೂ ಆಗಬಹುದು. ಆದರೆ ಆಗ ನನಗೆ ಪ್ರಶ್ನೆ ಅರ್ಥವಾಗುತ್ತಿಲ್ಲ.

ಪ್ರಶ್ನೆಯೆಂದರೆ, ಅಭಿವೃದ್ಧಿಯ ವಾಹಕವು ಅಲ್ಲಿ ಮತ್ತು ಇಲ್ಲಿಗೆ ಹೋಗುತ್ತದೆ ಮತ್ತು ಇಲ್ಲಿ ನಿಮ್ಮದು ಸಮಾನಾಂತರವಾಗಿ ಹೋಗುತ್ತದೆಯೇ? ಆ. ಅವರು ಇನ್ನೂ ಅದರ ಬಗ್ಗೆ ಯೋಚಿಸಲಿಲ್ಲವೇ?

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

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

ಶುಭ ಅಪರಾಹ್ನ ದೀರ್ಘ ವಹಿವಾಟಿನ ಅಪಾಯಗಳ ಬಗ್ಗೆ ನೀವು ಮಾತನಾಡಿದ್ದೀರಿ. ಅಳಿಸುವಿಕೆಗಳ ಸಂದರ್ಭದಲ್ಲಿ ಆಟೋವ್ಯಾಕ್ಯೂಮ್ ಅನ್ನು ನಿರ್ಬಂಧಿಸಲಾಗಿದೆ ಎಂದು ನೀವು ಹೇಳಿದ್ದೀರಿ. ಅದು ನಮಗೆ ಹೇಗೆ ಹಾನಿ ಮಾಡುತ್ತದೆ? ಏಕೆಂದರೆ ನಾವು ಜಾಗವನ್ನು ಮುಕ್ತಗೊಳಿಸುವ ಮತ್ತು ಅದನ್ನು ಬಳಸಲು ಸಾಧ್ಯವಾಗುವ ಬಗ್ಗೆ ಹೆಚ್ಚು ಮಾತನಾಡುತ್ತಿದ್ದೇವೆ. ನಾವು ಇನ್ನೇನು ಕಾಣೆಯಾಗಿದ್ದೇವೆ?

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

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

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

ನಾವು ಈಗಾಗಲೇ ಕಸದ ಆಯ್ಕೆಯನ್ನು ಮಾಡುತ್ತಿರುವಾಗ ಮತ್ತು ನಾವು ಹೊಂದಿರುವಾಗ, ಉದಾಹರಣೆಗೆ, ಅಳಿಸಲಾದ ಫ್ಲ್ಯಾಗ್

ಪೋಸ್ಟ್‌ಗ್ರೆಸ್‌ನಲ್ಲಿ ಆಟೋವ್ಯಾಕ್ಯೂಮ್ ಸ್ವಯಂಚಾಲಿತವಾಗಿ ಏನು ಮಾಡುತ್ತದೆ.

ಓಹ್, ಅವನು ಅದನ್ನು ಮಾಡುತ್ತಾನೆಯೇ?

ಆಟೋವ್ಯಾಕ್ಯೂಮ್ ಕಸ ಸಂಗ್ರಾಹಕ.

ಧನ್ಯವಾದಗಳು!

ವರದಿಗಾಗಿ ಧನ್ಯವಾದಗಳು! ಎಲ್ಲಾ ಕಸವು ಮುಖ್ಯ ಟೇಬಲ್‌ನಿಂದ ಎಲ್ಲೋ ಬದಿಗೆ ಕೊಳಕು ಆಗುವ ರೀತಿಯಲ್ಲಿ ವಿಭಜನೆಯೊಂದಿಗೆ ಡೇಟಾಬೇಸ್ ಅನ್ನು ತಕ್ಷಣವೇ ವಿನ್ಯಾಸಗೊಳಿಸಲು ಒಂದು ಆಯ್ಕೆ ಇದೆಯೇ?

ಸಹಜವಾಗಿ ಹೊಂದಿವೆ.

ನಾವು ಬಳಸಬಾರದ ಟೇಬಲ್‌ಗೆ ಬೀಗ ಹಾಕಿದ್ದರೆ ನಮ್ಮನ್ನು ನಾವು ರಕ್ಷಿಸಿಕೊಳ್ಳಲು ಸಾಧ್ಯವೇ?

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

ಮೂಲ: www.habr.com