DBA ಬೋಟ್ ಜೋ. ಅನಾಟೊಲಿ ಸ್ಟಾನ್ಸ್ಲರ್ (Postgres.ai)

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

ವೀಡಿಯೊ:

ಎಲ್ಲರಿಗು ನಮಸ್ಖರ! ನನ್ನ ಹೆಸರು ಅನಾಟೊಲಿ ಸ್ಟಾನ್ಸ್ಲರ್. ನಾನು ಕಂಪನಿಯಲ್ಲಿ ಕೆಲಸ ಮಾಡುತ್ತೇನೆ postgres.ai. ಡೆವಲಪರ್‌ಗಳು, ಡಿಬಿಎಗಳು ಮತ್ತು ಕ್ಯೂಎಗಳಿಂದ ಪೋಸ್ಟ್‌ಗ್ರೆಸ್‌ನ ಕೆಲಸಕ್ಕೆ ಸಂಬಂಧಿಸಿದ ವಿಳಂಬಗಳನ್ನು ತೆಗೆದುಹಾಕುವ ಮೂಲಕ ಅಭಿವೃದ್ಧಿ ಪ್ರಕ್ರಿಯೆಯನ್ನು ವೇಗಗೊಳಿಸಲು ನಾವು ಬದ್ಧರಾಗಿದ್ದೇವೆ.

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

ನಾವು ಸಂಕೀರ್ಣವಾದ ಹೆಚ್ಚಿನ-ಲೋಡ್ ವಲಸೆಗಳನ್ನು ಅಭಿವೃದ್ಧಿಪಡಿಸುತ್ತಿರುವಾಗ ಮತ್ತು ಮಾಡುತ್ತಿರುವಾಗ, ನಾವು ನಮ್ಮನ್ನು ಕೇಳಿಕೊಳ್ಳುತ್ತೇವೆ: "ಈ ವಲಸೆಯು ತೆಗೆದುಕೊಳ್ಳುತ್ತದೆಯೇ?". ನಾವು ವಿಮರ್ಶೆಯನ್ನು ಬಳಸುತ್ತೇವೆ, ಹೆಚ್ಚು ಅನುಭವಿ ಸಹೋದ್ಯೋಗಿಗಳು, DBA ತಜ್ಞರ ಜ್ಞಾನವನ್ನು ನಾವು ಬಳಸುತ್ತೇವೆ. ಮತ್ತು ಅದು ಹಾರುತ್ತದೆಯೇ ಅಥವಾ ಇಲ್ಲವೇ ಎಂದು ಅವರು ಹೇಳಬಹುದು.

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

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

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

ಇದು ನೋವುಂಟುಮಾಡುತ್ತದೆ, ಇದು ದುಬಾರಿಯಾಗಿದೆ. ಬಹುಶಃ ಮಾಡದಿರುವುದು ಉತ್ತಮ.

ಮತ್ತು ಅದನ್ನು ಮಾಡಲು ಉತ್ತಮ ಮಾರ್ಗ ಯಾವುದು?

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

ಇದು ಕೆಲವು ದೋಷಗಳನ್ನು ತೆಗೆದುಹಾಕಲು ನಮಗೆ ಅನುಮತಿಸುತ್ತದೆ, ಅಂದರೆ ಅವು ಪ್ರಾಡ್‌ನಲ್ಲಿ ಇರುವುದನ್ನು ತಡೆಯುತ್ತದೆ.

ಸಮಸ್ಯೆಗಳೇನು?

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

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

ಇದು ಹಿಂದಿನ ವಿಧಾನಕ್ಕಿಂತ ಉತ್ತಮವಾಗಿದೆ, ಆದರೆ ಕೆಲವು ರೀತಿಯ ದೋಷವು ಉತ್ಪಾದನೆಗೆ ಹೋಗುವ ಹೆಚ್ಚಿನ ಸಂಭವನೀಯತೆ ಇನ್ನೂ ಇದೆ.

ಪ್ರತಿ ಡೆವಲಪರ್‌ಗೆ ಪರೀಕ್ಷಾ ಬೆಂಚ್, ಪೂರ್ಣ-ಗಾತ್ರದ ಪ್ರತಿಯನ್ನು ನೀಡುವುದನ್ನು ತಡೆಯುವುದು ಯಾವುದು? ದಾರಿಯಲ್ಲಿ ಏನು ಸಿಗುತ್ತದೆ ಎಂಬುದು ಸ್ಪಷ್ಟವಾಗಿದೆ ಎಂದು ನಾನು ಭಾವಿಸುತ್ತೇನೆ.

ಟೆರಾಬೈಟ್‌ಗಿಂತ ದೊಡ್ಡದಾದ ಡೇಟಾಬೇಸ್ ಅನ್ನು ಯಾರು ಹೊಂದಿದ್ದಾರೆ? ಅರ್ಧಕ್ಕಿಂತ ಹೆಚ್ಚು ಕೊಠಡಿ.

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

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

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

ಆದರೆ ಅವರು ಈ ವಿಧಾನವನ್ನು ಬಳಸುತ್ತಾರೆ ಏಕೆಂದರೆ ಇದು ಉತ್ಪನ್ನವನ್ನು ವಿಶ್ವಾಸಾರ್ಹವಾಗಿ ಇರಿಸಿಕೊಳ್ಳಲು ಅನುವು ಮಾಡಿಕೊಡುತ್ತದೆ.

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

ಮತ್ತು ಇದು ಸಾಧ್ಯ.

ಮತ್ತು ಈ ವಿಧಾನದಲ್ಲಿ, ನಾವು ಪ್ರತಿ ಡೆವಲಪರ್‌ಗೆ ತೆಳುವಾದ ತದ್ರೂಪುಗಳನ್ನು ಮಾಡಿದಾಗ, ನಾವು ಅದನ್ನು ಒಂದು ಯಂತ್ರದಲ್ಲಿ ಹಂಚಿಕೊಳ್ಳಬಹುದು. ಉದಾಹರಣೆಗೆ, ನೀವು 10TB ಡೇಟಾಬೇಸ್ ಹೊಂದಿದ್ದರೆ ಮತ್ತು ಅದನ್ನು 10 ಡೆವಲಪರ್‌ಗಳಿಗೆ ನೀಡಲು ಬಯಸಿದರೆ, ನೀವು XNUMX x XNUMXTB ಡೇಟಾಬೇಸ್‌ಗಳನ್ನು ಹೊಂದುವ ಅಗತ್ಯವಿಲ್ಲ. ಒಂದು ಯಂತ್ರವನ್ನು ಬಳಸಿಕೊಂಡು ಪ್ರತಿ ಡೆವಲಪರ್‌ಗೆ ತೆಳುವಾದ ಪ್ರತ್ಯೇಕವಾದ ಪ್ರತಿಗಳನ್ನು ಮಾಡಲು ನಿಮಗೆ ಕೇವಲ ಒಂದು ಯಂತ್ರದ ಅಗತ್ಯವಿದೆ. ಇದು ಹೇಗೆ ಕೆಲಸ ಮಾಡುತ್ತದೆ ಎಂಬುದನ್ನು ಸ್ವಲ್ಪ ಸಮಯದ ನಂತರ ನಾನು ನಿಮಗೆ ಹೇಳುತ್ತೇನೆ.

ನಿಜವಾದ ಉದಾಹರಣೆ:

• DB - 4,5 ಟೆರಾಬೈಟ್‌ಗಳು.

• ನಾವು 30 ಸೆಕೆಂಡುಗಳಲ್ಲಿ ಸ್ವತಂತ್ರ ಪ್ರತಿಗಳನ್ನು ಪಡೆಯಬಹುದು.

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

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

ನಮ್ಮ ಸಂದರ್ಭದಲ್ಲಿ, ಇದು OpenZFS ವ್ಯವಸ್ಥೆಯನ್ನು ಬಳಸಿಕೊಂಡು ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ.

OpenZFS ಒಂದು ಕಾಪಿ-ಆನ್-ರೈಟ್ ಫೈಲ್ ಸಿಸ್ಟಮ್ ಆಗಿದ್ದು ಅದು ಬಾಕ್ಸ್‌ನ ಹೊರಗೆ ಸ್ನ್ಯಾಪ್‌ಶಾಟ್‌ಗಳು ಮತ್ತು ಕ್ಲೋನ್‌ಗಳನ್ನು ಬೆಂಬಲಿಸುತ್ತದೆ. ಇದು ವಿಶ್ವಾಸಾರ್ಹ ಮತ್ತು ಸ್ಕೇಲೆಬಲ್ ಆಗಿದೆ. ಅವಳು ನಿರ್ವಹಿಸಲು ತುಂಬಾ ಸುಲಭ. ಇದನ್ನು ಅಕ್ಷರಶಃ ಎರಡು ತಂಡಗಳಲ್ಲಿ ನಿಯೋಜಿಸಬಹುದು.

ಇತರ ಆಯ್ಕೆಗಳಿವೆ:

• ಎಲ್ವಿಎಂ,

• ಸಂಗ್ರಹಣೆ (ಉದಾಹರಣೆಗೆ, ಶುದ್ಧ ಸಂಗ್ರಹಣೆ).

ನಾನು ಮಾತನಾಡುತ್ತಿರುವ ಡೇಟಾಬೇಸ್ ಲ್ಯಾಬ್ ಮಾಡ್ಯುಲರ್ ಆಗಿದೆ. ಈ ಆಯ್ಕೆಗಳನ್ನು ಬಳಸಿಕೊಂಡು ಕಾರ್ಯಗತಗೊಳಿಸಬಹುದು. ಆದರೆ ಸದ್ಯಕ್ಕೆ, ನಾವು OpenZFS ಮೇಲೆ ಕೇಂದ್ರೀಕರಿಸಿದ್ದೇವೆ, ಏಕೆಂದರೆ ನಿರ್ದಿಷ್ಟವಾಗಿ LVM ನಲ್ಲಿ ಸಮಸ್ಯೆಗಳಿದ್ದವು.

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

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

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

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

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

• ಮೊದಲನೆಯದು ಡೇಟಾದ ಮೂಲವಾಗಿದೆ, ನೀವು ಅದನ್ನು ಎಲ್ಲಿಂದ ತೆಗೆದುಕೊಳ್ಳುತ್ತೀರಿ. ನೀವು ಉತ್ಪಾದನೆಯೊಂದಿಗೆ ಪ್ರತಿಕೃತಿಯನ್ನು ಹೊಂದಿಸಬಹುದು. ನೀವು ಕಾನ್ಫಿಗರ್ ಮಾಡಿದ ಬ್ಯಾಕ್‌ಅಪ್‌ಗಳನ್ನು ನೀವು ಈಗಾಗಲೇ ಬಳಸಬಹುದು, ನಾನು ಭಾವಿಸುತ್ತೇನೆ. WAL-E, WAL-G ಅಥವಾ ಬರ್ಮನ್. ಮತ್ತು ನೀವು RDS ಅಥವಾ ಕ್ಲೌಡ್ SQL ನಂತಹ ಕೆಲವು ರೀತಿಯ ಕ್ಲೌಡ್ ಪರಿಹಾರವನ್ನು ಬಳಸುತ್ತಿದ್ದರೂ ಸಹ, ನೀವು ಲಾಜಿಕಲ್ ಡಂಪ್‌ಗಳನ್ನು ಬಳಸಬಹುದು. ಆದರೆ ಬ್ಯಾಕ್‌ಅಪ್‌ಗಳನ್ನು ಬಳಸಲು ನಾವು ಇನ್ನೂ ನಿಮಗೆ ಸಲಹೆ ನೀಡುತ್ತೇವೆ, ಏಕೆಂದರೆ ಈ ವಿಧಾನದಿಂದ ನೀವು ಫೈಲ್‌ಗಳ ಭೌತಿಕ ರಚನೆಯನ್ನು ಸಹ ಉಳಿಸಿಕೊಳ್ಳುತ್ತೀರಿ, ಇದು ಅಸ್ತಿತ್ವದಲ್ಲಿರುವ ಸಮಸ್ಯೆಗಳನ್ನು ಹಿಡಿಯಲು ನೀವು ಉತ್ಪಾದನೆಯಲ್ಲಿ ನೋಡುವ ಮೆಟ್ರಿಕ್‌ಗಳಿಗೆ ಇನ್ನಷ್ಟು ಹತ್ತಿರವಾಗಲು ಅನುವು ಮಾಡಿಕೊಡುತ್ತದೆ.

• ಎರಡನೆಯದು ನೀವು ಡೇಟಾಬೇಸ್ ಲ್ಯಾಬ್ ಅನ್ನು ಹೋಸ್ಟ್ ಮಾಡಲು ಬಯಸುತ್ತೀರಿ. ಅದು ಕ್ಲೌಡ್ ಆಗಿರಬಹುದು, ಆನ್-ಪ್ರಿಮೈಸ್ ಆಗಿರಬಹುದು. ZFS ಡೇಟಾ ಕಂಪ್ರೆಷನ್ ಅನ್ನು ಬೆಂಬಲಿಸುತ್ತದೆ ಎಂದು ಇಲ್ಲಿ ಹೇಳುವುದು ಮುಖ್ಯವಾಗಿದೆ. ಮತ್ತು ಇದು ಸಾಕಷ್ಟು ಚೆನ್ನಾಗಿ ಮಾಡುತ್ತದೆ.

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

ಅಂತಹ ವ್ಯವಸ್ಥೆಯನ್ನು ವಿವಿಧ ಸಂದರ್ಭಗಳಲ್ಲಿ ಬಳಸಬಹುದು.

• ಇವು ಡೆವಲಪರ್‌ಗಳು, ಪ್ರಶ್ನೆ ಮೌಲ್ಯೀಕರಣಕ್ಕಾಗಿ, ಆಪ್ಟಿಮೈಸೇಶನ್‌ಗಾಗಿ DBAಗಳು.

• ನಾವು ಅದನ್ನು ಉತ್ಪನ್ನಕ್ಕೆ ಹೊರತರುವ ಮೊದಲು ನಿರ್ದಿಷ್ಟ ವಲಸೆಯನ್ನು ಪರೀಕ್ಷಿಸಲು QA ಪರೀಕ್ಷೆಯಲ್ಲಿ ಇದನ್ನು ಬಳಸಬಹುದು. ಮತ್ತು ನಾವು ನೈಜ ಡೇಟಾದೊಂದಿಗೆ QA ಗಾಗಿ ವಿಶೇಷ ಪರಿಸರಗಳನ್ನು ಸಹ ಸಂಗ್ರಹಿಸಬಹುದು, ಅಲ್ಲಿ ಅವರು ಹೊಸ ಕಾರ್ಯವನ್ನು ಪರೀಕ್ಷಿಸಬಹುದು. ಮತ್ತು ಇದು ಗಂಟೆಗಳವರೆಗೆ ಕಾಯುವ ಬದಲು ಸೆಕೆಂಡುಗಳನ್ನು ತೆಗೆದುಕೊಳ್ಳುತ್ತದೆ, ಮತ್ತು ತೆಳುವಾದ ನಕಲುಗಳನ್ನು ಬಳಸದ ಇತರ ಕೆಲವು ಸಂದರ್ಭಗಳಲ್ಲಿ ಬಹುಶಃ ದಿನಗಳು.

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

ಈ ವಿಧಾನದೊಂದಿಗೆ:

1. "ಪ್ರಾಡ್" ನಲ್ಲಿ ದೋಷಗಳ ಕಡಿಮೆ ಸಂಭವನೀಯತೆ, ಏಕೆಂದರೆ ನಾವು ಪೂರ್ಣ-ಗಾತ್ರದ ಡೇಟಾದಲ್ಲಿ ಎಲ್ಲಾ ಬದಲಾವಣೆಗಳನ್ನು ಪರೀಕ್ಷಿಸಿದ್ದೇವೆ.

2. ನಾವು ಪರೀಕ್ಷೆಯ ಸಂಸ್ಕೃತಿಯನ್ನು ಹೊಂದಿದ್ದೇವೆ, ಏಕೆಂದರೆ ಈಗ ನೀವು ನಿಮ್ಮ ಸ್ವಂತ ನಿಲುವಿಗಾಗಿ ಗಂಟೆಗಟ್ಟಲೆ ಕಾಯಬೇಕಾಗಿಲ್ಲ.

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

• ಕಡಿಮೆ ರಿಫ್ಯಾಕ್ಟರಿಂಗ್ ಇರುತ್ತದೆ. ಕಡಿಮೆ ದೋಷಗಳು ಉತ್ಪನ್ನದಲ್ಲಿ ಕೊನೆಗೊಳ್ಳುತ್ತವೆ. ನಾವು ಅವುಗಳನ್ನು ಕಡಿಮೆ ನಂತರ ಮರುಪರಿಶೀಲಿಸುತ್ತೇವೆ.

• ನಾವು ಬದಲಾಯಿಸಲಾಗದ ಬದಲಾವಣೆಗಳನ್ನು ಹಿಂತಿರುಗಿಸಬಹುದು. ಇದು ಪ್ರಮಾಣಿತ ವಿಧಾನವಲ್ಲ.

1. ನಾವು ಪರೀಕ್ಷಾ ಬೆಂಚುಗಳ ಸಂಪನ್ಮೂಲಗಳನ್ನು ಹಂಚಿಕೊಳ್ಳುವುದರಿಂದ ಇದು ಪ್ರಯೋಜನಕಾರಿಯಾಗಿದೆ.

ಈಗಾಗಲೇ ಒಳ್ಳೆಯದು, ಆದರೆ ಇನ್ನೇನು ವೇಗಗೊಳಿಸಬಹುದು?

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

ಈಗ ಒಂದು ಕೆಟ್ಟ ವೃತ್ತವಿದೆ, ಡೆವಲಪರ್, ನಿಜವಾದ ಪೂರ್ಣ-ಗಾತ್ರದ ಡೇಟಾಗೆ ಪ್ರವೇಶವನ್ನು ಪಡೆಯಲು, ಪರಿಣಿತರಾಗಬೇಕು. ಅಂತಹ ಪ್ರವೇಶದೊಂದಿಗೆ ಅವನು ನಂಬಬೇಕು.

ಆದರೆ ಅದು ಇಲ್ಲದಿದ್ದರೆ ಹೇಗೆ ಬೆಳೆಯುವುದು. ನಿಮಗೆ ಲಭ್ಯವಿರುವ ಪರೀಕ್ಷಾ ದತ್ತಾಂಶಗಳ ಒಂದು ಚಿಕ್ಕ ಸೆಟ್ ಮಾತ್ರ ಇದ್ದರೆ ಏನು? ಆಗ ನಿಮಗೆ ನಿಜವಾದ ಅನುಭವ ಸಿಗುವುದಿಲ್ಲ.

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

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

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

ಆದರೆ ಸಹಜವಾಗಿ, ಸಮಸ್ಯೆಗಳಿವೆ. ಇದು ನೈಜ ಜಗತ್ತು ಮತ್ತು ನಾವು ಏಕಕಾಲದಲ್ಲಿ ಅನೇಕ ಕ್ಲೋನ್‌ಗಳನ್ನು ಹೋಸ್ಟ್ ಮಾಡುವ ಸರ್ವರ್ ಅನ್ನು ಬಳಸುತ್ತಿರುವ ಕಾರಣ, ನಾವು ಕ್ಲೋನ್‌ಗಳಿಗೆ ಲಭ್ಯವಿರುವ ಮೆಮೊರಿ ಮತ್ತು CPU ಪವರ್‌ನ ಪ್ರಮಾಣವನ್ನು ಕುಗ್ಗಿಸಬೇಕು.

ಆದರೆ ಈ ಪರೀಕ್ಷೆಗಳು ತೋರಿಕೆಯಾಗಬೇಕಾದರೆ, ನೀವು ಹೇಗಾದರೂ ಈ ಸಮಸ್ಯೆಯನ್ನು ಪರಿಹರಿಸಬೇಕಾಗಿದೆ.

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

ಉತ್ಪಾದನೆಯಲ್ಲಿರುವಂತೆಯೇ ಅದೇ ಯಂತ್ರಾಂಶವನ್ನು ಹೊಂದಲು ಇದು ತಂಪಾಗಿರುತ್ತದೆ, ಆದರೆ ಇದು ಭಿನ್ನವಾಗಿರಬಹುದು.

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

ನೀವು ಕಾನ್ಫಿಗರೇಶನ್‌ನಲ್ಲಿ ಯಾವ ಗಾತ್ರವನ್ನು ನಿರ್ದಿಷ್ಟಪಡಿಸುತ್ತೀರಿ ಎಂಬುದರ ಆಧಾರದ ಮೇಲೆ ಪೋಸ್ಟ್‌ಗ್ರೆಸ್ ಪ್ರಾರಂಭವಾದಾಗ ಹಂಚಿಕೆಯ ಬಫರ್ ಸಂಗ್ರಹವನ್ನು ಹಂಚಲಾಗುತ್ತದೆ ಎಂಬುದನ್ನು ಗಮನಿಸುವುದು ಮುಖ್ಯವಾಗಿದೆ.

ಮತ್ತು ಎರಡನೇ ಸಂಗ್ರಹವು ಲಭ್ಯವಿರುವ ಎಲ್ಲಾ ಜಾಗವನ್ನು ಬಳಸುತ್ತದೆ.

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

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

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

ಉದಾಹರಣೆಗೆ, ನಾವು ಉತ್ಪನ್ನದಲ್ಲಿ ದೊಡ್ಡ ಸಂಗ್ರಹವನ್ನು ಹೊಂದಿದ್ದರೆ, ನಂತರ Postgres ಸೂಚ್ಯಂಕವನ್ನು ಬಳಸಲು ಬಯಸುತ್ತದೆ. ಮತ್ತು ಇಲ್ಲದಿದ್ದರೆ, ನಂತರ SeqScan ಇರುತ್ತದೆ. ಮತ್ತು ನಮ್ಮ ಯೋಜನೆಗಳು ಹೊಂದಿಕೆಯಾಗದಿದ್ದರೆ ಏನು ಪ್ರಯೋಜನ?

ಆದರೆ ಇಲ್ಲಿ ನಾವು ವಾಸ್ತವವಾಗಿ ಪೋಸ್ಟ್‌ಗ್ರೆಸ್‌ನಲ್ಲಿನ ಯೋಜನೆಯು ಯೋಜನೆಯಲ್ಲಿ ಹಂಚಿಕೆಯ ಬಫರ್‌ನಲ್ಲಿ ನಿರ್ದಿಷ್ಟಪಡಿಸಿದ ನಿರ್ದಿಷ್ಟ ಗಾತ್ರವನ್ನು ಅವಲಂಬಿಸಿರುವುದಿಲ್ಲ, ಇದು ಪರಿಣಾಮಕಾರಿ_ಕ್ಯಾಶ್_ಸೈಜ್ ಅನ್ನು ಅವಲಂಬಿಸಿರುತ್ತದೆ.

Effective_cache_size ಎಂಬುದು ನಮಗೆ ಲಭ್ಯವಿರುವ ಸಂಗ್ರಹದ ಅಂದಾಜು ಮೊತ್ತವಾಗಿದೆ, ಅಂದರೆ ಬಫರ್ ಸಂಗ್ರಹ ಮತ್ತು ಫೈಲ್ ಸಿಸ್ಟಮ್ ಸಂಗ್ರಹದ ಮೊತ್ತ. ಇದನ್ನು ಸಂರಚನೆಯಿಂದ ಹೊಂದಿಸಲಾಗಿದೆ. ಮತ್ತು ಈ ಸ್ಮರಣೆಯನ್ನು ನಿಯೋಜಿಸಲಾಗಿಲ್ಲ.

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

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

• ಇದು ಪ್ರಸ್ತುತ ಉತ್ಪನ್ನದ ಮೇಲೆ ಇರುವ ಲೋಡ್ ಅನ್ನು ಅವಲಂಬಿಸಿರುತ್ತದೆ.

• ಇದು ಯಂತ್ರದ ಗುಣಲಕ್ಷಣಗಳನ್ನು ಅವಲಂಬಿಸಿರುತ್ತದೆ.

ಮತ್ತು ಇದು ಪರೋಕ್ಷ ನಿಯತಾಂಕವಾಗಿದೆ, ಆದರೆ ವಾಸ್ತವವಾಗಿ ಫಲಿತಾಂಶವನ್ನು ಪಡೆಯಲು ಈ ಪ್ರಶ್ನೆಯು ಓದುವ ಡೇಟಾದ ಪ್ರಮಾಣದಿಂದ ನಾವು ನಿಖರವಾಗಿ ಆಪ್ಟಿಮೈಜ್ ಮಾಡಬಹುದು.

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

ಜೋ ನಿರ್ದಿಷ್ಟವಾಗಿ ಹೇಗೆ ಹೊಂದುವಂತೆ ಮಾಡಲಾಗಿದೆ ಎಂಬುದನ್ನು ನೋಡೋಣ.

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

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

ಯೋಜನೆ ಮತ್ತು ಮೆಟ್ರಿಕ್‌ಗಳ ಆಧಾರದ ಮೇಲೆ ಬಿ ಜೋ ನಿಮಗೆ ಸ್ವಯಂಚಾಲಿತ ಶಿಫಾರಸುಗಳನ್ನು ತೋರಿಸುತ್ತಾರೆ.

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

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

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

ಮತ್ತು ಪ್ರಶ್ನೆಯಲ್ಲಿನ ಪರಿಸ್ಥಿತಿಗಳು ಮತ್ತು ಸೂಚ್ಯಂಕದಲ್ಲಿನ ಷರತ್ತುಗಳು ಭಾಗಶಃ ಹೊಂದಿಕೆಯಾಗದ ಕಾರಣ ಇದು ಯೋಜನೆಯಲ್ಲಿ ಸಂಭವಿಸಿದೆ.

ಸೂಚ್ಯಂಕವನ್ನು ಹೆಚ್ಚು ನಿಖರವಾಗಿ ಮಾಡಲು ಪ್ರಯತ್ನಿಸೋಣ ಮತ್ತು ಅದರ ನಂತರ ಪ್ರಶ್ನೆಯ ಕಾರ್ಯಗತಗೊಳಿಸುವಿಕೆಯು ಹೇಗೆ ಬದಲಾಗುತ್ತದೆ ಎಂಬುದನ್ನು ನೋಡೋಣ.

ಸೂಚ್ಯಂಕದ ರಚನೆಯು ಸಾಕಷ್ಟು ಸಮಯ ತೆಗೆದುಕೊಂಡಿತು, ಆದರೆ ಈಗ ನಾವು ಪ್ರಶ್ನೆಯನ್ನು ಪರಿಶೀಲಿಸುತ್ತೇವೆ ಮತ್ತು 2,5 ನಿಮಿಷಗಳ ಬದಲಿಗೆ ಸಮಯವು ಕೇವಲ 156 ಮಿಲಿಸೆಕೆಂಡುಗಳು ಎಂದು ನೋಡುತ್ತೇವೆ, ಅದು ಸಾಕಷ್ಟು ಉತ್ತಮವಾಗಿದೆ. ಮತ್ತು ನಾವು ಕೇವಲ 6 ಮೆಗಾಬೈಟ್ ಡೇಟಾವನ್ನು ಓದುತ್ತೇವೆ.

ಮತ್ತು ಈಗ ನಾವು ಸೂಚ್ಯಂಕ ಮಾತ್ರ ಸ್ಕ್ಯಾನ್ ಅನ್ನು ಬಳಸುತ್ತೇವೆ.

ಇನ್ನೊಂದು ಪ್ರಮುಖ ಕಥೆ ಏನೆಂದರೆ, ನಾವು ಯೋಜನೆಯನ್ನು ಇನ್ನಷ್ಟು ಅರ್ಥವಾಗುವ ರೀತಿಯಲ್ಲಿ ಪ್ರಸ್ತುತಪಡಿಸಲು ಬಯಸುತ್ತೇವೆ. ನಾವು ಫ್ಲೇಮ್ ಗ್ರಾಫ್‌ಗಳನ್ನು ಬಳಸಿಕೊಂಡು ದೃಶ್ಯೀಕರಣವನ್ನು ಅಳವಡಿಸಿದ್ದೇವೆ.

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

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

ಸಹಜವಾಗಿ, ಎಲ್ಲರಿಗೂ ವಿವರಿಸಲು ತಿಳಿದಿದೆ.depesz.com. ಈ ದೃಶ್ಯೀಕರಣದ ಉತ್ತಮ ವೈಶಿಷ್ಟ್ಯವೆಂದರೆ ನಾವು ಪಠ್ಯ ಯೋಜನೆಯನ್ನು ಉಳಿಸುತ್ತೇವೆ ಮತ್ತು ಕೆಲವು ಮೂಲಭೂತ ನಿಯತಾಂಕಗಳನ್ನು ಟೇಬಲ್‌ಗೆ ಹಾಕುತ್ತೇವೆ ಇದರಿಂದ ನಾವು ವಿಂಗಡಿಸಬಹುದು.

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

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

ಸಹಯೋಗ

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

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

ಪರಿಹಾರವು ಸ್ವತಃ ಕ್ರಾಂತಿಕಾರಿ ಅಲ್ಲ ಎಂದು ಗಮನಿಸುವುದು ಮುಖ್ಯವಾಗಿದೆ, ಏಕೆಂದರೆ ಡೆಲ್ಫಿಕ್ಸ್ ಇದೆ, ಆದರೆ ಇದು ಎಂಟರ್‌ಪ್ರೈಸ್ ಪರಿಹಾರವಾಗಿದೆ. ಇದು ಸಂಪೂರ್ಣವಾಗಿ ಮುಚ್ಚಲ್ಪಟ್ಟಿದೆ, ಇದು ತುಂಬಾ ದುಬಾರಿಯಾಗಿದೆ. ನಾವು ವಿಶೇಷವಾಗಿ Postgres ನಲ್ಲಿ ಪರಿಣತಿ ಹೊಂದಿದ್ದೇವೆ. ಇವೆಲ್ಲವೂ ಓಪನ್ ಸೋರ್ಸ್ ಉತ್ಪನ್ನಗಳು. ನಮ್ಮ ಜೊತೆಗೂಡು!

ಇಲ್ಲಿ ನಾನು ಕೊನೆಗೊಳ್ಳುತ್ತೇನೆ. ಧನ್ಯವಾದ!

ಪ್ರಶ್ನೆಗಳು

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

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

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

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

ಪ್ರತಿ ಕ್ಲೋನ್‌ಗೆ ಕೆಲವು ಟಿಟಿಎಲ್ ಇದೆ. ಮೂಲಭೂತವಾಗಿ, ನಾವು ಸ್ಥಿರ ಟಿಟಿಎಲ್ ಅನ್ನು ಹೊಂದಿದ್ದೇವೆ.

ಏನು, ರಹಸ್ಯವಾಗಿಲ್ಲದಿದ್ದರೆ?

1 ಗಂಟೆ, ಅಂದರೆ ಐಡಲ್ - 1 ಗಂಟೆ. ಅದನ್ನು ಬಳಸದಿದ್ದರೆ, ನಾವು ಅದನ್ನು ಬ್ಯಾಂಗ್ ಮಾಡುತ್ತೇವೆ. ಆದರೆ ಇಲ್ಲಿ ಯಾವುದೇ ಆಶ್ಚರ್ಯವಿಲ್ಲ, ಏಕೆಂದರೆ ನಾವು ಸೆಕೆಂಡುಗಳಲ್ಲಿ ಕ್ಲೋನ್ ಅನ್ನು ಹೆಚ್ಚಿಸಬಹುದು. ಮತ್ತು ನಿಮಗೆ ಮತ್ತೆ ಅಗತ್ಯವಿದ್ದರೆ, ದಯವಿಟ್ಟು.

ತಂತ್ರಜ್ಞಾನಗಳ ಆಯ್ಕೆಯಲ್ಲಿ ನಾನು ಆಸಕ್ತಿ ಹೊಂದಿದ್ದೇನೆ, ಏಕೆಂದರೆ, ಉದಾಹರಣೆಗೆ, ನಾವು ಒಂದು ಕಾರಣಕ್ಕಾಗಿ ಅಥವಾ ಇನ್ನೊಂದು ಕಾರಣಕ್ಕಾಗಿ ಹಲವಾರು ವಿಧಾನಗಳನ್ನು ಸಮಾನಾಂತರವಾಗಿ ಬಳಸುತ್ತೇವೆ. ಏಕೆ ZFS? ನೀವು LVM ಅನ್ನು ಏಕೆ ಬಳಸಲಿಲ್ಲ? LVM ನಲ್ಲಿ ಸಮಸ್ಯೆಗಳಿವೆ ಎಂದು ನೀವು ಉಲ್ಲೇಖಿಸಿದ್ದೀರಿ. ಸಮಸ್ಯೆಗಳೇನು? ನನ್ನ ಅಭಿಪ್ರಾಯದಲ್ಲಿ, ಕಾರ್ಯಕ್ಷಮತೆಯ ದೃಷ್ಟಿಯಿಂದ ಶೇಖರಣೆಯೊಂದಿಗೆ ಅತ್ಯಂತ ಸೂಕ್ತವಾದ ಆಯ್ಕೆಯಾಗಿದೆ.

ZFS ನ ಮುಖ್ಯ ಸಮಸ್ಯೆ ಏನು? ನೀವು ಒಂದೇ ಹೋಸ್ಟ್‌ನಲ್ಲಿ ರನ್ ಮಾಡಬೇಕು, ಅಂದರೆ ಎಲ್ಲಾ ನಿದರ್ಶನಗಳು ಒಂದೇ OS ನಲ್ಲಿ ವಾಸಿಸುತ್ತವೆ. ಮತ್ತು ಸಂಗ್ರಹಣೆಯ ಸಂದರ್ಭದಲ್ಲಿ, ನೀವು ವಿವಿಧ ಸಾಧನಗಳನ್ನು ಸಂಪರ್ಕಿಸಬಹುದು. ಮತ್ತು ಅಡಚಣೆಯು ಶೇಖರಣಾ ವ್ಯವಸ್ಥೆಯಲ್ಲಿರುವ ಬ್ಲಾಕ್‌ಗಳು ಮಾತ್ರ. ಮತ್ತು ತಂತ್ರಜ್ಞಾನಗಳ ಆಯ್ಕೆಯ ಪ್ರಶ್ನೆಯು ಆಸಕ್ತಿದಾಯಕವಾಗಿದೆ. ಏಕೆ LVM ಅಲ್ಲ?

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

ನಿಕೊಲಾಯ್ ಸಮೋಖ್ವಾಲೋವ್: ನಾನು ಮತ್ತಷ್ಟು ಕಾಮೆಂಟ್ ಮಾಡಬಹುದೇ? ನನ್ನ ಹೆಸರು ನಿಕೋಲಾಯ್, ನಾವು ಅನಾಟೊಲಿಯೊಂದಿಗೆ ಕೆಲಸ ಮಾಡುತ್ತೇವೆ. ಸಂಗ್ರಹಣೆ ಉತ್ತಮವಾಗಿದೆ ಎಂದು ನಾನು ಒಪ್ಪುತ್ತೇನೆ. ಮತ್ತು ನಮ್ಮ ಕೆಲವು ಗ್ರಾಹಕರು ಶುದ್ಧ ಸಂಗ್ರಹಣೆ ಇತ್ಯಾದಿಗಳನ್ನು ಹೊಂದಿದ್ದಾರೆ.

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

ಆದರೆ ZFS ಎಲ್ಲರಿಗೂ ಲಭ್ಯವಿದೆ. DelPhix ಈಗಾಗಲೇ ಸಾಕಷ್ಟು, ಅವರು 300 ಗ್ರಾಹಕರನ್ನು ಹೊಂದಿದ್ದಾರೆ. ಇವುಗಳಲ್ಲಿ, ಫಾರ್ಚೂನ್ 100 50 ಕ್ಲೈಂಟ್‌ಗಳನ್ನು ಹೊಂದಿದೆ, ಅಂದರೆ ಅವರು NASA ಅನ್ನು ಗುರಿಯಾಗಿಸಿಕೊಂಡಿದ್ದಾರೆ, ಇತ್ಯಾದಿ. ಪ್ರತಿಯೊಬ್ಬರೂ ಈ ತಂತ್ರಜ್ಞಾನವನ್ನು ಪಡೆಯುವ ಸಮಯ. ಮತ್ತು ಅದಕ್ಕಾಗಿಯೇ ನಾವು ತೆರೆದ ಮೂಲ ಕೋರ್ ಅನ್ನು ಹೊಂದಿದ್ದೇವೆ. ನಾವು ಮುಕ್ತ ಮೂಲವಲ್ಲದ ಇಂಟರ್ಫೇಸ್ ಭಾಗವನ್ನು ಹೊಂದಿದ್ದೇವೆ. ಇದು ನಾವು ತೋರಿಸುವ ವೇದಿಕೆ. ಆದರೆ ಅದು ಎಲ್ಲರಿಗೂ ಲಭ್ಯವಾಗಬೇಕೆಂದು ನಾವು ಬಯಸುತ್ತೇವೆ. ಲ್ಯಾಪ್‌ಟಾಪ್‌ಗಳಲ್ಲಿ ಎಲ್ಲಾ ಪರೀಕ್ಷಕರು ಊಹಿಸುವುದನ್ನು ನಿಲ್ಲಿಸುವಂತೆ ನಾವು ಕ್ರಾಂತಿಯನ್ನು ಮಾಡಲು ಬಯಸುತ್ತೇವೆ. ನಾವು SELECT ಎಂದು ಬರೆಯಬೇಕು ಮತ್ತು ಅದು ನಿಧಾನವಾಗಿದೆ ಎಂದು ತಕ್ಷಣ ನೋಡಬೇಕು. ಅದರ ಬಗ್ಗೆ DBA ನಿಮಗೆ ಹೇಳಲು ಕಾಯುವುದನ್ನು ನಿಲ್ಲಿಸಿ. ಇಲ್ಲಿ ಮುಖ್ಯ ಗುರಿಯಾಗಿದೆ. ಮತ್ತು ನಾವೆಲ್ಲರೂ ಇದಕ್ಕೆ ಬರುತ್ತೇವೆ ಎಂದು ನಾನು ಭಾವಿಸುತ್ತೇನೆ. ಮತ್ತು ಪ್ರತಿಯೊಬ್ಬರೂ ಹೊಂದಲು ನಾವು ಈ ವಿಷಯವನ್ನು ತಯಾರಿಸುತ್ತೇವೆ. ಆದ್ದರಿಂದ ZFS, ಏಕೆಂದರೆ ಇದು ಎಲ್ಲೆಡೆ ಲಭ್ಯವಿರುತ್ತದೆ. ಸಮಸ್ಯೆಗಳನ್ನು ಪರಿಹರಿಸಲು ಮತ್ತು ಮುಕ್ತ ಮೂಲ ಪರವಾನಗಿ ಇತ್ಯಾದಿಗಳನ್ನು ಹೊಂದಿದ್ದಕ್ಕಾಗಿ ಸಮುದಾಯಕ್ಕೆ ಧನ್ಯವಾದಗಳು.*

ಶುಭಾಶಯಗಳು! ವರದಿಗಾಗಿ ಧನ್ಯವಾದಗಳು! ನನ್ನ ಹೆಸರು ಮ್ಯಾಕ್ಸಿಮ್. ನಾವು ಅದೇ ಸಮಸ್ಯೆಗಳನ್ನು ನಿಭಾಯಿಸಿದ್ದೇವೆ. ಅವರು ತಮ್ಮದೇ ಆದ ಮೇಲೆ ನಿರ್ಧರಿಸಿದರು. ಈ ತದ್ರೂಪುಗಳ ನಡುವೆ ನೀವು ಸಂಪನ್ಮೂಲಗಳನ್ನು ಹೇಗೆ ಹಂಚಿಕೊಳ್ಳುತ್ತೀರಿ? ಪ್ರತಿಯೊಂದು ಕ್ಲೋನ್ ಯಾವುದೇ ಸಮಯದಲ್ಲಿ ತನ್ನದೇ ಆದ ಕೆಲಸವನ್ನು ಮಾಡಬಹುದು: ಒಬ್ಬರು ಒಂದು ವಿಷಯವನ್ನು ಪರೀಕ್ಷಿಸುತ್ತಾರೆ, ಇನ್ನೊಂದು ಇನ್ನೊಂದು, ಯಾರಾದರೂ ಸೂಚ್ಯಂಕವನ್ನು ನಿರ್ಮಿಸುತ್ತಾರೆ, ಯಾರಿಗಾದರೂ ಭಾರೀ ಕೆಲಸವಿದೆ. ಮತ್ತು ನೀವು ಇನ್ನೂ CPU ನಿಂದ ಭಾಗಿಸಬಹುದಾದರೆ, ನಂತರ IO ಮೂಲಕ, ನೀವು ಹೇಗೆ ಭಾಗಿಸುತ್ತೀರಿ? ಇದು ಮೊದಲ ಪ್ರಶ್ನೆ.

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

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

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

ನನಗೆ ಎರಡು ಪ್ರಶ್ನೆಗಳಿವೆ. ಇದು ತುಂಬಾ ತಂಪಾದ ವಿಷಯವಾಗಿದೆ. ಕ್ರೆಡಿಟ್ ಕಾರ್ಡ್ ಸಂಖ್ಯೆಗಳಂತಹ ಉತ್ಪಾದನಾ ಡೇಟಾವು ನಿರ್ಣಾಯಕವಾಗಿರುವ ಸಂದರ್ಭಗಳಿವೆಯೇ? ಈಗಾಗಲೇ ಏನಾದರೂ ಸಿದ್ಧವಾಗಿದೆಯೇ ಅಥವಾ ಅದು ಪ್ರತ್ಯೇಕ ಕಾರ್ಯವೇ? ಮತ್ತು ಎರಡನೇ ಪ್ರಶ್ನೆ - MySQL ಗೆ ಈ ರೀತಿಯ ಏನಾದರೂ ಇದೆಯೇ?

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

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

ಆದರೆ ಸಿಸ್ಟಮ್ ವಿಸ್ತರಿಸಬಹುದಾದ ಕಾರಣ, ಇದನ್ನು MySQL ಗಾಗಿಯೂ ಬಳಸಬಹುದು. ಮತ್ತು ಅಂತಹ ಉದಾಹರಣೆಗಳಿವೆ. ಯಾಂಡೆಕ್ಸ್ ಇದೇ ರೀತಿಯ ವಿಷಯವನ್ನು ಹೊಂದಿದೆ, ಆದರೆ ಅವರು ಅದನ್ನು ಎಲ್ಲಿಯೂ ಪ್ರಕಟಿಸುವುದಿಲ್ಲ. ಅವರು ಅದನ್ನು Yandex.Metrica ಒಳಗೆ ಬಳಸುತ್ತಾರೆ. ಮತ್ತು MySQL ಬಗ್ಗೆ ಕೇವಲ ಒಂದು ಕಥೆ ಇದೆ. ಆದರೆ ತಂತ್ರಜ್ಞಾನಗಳು ಒಂದೇ ಆಗಿವೆ, ZFS.

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

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

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

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

ಪ್ರತಿ ಬಾರಿಯೂ ಸೂಚ್ಯಂಕವನ್ನು ರಚಿಸಲಾಗುತ್ತದೆಯೇ?

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

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

ಇಲ್ಲಿ ಇನ್ನೊಂದು ಸಮಸ್ಯೆ ಇದೆ. ನೀವು ಕ್ಲೌಡ್ ಪರಿಹಾರವನ್ನು ಬಳಸಿದರೆ, ಅಲ್ಲಿ ತಾರ್ಕಿಕ ಡಂಪ್‌ಗಳು ಮಾತ್ರ ಲಭ್ಯವಿರುತ್ತವೆ, ಏಕೆಂದರೆ Google, Amazon ನಿಮಗೆ ಭೌತಿಕ ನಕಲನ್ನು ತೆಗೆದುಕೊಳ್ಳಲು ಅನುಮತಿಸುವುದಿಲ್ಲ. ಸಮಸ್ಯೆ ಇರುತ್ತದೆ.

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

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

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

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

ಹಿಂದಿನ ಪ್ರತಿಕೃತಿಗಳಿಂದ ಹಿಂದಿನ ಲೇಯರ್‌ಗಳಿಂದ.

ಹಿಂದಿನ ಲೇಯರ್‌ಗಳು ಬೀಳುತ್ತವೆ, ಆದರೆ ಅವು ಹಳೆಯ ಲೇಯರ್ ಅನ್ನು ಉಲ್ಲೇಖಿಸುತ್ತವೆ ಮತ್ತು ನವೀಕರಣದಲ್ಲಿ ಸ್ವೀಕರಿಸಿದ ಕೊನೆಯ ಲೇಯರ್‌ನಿಂದ ಅವರು ಹೊಸ ಚಿತ್ರಗಳನ್ನು ತೆಗೆದುಕೊಳ್ಳುತ್ತಾರೆಯೇ?

ಸಾಮಾನ್ಯವಾಗಿ, ಹೌದು.

ನಂತರ ಪರಿಣಾಮವಾಗಿ ನಾವು ಪದರಗಳ ಅಂಜೂರದವರೆಗೆ ಹೊಂದಿರುತ್ತದೆ. ಮತ್ತು ಕಾಲಾನಂತರದಲ್ಲಿ ಅವುಗಳನ್ನು ಸಂಕುಚಿತಗೊಳಿಸಬೇಕೇ?

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

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

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

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

ಈಗ ಸ್ಲಾಕ್‌ಗೆ ಲಿಂಕ್ ಇದೆ, ಅಂದರೆ ಬೇರೆ ಯಾವುದೇ ಸಂದೇಶವಾಹಕ ಇಲ್ಲ, ಆದರೆ ನಾನು ನಿಜವಾಗಿಯೂ ಇತರ ಸಂದೇಶವಾಹಕರಿಗೆ ಬೆಂಬಲವನ್ನು ನೀಡಲು ಬಯಸುತ್ತೇನೆ. ನೀವು ಏನು ಮಾಡಬಹುದು? ನೀವು ಜೋ ಇಲ್ಲದೆ DB ಲ್ಯಾಬ್ ಅನ್ನು ನಿಯೋಜಿಸಬಹುದು, REST API ಸಹಾಯದಿಂದ ಅಥವಾ ನಮ್ಮ ಪ್ಲಾಟ್‌ಫಾರ್ಮ್‌ನ ಸಹಾಯದಿಂದ ಹೋಗಿ ಮತ್ತು ತದ್ರೂಪುಗಳನ್ನು ರಚಿಸಬಹುದು ಮತ್ತು PSQL ನೊಂದಿಗೆ ಸಂಪರ್ಕಿಸಬಹುದು. ಆದರೆ ನಿಮ್ಮ ಡೆವಲಪರ್‌ಗಳಿಗೆ ಡೇಟಾಗೆ ಪ್ರವೇಶವನ್ನು ನೀಡಲು ನೀವು ಸಿದ್ಧರಾಗಿದ್ದರೆ ಇದನ್ನು ಮಾಡಬಹುದು, ಏಕೆಂದರೆ ಇನ್ನು ಮುಂದೆ ಯಾವುದೇ ಪರದೆಯು ಇರುವುದಿಲ್ಲ.

ನನಗೆ ಈ ಪದರ ಅಗತ್ಯವಿಲ್ಲ, ಆದರೆ ನನಗೆ ಅಂತಹ ಅವಕಾಶ ಬೇಕು.

ನಂತರ ಹೌದು, ಇದನ್ನು ಮಾಡಬಹುದು.

ಮೂಲ: www.habr.com