OpenAIನಲ್ಲಿ Git ಸಾಮರ್ಥ್ಯ ವಿಸ್ತರಣೆ
Git ಪರಿಸರ ವ್ಯವಸ್ಥೆಯಲ್ಲಿ ಹೂಡಿಕೆ ಮಾಡುತ್ತಲೇ, ಏಜೆಂಟ್‌ಗಳ ಕಾರ್ಯಪ್ರಮಾಣಕ್ಕೆ ತಕ್ಕ ಮೂಲ ಕೋಡ್ ನಿಯಂತ್ರಣದ ನಿರ್ಮಾಣ.
ಕಳೆದ ವರ್ಷದಲ್ಲಿ, ನಮ್ಮ ಏಕೀಕೃತ ರಿಪೊಸಿಟರಿಯ ಗಾತ್ರ ಮತ್ತು ಅದರ ಮೇಲಿನ ಬೇಡಿಕೆಗಳು ಅಚ್ಚರಿಯ ವೇಗದಲ್ಲಿ ಹೆಚ್ಚಾಗಿವೆ. Codex ಸಾಧ್ಯವಾಗಿಸುವ ಏಕಕಾಲದ ಕೆಲಸದ ಪ್ರಮಾಣಕ್ಕೆ ತಕ್ಕಂತೆ ವಿಸ್ತರಿಸಲು, ನಮ್ಮ ಮೂಲ ಕೋಡ್ ನಿಯಂತ್ರಣ ವ್ಯವಸ್ಥೆಯನ್ನು ಪುನರ್‌ರೂಪಿಸಬೇಕೆಂಬುದು ಸ್ಪಷ್ಟವಾಗಿತ್ತು.
ಯಾವುದೇ ಎಂಜಿನಿಯರಿಂಗ್ ಕೆಲಸಕ್ಕೆ ಅಡ್ಡಿಯಾಗದೆ ಅಥವಾ ನಮ್ಮ ತಂಡ Git ಬಳಸುವ ರೀತಿಯನ್ನು ಬದಲಿಸದೆ, Git ರಿಪೊಸಿಟರಿಗಳಿಗೆ ಹೊಸ ಹಿಂಭಾಗದ ವ್ಯವಸ್ಥೆಯಾದ Pando ನಿರ್ಮಿಸಿದೆವು. ಈಗ OpenAIನ ಏಕೀಕೃತ ರಿಪೊಸಿಟರಿಯ ಎಲ್ಲ ಅಭಿವೃದ್ಧಿ ಕಾರ್ಯಕ್ಕೂ Pando ಆಧಾರವಾಗಿದೆ. Pando ವಿನ್ಯಾಸಕ್ಕೆ ಎರಡು ಮಹತ್ವಾಕಾಂಕ್ಷಿ ಗುರಿಗಳಿವೆ: ಮೊದಲನೆಯದು, ಅನೇಕ ಶಾಖೆಗಳಿಗೆ ಏಕಕಾಲದಲ್ಲಿ ಪುಶ್ ಮಾಡಲು ಅನುಕೂಲವಾಗುವಂತೆ, ಹೆಚ್ಚಿನ ಘಟಕಗಳನ್ನು ಸೇರಿಸಿ ವಿಸ್ತರಿಸಬಹುದಾದ ಬರವಣಿಗೆ ಸಾಮರ್ಥ್ಯ. ಎರಡನೆಯದು, ಓದುವ ಥ್ರೂಪುಟ್ ಗರಿಷ್ಠಗೊಳಿಸುವುದು. ಇದರಿಂದ ಕ್ಲೈಂಟ್‌ಗಳು ಲಭ್ಯ ಜಾಲದ ಬ್ಯಾಂಡ್‌ವಿಡ್ತ್ ಅನ್ನು ಸಂಪೂರ್ಣ ಬಳಸುವಷ್ಟು ವೇಗವಾಗಿ ಡೇಟಾ ಡೌನ್‌ಲೋಡ್ ಮಾಡಬಹುದು.
Git ಪ್ರೋಟೋಕಾಲ್ ಮತ್ತು ಕ್ಲೈಂಟ್‌ನೊಂದಿಗೆ ಹೊಂದಾಣಿಕೆ ಉಳಿಸಿಕೊಂಡೇ ಈ ಗುರಿಗಳನ್ನು ಸಾಧಿಸಿದೆವು. ಇದರಿಂದ ನಮ್ಮ ಎಂಜಿನಿಯರ್‌ಗಳು ಮತ್ತು ಏಜೆಂಟ್‌ಗಳು ತಮ್ಮ ಈಗಿನ ಕಾರ್ಯವಿಧಾನಗಳಲ್ಲಿ Pandoವನ್ನು ಸುಲಭವಾಗಿ ಅಳವಡಿಸಿಕೊಳ್ಳಲು ಸಾಧ್ಯವಾಯಿತು. ನೈಜ ಬಳಕೆಯಲ್ಲಿ, Pando ಪುಶ್ ವಿಳಂಬದ ಮಧ್ಯಕವನ್ನು ಸುಮಾರು ಐದನೇ ಒಂದು ಭಾಗಕ್ಕೆ ಇಳಿಸಿತು. ಈಗ ಅದು ದಿನಕ್ಕೆ ಸುಮಾರು ಒಂದು ಪೆಟಾಬೈಟ್ Git ಡೇಟಾವನ್ನು ಒದಗಿಸುತ್ತದೆ.
ಹೊಸ ಮೂಲ ಕೋಡ್ ನಿಯಂತ್ರಣ ವ್ಯವಸ್ಥೆಯನ್ನು ನಿರ್ಮಿಸಲು ನಮಗಿದ್ದ ಕಾರಣಗಳನ್ನು ಮತ್ತು Git ಹೊಂದಾಣಿಕೆ ಉಳಿಸಿಕೊಳ್ಳಲು ನಿರ್ಧರಿಸಿದ್ದೇಕೆ ಎಂಬುದನ್ನು ಇಲ್ಲಿ ವಿವರಿಸುತ್ತೇವೆ. Git ಸಾಮರ್ಥ್ಯ ವಿಸ್ತರಿಸುವ ಸಾಮಾನ್ಯ ವಿಧಾನಗಳೊಂದಿಗೆ ನಮ್ಮ ವ್ಯವಸ್ಥೆಯನ್ನು ಹೋಲಿಸಿ, OpenAIನ ವಿಸ್ತರಣಾ ಅಗತ್ಯಗಳನ್ನು ಪೂರೈಸಲು Pando ಏಕೆ ವಿಶೇಷವಾಗಿ ಸಮರ್ಥವಾಗಿದೆ ಎಂಬುದನ್ನು ವಿವರಿಸುತ್ತೇವೆ. ಮುಂದಿನ ಯೋಜನೆಗಳು ಮತ್ತು ಏಜೆಂಟ್‌ಗಳ ಪ್ರಮಾಣದ ಕೆಲಸಕ್ಕೆ ಬೆಂಬಲ ನೀಡಲು Gitಗೆ ನಮ್ಮ ಕೊಡುಗೆಗಳನ್ನು ಹೇಗೆ ಮುಂದುವರಿಸುತ್ತೇವೆ ಎಂಬುದನ್ನೂ ಚರ್ಚಿಸುತ್ತೇವೆ.
Codex, OpenAIನ ಅಭಿವೃದ್ಧಿಯ ಪ್ರಮಾಣ ಮತ್ತು ವೇಗವನ್ನು ಬದಲಿಸಿದೆ. ಎಂಜಿನಿಯರ್‌ಗಳು ಸಮಾನಾಂತರವಾಗಿ ಇನ್ನಷ್ಟು ಹೆಚ್ಚಿನ ಕೆಲಸ ಮಾಡಲು ಇದು ಅವಕಾಶ ನೀಡಿದೆ. ಅಂದರೆ ಹೆಚ್ಚಿನ ಶಾಖೆಗಳು, ಪುಶ್‌ಗಳು ಮತ್ತು ವಿಲೀನಗಳು; ಜೊತೆಗೆ ಅಭಿವೃದ್ಧಿ ಪರಿಸರಗಳು, ಸಂಶೋಧನಾ ಕಾರ್ಯಗಳು ಮತ್ತು ನಿರಂತರ ಏಕೀಕರಣದಿಂದ ಹೆಚ್ಚಿನ ಫೆಚ್‌ಗಳು ಮತ್ತು ಕ್ಲೋನ್‌ಗಳು.
ಈ ಬೇಡಿಕೆಗಳು ಒಂದಕ್ಕೊಂದು ಸೇರಿ ಹೆಚ್ಚುತ್ತವೆ. ಈಗ ಒಬ್ಬ ಎಂಜಿನಿಯರ್ ಒಮ್ಮೆಗೆ ಹಲವು ಬದಲಾವಣೆಗಳನ್ನು ನಿರಂತರ ಏಕೀಕರಣಕ್ಕೆ ಸಿದ್ಧವಾಗಿಡುತ್ತಾರೆ. ಪ್ರತಿ ಪುಶ್ ಒಂದೇ ಕಮಿಟ್ ಪಡೆಯುವ ಹಲವು ಕಾರ್ಯಗಳನ್ನು ಪ್ರಾರಂಭಿಸಬಹುದು.
ಕಳೆದ ವರ್ಷದ ಕೊನೆಯ ಹೊತ್ತಿನಿಂದ, ನಮ್ಮ ಏಕೀಕೃತ ರಿಪೊಸಿಟರಿಗೆ ಆಧಾರವಾಗಿದ್ದ ವ್ಯವಸ್ಥೆಗಳು ಈ ವೇಗಕ್ಕೆ ಹೊಂದಿಕೊಳ್ಳಲು ಹೆಣಗುತ್ತಿದ್ದವು. ಫೆಚ್ ಮತ್ತು ಪುಶ್‌ಗಳು ನಿಧಾನವಾದವು, ವಿಲೀನಗಳು ವಿಫಲವಾದವು; ಕೆಲವೊಮ್ಮೆ ವಿಶ್ವಾಸಾರ್ಹತೆ 90%ಗಿಂತಲೂ ಕೆಳಗಿಳಿಯಿತು. ನಾವು ತಲುಪಿದ್ದು Gitನ ಮಿತಿಯನ್ನೇ, ಅಥವಾ ನಮ್ಮ ಏಕೀಕೃತ ರಿಪೊಸಿಟರಿಯನ್ನು ಒದಗಿಸುತ್ತಿದ್ದ ವಿಧಾನದ ಮಿತಿಯನ್ನೇ? ಇಮೇಲ್ ಮೂಲಕ ಕರ್ನೆಲ್ ತಿದ್ದುಪಡಿಗಳನ್ನು ವಿನಿಮಯ ಮಾಡಿಕೊಳ್ಳುತ್ತಿದ್ದ ಸಮುದಾಯದಿಂದ Git ಬೆಳೆದುಬಂದಿತು. ಎರಡು ದಶಕಗಳಿಗಿಂತ ಹೆಚ್ಚು ಕಾಲ, ತಂತ್ರಾಂಶ ನಿರ್ಮಿಸುವ ವಿಧಾನ ಬದಲಾದಂತೆ ಅಭಿವೃದ್ಧಿಪಡಿಸುವವರು Gitಗೆ ಹೊಂದುವಂತೆ ತಮ್ಮ ಸಾಧನಗಳನ್ನು ರೂಪಿಸಿಕೊಂಡಿದ್ದಾರೆ. ನಮ್ಮ ಏಕೀಕೃತ ರಿಪೊಸಿಟರಿಯಲ್ಲಿ ಅಡಚಣೆಗಳು ಕಾಣತೊಡಗಿದಾಗ, ಆ ಕೆಲಸದ ಮೇಲೆಯೇ ಮುಂದುವರಿಯಲು ಸಾಧ್ಯವಾಗುವುದು ನಮಗೆ ಮುಖ್ಯವಾಗಿತ್ತು.
ಪರಿಚಿತ ಕಾರ್ಯವಿಧಾನವನ್ನು ಉಳಿಸಿಕೊಂಡೇ, ಬೇರೆಬೇರೆ ಶಾಖೆಗಳ ಪುಶ್‌ಗಳನ್ನು ಸಮಾನಾಂತರವಾಗಿ ನಿರ್ವಹಿಸಲು ಮತ್ತು ಒಂದೇ ಇತಿಹಾಸವನ್ನು ಅನೇಕ ಓದುಗರಿಗೆ ಏಕಕಾಲದಲ್ಲಿ ಒದಗಿಸಲು ಹಿಂಭಾಗದ ವ್ಯವಸ್ಥೆಯನ್ನು ಮರುನಿರ್ಮಿಸುವ ಮಾರ್ಗ ನಮಗೆ ಕಂಡಿತು. ಮೂಲ ಕೋಡ್ ನಿಯಂತ್ರಣ ಕಾರ್ಯವಿಧಾನಕ್ಕೆ Git ಅನ್ನು ಅಡಿಪಾಯವಾಗಿಸಿಕೊಂಡರೆ, ಕ್ಲೈಂಟ್‌ನ ಸುಧಾರಣೆಗಳು OpenAI ಹೊರಗೂ ಉಪಯುಕ್ತವಾಗಬಹುದು. ನಮ್ಮ Git ಪ್ರತಿಯಲ್ಲಿನ(ಹೊಸ ಕಿಟಕಿಯಲ್ಲಿ ತೆರೆಯುತ್ತದೆ) ಸುಧಾರಣೆಗಳನ್ನು ಮೂಲ ಯೋಜನೆಗೆ ಕೊಡುಗೆಯಾಗಿ ನೀಡಿ, ವಿಶಾಲ ಸಮುದಾಯದೊಂದಿಗೆ ಹಂಚಿಕೊಳ್ಳಲು ನಾವು ಬಯಸಿದೆವು.
ಮೂಲ ಕೋಡ್ ನಿಯಂತ್ರಣ ವ್ಯವಸ್ಥೆಯ ವಿಸ್ತರಣೆಗೆ ಎರಡು ಮುಖ್ಯ ಆಯಾಮಗಳಿವೆ: ಬೇರೆಬೇರೆ ಶಾಖೆಗಳಿಗೆ ಪುಶ್ ಮಾಡುವ ಅನೇಕ ಬರಹಗಾರರು ಮತ್ತು ಒಂದೇ ಇತಿಹಾಸವನ್ನು ಪಡೆಯುವ ಅನೇಕ ಓದುಗರು. Pando ಎರಡಕ್ಕೂ ಅನುಕೂಲವಾಗುವಂತೆ ವಿನ್ಯಾಸಗೊಂಡಿದೆ.
ಮೊದಲನೆಯದಾಗಿ, Pando ಪ್ರತಿ ಶಾಖೆಯ ನವೀಕರಣಗಳನ್ನು ಸ್ವತಂತ್ರವಾಗಿ ಸಮನ್ವಯಗೊಳಿಸುತ್ತದೆ. ಸಂಬಂಧವಿಲ್ಲದ ಶಾಖೆಗಳ ನವೀಕರಣಗಳು ಸಮಾನಾಂತರವಾಗಿ ನಡೆಯಬಹುದು. ಶಾಖೆಯನ್ನು ಪಡೆಯುವ ಓದುಗನಿಗೆ ಆ ಪರಿಷ್ಕರಣೆಗೆ ಬೇಕಾದ ಇತಿಹಾಸ ಸಿಗುತ್ತದೆ. ಆದರೆ ಹಲವು ಶಾಖೆಗಳನ್ನು ನೋಡುವ ಓದುಗನಿಗೆ ಅವು ಬೇರೆಬೇರೆ ಸಮಯದ ಸ್ಥಿತಿಗಳಲ್ಲಿ ಕಾಣಬಹುದು ಎಂಬುದು ಇದರ ಮಿತಿ.
ಎರಡನೆಯದಾಗಿ, ಪ್ರತಿ ಕ್ಲೈಂಟ್‌ಗೆ ಪ್ರತ್ಯೇಕ ಪ್ಯಾಕ್‌ಫೈಲ್ ರಚಿಸುವ ಬದಲು Pando ಫೆಚ್‌ಗಳಾದ್ಯಂತ ಪ್ಯಾಕ್‌ಫೈಲ್‌ಗಳನ್ನು ಮರುಬಳಕೆ ಮಾಡುತ್ತದೆ. ಪ್ಯಾಕ್‌ಫೈಲ್ ಎಂದರೆ ಹಲವು ಆಬ್ಜೆಕ್ಟ್‌ಗಳನ್ನು ಒಟ್ಟಿಗೆ ಸಂಕುಚಿತಗೊಳಿಸುವ Git ಸ್ವರೂಪ. ಕ್ಲೈಂಟ್ ತನ್ನ ಬಳಿ ಈಗಾಗಲೇ ಇರುವ ಕೆಲವು ಆಬ್ಜೆಕ್ಟ್‌ಗಳನ್ನು ಡೌನ್‌ಲೋಡ್ ಮಾಡಬಹುದು. ಆದರೆ ಸರ್ವರ್ ಅತಿ ಕಡಿಮೆ ಗಣನೆಯೊಂದಿಗೆ ಒಂದೇ ಬೈಟ್‌ಗಳನ್ನು ಅನೇಕ ಕ್ಲೈಂಟ್‌ಗಳಿಗೆ ಒದಗಿಸಬಹುದು.
ಈ ಆಯ್ಕೆಗಳಿಂದ ಶಾಖೆಗಳಾದ್ಯಂತ ಬರವಣಿಗೆಯ ಸಾಮರ್ಥ್ಯ ವಿಸ್ತರಿಸಿ, ತಾತ್ಕಾಲಿಕ ಸಂಗ್ರಹಗಳಿಂದ ಓದುಗಳನ್ನು ಪೂರೈಸಬಹುದು. ಇವೆಲ್ಲ ಹೇಗೆ ಹೊಂದಿಕೊಳ್ಳುತ್ತವೆ ಎಂಬುದನ್ನು ತಿಳಿಯಲು, Git ಇತಿಹಾಸವನ್ನು ಹೇಗೆ ಸಂಗ್ರಹಿಸುತ್ತದೆ ಮತ್ತು ವರ್ಗಾಯಿಸುತ್ತದೆ ಎಂಬುದರಿಂದ ಆರಂಭಿಸೋಣ.
ರಿಪೊಸಿಟರಿಯ ಎರಡು ಭಾಗಗಳನ್ನು Git ಸಿಂಕ್‌ನಲ್ಲಿಡಬೇಕು: ಆಬ್ಜೆಕ್ಟ್‌ಗಳು ಮತ್ತು ಉಲ್ಲೇಖಗಳು.
Git ರಿಪೊಸಿಟರಿ ಕಡತಗಳ ಸ್ಥಿತಿಚಿತ್ರಗಳು ಮತ್ತು ಅವನ್ನು ಜೋಡಿಸುವ ಇತಿಹಾಸವನ್ನು ಆಬ್ಜೆಕ್ಟ್‌ಗಳ ಗ್ರಾಫ್ ಆಗಿ ದಾಖಲಿಸುತ್ತದೆ. ಆಬ್ಜೆಕ್ಟ್ ಒಂದು ಬ್ಲಾಬ್, ಟ್ರೀ, ಕಮಿಟ್ ಅಥವಾ ಟ್ಯಾಗ್ ಆಗಿರಬಹುದು. ಬ್ಲಾಬ್‌ಗಳು ಪ್ರತ್ಯೇಕ ಕಡತದ ವಿಷಯವನ್ನು ಹೊಂದಿರುತ್ತವೆ. ಟ್ರೀಗಳು ಹೆಸರುಗಳನ್ನು ಬ್ಲಾಬ್‌ಗಳು ಅಥವಾ ಇತರ ಟ್ರೀಗಳೊಂದಿಗೆ ಜೋಡಿಸಿ ಡೈರೆಕ್ಟರಿ ರಚನೆಯನ್ನು ರೂಪಿಸುತ್ತವೆ. ಕಮಿಟ್‌ಗಳು ಮೂಲ ಟ್ರೀ ಮತ್ತು ಶೂನ್ಯ ಅಥವಾ ಹೆಚ್ಚಿನ ಮೂಲ ಕಮಿಟ್‌ಗಳನ್ನು ಸೂಚಿಸಿ, ನಿಮ್ಮ ರಿಪೊಸಿಟರಿಯ ಇತಿಹಾಸವನ್ನು ರೂಪಿಸುತ್ತವೆ.
ಆಬ್ಜೆಕ್ಟ್‌ಗಳ ಪ್ರಕಾರ ಮತ್ತು ವಿಷಯದ ಹ್ಯಾಶ್ ಮೂಲಕ ಅವನ್ನು ಗುರುತಿಸಲಾಗುತ್ತದೆ. ಆಬ್ಜೆಕ್ಟ್‌ಗಳನ್ನು ಬದಲಾಯಿಸಲಾಗದು: ಬದಲಾದ ಕಡತವನ್ನು ದಾಖಲಿಸಿದಾಗ ಹೊಸ ಬ್ಲಾಬ್ ರಚನೆಯಾಗುತ್ತದೆ. ಬದಲಾಗದ ಕಡತಗಳು ಮತ್ತು ಡೈರೆಕ್ಟರಿಗಳು ಈಗಿರುವ ಆಬ್ಜೆಕ್ಟ್‌ಗಳನ್ನೇ ಮರುಬಳಕೆ ಮಾಡಬಹುದು.
ಶಾಖೆಗಳು ಮತ್ತು ಟ್ಯಾಗ್‌ಗಳು ಕಮಿಟ್‌ಗಳನ್ನು ಸೂಚಿಸುವ ಉಲ್ಲೇಖಗಳು, ಅಂದರೆ “ರೆಫ್‌ಗಳು”. ಶಾಖೆಯಲ್ಲಿ ಕಮಿಟ್ ಮಾಡಿದಾಗ ಹೊಸ ಕಮಿಟ್ ರಚನೆಯಾಗುತ್ತದೆ ಮತ್ತು ಅದನ್ನು ಸೂಚಿಸುವಂತೆ ಶಾಖೆಯ ಉಲ್ಲೇಖ ನವೀಕರಣಗೊಳ್ಳುತ್ತದೆ.
Git ಆಬ್ಜೆಕ್ಟ್‌ಗಳು ತಮ್ಮ ಗುರುತುಗಳ ಮೂಲಕ ಪರಸ್ಪರ ಉಲ್ಲೇಖಿಸುತ್ತವೆ: ಕಮಿಟ್‌ಗಳು ಟ್ರೀಗಳನ್ನು, ಟ್ರೀಗಳು ಇತರ ಟ್ರೀಗಳು ಮತ್ತು ಬ್ಲಾಬ್‌ಗಳನ್ನು ಉಲ್ಲೇಖಿಸುತ್ತವೆ. refs/heads/main ಶಾಖೆ C2 ಕಮಿಟ್ ಅನ್ನು ಸೂಚಿಸುತ್ತದೆ; ಅದರ ಮೂಲ ಕಮಿಟ್ C1. C1 ಮೂಲ ಟ್ರೀ T1 ಅನ್ನು ಸೂಚಿಸುತ್ತದೆ; ಅದರಲ್ಲಿ parser.py ಬ್ಲಾಬ್ B1 ಅನ್ನು ಉಲ್ಲೇಖಿಸುತ್ತದೆ. C2 ಮೂಲ ಟ್ರೀ T2 ಅನ್ನು ಸೂಚಿಸುತ್ತದೆ; ಅದರಲ್ಲಿ parser.py ಬ್ಲಾಬ್ B2 ಅನ್ನು ಉಲ್ಲೇಖಿಸುತ್ತದೆ. ಎರಡೂ ಮೂಲ ಟ್ರೀಗಳಲ್ಲಿ docs/ ಒಂದೇ ಟ್ರೀ T3 ಅನ್ನು ಉಲ್ಲೇಖಿಸುತ್ತದೆ. ಅದರ README.md ನಮೂದು ಬ್ಲಾಬ್ B3 ಅನ್ನು ಮತ್ತು usage.md ಬ್ಲಾಬ್ B4 ಅನ್ನು ಸೂಚಿಸುತ್ತವೆ.
Git ಆಬ್ಜೆಕ್ಟ್‌ಗಳನ್ನು “ಪ್ರತ್ಯೇಕ” ಅಥವಾ “ಪ್ಯಾಕ್ ಮಾಡಿದ” ಸ್ಥಿತಿಯಲ್ಲಿ ಸಂಗ್ರಹಿಸುತ್ತದೆ. ಪ್ರತ್ಯೇಕ ಆಬ್ಜೆಕ್ಟ್‌ಗಳನ್ನು ಅವುಗಳ ಆಬ್ಜೆಕ್ಟ್ ಗುರುತಿನಿಂದ ಗುರುತಿಸಲಾಗುವ ಪ್ರತ್ಯೇಕ ಕಡತಗಳಲ್ಲಿ ಸಂಗ್ರಹಿಸಲಾಗುತ್ತದೆ. ಪ್ಯಾಕ್ ಮಾಡಿದ ಆಬ್ಜೆಕ್ಟ್‌ಗಳನ್ನು ಪ್ಯಾಕ್‌ಫೈಲ್‌ನಲ್ಲಿ ಒಟ್ಟಿಗೆ ಸಂಗ್ರಹಿಸಲಾಗುತ್ತದೆ. ಇದರಿಂದ ಹೋಲುವ ಆಬ್ಜೆಕ್ಟ್‌ಗಳನ್ನು ಪರಸ್ಪರ ವ್ಯತ್ಯಾಸಗಳ ರೂಪದಲ್ಲಿ ಸಂಗ್ರಹಿಸಬಹುದು.
Git ಬ್ಲಾಬ್‌ಗಳನ್ನು ಪ್ರತ್ಯೇಕ ಕಡತಗಳಾಗಿ ಸಂಗ್ರಹಿಸಬಹುದು ಅಥವಾ ಒಂದನ್ನು ಮತ್ತೊಂದರಿಂದಿರುವ ವ್ಯತ್ಯಾಸವಾಗಿ ಸಂಕೇತಿಸಿ ಒಟ್ಟಿಗೆ ಪ್ಯಾಕ್ ಮಾಡಬಹುದು.
Git ನಲ್ಲಿ, ಕಮಿಟ್‌ನಿಂದ ಅದರ ಮೂಲ ಕಮಿಟ್‌ಗಳು, ಟ್ರೀಗಳು ಮತ್ತು ಬ್ಲಾಬ್‌ಗಳ ಕೊಂಡಿಗಳನ್ನು ಅನುಸರಿಸಿ ಆಬ್ಜೆಕ್ಟ್ ಹುಡುಕಲು ಸಾಧ್ಯವಾದರೆ, ಅದು ಆ ಕಮಿಟ್‌ನಿಂದ ತಲುಪಬಹುದಾದ ಆಬ್ಜೆಕ್ಟ್ ಆಗಿರುತ್ತದೆ. ಫೆಚ್ ವೇಳೆ ಕ್ಲೈಂಟ್ ತನಗೆ ಯಾವ ಕಮಿಟ್‌ಗಳು ಬೇಕು ಮತ್ತು ಯಾವುವು ಈಗಾಗಲೇ ಇವೆ ಎಂದು ಸರ್ವರ್‌ಗೆ ತಿಳಿಸುತ್ತದೆ. ಸರ್ವರ್ ಬೇಕಿರುವ ಕಮಿಟ್‌ಗಳಿಂದ ತಲುಪಬಹುದಾದ ಆಬ್ಜೆಕ್ಟ್‌ಗಳನ್ನು ಹುಡುಕಿ, ಕ್ಲೈಂಟ್ ಬಳಿ ಈಗಾಗಲೇ ಇವೆಂದು ತಿಳಿದಿರುವುದನ್ನು ಹೊರಗಿಡುತ್ತದೆ. ಉಳಿದವುಗಳನ್ನು Git ಡಿಸ್ಕ್‌ನಲ್ಲಿ ಬಳಸುವ ಅದೇ ಸ್ವರೂಪದ ಪ್ಯಾಕ್‌ಫೈಲ್ ಆಗಿ ಕಳುಹಿಸುತ್ತದೆ. ಪೂರ್ಣ ಕ್ಲೋನ್ ಯಾವುದೇ ಆಬ್ಜೆಕ್ಟ್‌ಗಳಿಲ್ಲದೆ ಆರಂಭವಾಗುತ್ತದೆ. ಆದ್ದರಿಂದ ಕ್ಲೋನ್ ಮಾಡುತ್ತಿರುವ ಇತಿಹಾಸದಿಂದ ತಲುಪಬಹುದಾದ ಎಲ್ಲ ಆಬ್ಜೆಕ್ಟ್‌ಗಳೂ ಅದಕ್ಕೆ ಬೇಕು.
ಒಂದು ಅಥವಾ ಹೆಚ್ಚಿನ ಉಲ್ಲೇಖಗಳನ್ನು ನವೀಕರಿಸಲು ಸರ್ವರ್‌ಗೆ ಕೇಳುವ ಮೂಲಕ, ಪುಶ್ ಆಬ್ಜೆಕ್ಟ್‌ಗಳನ್ನು ವಿರುದ್ಧ ದಿಕ್ಕಿನಲ್ಲಿ ವರ್ಗಾಯಿಸುತ್ತದೆ. ಸರ್ವರ್ ಬಳಿ ಈಗಾಗಲೇ ಇರುವ ಆಬ್ಜೆಕ್ಟ್‌ಗಳನ್ನು ಕಳುಹಿಸದಿರಲು, ಅದು ಸೂಚಿಸಿದ ಉಲ್ಲೇಖಗಳ ಗುಂಪನ್ನು ಕ್ಲೈಂಟ್ ಬಳಸುತ್ತದೆ. ಹೀಗಾಗಿ ಕಳುಹಿಸುವ ಪ್ಯಾಕ್ ಈಗಿರುವ ಆಬ್ಜೆಕ್ಟ್‌ಗಳನ್ನು ಅವಲಂಬಿಸಬಹುದು: ಹೊಸ ಇತಿಹಾಸ ಮರುನಿರ್ಮಿಸಲು ಪ್ಯಾಕ್ ಸ್ವೀಕರಿಸಿದರೆ ಮಾತ್ರ ಸಾಲದು.
Git ರಿಪೊಸಿಟರಿಯನ್ನು ಪ್ರತಿರೂಪಿಸುವುದೆಂದರೆ ಹಲವು ಸರ್ವರ್‌ಗಳಲ್ಲಿ ಆಬ್ಜೆಕ್ಟ್‌ಗಳು ಮತ್ತು ಉಲ್ಲೇಖಗಳೆರಡೂ ಲಭ್ಯವಾಗುವಂತೆ ಇಡುವುದು. ಉಲ್ಲೇಖದ ಹೊಸ ಮೌಲ್ಯವನ್ನು ಪ್ರತಿರೂಪವು ಒದಗಿಸುವ ಮೊದಲು, ಆ ಮೌಲ್ಯದಿಂದ ತಲುಪಬಹುದಾದ ಆಬ್ಜೆಕ್ಟ್‌ಗಳನ್ನು ಒದಗಿಸಲು ಅದು ಸಮರ್ಥವಾಗಿರಬೇಕು. ಸ್ಪರ್ಧಿಸುವ ಉಲ್ಲೇಖ ನವೀಕರಣಗಳನ್ನೂ ಸೇವೆ ಸಮನ್ವಯಗೊಳಿಸಬೇಕು. ಅಂದರೆ ಒಂದೇ ಶಾಖೆಯನ್ನು ಅದೇ ಹಳೆಯ ತುದಿಯಿಂದ ಬೇರೆಬೇರೆ ಹೊಸ ಕಮಿಟ್‌ಗಳಿಗೆ ಕೊಂಡೊಯ್ಯಲು ಯತ್ನಿಸುವ ಪುಶ್‌ಗಳನ್ನು ನಿರ್ವಹಿಸಬೇಕು. ರಿಪೊಸಿಟರಿಯ ಎಲ್ಲ ಬರವಣಿಗೆಗಳಿಗೆ ಒಂದೇ ಕ್ರಮ ವಿಧಿಸುವ ವ್ಯವಸ್ಥೆಗಳಲ್ಲಿ, ಸಂಬಂಧವಿಲ್ಲದ ಶಾಖೆಗಳ ಪುಶ್‌ಗಳೂ ಪರಸ್ಪರ ಕಾಯಬೇಕಾಗಬಹುದು.
Pando ವಿನ್ಯಾಸದ ವೇಳೆ, Git ಬಳಸಿ ಮೂಲ ಕೋಡ್ ನಿಯಂತ್ರಣ ವಿಸ್ತರಿಸುವ ಸಾಂಪ್ರದಾಯಿಕ ವಿಧಾನಗಳನ್ನು ಮೌಲ್ಯಮಾಪನ ಮಾಡಿದೆವು. ಒಂದು ವಿಧಾನವು ಮೂರು ಹಂತದ ಕಮಿಟ್ (3PC, ಹಲವು ನೋಡ್‌ಗಳ ನಡುವೆ ಕಮಿಟ್ ಸಮನ್ವಯಗೊಳಿಸುವ ಪ್ರೋಟೋಕಾಲ್) ಬಳಸಿ ರಿಪೊಸಿಟರಿ ಪ್ರತಿರೂಪಗಳ ಉಲ್ಲೇಖ ನವೀಕರಣಗಳನ್ನು ಸಮನ್ವಯಗೊಳಿಸುತ್ತದೆ. ಮತ್ತೊಂದು, ಬ್ಲಾಬ್ ಸಂಗ್ರಹದಲ್ಲಿನ ಹಂಚಿದ ಪೂರ್ವಲೇಖನ ದಾಖಲೆ (WAL, ಬದಲಾವಣೆಗಳನ್ನು ಅನ್ವಯಿಸುವ ಮುನ್ನ ಬರೆಯುವ ದಾಖಲೆ) ಮೂಲಕ ನವೀಕರಣಗಳಿಗೆ ಕ್ರಮ ನೀಡುತ್ತದೆ.
ನಾವು ಮಾದರಿಯಾಗಿಸಿದ ಮೂರು ಹಂತದ ಕಮಿಟ್ ವಿನ್ಯಾಸದಲ್ಲಿ, Git ಸೇವೆಯು ಹಲವು ಪ್ರತಿರೂಪಗಳಲ್ಲಿ ರಿಪೊಸಿಟರಿಯ ಸಂಪೂರ್ಣ ಪ್ರತಿಯನ್ನು ಇಡುತ್ತದೆ. ಯಾವುದೇ ಸರ್ವರ್ ಪುಶ್ ಸ್ವೀಕರಿಸಿದಾಗ, ಬರುವ ಪ್ಯಾಕ್‌ಫೈಲ್ ಅನ್ನು ನಕಲಿಸಿ ಎಲ್ಲ ಪ್ರತಿರೂಪಗಳಿಗೆ ಸಮಾನಾಂತರವಾಗಿ ಕಳುಹಿಸಲಾಗುತ್ತದೆ. ಪುಶ್ ಪ್ರಕಟಿಸಲು, ಬಹುಮತದಷ್ಟು ಪ್ರತಿರೂಪಗಳು ಉಲ್ಲೇಖ ನವೀಕರಣವನ್ನು ಸ್ವೀಕರಿಸಬೇಕು. ಇದನ್ನು ನಿರ್ವಹಿಸುವ ಸರ್ವರ್ ಸಮನ್ವಯಕಾರಕವಾಗಿರುತ್ತದೆ. ಅದರ ಮತ್ತು ಪ್ರತಿ ಇತರ ಪ್ರತಿರೂಪದ ನಡುವೆ ಹಲವು ಸುತ್ತಿನ ಸಂವಹನ ಅಗತ್ಯ.
ಉಲ್ಲೇಖ ನವೀಕರಣ ಸ್ವೀಕರಿಸಲು, ಪ್ರತಿ ಪ್ರತಿರೂಪವು ತನ್ನ ಉಲ್ಲೇಖದ ಪ್ರತಿಯನ್ನು ಲಾಕ್ ಮಾಡಿ, ಅದು ಇನ್ನೂ ಕ್ಲೈಂಟ್ ನಿರೀಕ್ಷಿಸುವ ಕಮಿಟ್‌ನತ್ತಲೇ ಸೂಚಿಸುತ್ತಿದೆಯೇ ಎಂದು ಪರಿಶೀಲಿಸುತ್ತದೆ. ನಂತರ ಸಮನ್ವಯಕಾರಕವು ಸ್ವೀಕರಿಸಿದ ಪ್ರತಿರೂಪಗಳಿಗೆ ಪೂರ್ವ-ಕಮಿಟ್ ಸಂದೇಶ ಕಳುಹಿಸುತ್ತದೆ. ಬಹುಮತದಷ್ಟು ಪ್ರತಿರೂಪಗಳು ಪೂರ್ವ-ಕಮಿಟ್ ಸಂದೇಶ ಸ್ವೀಕಾರ ದೃಢಪಡಿಸಿದ ಬಳಿಕ, ನವೀಕರಣ ನಡೆಸಲು ಸಮನ್ವಯಕಾರಕ ಅವುಗಳಿಗೆ ತಿಳಿಸುತ್ತದೆ. ನಂತರ ಯಾವುದೇ ನವೀಕೃತ ಪ್ರತಿರೂಪವು ತನ್ನ ಸ್ಥಳೀಯ ರಿಪೊಸಿಟರಿ ಪ್ರತಿಯಿಂದ ಹೊಸ ಶಾಖಾ ತುದಿಯನ್ನು ಸೂಚಿಸಬಹುದು.
ಸಂಪೂರ್ಣ ಪ್ರತಿರೂಪಗಳನ್ನು ಉಳಿಸಿಕೊಳ್ಳುವುದರಿಂದ ಓದುಗಳನ್ನು ಸ್ಥಳೀಯವಾಗಿಯೇ ಪೂರೈಸಬಹುದು. ಕ್ಲೈಂಟ್ ಯಾವ ಪ್ರತಿರೂಪ ಆಯ್ದರೂ ಎಲ್ಲ ಉಲ್ಲೇಖಗಳ ಸುಸಂಗತ ನೋಟ ಸಿಗುತ್ತದೆ ಎಂಬ ಖಾತರಿಯೂ ಇರುತ್ತದೆ. ಇದರ ಪರಿಣಾಮವಾಗಿ ಉಲ್ಲೇಖಗಳನ್ನು ಒಂದೊಂದಾಗಿ ನವೀಕರಿಸಲಾಗುತ್ತದೆ. ಪ್ರತಿರೂಪಗಳ ನಡುವೆ ಉಲ್ಲೇಖ ನವೀಕರಣ ಸಮನ್ವಯಗೊಳಿಸಲು ಪ್ರತಿ ಪುಶ್‌ಗೂ ಹಲವು ಸುತ್ತಿನ ವಿನಿಮಯ ಬೇಕಾಗುತ್ತದೆ.
ಅಗತ್ಯ ಸಂಖ್ಯೆಯ ಪ್ರತಿರೂಪಗಳ ಒಪ್ಪಿಗೆಗಾಗಿ ಕಾಯುವುದರಿಂದ, ಅವುಗಳ ಡಿಸ್ಕ್ ಕಾರ್ಯಕ್ಷಮತೆ ಮತ್ತು ಸಂವಹನ ವಿಳಂಬವು ಪುಶ್ ಸಮಯದ ಮೇಲೆ ಪರಿಣಾಮ ಬೀರುತ್ತವೆ. ಬರವಣಿಗೆಯ ಪ್ರಮಾಣ ಹೆಚ್ಚಿದಂತೆ, ಪ್ರತಿರೂಪಗಳು ಬರುವ ಪ್ಯಾಕ್‌ಗಳ ಜೊತೆಗೆ ಓದುವ ವಿನಂತಿಗಳನ್ನೂ ಸಮರ್ಥವಾಗಿ ನಿರ್ವಹಿಸಬೇಕು.
ನಾವು ಮಾದರಿಯಾಗಿಸಿದ WAL ಆಧಾರಿತ ವಿನ್ಯಾಸದಲ್ಲಿ, ರಿಪೊಸಿಟರಿಯಾದ್ಯಂತ ನವೀಕರಣಗಳಿಗೆ ಕ್ರಮ ನೀಡಲು Git ಸೇವೆ ಬ್ಲಾಬ್ ಸಂಗ್ರಹದಲ್ಲಿನ ಹಂಚಿದ ಮ್ಯಾನಿಫೆಸ್ಟ್ ಬಳಸುತ್ತದೆ. ಸರ್ವರ್ ಪುಶ್ ಸ್ವೀಕರಿಸಿದಾಗ, ಬರುವ ಪ್ಯಾಕ್‌ಫೈಲ್ ಅನ್ನು ಬ್ಲಾಬ್ ಸಂಗ್ರಹಕ್ಕೆ ಅಪ್‌ಲೋಡ್ ಮಾಡಿ, ತನ್ನ ಸ್ಥಳೀಯ ರಿಪೊಸಿಟರಿ ಪ್ರತಿಯಲ್ಲಿ ಉಲ್ಲೇಖ ನವೀಕರಣವನ್ನು ಸಿದ್ಧಪಡಿಸುತ್ತದೆ. ಪುಶ್ ಪ್ರಕಟಿಸಲು, ಬ್ಲಾಬ್ ಸಂಗ್ರಹದಲ್ಲಿರುವ ಹಂಚಿದ ಮ್ಯಾನಿಫೆಸ್ಟ್‌ಗೆ ನಮೂದೊಂದನ್ನು ಸೇರಿಸುತ್ತದೆ. ಅದು ಉಲ್ಲೇಖ ನವೀಕರಣವನ್ನು ದಾಖಲಿಸಿ ಪ್ಯಾಕ್‌ಫೈಲ್ ಅನ್ನು ಸೂಚಿಸುತ್ತದೆ. ನಂತರ Git ಸರ್ವರ್ ಹೋಲಿಸಿ-ಬದಲಿಸುವ ಕಾರ್ಯಾಚರಣೆ ಬಳಸಿ ಮ್ಯಾನಿಫೆಸ್ಟ್ ನವೀಕರಿಸುತ್ತದೆ. ಇದು ಅವಿಭಾಜ್ಯವಾಗಿ ಮ್ಯಾನಿಫೆಸ್ಟ್ ಬದಲಿಸುತ್ತದೆ; ಇಲ್ಲವಾದರೆ ಬದಲಾವಣೆಯನ್ನು ತಿರಸ್ಕರಿಸುತ್ತದೆ. ಈ ನಡುವೆ ಇನ್ನೊಬ್ಬ ಬರಹಗಾರ ಅದನ್ನು ನವೀಕರಿಸಿದ್ದರೆ, ಸರ್ವರ್ ಮಧ್ಯೆ ಸೇರಿದ ನಮೂದುಗಳನ್ನು ಓದುತ್ತದೆ, ತನ್ನ ಉಲ್ಲೇಖ ನವೀಕರಣ ಇನ್ನೂ ಮಾನ್ಯವೇ ಎಂದು ಪರಿಶೀಲಿಸುತ್ತದೆ ಮತ್ತು ಈಗಾಗಲೇ ಅಪ್‌ಲೋಡ್ ಮಾಡಿದ ಪ್ಯಾಕ್‌ಫೈಲ್ ಬಳಸಿ ಮತ್ತೆ ಪ್ರಯತ್ನಿಸುತ್ತದೆ.
ಬರಹಗಾರರು ತಮ್ಮ ಪ್ಯಾಕ್‌ಫೈಲ್‌ಗಳನ್ನು ಸಮಾನಾಂತರವಾಗಿ ಅಪ್‌ಲೋಡ್ ಮಾಡಬಹುದು. ಆದರೆ ಸಂಬಂಧವಿಲ್ಲದ ಶಾಖೆಗಳ ಪುಶ್‌ಗಳಿಗೂ ಅದೇ ಮ್ಯಾನಿಫೆಸ್ಟ್ ನವೀಕರಿಸಬೇಕಾಗುತ್ತದೆ. ಯಶಸ್ವಿ ಹೋಲಿಸಿ-ಬದಲಿಸುವ ಕಾರ್ಯದ ಸಂಪೂರ್ಣ ವಿನಿಮಯಕ್ಕೆ ಬೇಕಾದ ಸಮಯವು, ರಿಪೊಸಿಟರಿ ಎಷ್ಟು ಬಾರಿ ಹೊಸ ಮ್ಯಾನಿಫೆಸ್ಟ್ ಪ್ರಕಟಿಸಬಹುದು ಎಂಬುದನ್ನು ಮಿತಿಗೊಳಿಸುತ್ತದೆ. ಕಡಿಮೆ ವಿಳಂಬದ ಬ್ಲಾಬ್ ಸಂಗ್ರಹ ಈ ಹಂತವನ್ನು ವೇಗಗೊಳಿಸುತ್ತದೆ. ಗುಂಪುಗೂಡಿಸುವುದರಿಂದ ಒಂದೇ ಮ್ಯಾನಿಫೆಸ್ಟ್ ಮೂಲಕ ಹಲವು ಉಲ್ಲೇಖಗಳನ್ನು ಒಮ್ಮೆಗೆ ನವೀಕರಿಸಬಹುದು. ಆದರೆ ನವೀಕರಣಗಳನ್ನು ಸರದಿಯಲ್ಲಿ ಕಾಯಿಸಬೇಕಾಗುತ್ತದೆ ಮತ್ತು ವಿಳಂಬ ಹೆಚ್ಚುತ್ತದೆ.
ಬ್ಲಾಬ್ ಸಂಗ್ರಹ ಪ್ಯಾಕ್‌ಫೈಲ್‌ಗಳನ್ನು ಸಮಾನಾಂತರವಾಗಿ ಸ್ವೀಕರಿಸಬಹುದು. ಆದರೆ ಹಂಚಿದ ಮ್ಯಾನಿಫೆಸ್ಟ್‌ನ ನವೀಕರಣಗಳು ಇನ್ನೂ ಪರಸ್ಪರ ಸ್ಪರ್ಧಿಸುತ್ತವೆ. ಬ್ಲಾಬ್ ಸಂಗ್ರಹದ ಸಾಮರ್ಥ್ಯ ಹೆಚ್ಚಿಸಿದರಷ್ಟೇ ಆ ಅಡಚಣೆ ನಿವಾರಣೆಯಾಗುವುದಿಲ್ಲ. ಪ್ರತಿ ಪ್ರತಿರೂಪವೂ ಪ್ಯಾಕ್‌ಗಳನ್ನು ಸ್ಥಳೀಯವಾಗಿ ಒದಗಿಸುವ ಮೊದಲು, ಬ್ಲಾಬ್ ಸಂಗ್ರಹದಿಂದ ಅವನ್ನು ಓದಿ ಸೂಚ್ಯಂಕ ರಚಿಸಬೇಕು. ಬರುವ ಬರವಣಿಗೆಗಳ ವೇಗ ಆ ಕೆಲಸವನ್ನು ಮೀರಿದರೆ, ಪ್ರತಿರೂಪಗಳು ಹಿಂದೆ ಬೀಳುತ್ತವೆ. ಹೊಸದಾಗಿ ಪುಶ್ ಮಾಡಿದ ಕಮಿಟ್‌ಗಳನ್ನು ಪಡೆಯಲು ಕ್ಲೈಂಟ್‌ಗಳು ಹೆಚ್ಚು ಕಾಯಬೇಕಾಗುತ್ತದೆ.
ಇಲ್ಲಿಯೇ Pando ಪ್ರಸ್ತುತವಾಗುತ್ತದೆ. Pando, Git ರಿಪೊಸಿಟರಿಗಳನ್ನು ಒದಗಿಸುವ ಹೊಸ ವಾಸ್ತುಶಿಲ್ಪ. ಅನೇಕ ಕ್ಲೈಂಟ್‌ಗಳು ಏಕಕಾಲದಲ್ಲಿ ಪುಶ್ ಮಾಡುವ ಪ್ರಮಾಣಕ್ಕೆ ವಿಸ್ತರಿಸುವುದು ಇದರ ಗುರಿ. ಇದು ಕಾರ್ಯನಿರ್ವಹಿಸುವ ಬಗೆ ಹೀಗಿದೆ:
Pando ಅಭಿವೃದ್ಧಿಪಡಿಸುವ ಮುನ್ನ, Git ವಿಷಯದಲ್ಲಿ ರಾಜಿಯಾಗದೆಯೇ ನಮ್ಮ ಅಗತ್ಯಗಳನ್ನು ಪೂರೈಸಬಹುದು ಎಂಬ ಊಹೆ ನಮಗಿತ್ತು. ಆದರೆ ಹೆಚ್ಚಿನ Git ವ್ಯವಸ್ಥೆಗಳು ಅಗತ್ಯವೆಂದು ಭಾವಿಸುವ ಕೆಲವು ಅಂಶಗಳಲ್ಲಿ ರಾಜಿಯಾಗಬೇಕಾಯಿತು:
ರಿಪೊಸಿಟರಿಯಾದ್ಯಂತ ಸುಸಂಗತತೆ: ಎಲ್ಲ ಉಲ್ಲೇಖಗಳ ಒಂದೇ ಕ್ಷಣದ ಸುಸಂಗತ ಸ್ಥಿತಿಚಿತ್ರ ನೀಡಲು ರಿಪೊಸಿಟರಿಯಾದ್ಯಂತ ಸಮನ್ವಯ ಅಗತ್ಯ. ಎಲ್ಲ ಉಲ್ಲೇಖ ನವೀಕರಣಗಳನ್ನು ಒಂದೇ ಕ್ರಮಕ್ಕೆ ಒಳಪಡಿಸುವ ವ್ಯವಸ್ಥೆಯಲ್ಲಿ, ಸಂಬಂಧವಿಲ್ಲದ ಶಾಖೆಗಳ ಪುಶ್‌ಗಳು ಒಂದೇ ಸಮನ್ವಯ ಕೇಂದ್ರಕ್ಕಾಗಿ ಸ್ಪರ್ಧಿಸುತ್ತವೆ.
ಪ್ರತಿ ಕ್ಲೈಂಟ್‌ಗೆ ಪ್ರತ್ಯೇಕ ಪ್ಯಾಕ್‌ಫೈಲ್‌ಗಳು: ಬೇರೆಬೇರೆ ಸ್ಥಳೀಯ ಇತಿಹಾಸ ಹೊಂದಿರುವ ಎರಡು ಕ್ಲೈಂಟ್‌ಗಳು ಒಂದೇ ಶಾಖೆಯನ್ನು ಪಡೆದರೆ, ಅವುಗಳ ಬಳಿ ಈಗಾಗಲೇ ಇರುವ ಆಬ್ಜೆಕ್ಟ್‌ಗಳನ್ನು ಕಳುಹಿಸದಿರಲು ಸರ್ವರ್ ಪ್ರತಿಯೊಂದಕ್ಕೂ ಪ್ರತ್ಯೇಕ ಪ್ಯಾಕ್ ರಚಿಸಬೇಕಾಗಬಹುದು. ಈ ಪ್ರತಿಕ್ರಿಯೆಗಳನ್ನು ರಚಿಸಲು CPU ಮತ್ತು ಡಿಸ್ಕ್ ಒಳಹರಿವು/ಹೊರಹರಿವು ಬೇಕಾಗುವುದರಿಂದ, ಹೆಚ್ಚಿನ ಸಂಖ್ಯೆಯ ಓದುಗರಿಗೆ ಸೇವೆ ವಿಸ್ತರಿಸುವುದು ಕಷ್ಟವಾಗುತ್ತದೆ.
ಬದಲಾಗಿ, ಬರವಣಿಗೆಯ ಸಾಮರ್ಥ್ಯ ವಿಸ್ತರಿಸಲು Pando ಸಡಿಲ ಸುಸಂಗತತೆಯ ಮಾದರಿಯನ್ನು (ಕಾರಣಾಧಾರಿತ ಸುಸಂಗತತೆ) ಒದಗಿಸುತ್ತದೆ; ಓದುವ ಸಾಮರ್ಥ್ಯ ವಿಸ್ತರಿಸಲು ಪ್ಯಾಕ್‌ಫೈಲ್‌ಗಳನ್ನು ಮರುಬಳಕೆ ಮಾಡುತ್ತದೆ.
ಕ್ಲೈಂಟ್ ಒಂದು ಶಾಖೆಗೆ ಪುಶ್ ಮಾಡಿದಾಗ, ಬರುವ ಪ್ಯಾಕ್‌ಫೈಲ್ ಅನ್ನು Pando ಬ್ಲಾಬ್ ಸಂಗ್ರಹದಲ್ಲಿ ಬದಲಾಯಿಸಲಾಗದ ಬ್ಲಾಬ್ ಆಗಿ ಉಳಿಸುತ್ತದೆ. ಶಾಖೆ ಮುಂದೆ ಸಾಗಿದಾಗಲೆಲ್ಲ, Pando ಮೆಟಾಡೇಟಾ ಸಂಗ್ರಹದಲ್ಲಿ ಉಲ್ಲೇಖ ಆವೃತ್ತಿಯನ್ನು ದಾಖಲಿಸುತ್ತದೆ. ಅದರಲ್ಲಿ ಹೊಸ ತುದಿ, ಅದನ್ನು ಒದಗಿಸಿದ ಪ್ಯಾಕ್ ಮತ್ತು ಆ ಪ್ಯಾಕ್ ಅವಲಂಬಿಸಿರುವ ಹಿಂದಿನ ಉಲ್ಲೇಖ ಆವೃತ್ತಿಗಳು ಇರುತ್ತವೆ. ಬ್ಲಾಬ್ ಸಂಗ್ರಹ ಮತ್ತು ಮೆಟಾಡೇಟಾ ಸಂಗ್ರಹ ಎರಡನ್ನೂ ಹೆಚ್ಚಿನ ಘಟಕಗಳನ್ನು ಸೇರಿಸುವ ಮೂಲಕ ವಿಸ್ತರಿಸಬಹುದು.
Pando ದಿಂದ ಕಮಿಟ್ ಅಥವಾ ಉಲ್ಲೇಖವನ್ನು ಪಡೆಯಲು, ಉಲ್ಲೇಖ ಆವೃತ್ತಿಗಳ ಗುಂಪನ್ನು (ಪ್ಯಾಕ್‌ಫೈಲ್‌ಗಳನ್ನು) ಕ್ಲೈಂಟ್‌ನಲ್ಲಿ ಮರುಅನ್ವಯಿಸಬೇಕು. ಇದರಿಂದ ಪಡೆಯುತ್ತಿರುವ ಉಲ್ಲೇಖ ಆವೃತ್ತಿಯನ್ನು ರಚಿಸಿದ ಕ್ಲೈಂಟ್‌ನ ಸ್ಥಿತಿ ಮರುನಿರ್ಮಾಣವಾಗುತ್ತದೆ. ಇದು ಇಡೀ ರಿಪೊಸಿಟರಿಯಾದ್ಯಂತ ದುರ್ಬಲ ಸ್ವರೂಪದ ಸುಸಂಗತತೆ ನೀಡುತ್ತದೆ; ಪ್ರತ್ಯೇಕ ಉಲ್ಲೇಖಗಳ ನವೀಕರಣಗಳಿಗೆ ಮಾತ್ರ ಕ್ರಮಬದ್ಧವಾಗಿ ನಡೆದಂತೆಯೇ ಫಲಿತಾಂಶ ಸಿಗುವ ಖಾತರಿ ನೀಡುತ್ತದೆ. ಒಂದೇ ಉಲ್ಲೇಖಕ್ಕೆ ಏಕಕಾಲದಲ್ಲಿ ಪುಶ್ ಮಾಡಿದಾಗ ಮಾತ್ರ ಕ್ಲೈಂಟ್‌ಗಳ ನಡುವೆ ಸಂಘರ್ಷ ಉಂಟಾಗುತ್ತದೆ. ಹಲವು ಶಾಖೆಗಳನ್ನು ಓದುವ ಕ್ಲೈಂಟ್, ಆ ಓದುಗಳು ರಿಪೊಸಿಟರಿಯಾದ್ಯಂತ ಒಂದೇ ಕ್ಷಣದ ಸ್ಥಿತಿಯನ್ನು ಸೂಚಿಸುತ್ತವೆ ಎಂದು ಭಾವಿಸಲಾಗದು.
ಮುಖ್ಯ ಶಾಖೆಗೆ ಪುಶ್ ಮಾಡಿದಾಗ, ಒಂದು ಅಥವಾ ಹೆಚ್ಚಿನ ಕಮಿಟ್‌ಗಳಿರುವ ಹೆಚ್ಚುವರಿ ಪ್ಯಾಕ್ ಸೇರುತ್ತದೆ. ಉಪಶಾಖೆಗೆ ಮಾಡುವ ಪ್ರತಿ ಪುಶ್‌ನಲ್ಲೂ ಆ ವಿಷಯದ ಹಿಂದಿನ ಕಮಿಟ್‌ಗಳು ಮತ್ತೆ ಸೇರಿರುತ್ತವೆ. ಹೀಗಾಗಿ ಸೂಚಿಸಲಾದ ಮುಖ್ಯ ಶಾಖೆಯ ಆವೃತ್ತಿ ಹೊಂದಿರುವ ಕ್ಲೈಂಟ್ ಆ ವಿಷಯವನ್ನು ಒಂದೇ ಪ್ಯಾಕ್‌ನಲ್ಲಿ ಪಡೆಯಬಹುದು.
ಇದು ಕಾರಣಾಧಾರಿತ ಸುಸಂಗತತೆಯ ಒಂದು ರೂಪ. ಉಲ್ಲೇಖವನ್ನು ಫೆಚ್ ಮಾಡುವಾಗ, ಅದನ್ನು ರಚಿಸಿದ ಬರಹಗಾರನ ಇತಿಹಾಸವು ಓದುಗನಿಗೆ ಕಾಣುತ್ತದೆ. ಪುಶ್ ವೇಳೆ ಕ್ಲೈಂಟ್ ಮತ್ತು ಸರ್ವರ್ ಯಾವ ಸಾಮಾನ್ಯ ಇತಿಹಾಸವನ್ನು ಒಪ್ಪಿಕೊಳ್ಳುತ್ತವೆ ಎಂಬುದನ್ನು Pando ನಿಯಂತ್ರಿಸುತ್ತದೆ. ಇದರಿಂದ ಕ್ಲೈಂಟ್‌ಗಳು ಸುಲಭವಾಗಿ ಹಂಚಿಕೊಳ್ಳಬಹುದಾದ ಪ್ಯಾಕ್‌ಫೈಲ್‌ಗಳನ್ನು ರಚಿಸುತ್ತವೆ.
ಹೀಗಾಗಿ Git ಕಾರ್ಯಾಚರಣೆಗಳ ವೇಳೆ Pando ಎಲ್ಲ ಉಲ್ಲೇಖಗಳ ಒಂದೇ ಕ್ಷಣದ ಸ್ಥಿತಿಯನ್ನಾಗಲಿ, ಕ್ಲೋನ್ ಅಥವಾ ಫೆಚ್‌ನಲ್ಲಿ ಉಲ್ಲೇಖ ನವೀಕರಣಗಳ ಒಟ್ಟಾರೆ ಕ್ರಮವನ್ನಾಗಲಿ ಒದಗಿಸುವುದಿಲ್ಲ. ಉದಾಹರಣೆಗೆ, ಪೂರ್ಣ ಕ್ಲೋನ್‌ನ ಸಮಾಲೋಚನೆ ನಡೆಯುವಾಗ foo ಮತ್ತು bar ಶಾಖೆಗಳೆರಡೂ ನವೀಕರಣಗೊಳ್ಳುತ್ತವೆ ಎಂದುಕೊಳ್ಳಿ. ಸಮಾಲೋಚನೆಯ ವೇಳೆ ಒಂದು ಕ್ಲೈಂಟ್‌ಗೆ foo ಆವೃತ್ತಿ 1ರಲ್ಲಿ ಮತ್ತು bar ಆವೃತ್ತಿ 2ರಲ್ಲಿ ಕಾಣಬಹುದು. ಮತ್ತೊಂದು ಕ್ಲೈಂಟ್‌ಗೆ foo ಆವೃತ್ತಿ 2ರಲ್ಲಿ ಮತ್ತು bar ಆವೃತ್ತಿ 1ರಲ್ಲಿ ಕಾಣಬಹುದು. ಪ್ರಾಯೋಗಿಕವಾಗಿ, ಬಳಕೆದಾರರು ಮತ್ತು ಏಜೆಂಟ್‌ಗಳು ಉಲ್ಲೇಖ ನವೀಕರಣಗಳ ಜಾಗತಿಕ ಕ್ರಮವನ್ನು ಅವಲಂಬಿಸುವುದಿಲ್ಲ; ಒಂದೇ ಉಲ್ಲೇಖದ ನವೀಕರಣ ಕ್ರಮವನ್ನು ಅವಲಂಬಿಸುತ್ತಾರೆ.
ಮೂರು ಸುಸಂಗತತಾ ಮಾದರಿಗಳ ಈ ಅನುಕರಣೆಯಲ್ಲಿ, 1,000 ಕ್ಲೈಂಟ್‌ಗಳು ತಲಾ ಪ್ರತ್ಯೇಕ ಶಾಖೆಯನ್ನು ಆಯ್ದು, ವಿಶಿಷ್ಟ ಕಮಿಟ್‌ಗಳನ್ನು ಪದೇಪದೇ ಪುಶ್ ಮಾಡುವಂತೆ ಹೊಂದಿಸಿದ್ದೇವೆ. ಒಟ್ಟು ಕಳೆದ ಸಮಯ ಮತ್ತು ಪುಶ್‌ನಿಂದ ಫೆಚ್‌ವರೆಗಿನ ವಿಳಂಬವನ್ನು ಅಳೆಯುತ್ತೇವೆ. ಎರಡನೆಯದು ಕಾರ್ಯಭಾರಗಳಿಗೆ ಪ್ರಮುಖ ಅಳತೆ. ಬಳಕೆದಾರರು ಮತ್ತು ಏಜೆಂಟ್‌ಗಳು ಸಹಕರಿಸಲು ಅಥವಾ ಆವೃತ್ತಿ ನಿಯಂತ್ರಣ ಅವಲಂಬಿಸಿರುವ ಇತರ ವ್ಯವಸ್ಥೆಗಳನ್ನು ಬಳಸಲು ಬೇಕಾದ ಸಂಪೂರ್ಣ ವಿನಿಮಯದ ಸಮಯವನ್ನು ಅದು ಅಳೆಯುತ್ತದೆ. ಈ ಅನುಕರಣೆಯಲ್ಲಿ ಸಾಮಾನ್ಯದಿಂದ ಉನ್ನತ ದರ್ಜೆಯವರೆಗಿನ ವರ್ಚುವಲ್ ಯಂತ್ರಗಳು ಮತ್ತು ಬ್ಲಾಬ್ ಸಂಗ್ರಹ ವ್ಯವಸ್ಥೆಗಳ ಯಂತ್ರಾಂಶವನ್ನು ಮಾದರಿಯಾಗಿಸಲಾಗಿದೆ. ಈ ಅನುಕರಣೆಯಲ್ಲಿ, ಮೂರು ಹಂತದ ಕಮಿಟ್‌ಗಾಗಿ ರಿಪೊಸಿಟರಿಯಾದ್ಯಂತ ಸುಸಂಗತತೆಯ ನಿಯಮವನ್ನು ಸಡಿಲಿಸಿದ್ದೇವೆ.
Simulating Git Server Implementations
Follow each writer through repeated pushes, and separately measure when an independent reader can check out each commit.
Pando ವನ್ನು ಇನ್ನೆರಡು ವಿಧಾನಗಳೊಂದಿಗೆ ಹೋಲಿಸುವ ಈ ಅನುಕರಣೆಯನ್ನು ಚಲಾಯಿಸಿ. ಅವುಗಳ ಹೋಲಿಕೆ ನೋಡಲು ಸಾಮಾನ್ಯದಿಂದ ಉನ್ನತ ದರ್ಜೆಯವರೆಗಿನ ಯಂತ್ರಾಂಶ ಮೂಲಸೌಕರ್ಯ, ಕ್ಲೈಂಟ್‌ಗಳ ಸಂಖ್ಯೆ ಮತ್ತು ಇತರ ಸೆಟ್ಟಿಂಗ್‌ಗಳನ್ನು ಆಯ್ಕೆಮಾಡಿ.
ಮಾದರಿಯಾಗಿಸಿದ ಮೂರು ಹಂತದ ಕಮಿಟ್ ವ್ಯವಸ್ಥೆಯ ಡಿಸ್ಕ್‌ಗಳು ಭಾರದ ಅಡಿಯಲ್ಲಿ ಪೂರ್ಣ ಸಾಮರ್ಥ್ಯ ತಲುಪಿದಾಗ ಬರವಣಿಗೆಯ ವಿಳಂಬ ಬಹಳ ಹೆಚ್ಚಾಗುತ್ತದೆ. ಅದೇ ಕಾರಣದಿಂದ ಪೂರ್ವಲೇಖನ ದಾಖಲೆಯ ವ್ಯವಸ್ಥೆಗಳಲ್ಲಿ ಓದುವ ವಿಳಂಬ ಬಹಳ ಹೆಚ್ಚಾಗುತ್ತದೆ; ದಾಖಲೆಯಿಂದ ಓದುವ ವೇಗವನ್ನು ಕಾಯ್ದುಕೊಳ್ಳಲು ಸರ್ವರ್‌ಗಳು ಹೆಣಗುತ್ತವೆ. ನಮ್ಮ ಏಕೀಕೃತ ರಿಪೊಸಿಟರಿಯ ನೈಜ ಪರೀಕ್ಷೆಗಳಲ್ಲೂ ಈ ಅನುಕರಣೆಯಲ್ಲೂ, ಭಾರದ ಅಡಿಯಲ್ಲಿ ಕಾರ್ಯಕ್ಷಮತೆಗೆ ಧಕ್ಕೆಯಾಗದಂತೆ ಹಲವು ಸಾವಿರ ಕ್ಲೈಂಟ್‌ಗಳು ಏಕಕಾಲದಲ್ಲಿ ಪುಶ್ ಮಾಡಲು Pando ನೆರವಾಗುತ್ತದೆ.
ಪುಶ್ ನಿರ್ವಹಿಸುವಾಗ, Pando ಬರುವ ಪ್ಯಾಕ್‌ಫೈಲ್ ಅನ್ನು ಸ್ಥಳೀಯ ರಿಪೊಸಿಟರಿಯಲ್ಲಿ ಬಿಚ್ಚಿಡದೆ, ಬ್ಲಾಬ್ ಸಂಗ್ರಹಕ್ಕೆ ಹರಿಸುತ್ತಲೇ ಪರಿಶೀಲಿಸುತ್ತದೆ. ಕ್ಲೈಂಟ್ ಫೆಚ್ ಆರಂಭಿಸಿದಾಗ, ಓದುಗನಿಗೆ ಅಗತ್ಯವಿರುವ ಸಂಗ್ರಹಿತ ಪ್ಯಾಕ್‌ಗಳನ್ನು Pando ಆಯ್ಕೆ ಮಾಡುತ್ತದೆ; ಓದುಗ ಅವನ್ನು ಡೌನ್‌ಲೋಡ್ ಮಾಡುತ್ತದೆ. ಯಾವ ಸರ್ವರ್ ಕೂಡ ಸ್ಥಳೀಯ ರಿಪೊಸಿಟರಿಗೆ ಪ್ಯಾಕ್‌ಫೈಲ್‌ಗಳನ್ನು ಅನ್ವಯಿಸಬೇಕಿಲ್ಲ ಅಥವಾ ಹೆಚ್ಚು ಸಂಪನ್ಮೂಲ ಬೇಡುವ ಪ್ಯಾಕ್ ಬಿಚ್ಚುವ ಮತ್ತು ಕಟ್ಟುವ ಕಾರ್ಯಗಳನ್ನು ಮಾಡಬೇಕಿಲ್ಲ. ಈ ಸರ್ವರ್‌ಗಳು ಮುಖ್ಯವಾಗಿ ಸಮಾಲೋಚನೆ ಮತ್ತು ಪ್ಯಾಕ್‌ಫೈಲ್ ಆಯ್ಕೆ ಮಾಡುವುದರಿಂದ, Pando ಸರ್ವರ್‌ಗಳು ಸಾಮಾನ್ಯ ಯಂತ್ರಾಂಶದಲ್ಲೇ ಕಾರ್ಯನಿರ್ವಹಿಸಬಹುದು.
ಇದರಿಂದ ಕ್ಲೈಂಟ್‌ಗಳು, ಕ್ಲೈಂಟ್‌ಗಳು ಮತ್ತು Pando ನಡುವಿನ ಜಾಲ ಹಾಗೂ ಬ್ಲಾಬ್ ಸಂಗ್ರಹ ಸೇವೆಯ ಮಿತಿಗಳವರೆಗೆ Pando ಸಾಮರ್ಥ್ಯ ವಿಸ್ತರಿಸಬಹುದು. ಸಾಕಷ್ಟು ಸಾಮರ್ಥ್ಯವಿದ್ದರೆ, ಸ್ವತಂತ್ರ ಶಾಖೆಗಳಲ್ಲಿ ಕೆಲಸ ಮಾಡುವ ಪ್ರತಿ ಕ್ಲೈಂಟ್ ತನ್ನ ಸಂಪರ್ಕ ಅನುಮತಿಸುವ ಗರಿಷ್ಠ ವೇಗದಲ್ಲಿ ಪ್ಯಾಕ್‌ಗಳನ್ನು ವರ್ಗಾಯಿಸಬಹುದು. ಆ ವೇಗದಲ್ಲಿ ಹೆಚ್ಚಿನ ಕ್ಲೈಂಟ್‌ಗಳಿಗೆ ಸೇವೆ ನೀಡಲು, Pando ಸರ್ವರ್‌ಗಳನ್ನು ಸೇರಿಸಿ, ಅವುಗಳ ಜೊತೆಗೆ ಮೆಟಾಡೇಟಾ ಮತ್ತು ಬ್ಲಾಬ್ ಸಂಗ್ರಹಗಳನ್ನು ವಿಸ್ತರಿಸಬಹುದು.
Pushing and Fetching a Branch in Pando
Pando stores the writer’s packfile in blob storage and records the ref version in metadata service. On fetch, Pando selects the packs the reader needs, and Express serves them.
ಏಜೆಂಟ್ ಸ್ಥಳೀಯವಾಗಿ ಕಡತಗಳನ್ನು ಸಂಪಾದಿಸಿ ಕಮಿಟ್ ರಚಿಸಿ, git ಪುಶ್ ಚಲಾಯಿಸುತ್ತದೆ. ಇದು ಶಾಖೆಯನ್ನು ನವೀಕರಿಸಲು ಆ ಬದಲಾವಣೆಗಳ ಪ್ಯಾಕ್‌ಫೈಲ್ ರಚಿಸುತ್ತದೆ. Pando ಪ್ಯಾಕ್ ಸ್ವೀಕರಿಸಿ ಅದನ್ನು ಬ್ಲಾಬ್ ಸಂಗ್ರಹಕ್ಕೆ ಹರಿಸುತ್ತದೆ. ಬರುವ ಪುಶ್ ಅನ್ನು ಒಂದೇ ಸುತ್ತಿನ ಡಿಕೋಡ್ ಮೂಲಕ ಪರಿಶೀಲಿಸಿದ ಬಳಿಕ, Pando ಬಹು-ಕೀ ವ್ಯವಹಾರ ಬಳಸಿ ನಮ್ಮ ಮೆಟಾಡೇಟಾ ಸಂಗ್ರಹದಲ್ಲಿ ಉಲ್ಲೇಖ ಆವೃತ್ತಿಯನ್ನು ದಾಖಲಿಸುತ್ತದೆ ಮತ್ತು ಉಲ್ಲೇಖ ಸೂಚಕವನ್ನು ಅವಿಭಾಜ್ಯ ಕಾರ್ಯಾಚರಣೆಯಾಗಿ ನವೀಕರಿಸುತ್ತದೆ. ಇದರಿಂದ Pando “ನೀವು ಬರೆದದ್ದನ್ನು ನೀವೇ ಓದುವ” ಸುಸಂಗತತೆ ಒದಗಿಸಬಹುದು. ಈ ಇಡೀ ಬರವಣಿಗೆ ಕಾರ್ಯಕ್ಕೆ ಮೆಟಾಡೇಟಾ ಓದುಗಳು ಮತ್ತು ಬರವಣಿಗೆಗಳು ಬೇಕಾಗುತ್ತವೆ.
ಮತ್ತೊಂದು ಕ್ಲೈಂಟ್ ಶಾಖೆಯನ್ನು ಪಡೆಯುವಾಗ, ಅದರ ಬಳಿ ಈಗಾಗಲೇ ಇರುವ ಇತಿಹಾಸ ಬಳಸಿ Pando ಸಂಗ್ರಹಿತ ಪ್ಯಾಕ್‌ಗಳ ಗುಂಪನ್ನು ಆಯ್ಕೆ ಮಾಡುತ್ತದೆ. ಈ ಕಾರ್ಯಕ್ಕೆ ಮೆಟಾಡೇಟಾ ಓದುಗಳು ಬೇಕಾಗುತ್ತವೆ. ಇಲ್ಲಿ ಎಂದರೆ ಕ್ಲೈಂಟ್ ಬಳಿ ಇರುವ ಮತ್ತು ಅದಕ್ಕೆ ಬೇಕಿರುವ ಸ್ಥಿತಿಗಳ ನಡುವಿನ ಉಲ್ಲೇಖ ಆವೃತ್ತಿಗಳ ಅತಿ ಕಡಿಮೆ ಅಂತರ. ಸರ್ವರ್ ಪ್ಯಾಕ್‌ಫೈಲ್ URI ಗಳನ್ನು ಹಿಂದಿರುಗಿಸುತ್ತದೆ. ಪ್ರಾದೇಶಿಕ ತಾತ್ಕಾಲಿಕ ಸಂಗ್ರಹಗಳಲ್ಲಿ ಪ್ಯಾಕ್‌ಫೈಲ್‌ಗಳನ್ನು ಇರಿಸುವ Express ಸೇವೆಯ ಮೂಲಕ ಕ್ಲೈಂಟ್ ಅವನ್ನು ಡೌನ್‌ಲೋಡ್ ಮಾಡುತ್ತದೆ.
ಈ ವಿನ್ಯಾಸವು Pando ವಾಸ್ತುಶಿಲ್ಪದ ಮೂರು ಮುಖ್ಯ ಸೇವೆಗಳನ್ನು ಅವಲಂಬಿಸಿದೆ: ಪುಶ್, ಫೆಚ್ ಮತ್ತು ಸಂದರ್ಭ ಸಂಕುಚಿತಗೊಳಿಸುವಿಕೆ.
ಕ್ಲೈಂಟ್ ಪುಶ್ ಮಾಡುವಾಗ, ಸಾಂಪ್ರದಾಯಿಕ Git ಸರ್ವರ್ ತನ್ನ ಎಲ್ಲ ಕಾರ್ಡ್‌ಗಳನ್ನು ತೋರಿಸುವ ಪೋಕರ್ ಆಟಗಾರನಂತೆ, ತನ್ನ ಬಳಿಯ ಪ್ರತಿ ಶಾಖೆಯನ್ನೂ ಕ್ಲೈಂಟ್‌ಗೆ ಬಹಿರಂಗಪಡಿಸುತ್ತದೆ. ನಂತರ ಕ್ಲೈಂಟ್ ಕಮಿಟ್‌ಗಳು, ಟ್ರೀಗಳು ಮತ್ತು ಬ್ಲಾಬ್‌ಗಳನ್ನು ಒಟ್ಟುಗೂಡಿಸಿ, ಸರ್ವರ್ ಬಳಿ ಈಗಾಗಲೇ ಇವೆಂದು ತಿಳಿದಿರುವ ಆಬ್ಜೆಕ್ಟ್‌ಗಳನ್ನು ಹೊರಗಿಡುವ ಪ್ಯಾಕ್‌ಫೈಲ್ ರಚಿಸುತ್ತದೆ.
ಹೆಚ್ಚು ಉಲ್ಲೇಖಗಳನ್ನು ಸೂಚಿಸುವುದರಿಂದ ಪುಶ್ ಗಾತ್ರ ಕಡಿಮೆಯಾಗಬಹುದು. ಆದರೆ ಬರಹಗಾರ ಹೊರಗಿಟ್ಟ ಆಬ್ಜೆಕ್ಟ್‌ಗಳು ಮತ್ತೊಂದು ಕ್ಲೈಂಟ್ ಬಳಿ ಇಲ್ಲದಿರಬಹುದು. ಹೀಗಾಗಿ ಆ ಪ್ಯಾಕ್ ಮರುಬಳಕೆ ಕಷ್ಟವಾಗಬಹುದು.
Pando ಬೇರೊಂದು ವಿಧಾನ ಅನುಸರಿಸುತ್ತದೆ. ತನ್ನ ಎಲ್ಲ ಕಾರ್ಡ್‌ಗಳನ್ನು ತೋರಿಸುವ ಬದಲು, ಆಯ್ದ ಕೆಲವು ಶಾಖೆಗಳನ್ನಷ್ಟೇ ಕ್ಲೈಂಟ್‌ಗೆ ಸೂಚಿಸುತ್ತದೆ. ಇದಕ್ಕೆ ಎರಡು ಕಾರಣಗಳಿವೆ:
ಪ್ರತಿ ಉಲ್ಲೇಖದ ಸುಸಂಗತ ನೋಟ ಒದಗಿಸಲು ಹೆಚ್ಚಿನ ಸಂಪನ್ಮೂಲ ಬೇಕಾಗುತ್ತದೆ. ಲಕ್ಷಾಂತರ ಶಾಖೆಗಳಿದ್ದಾಗ, ಉಲ್ಲೇಖಗಳನ್ನು ಸೂಚಿಸುವ ಮಾಹಿತಿಯೊಂದೇ 100 MiB ಮೀರಬಹುದು. ಇದನ್ನು ಒದಗಿಸಲು ಪ್ರತಿ ಸರ್ವರ್ ಗಣನೀಯ ಸಮನ್ವಯ ವೆಚ್ಚದೊಂದಿಗೆ ನವೀಕೃತ ಮ್ಯಾಪಿಂಗ್ ಉಳಿಸಿಕೊಳ್ಳಬೇಕು, ಅಥವಾ ಉಲ್ಲೇಖಗಳ ಸಂಖ್ಯೆಯೊಂದಿಗೆ ಬೆಳೆಯುವ ಡೇಟಾಬೇಸ್ ಪ್ರಶ್ನೆ ನಡೆಸಬೇಕು.
ಕ್ಲೈಂಟ್‌ಗೆ ಉಲ್ಲೇಖಗಳ ಉಪಗುಂಪನ್ನಷ್ಟೇ ಒದಗಿಸಿದರೆ, ಸರ್ವರ್ ಸ್ಪಷ್ಟವಾಗಿ ಹೊರಗಿಡಲು ಅನುಮತಿಸಿದ ಅಂಶಗಳನ್ನಷ್ಟೇ ಅವಲಂಬಿಸುವ ಪ್ಯಾಕ್ ಅನ್ನು ಕ್ಲೈಂಟ್ ರಚಿಸುತ್ತದೆ. ಈ ಅವಲಂಬನೆಗಳನ್ನು ದಾಖಲಿಸುವುದರಿಂದ, ಕ್ಲೈಂಟ್ ಒಂದು ಪುಶ್‌ನಲ್ಲಿ ರಚಿಸಿದ ಪ್ಯಾಕ್‌ಫೈಲ್ ಅನ್ನು ನಂತರದ ಫೆಚ್‌ಗೆ ಪ್ರತಿಕ್ರಿಯೆಯಾಗಿ ನೀಡಿ Pando ಮರುಬಳಕೆ ಮಾಡಬಹುದು.
Git ಸರ್ವರ್ ಹೆಚ್ಚು ಉಲ್ಲೇಖಗಳನ್ನು ಸೂಚಿಸಿದಂತೆ, ಪುಶ್ ಮಾಡುವ ಕ್ಲೈಂಟ್‌ಗಳಿಗೆ ಆಬ್ಜೆಕ್ಟ್‌ಗಳನ್ನು ಹೊರಗಿಡಲು ಹೆಚ್ಚಿನ ಆಧಾರಗಳು ಸಿಗುತ್ತವೆ. ಹೀಗಾಗಿ ಅವು ಚಿಕ್ಕ ಪ್ಯಾಕ್‌ಗಳನ್ನು ರಚಿಸಬಹುದು. ಆದರೆ ಈ ಪ್ಯಾಕ್‌ಫೈಲ್‌ಗಳನ್ನು ಮರುಬಳಕೆ ಮಾಡಲು, ಪಡೆಯುವ ಕ್ಲೈಂಟ್‌ಗಳ ಬಳಿ ಪ್ರತಿ ಅವಲಂಬನೆಯೂ ಇದೆ ಎಂದು ಸರ್ವರ್ ಖಚಿತಪಡಿಸಿಕೊಳ್ಳಬೇಕು. ಇಲ್ಲದಿದ್ದರೆ ಕ್ಲೈಂಟ್‌ಗೆ ಬೇಕಾದ ಆಬ್ಜೆಕ್ಟ್‌ಗಳು ಪ್ಯಾಕ್‌ಫೈಲ್‌ನಲ್ಲಿ ಇಲ್ಲದಿರಬಹುದು.
ಇನ್ನೊಂದೆಡೆ, Git ಸರ್ವರ್ ಯಾವುದೇ ಉಲ್ಲೇಖ ಸೂಚಿಸದಿದ್ದರೆ, ಕ್ಲೈಂಟ್ ರಿಪೊಸಿಟರಿಯ ಪೂರ್ಣ ಇತಿಹಾಸ ಒಳಗೊಂಡ ಪ್ಯಾಕ್‌ಫೈಲ್ ರಚಿಸುತ್ತದೆ. ಯಾವುದೇ ಇತರ ಕ್ಲೈಂಟ್ ಆ ಪ್ಯಾಕ್‌ಫೈಲ್ ಬಳಸಬಹುದು. ಆದರೆ ಯಾವುದೇ ಶಾಖೆಯ ಫೆಚ್ ಕೂಡ ಪೂರ್ಣ ಕ್ಲೋನ್‌ನಂತಾಗುವುದರಿಂದ ಗಣನೀಯ ವೆಚ್ಚವಾಗುತ್ತದೆ.
ಹೆಚ್ಚು ಉಲ್ಲೇಖಗಳನ್ನು ಸೂಚಿಸಿದಷ್ಟೂ ಪ್ಯಾಕ್‌ಫೈಲ್‌ಗಳು ಚಿಕ್ಕದಾಗುತ್ತವೆ. ಒಂದೇ ಉಲ್ಲೇಖ ಸೂಚಿಸುವುದರಿಂದಲೇ ಗಾತ್ರದ ಬಹುಪಾಲು ಕಡಿತ ಸಾಧ್ಯವಾಗಬಹುದು.
ಪೂರ್ವನಿಯೋಜಿತವಾಗಿ, ಕ್ಲೈಂಟ್ ಹೊಸ ವೈಶಿಷ್ಟ್ಯ ಶಾಖೆಯನ್ನು ಪುಶ್ ಮಾಡಿದಾಗ, Pando ನಿಗದಿತ ಮುಖ್ಯ ಶಾಖೆಯನ್ನಷ್ಟೇ ಆಧಾರವಾಗಿ ಸೂಚಿಸುತ್ತದೆ. ರಿಪೊಸಿಟರಿಯಲ್ಲಿ ಶಾಖೆಗಳು ಹೆಚ್ಚಿದರೂ ಸೂಚನಾ ಮಾಹಿತಿಯ ಗಾತ್ರ ಒಂದೇ ಆಗಿರುತ್ತದೆ. ಆದರೆ ಇದಕ್ಕೆ ಕೆಲವು ಮಿತಿಗಳಿವೆ. ಎಂಜಿನಿಯರ್ ಒಂದೇ ಶಾಖೆಗೆ ಹಲವು ಬಾರಿ ಪುಶ್ ಮಾಡಿದಾಗ ಅಥವಾ ಒಂದು ವೈಶಿಷ್ಟ್ಯ ಶಾಖೆಯ ಮೇಲೆ ಮತ್ತೊಂದನ್ನು ನಿರ್ಮಿಸಿದಾಗ, ಮುಖ್ಯ ಶಾಖೆಯ ಹೊರಗಿನ ಎಲ್ಲವನ್ನೂ ಕ್ಲೈಂಟ್ ಮತ್ತೆ ಕಳುಹಿಸಬೇಕು.
ಇದರಿಂದ ಸತತ ಶಾಖಾ ಪುಶ್‌ಗಳು ದೊಡ್ಡದಾಗುತ್ತವೆ, ಅನಗತ್ಯ ಪುನರಾವರ್ತಿತ ಆಬ್ಜೆಕ್ಟ್‌ಗಳನ್ನು ಒಳಗೊಂಡಿರಬಹುದು ಮತ್ತು ಕ್ಲೈಂಟ್‌ನ ಹೆಚ್ಚುವರಿ ಬ್ಯಾಂಡ್‌ವಿಡ್ತ್ ಬಳಸುತ್ತವೆ. ನಮ್ಮ ಏಕೀಕೃತ ರಿಪೊಸಿಟರಿಯಲ್ಲಿ ಈ ರೀತಿ ರಚಿಸಿದ ಪ್ಯಾಕ್‌ಫೈಲ್‌ಗಳ ಮಧ್ಯಕ ಗಾತ್ರ 20 KiB ಗಿಂತ ಕಡಿಮೆಯಿತ್ತು; 99ನೇ ಶತಕಾಂಶದ ಗಾತ್ರ 3 MiB ಗಿಂತ ಕಡಿಮೆಯಿತ್ತು. ನಮಗೆ ಇದು ಸಮಂಜಸವಾದ ಹೊಂದಾಣಿಕೆಯಾಗಿತ್ತು. ಸೂಚಿಸಲಾದ ಮುಖ್ಯ ಶಾಖೆಯ ಇತಿಹಾಸ ಈಗಾಗಲೇ ಇರುವ ಓದುಗ ಆ ಒಂದೇ ಪ್ಯಾಕ್‌ಫೈಲ್ ಮೂಲಕ ಶಾಖೆಯನ್ನು ಪಡೆಯಬಹುದು.
ಕ್ಲೈಂಟ್‌ಗೆ ಸೂಚಿಸಬೇಕಾದ ಉಲ್ಲೇಖಗಳ ಗುಂಪನ್ನು ಆಯ್ದ ಬಳಿಕ, Pando ಪುಶ್ ಸ್ವೀಕರಿಸಿ ತನ್ನ ಮೆಟಾಡೇಟಾ ಸಂಗ್ರಹವನ್ನು ನವೀಕರಿಸುತ್ತದೆ. Pando ಮೆಟಾಡೇಟಾ ನವೀಕರಣವನ್ನು ಸಮಕಾಲಿಕ ಮತ್ತು ಅಸಮಕಾಲಿಕ ಭಾಗಗಳಾಗಿ ವಿಭಜಿಸುತ್ತದೆ. ಹೊಸದಾಗಿ ನವೀಕರಿಸಿದ ಕಮಿಟ್ ಅನ್ನು ಕ್ಲೈಂಟ್‌ಗಳು ತಕ್ಷಣ ಪಡೆಯಲು ಸಮಕಾಲಿಕ ಮೆಟಾಡೇಟಾ ನವೀಕರಣ ಖಾತರಿ ನೀಡುತ್ತದೆ. ಇದು ಹೊಸ ಉಲ್ಲೇಖ ಆವೃತ್ತಿಯನ್ನು ಬರೆದು, ಉಲ್ಲೇಖ ಸೂಚಕದ ಮ್ಯಾಪಿಂಗ್ ಅನ್ನು ಆ ಆವೃತ್ತಿಗೆ ನವೀಕರಿಸುತ್ತದೆ. ಹೊಸ ತುದಿ, ಪ್ಯಾಕ್‌ಫೈಲ್ ಸಮಾಲೋಚನೆಗೆ ಬಳಸಿದ ಅವಲಂಬನೆಗಳು ಮತ್ತು ಪುಶ್ ಮಾಡಿದ ಪ್ಯಾಕ್‌ಫೈಲ್‌ನ ಕೊಂಡಿಯನ್ನು ಸಂಗ್ರಹಿಸುತ್ತದೆ.
ಅದೇ ವೇಳೆ, ಸಂಕುಚನವನ್ನು ನಿಗದಿಪಡಿಸುವಂತಹ ಅಸಮಕಾಲಿಕ ಕೆಲಸವನ್ನೂ ಅದೇ ವ್ಯವಹಾರದಲ್ಲಿ ದಾಖಲಿಸಲಾಗುತ್ತದೆ. ಅತಿ ದೊಡ್ಡ ಪುಶ್‌ಗಳಿಗೆ, ಕಮಿಟ್‌ಗಳ ಉಪಗುಂಪನ್ನಷ್ಟೇ ಸಮಕಾಲಿಕವಾಗಿ ಬರೆಯಲಾಗುತ್ತದೆ. ಇದರಿಂದ ಪುಶ್ ಗಾತ್ರ ಏನೇ ಇರಲಿ, ಮೆಟಾಡೇಟಾ ಸಂಗ್ರಹದಲ್ಲಿ ಸ್ಥಿರ ಸಂಖ್ಯೆಯ ಓದುಗಳು ಮತ್ತು ಬರವಣಿಗೆಗಳು ಮಾತ್ರ ಬೇಕಾಗುತ್ತವೆ.
ಮುಖ್ಯವಾಗಿ, Pando ಸರ್ವರ್‌ಗಳು ಸಂಬಂಧವಿಲ್ಲದ ಉಲ್ಲೇಖಗಳಿಗೆ ಬರುವ ಪುಶ್‌ಗಳನ್ನು ಸ್ವತಂತ್ರವಾಗಿ ಸ್ವೀಕರಿಸಬಹುದು. ಸ್ಪರ್ಧೆ ಉಂಟಾಗುವ ಏಕೈಕ ಕೀ ಎಂದರೆ ಉಲ್ಲೇಖ ಸೂಚಕ. ಹೋಲಿಸಿ-ಬದಲಿಸುವ ರೀತಿಯ ಅವಿಭಾಜ್ಯ ಕಾರ್ಯಾಚರಣೆಯಿಂದ ನಾವು ಅದನ್ನು ರಕ್ಷಿಸುತ್ತೇವೆ. Pando ಸರ್ವರ್‌ಗಳು, ಮೆಟಾಡೇಟಾ ಸಂಗ್ರಹ ವಿಸ್ತರಣಾ ಘಟಕಗಳು ಅಥವಾ ಬ್ಲಾಬ್ ಸಂಗ್ರಹಗಳನ್ನು ಸೇರಿಸಿ ಬರವಣಿಗೆಯ ಥ್ರೂಪುಟ್ ಹೆಚ್ಚಿಸಬಹುದು.
ಕ್ಲೈಂಟ್ ಫೆಚ್ ಮಾಡುವಾಗ, ಸರ್ವರ್‌ಗೆ ಕಮಿಟ್ ಗುರುತುಗಳ ಎರಡು ಗುಂಪುಗಳನ್ನು ಒದಗಿಸುತ್ತದೆ. ಪ್ರೋಟೋಕಾಲ್‌ನಲ್ಲಿ ಇವುಗಳನ್ನು have ಮತ್ತು want ಎಂದು ಕರೆಯಲಾಗುತ್ತದೆ. ಸಾಂಪ್ರದಾಯಿಕ Git ಸರ್ವರ್‌ನಲ್ಲಿ, ಈಗಿರುವ ಕಮಿಟ್‌ಗಳಿಂದ ತಲುಪಬಹುದಾದ ಮತ್ತು ಬೇಕಿರುವ ಕಮಿಟ್‌ಗಳಿಂದ ತಲುಪಬಹುದಾದ ಆಬ್ಜೆಕ್ಟ್‌ಗಳ ಸಮೂಹ ವ್ಯತ್ಯಾಸವನ್ನು ಸರ್ವರ್ ಲೆಕ್ಕಹಾಕುತ್ತದೆ. ಅವನ್ನು ಸಂಕುಚಿತಗೊಳಿಸಿ ಫಲಿತಾಂಶವನ್ನು ಕ್ಲೈಂಟ್‌ಗೆ ಕಳುಹಿಸುತ್ತದೆ. ಈ ಕಾರ್ಯವನ್ನು ವೇಗಗೊಳಿಸಲು ಮುಕ್ತಮೂಲ Git ಸರ್ವರ್‌ನಲ್ಲಿ ಹಲವು ಸ್ಥಳೀಯ ಸೂಚ್ಯಂಕಗಳಿದ್ದರೂ, ಈ ಪ್ಯಾಕ್‌ಫೈಲ್‌ಗಳ ಗಣನೆಗೆ ಹೆಚ್ಚಿನ ಸಂಪನ್ಮೂಲ ಬೇಕಾಗಬಹುದು. ಅವನ್ನು ತಾತ್ಕಾಲಿಕ ಸಂಗ್ರಹದಲ್ಲಿ ಮರುಬಳಕೆಗೆ ಇಡುವುದೂ ಸಾಮಾನ್ಯವಾಗಿ ಕಷ್ಟ.
ಬದಲಾಗಿ, ಪುಶ್ ವೇಳೆ ದಾಖಲಿಸಿದ ಕಮಿಟ್ ಮ್ಯಾಪಿಂಗ್‌ಗಳನ್ನು ಬಳಸಿ Pando ಕ್ಲೈಂಟ್‌ನ have ಮತ್ತು wantಗಳನ್ನು ಹುಡುಕುತ್ತದೆ. ಅವನ್ನು ಆ ಕಮಿಟ್‌ಗಳಿರುವ ಉಲ್ಲೇಖ ಆವೃತ್ತಿಗಳ ಗುಂಪಿಗೆ ಜೋಡಿಸುತ್ತದೆ. ಆ ಪ್ರತಿ ಉಲ್ಲೇಖ ಆವೃತ್ತಿಯೂ Pando ಹಿಂದೆ ಸ್ವೀಕರಿಸಿದ ಪ್ಯಾಕ್‌ಫೈಲ್‌ಗೆ ಕೊಂಡಿಯಾಗಿರುತ್ತದೆ. ಇದನ್ನು ಬಳಸಿ ಕ್ಲೈಂಟ್‌ಗೆ ಏನು ಬೇಕೆಂದು ಸರ್ವರ್ ನಿರ್ಧರಿಸಿ, ಅಗತ್ಯವಿರುವ ಆಬ್ಜೆಕ್ಟ್‌ಗಳ ಗುಂಪನ್ನು ಒಳಗೊಂಡ ಪ್ಯಾಕ್‌ಫೈಲ್‌ಗಳನ್ನು ಆಯ್ಕೆ ಮಾಡುತ್ತದೆ.
Planning fetches in Pando
Pando compares what a client has with what it wants, then selects the stored packfiles needed—including any missing branch dependencies.
Fetch 27 trunk packs.
Select a branch to include its trunk dependencies.
Git ಪ್ರೋಟೋಕಾಲ್‌ನ ಈಗಾಗಲೇ ಇರುವ ಮತ್ತು ಬೇಕಿರುವ ಕಮಿಟ್‌ಗಳನ್ನು Pando ಉಲ್ಲೇಖ ಆವೃತ್ತಿಗಳ ಸರಣಿಗೆ ಜೋಡಿಸುತ್ತದೆ. ಉಪಶಾಖೆ ಬೇಕೆಂದರೆ, ಅದು ಅವಲಂಬಿಸಿರುವ ಮುಖ್ಯ ಶಾಖೆಯ ಭಾಗಗಳವರೆಗೂ ಬೇಕು ಎಂದರ್ಥ.
ಕ್ಲೋನ್ ಅಥವಾ ಫೆಚ್‌ನ HTTP ಪ್ರತಿಕ್ರಿಯೆಯಲ್ಲಿ ಒಂದೇ ಪ್ಯಾಕ್‌ಫೈಲ್ ಕಳುಹಿಸಲು Git ಪ್ರೋಟೋಕಾಲ್ ಅವಕಾಶ ನೀಡುತ್ತದೆ. ಆದರೆ ಹೆಚ್ಚು ಗಮನ ಸೆಳೆಯದ Git ಪ್ರೋಟೋಕಾಲ್ ವೈಶಿಷ್ಟ್ಯವಾದ packfile-uri, ಹೆಚ್ಚುವರಿ ಪ್ಯಾಕ್‌ಗಳನ್ನು ಪ್ರತ್ಯೇಕವಾಗಿ ಡೌನ್‌ಲೋಡ್ ಮಾಡಲು ಕೊಂಡಿಗಳನ್ನು ಹಿಂದಿರುಗಿಸುವ ಅವಕಾಶವನ್ನು ಸರ್ವರ್‌ಗೆ ನೀಡುತ್ತದೆ. Pando ಇದನ್ನೇ ಸಂಪೂರ್ಣವಾಗಿ ಬಳಸುತ್ತದೆ ಮತ್ತು ಪ್ರತಿಕ್ರಿಯೆಯೊಳಗೆ ಖಾಲಿ ಪ್ಯಾಕ್‌ಫೈಲ್ ಕಳುಹಿಸುತ್ತದೆ. ಈ ವೈಶಿಷ್ಟ್ಯಕ್ಕೆ ಬೆಂಬಲವಾಗಿ, ಮೂಲ ಯೋಜನೆಯ packfile-uriಗೆ OpenAI ಹಲವು ಸುಧಾರಣೆಗಳನ್ನು ಕೊಡುಗೆಯಾಗಿ ನೀಡಿತು.
OpenAI ವ್ಯವಸ್ಥೆಗಳು ಹಲವು ಭೌಗೋಳಿಕ ಪ್ರದೇಶಗಳಲ್ಲಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತವೆ. ಹೀಗಾಗಿ ಪ್ರತಿಯೊಂದರಲ್ಲೂ ಸ್ಥಳೀಯ ತಾತ್ಕಾಲಿಕ ಸಂಗ್ರಹಗಳಿರುವ Pando ಕ್ಲಸ್ಟರ್‌ಗಳನ್ನು ನಿರ್ವಹಿಸುತ್ತೇವೆ. ಪ್ಯಾಕ್ ವಿತರಣಾ ಸೇವೆಯಾದ Express ನಮ್ಮ ಬ್ಲಾಬ್ ಸಂಗ್ರಹಕ್ಕೆ ತಾತ್ಕಾಲಿಕ ಸಂಗ್ರಹ ಒದಗಿಸುತ್ತದೆ. ಪ್ರತ್ಯೇಕ ಸೇವೆಯೊಂದು ಮೆಟಾಡೇಟಾ ಸಂಗ್ರಹಕ್ಕೆ ಅದೇ ಸೌಲಭ್ಯ ನೀಡುತ್ತದೆ. ಈ ತಾತ್ಕಾಲಿಕ ಸಂಗ್ರಹಗಳಿಂದಾಗಿ, ಕಮಿಟ್ ಗುರುತಿನ ವಿನಂತಿ ಅಥವಾ ಉಲ್ಲೇಖದ ವಿಶೇಷ ಓದನ್ನು ಆ ಕ್ಲಸ್ಟರ್‌ನ ಸಂಗ್ರಹಿತ ಸ್ಥಿತಿಯಿಂದಲೇ ಸಂಪೂರ್ಣವಾಗಿ ಪೂರೈಸಲು Pandoಗೆ ಸಾಧ್ಯವಾಗುತ್ತದೆ. ಪ್ಯಾಕ್‌ಫೈಲ್ ವಿನಂತಿಗಳನ್ನು Express ಸರ್ವರ್‌ಗಳಿಗೆ ಕಳುಹಿಸಲು ನಾವು ಸುಸಂಗತ ಹ್ಯಾಶಿಂಗ್ ಬಳಸುತ್ತೇವೆ. ತಾತ್ಕಾಲಿಕ ಸಂಗ್ರಹದಲ್ಲೇ ಡೇಟಾ ಸಿಗುವ ಪ್ರಮಾಣ 99% ಗಿಂತ ಹೆಚ್ಚಿದೆ.
ಈ ತಾತ್ಕಾಲಿಕ ಸಂಗ್ರಹ ವ್ಯವಸ್ಥೆ ಅತಿ ಹೆಚ್ಚಿನ ಥ್ರೂಪುಟ್ ಒದಗಿಸುತ್ತದೆ. ಕ್ಲೈಂಟ್‌ಗಳು ಮತ್ತು Pando ನಡುವಿನ ಜಾಲದ ಪೂರ್ಣ ಸಾಮರ್ಥ್ಯ ಬಳಸುವಷ್ಟು ಇದು ಸಮರ್ಥವಾಗಿದೆ. ಈ ಪ್ಯಾಕ್‌ಫೈಲ್ URI ಗಳು ಮತ್ತು ಸ್ಥಳೀಯ ತಾತ್ಕಾಲಿಕ ಸಂಗ್ರಹಗಳೊಂದಿಗೆ, ಪ್ರಮಾಣಿತ ಕ್ಲೌಡ್ ಪೂರೈಕೆದಾರರ ವರ್ಚುವಲ್ ಯಂತ್ರಗಳನ್ನು ಮಾತ್ರ ಬಳಸಿ ಕ್ಲೋನ್ ಮತ್ತು ಫೆಚ್ ಕಾರ್ಯಗಳು 10 Gbps ಜಾಲ ಸಂಪರ್ಕಗಳ ಪೂರ್ಣ ಸಾಮರ್ಥ್ಯ ಬಳಸುತ್ತವೆ ಎಂದು ದೃಢಪಡಿಸಿದ್ದೇವೆ.
ಹೆಚ್ಚಿನ Git ಸರ್ವರ್‌ಗಳಲ್ಲಿ, ಬೆಳೆಯುತ್ತಿರುವ ರಿಪೊಸಿಟರಿಯ ಕಾರ್ಯಕ್ಷಮತೆ ಕಾಪಾಡಲು ಮರುಪ್ಯಾಕಿಂಗ್ ಮತ್ತು ಬಳಕೆಯಲ್ಲಿಲ್ಲದ ಡೇಟಾ ತೆರವು ಅಗತ್ಯ. ಈ ಎರಡೂ ಹಂತಗಳು ಸಂಗ್ರಹಸ್ಥಳವನ್ನು ಮುಕ್ತಗೊಳಿಸುತ್ತವೆ, ಆದರೆ ಹೆಚ್ಚಿನ ಗಣನೆ ಮತ್ತು ಒಳಹರಿವು/ಹೊರಹರಿವು ಬೇಕಾಗುತ್ತದೆ.
OpenAI ನ ಏಕೀಕೃತ ರಿಪೊಸಿಟರಿಯಂತಹ ವೇಗವಾಗಿ ಬದಲಾಗುವ ರಿಪೊಸಿಟರಿಯಲ್ಲಿ, ಕೊನೆಯ ಫೆಚ್‌ನಿಂದ ನಡೆದ ಪ್ರತಿ ಪುಶ್‌ಗೆ ಪ್ರತ್ಯೇಕ ಪ್ಯಾಕ್‌ಫೈಲ್ URI ಕಳುಹಿಸುವುದು ಪ್ರಾಯೋಗಿಕವಲ್ಲ. ತನ್ನ ಮುಖ್ಯ ಶಾಖೆಯನ್ನು ನವೀಕೃತವಾಗಿಡಲು ಕ್ಲೈಂಟ್ ಪ್ರತಿದಿನ ಹತ್ತಾರು ಸಾವಿರ ಪ್ಯಾಕ್‌ಫೈಲ್‌ಗಳನ್ನು ಡೌನ್‌ಲೋಡ್ ಮಾಡಬೇಕಾಗುತ್ತದೆ.
ಬದಲಾಗಿ, ಈ ಹೆಚ್ಚುವರಿ ವೆಚ್ಚ ಕಡಿಮೆ ಮಾಡಲು Pando ಹಿನ್ನೆಲೆಯಲ್ಲೇ ಪ್ಯಾಕ್‌ಗಳನ್ನು ಒಗ್ಗೂಡಿಸುತ್ತದೆ. ಇದಕ್ಕೆ ದಾಖಲೆ-ರಚಿತ ವಿಲೀನ ಟ್ರೀಗಳ ಸಂಕುಚನದಂತಹ ವಿನ್ಯಾಸ ಅನುಸರಿಸುತ್ತದೆ. ಪ್ರತಿ ಪುಶ್, Pando “L0” ಎಂದು ಕರೆಯುವ ಪ್ಯಾಕ್‌ಫೈಲ್ ರಚಿಸುತ್ತದೆ. ಇದು Pando ಕಳುಹಿಸಬಹುದಾದ ಡೇಟಾದ ಅತಿ ಚಿಕ್ಕ ಘಟಕ. ಕಾಲಕ್ರಮೇಣ ಹಿನ್ನೆಲೆ ಕಾರ್ಯಕರ್ತರು ಈ ಪ್ಯಾಕ್‌ಫೈಲ್‌ಗಳನ್ನು, ಉಲ್ಲೇಖ ಆವೃತ್ತಿಗಳ ಸರಣಿಯನ್ನು ಆವರಿಸುವ ಗುಂಪುಗಳಲ್ಲಿ ಸಂಗ್ರಹಿಸುತ್ತಾರೆ. ಈ ಗುಂಪುಗಳು L0 ದಿಂದ ಗುಣೋತ್ತರವಾಗಿ ವಿಸ್ತರಿಸುತ್ತವೆ. ಇಂದು ನಮ್ಮ ಏಕೀಕೃತ ರಿಪೊಸಿಟರಿ L4 ವರೆಗಿನ ಪ್ಯಾಕ್‌ಫೈಲ್ ಆವರಣ ಗುಂಪುಗಳನ್ನು ಬಳಸುತ್ತದೆ.
ಈ ಆವರಣ ಗುಂಪುಗಳು ಎರಡು ಉದ್ದೇಶಗಳನ್ನು ಪೂರೈಸುತ್ತವೆ. ಆವರಣ ಗುಂಪು ಸಾಕಷ್ಟು ತುಂಬಿದ ಬಳಿಕ, ಸಂಕುಚನ ಕಾರ್ಯಕರ್ತ ಅದನ್ನು ವಹಿಸಿಕೊಂಡು ಒಂದೇ ಪ್ಯಾಕ್‌ಫೈಲ್ ರಚಿಸುತ್ತದೆ. ಪ್ಯಾಕ್‌ಫೈಲ್‌ನ ಆಬ್ಜೆಕ್ಟ್‌ಗಳನ್ನು ಮರುಹೊಂದಿಸುವ ಮೂಲಕ ಇದು ಸಂಕುಚನ ಅನುಪಾತವನ್ನು ಸುಧಾರಿಸುತ್ತದೆ. ಜೊತೆಗೆ, ಉಲ್ಲೇಖ ಆವೃತ್ತಿಗಳ ಮೇಲೆ ಮಧ್ಯದ ಹಂತಗಳನ್ನು ದಾಟಲು ನೆರವಾಗುವ ಪಟ್ಟಿಯಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸಿ ಫೆಚ್ ಸಮಾಲೋಚನೆಯ ಕಾರ್ಯಕ್ಷಮತೆಯನ್ನೂ ಸುಧಾರಿಸುತ್ತದೆ. ಪ್ರತಿ ಹಂತದ ಸೂಚ್ಯಂಕಗಳನ್ನು ಏಕಕಾಲದಲ್ಲಿ ಪರಿಶೀಲಿಸುವ ಮೂಲಕ, Pando ಲಘುಗಣಕೀಯ ಸಮಯದಲ್ಲಿ ಕ್ಲೈಂಟ್‌ಗೆ ಕಳುಹಿಸಬೇಕಾದ ಪ್ಯಾಕ್‌ಗಳ ಗುಂಪನ್ನು ಆಯ್ಕೆ ಮಾಡಬಹುದು. ಮರುಪ್ಯಾಕ್ ಆಗಿರಲಿ ಇಲ್ಲದಿರಲಿ, ಈ ಪ್ಯಾಕ್‌ಫೈಲ್ ಆವರಣ ಗುಂಪುಗಳು ಫೆಚ್ ಯೋಜನೆಗೆ ಹೆಚ್ಚು ಪರಿಣಾಮಕಾರಿ ಪರಿಹಾರ ನೀಡುತ್ತವೆ. ಇದರಿಂದ Pando ಗೆ ಬೇಕಾಗುವ ಥ್ರೂಪುಟ್ ಮತ್ತು ವಿಳಂಬಕ್ಕೆ ಸಂಬಂಧಿಸಿದ ಬೇಡಿಕೆಗಳೆರಡೂ ಕಡಿಮೆಯಾಗುತ್ತವೆ.
Compaction in Pando
Small packfiles are grouped into larger covers across levels, improving compression and speeding up fetches.
ಸಂಕುಚನವು ಹಲವು ಉಲ್ಲೇಖ ಆವೃತ್ತಿಗಳ ಪ್ಯಾಕ್‌ಫೈಲ್‌ಗಳನ್ನು ಹಿನ್ನೆಲೆಯಲ್ಲೇ ಒಗ್ಗೂಡಿಸುತ್ತದೆ. ಇದರಿಂದ ಕಡಿಮೆ ಕಡತಗಳೊಂದಿಗೆ ಹೆಚ್ಚು ಪರಿಣಾಮಕಾರಿಯಾಗಿ ಫೆಚ್ ಮಾಡಬಹುದು.
ಅನೇಕ Git ಸರ್ವರ್‌ಗಳಿಗಿಂತ ಭಿನ್ನವಾಗಿ, ಪ್ರತಿ ಹಂತದ ಪ್ಯಾಕ್‌ಫೈಲ್‌ಗಳನ್ನು ಉಳಿಸಿಕೊಳ್ಳಲಾಗುತ್ತದೆ; ಅವನ್ನು ತ್ಯಜಿಸುವುದಿಲ್ಲ ಅಥವಾ ಅನಗತ್ಯ ಡೇಟಾ ಎಂದು ತೆರವುಗೊಳಿಸುವುದಿಲ್ಲ. ಕ್ಲೈಂಟ್‌ಗಳು ಫೆಚ್‌ನಲ್ಲಿ ವಿನಂತಿಸುವ have ಮತ್ತು wantಗಳ ಆಧಾರದಲ್ಲಿ, ಪ್ರತಿ ಹಂತದ ಪ್ಯಾಕ್‌ಗಳನ್ನೂ ನಿರಂತರವಾಗಿ ಸೇವೆ ನೀಡಲು ಬಳಸಲಾಗುತ್ತದೆ. Pando ವನ್ನು API ಯಾಗಿ ಬಳಸುವ ಕ್ಲೈಂಟ್‌ಗಳಿಗೆ, ಪ್ಯಾಕ್‌ಫೈಲ್‌ನ ಯಾವುದೇ ಆಬ್ಜೆಕ್ಟ್ ಓದಲು ಸಾಮಾನ್ಯವಾಗಿ L4 ಗಿಂತ L0 ದಿಂದ ಕಡಿಮೆ ಡೇಟಾ ಓದಿದರೆ ಸಾಕಾಗುತ್ತದೆ. ಏಕೆಂದರೆ ಅದು ಸಂಕುಚಿತವಾಗಿರುವ ಸಾಧ್ಯತೆ ಕಡಿಮೆ.
Pando ದಲ್ಲಿನ ಸಂಕುಚನವು ಕ್ಲೈಂಟ್‌ಗಳಿಗೆ ಕಳುಹಿಸುವ ಒಟ್ಟು ಡೇಟಾ ಗಾತ್ರವನ್ನು ಗಣನೀಯವಾಗಿ ಕಡಿಮೆ ಮಾಡುತ್ತದೆ. ಕ್ಲೈಂಟ್ ಎಷ್ಟು ಹಿಂದೆ ಉಳಿದಿದೆ ಎಂಬುದಕ್ಕೆ ಹೋಲಿಸಿದರೆ ಪ್ಯಾಕ್ ಯೋಜನೆಯ ಕೆಲಸ ನಿಧಾನವಾದ ದರದಲ್ಲಿ ಬೆಳೆಯಲು ಸಹ ನೆರವಾಗುತ್ತದೆ. ದೊಡ್ಡದಾದ ಮತ್ತು ವೇಗವಾಗಿ ಬದಲಾಗುವ ರಿಪೊಸಿಟರಿಗಳಿಗೆ ಇದು ವಿಶೇಷವಾಗಿ ಮುಖ್ಯ. ತಂತ್ರಾಂಶ ಅಭಿವೃದ್ಧಿಯಲ್ಲಿ ಇವು ಹೊಸ ಸಾಮಾನ್ಯ ಸ್ಥಿತಿಯಾಗಲಿವೆ ಎಂದು ನಾವು ನಿರೀಕ್ಷಿಸುತ್ತೇವೆ.
Codex ಬಳಸಿ Pando ನಿರ್ಮಿಸಿ, ಆರಂಭದಿಂದ ನೈಜ ಬಳಕೆಗೆ ಕೇವಲ 10 ವಾರಗಳಲ್ಲಿ ತಂದೆವು. Pando ದ ಮೂಲಭಾಗವನ್ನು ಒಬ್ಬರೇ ಎಂಜಿನಿಯರ್ ವಿನ್ಯಾಸಗೊಳಿಸಿದರು, ಏಜೆಂಟ್‌ಗಳ ತಂಡಗಳು ಕಾರ್ಯರೂಪಕ್ಕೆ ತಂದವು ಮತ್ತು ಬೆರಳೆಣಿಕೆಯ ಎಂಜಿನಿಯರ್‌ಗಳು ನಿಯೋಜಿಸಿದರು. ಈ ವರ್ಷದ ಏಪ್ರಿಲ್‌ನಲ್ಲಿ Pando ನೈಜ ಬಳಕೆಯ ವಿನಂತಿಗಳನ್ನು ನಿರ್ವಹಿಸಲು ಆರಂಭಿಸಿತು. OpenAI ನಲ್ಲಿ ಬಳಸುವ ಮೂಲ ಕೋಡ್ ನಿಯಂತ್ರಣ ನಿರ್ವಹಣಾ ಸಾಧನಗಳ ದೊಡ್ಡ ವ್ಯವಸ್ಥೆಯ ಒಂದು ಭಾಗವಿದು.
Pando ವಿನ್ಯಾಸವನ್ನು ಪರಿಶೀಲಿಸಲು ನಾವು ಹಲವು ಬಗೆಯ ವಿಧಾನಗಳನ್ನು ಬಳಸಿದೆವು. ಹೆಚ್ಚು ಸುರಕ್ಷಿತ ತಂತ್ರಾಂಶ ಅಡಿಪಾಯಗಳನ್ನು ನಿರ್ಮಿಸುವ ನಮ್ಮ ತತ್ವಗಳನ್ನು ಅನ್ವಯಿಸಿದೆವು. ಸಂಪೂರ್ಣ ಹೊಸ ಯೋಜನೆಯಾಗಿದ್ದರಿಂದ, ಹಳೆಯ ಅವಲಂಬನೆಗಳಿಲ್ಲದೆ Rust ನಲ್ಲಿ Pando ನಿರ್ಮಿಸಲು ನಿರ್ಧರಿಸಿದೆವು. ಏಜೆಂಟ್‌ಗಳು ತಮ್ಮ ಬದಲಾವಣೆಗಳನ್ನು ಪ್ರಮಾಣಿತ Git ವರ್ತನೆಯೊಂದಿಗೆ ಹೋಲಿಸಿ ಪರೀಕ್ಷಿಸಲು ಅನುಸರಣಾ ಪರೀಕ್ಷಾ ಸಮೂಹವನ್ನು ಬರೆದೆವು. ವ್ಯವಸ್ಥೆಯ ಅಚಲ ನಿಯಮಗಳು ಮತ್ತು ಗುಣಲಕ್ಷಣಗಳನ್ನು ಪರಿಶೀಲಿಸಲು ನಿರ್ಧಾರಿತ ಫಲಿತಾಂಶ ನೀಡುವ ಅನುಕರಣಾ ಪರೀಕ್ಷೆಯ ಪೂರಕ ವ್ಯವಸ್ಥೆಗಳನ್ನೂ ಅಭಿವೃದ್ಧಿಪಡಿಸಿದೆವು. ಸಮಾಲೋಚನೆ ಮತ್ತು ಪ್ಯಾಕ್ ಯೋಜನೆಯಲ್ಲಿನ ಸೂಕ್ಷ್ಮ ಸಮಕಾಲೀನ ಸಂಘರ್ಷಗಳು ಹಾಗೂ ಹಿನ್ನಡೆಗಳನ್ನು ಪತ್ತೆಹಚ್ಚಿ ತಗ್ಗಿಸಲು ಇದು ನೆರವಾಯಿತು.
ಈ ವ್ಯವಸ್ಥೆಗೆ ಹಲವು ಮಾಡೆಲ್‌ಗಳು ಕೊಡುಗೆ ನೀಡಿವೆ. ಹೊಸ ಮಾಡೆಲ್‌ಗಳು ಲಭ್ಯವಾದಂತೆ, Pandoದ ಕಾರ್ಯಕ್ಷಮತೆ ಮತ್ತು ವಿಶ್ವಾಸಾರ್ಹತೆ ಸುಧಾರಿಸಲು ಅವನ್ನು ಬಳಸಿದೆವು. GPT‑6 Astra ಬಳಸಿ, ಏಜೆಂಟ್‌ಗಳು “Pando ಸಿದ್ಧಾಂತ”ಕ್ಕೆ ಔಪಚಾರಿಕ ರೂಪ ನೀಡಲು Lean ಮತ್ತು TLA+ ಬರೆದವು. ಅನುಷ್ಠಾನದ ದೋಷಗಳನ್ನು ಪತ್ತೆಹಚ್ಚಿ ಸರಿಪಡಿಸಲು ಮತ್ತು ವ್ಯವಸ್ಥೆಯ ಗುಣಲಕ್ಷಣಗಳನ್ನು ಸಾಬೀತುಪಡಿಸಲು ನಾವು ಅದನ್ನು ಬಳಸಿದೆವು. Pando ದಲ್ಲಿನ ಅಪರೂಪದ ಸಂದರ್ಭಗಳನ್ನು ಪತ್ತೆಹಚ್ಚಿ ಸರಿಪಡಿಸಲು ಹಲವು ನಿರಂತರ ಅಧಿವೇಶನಗಳು ನೂರಾರು ಗಂಟೆಗಳ ಕಾಲ ನಡೆದವು. Daybreak ಸಾಮರ್ಥ್ಯವಿರುವ ಮಾಡೆಲ್‌ಗಳನ್ನು ಬಳಸಿ Git ಮತ್ತು Pando ದ ಭದ್ರತಾ ದೌರ್ಬಲ್ಯಗಳನ್ನು ಪರೀಕ್ಷಿಸಲು ಹಗಲಿರುಳು ಏಜೆಂಟ್‌ಗಳನ್ನು ನಡೆಸುತ್ತೇವೆ.
ಮೊದಲು Pandoವನ್ನು ನಮ್ಮ ಈಗಿನ ಮೂಲ ಕೋಡ್ ನಿಯಂತ್ರಣ ವ್ಯವಸ್ಥೆಗೆ ಓದು ಮತ್ತು ಬರವಣಿಗೆಯನ್ನು ಸಾಗಿಸುವ ಮಧ್ಯವರ್ತಿಯಾಗಿ ನಿಯೋಜಿಸಿದೆವು. ಇದರಿಂದ Pando ಮತ್ತು ಹಿಂದಿನ ವ್ಯವಸ್ಥೆಯನ್ನು ಸಿಂಕ್‌ನಲ್ಲಿಡಲು ಸಾಧ್ಯವಾಯಿತು. ಹೀಗಾಗಿ ಸೇವೆಗೆ ಅಡಚಣೆಯಾಗದೆ ವಿನಂತಿಗಳನ್ನು ಸುರಕ್ಷಿತವಾಗಿ Pando ಗೆ ವರ್ಗಾಯಿಸಬಹುದು.
ತನ್ನ ತಾತ್ಕಾಲಿಕ ಸಂಗ್ರಹ ವಿನ್ಯಾಸದ ಭಾಗವಾಗಿ, ವಿನಂತಿಗಳನ್ನು ಮುಂದಕ್ಕೆ ಕಳುಹಿಸುವ ಮೊದಲು Pando ನಕಲುಗಳನ್ನು ತೆಗೆದುಹಾಕಿ ಅವನ್ನು ಒಗ್ಗೂಡಿಸಬಹುದು. ಇದರಿಂದ ವ್ಯವಸ್ಥೆಗಳನ್ನು ಒಂದೊಂದಾಗಿ Pando ಗೆ ವರ್ಗಾಯಿಸುವಾಗ ಈಗಿನ ಸಾಧನಗಳು ಸರಿಯಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುವಂತೆ ನೋಡಿಕೊಳ್ಳಲು ಸಾಧ್ಯವಾಯಿತು. ಹೆಚ್ಚಿನ ಕಾರ್ಯಭಾರಗಳನ್ನು Pando ಗೆ ವರ್ಗಾಯಿಸಿದಂತೆ, ಅವುಗಳ ಪುಶ್‌ಗಳು Pando ದ ತಾತ್ಕಾಲಿಕ ಸಂಗ್ರಹವನ್ನು ತುಂಬಿ, ಹಿಂದಿನ ಹಿಂಭಾಗದ ವ್ಯವಸ್ಥೆಯ ವಿಶ್ವಾಸಾರ್ಹತೆಯನ್ನು ಸುಧಾರಿಸಿದವು.
Pando ಬಳಕೆಯ ಕಾರ್ಯಕ್ಷಮತೆ ಉತ್ತಮಗೊಳಿಸಲು, Git ನ ನಮ್ಮ ಸಾರ್ವಜನಿಕ ವಿತರಣೆಯನ್ನು ಅಭಿವೃದ್ಧಿಪಡಿಸುವವರ ಯಂತ್ರಗಳಿಗೆ ಮತ್ತು ChatGPT ಡೆಸ್ಕ್‌ಟಾಪ್ ಆ್ಯಪ್‌ನೊಳಗೆ ಒದಗಿಸಲು ಆರಂಭಿಸಿದೆವು. ಕ್ಲೈಂಟ್‌ಗಳನ್ನು ಹಂತ ಹಂತವಾಗಿ Pando ಗೆ ವರ್ಗಾಯಿಸಲು, Git ಆಜ್ಞಾ ಸಾಲು ಇಂಟರ್‌ಫೇಸ್ ಸುತ್ತಲಿನ ಆಂತರಿಕ ಆವರಣ ಸಾಧನವನ್ನು ಬಳಸಿದೆವು. ಬದಲಾವಣೆ ವಿನಂತಿಗಳ ನಿರ್ವಹಣೆ, ಕೋಡ್ ಪರಿಶೀಲನೆ ಮತ್ತು ಸ್ವಯಂಚಾಲನೆಗಾಗಿ API ಗಳಿಗೆ ಹಲವು ಇತರ ಸಾಧನಗಳನ್ನು ರಚಿಸಿದೆವು. Git ಸಂಚಾರದ ಜೊತೆಗೆ, ಹಳೆಯ API ಗಳು, ವೆಬ್‌ಹುಕ್‌ಗಳು ಮತ್ತು ರಿಪೊಸಿಟರಿ ಡೌನ್‌ಲೋಡ್‌ಗಳನ್ನು ಅವಲಂಬಿಸಿದ್ದ ನೂರಾರು ಏಕೀಕರಣಗಳನ್ನು ವರ್ಗಾಯಿಸಿದೆವು.
ಈ ಬದಲಾವಣೆಗೆ ಅಭಿವೃದ್ಧಿಪಡಿಸುವವರಿಗೆ ಮತ್ತು ತಂಡಗಳಿಗೆ Codex ಸ್ವತಃ ನೆರವಾಯಿತು. ಈಗಿರುವ ಕೆಲಸದ ಪ್ರತಿಗಳನ್ನು ಸಿದ್ಧಪಡಿಸಲು ಮತ್ತು ಹೊಸ ವ್ಯವಸ್ಥೆ ಬಳಸುವಂತೆ ಏಜೆಂಟ್‌ಗಳಿಗೆ ಮಾರ್ಗದರ್ಶನ ನೀಡಲು ಕೌಶಲ್ಯಗಳನ್ನು ರಚಿಸಿದೆವು. ಹೀಗಾಗಿ ಅಭಿವೃದ್ಧಿಪಡಿಸುವವರು ತಮ್ಮ ಅಭಿವೃದ್ಧಿ ಪರಿಸರಗಳು ಮತ್ತು ಸೇವೆಗಳನ್ನು ವರ್ಗಾಯಿಸುವಂತೆ Codex ಗೆ ಕೇಳಿದರೆ ಸಾಕಾಗಿತ್ತು.
Pando ಗೆ ಬದಲಾದದ್ದರಿಂದ ವಿಲೀನದ ವಿಶ್ವಾಸಾರ್ಹತೆ ಸುಧಾರಿಸಿತು ಮತ್ತು ಪುಶ್ ವಿಳಂಬದ ಮಧ್ಯಕ ಸುಮಾರು 80% ಕಡಿಮೆಯಾಯಿತು.
ಕೇವಲ ಬೆರಳೆಣಿಕೆಯ CPU ಕೋರ್‌ಗಳೊಂದಿಗೆ Pando ದಿನಕ್ಕೆ ಒಂದು ಪೆಟಾಬೈಟ್ Git ಡೇಟಾ ಒದಗಿಸಬಹುದು. ಒಂದೇ ಗಂಟೆಯಲ್ಲಿ Pando 57 ಟೆರಾಬೈಟ್‌ಗಿಂತ ಹೆಚ್ಚು Git ಪ್ಯಾಕ್‌ಗಳನ್ನು ಒದಗಿಸಿದೆ. ಅದರಲ್ಲಿ 99% ಗಿಂತ ಹೆಚ್ಚು ಬೈಟ್‌ಗಳು ಸ್ಥಳೀಯ ಡಿಸ್ಕ್ ತಾತ್ಕಾಲಿಕ ಸಂಗ್ರಹದಿಂದ ಬಂದಿವೆ.
ಪ್ಯಾಕ್‌ಗಳ ಮರುಬಳಕೆಯಿಂದ ಸೇವೆ ನೀಡುವ ನೋಡ್‌ಗಳಲ್ಲಿ ಅತಿ ಕಡಿಮೆ ಗಣನೆಯೊಂದಿಗೆ, ಅನೇಕ ಕ್ಲೈಂಟ್‌ಗಳು ಒಂದೇ ರಿಪೊಸಿಟರಿ ಇತಿಹಾಸವನ್ನು ಡೌನ್‌ಲೋಡ್ ಮಾಡಬಹುದು. ಈ ಉದಾಹರಣೆ ಒಂದೇ ರಿಪೊಸಿಟರಿಯನ್ನು ತೋರಿಸುತ್ತದೆ. ಆದರೆ ಇನ್ನೂ ಅನೇಕ ರಿಪೊಸಿಟರಿಗಳಿಗೆ ಬೆಂಬಲ ನೀಡುವಂತೆ Pando ವಿನ್ಯಾಸಗೊಂಡಿದೆ. ಬೇಡಿಕೆ ಹೆಚ್ಚಿದಂತೆ, ಡೇಟಾ ವಿತರಣೆ ಮತ್ತು Git ಸಮಾಲೋಚನೆಯ ಸಾಮರ್ಥ್ಯಗಳನ್ನು ಸ್ವತಂತ್ರವಾಗಿ ವಿಸ್ತರಿಸಬಹುದು.
Git ಪ್ರೋಟೋಕಾಲ್ ಮತ್ತು ಕ್ಲೈಂಟ್ ಆಧಾರದಲ್ಲಿ Pando ನಿರ್ಮಿಸಿದ್ದರಿಂದ, Git ನ ಸ್ವಂತ ಕಾರ್ಯಕ್ಷಮತೆ ಸುಧಾರಿಸುವ ಅವಕಾಶಗಳು ಮತ್ತು ದೋಷಗಳನ್ನು ಗುರುತಿಸಲು ಸಾಧ್ಯವಾಯಿತು.
ಉದಾಹರಣೆಗೆ, Pando ಮರುಬಳಕೆ ಮಾಡಬಹುದಾದ ಪ್ಯಾಕ್‌ಗಳನ್ನು ನೇರವಾಗಿ ಕ್ಲೈಂಟ್‌ಗಳಿಗೆ ಒದಗಿಸುತ್ತದೆ. ಹೀಗಾಗಿ ಅವನ್ನು ಡೌನ್‌ಲೋಡ್ ಮಾಡಿ ಸೂಚ್ಯಂಕ ರಚಿಸುವುದು ವ್ಯವಸ್ಥೆಯನ್ನು ವೇಗವಾಗಿ ಮತ್ತು ವಿಶ್ವಾಸಾರ್ಹವಾಗಿ ಮಾಡುವ ಮುಖ್ಯ ಭಾಗವಾಯಿತು. ಈ ಕೆಲಸದಿಂದ ಏಕಕಾಲದ ಡೌನ್‌ಲೋಡ್‌ಗಳು, ಅಡ್ಡಿಪಡಿಸಿದ ವರ್ಗಾವಣೆಗಳ ನಂತರದ ತೆರವು ಮತ್ತು ಈಗಾಗಲೇ ಪೂರ್ಣಗೊಂಡ ಡೌನ್‌ಲೋಡ್‌ಗಳ ಮರುಆರಂಭದಲ್ಲಿನ ಅಪರೂಪದ ಸಂದರ್ಭಗಳು ಬೆಳಕಿಗೆ ಬಂದವು. ಆ ಕಾರ್ಯಪಥಗಳನ್ನು ಸರಿಪಡಿಸಿ, ಫೆಚ್‌ಗೆ ಈಗಿರುವ ಪ್ಯಾಕ್ ಸ್ವೀಕರಿಸುವಾಗ ಪರಿಶೀಲನೆಗಳನ್ನು ಸೇರಿಸಿದೆವು. ಆ ಕೆಲಸವನ್ನು ಮೂಲ ಯೋಜನೆಗೆ ಮರಳಿ ಕೊಡುಗೆಯಾಗಿ ನೀಡಿದೆವು.
ಸಮಯ ಮತ್ತು ಬ್ಯಾಂಡ್‌ವಿಡ್ತ್ ಎಲ್ಲಿ ಬಳಕೆಯಾಗುತ್ತಿವೆ ಎಂಬುದನ್ನೂ ತಿಳಿಯಬೇಕಿತ್ತು. ಆದ್ದರಿಂದ packfile-uri ಡೌನ್‌ಲೋಡ್‌ಗಳಿಗೆ ಕಾರ್ಯಜಾಡು ಮತ್ತು ಪ್ಯಾಕ್ ರಚನೆಗೆ ಬೈಟ್ ಎಣಿಕೆಗಳನ್ನು ಸೇರಿಸಿದೆವು. ನಿಧಾನವಾದ ಫೆಚ್‌ನ ಸಮಯ ಪ್ಯಾಕ್ ರಚನೆಗೋ ಅಥವಾ ವರ್ಗಾವಣೆಗೋ ವ್ಯಯವಾಗುತ್ತಿದೆ ಎಂಬುದನ್ನು ತಿಳಿಯುವುದು ಸುಲಭವಾಯಿತು.
OpenAI ನ Git ನಿರ್ಮಿತ ಆವೃತ್ತಿಯಲ್ಲಿ(ಹೊಸ ಕಿಟಕಿಯಲ್ಲಿ ತೆರೆಯುತ್ತದೆ), ಕ್ಲೈಂಟ್ ಸ್ವತಂತ್ರ ಪ್ಯಾಕ್‌ಗಳನ್ನು ಸಮಾನಾಂತರವಾಗಿ ಡೌನ್‌ಲೋಡ್ ಮಾಡಿ ಸೂಚ್ಯಂಕ ರಚಿಸಬಹುದು. “ಸ್ಪಷ್ಟವಾಗಿ ಇರುವ ಕಮಿಟ್‌ಗಳು” ಎಂಬ ಪರಿಕಲ್ಪನೆಯನ್ನು ಸೇರಿಸಿದೆವು. ಇದರಿಂದ ಪುಶ್ ಮಾಡುವ ಕ್ಲೈಂಟ್ ತನ್ನ ಪ್ಯಾಕ್‌ನಿಂದ ಹೊರಗಿಡಬಹುದಾದ ಇತಿಹಾಸದಿಂದ ಪ್ರತ್ಯೇಕವಾಗಿ, ಶಾಖೆಯ ಈಗಿನ ತುದಿಯನ್ನು ಸರ್ವರ್ ಸೂಚಿಸಬಹುದು. Pando ದಲ್ಲಿ ಇದರಿಂದ ಕ್ಲೈಂಟ್‌ಗಳು --force-with-lease ಬಳಸಿ ವೈಶಿಷ್ಟ್ಯ ಶಾಖೆ ಬದಲಾಗಿಲ್ಲ ಎಂದು ಪರಿಶೀಲಿಸಬಹುದು ಮತ್ತು ಮುಖ್ಯ ಶಾಖೆಯನ್ನಷ್ಟೇ ಆಧರಿಸಿ ಪ್ಯಾಕ್ ರಚಿಸಬಹುದು. ನಂತರ ಆ ಮುಖ್ಯ ಶಾಖೆಯ ಇತಿಹಾಸವಿರುವ ಯಾರಾದರೂ ಅದೇ ಪ್ಯಾಕ್ ಬಳಸಿ ಶಾಖೆಯನ್ನು ಪಡೆಯಬಹುದು.
ಈ ಸುಧಾರಣೆಗಳಲ್ಲಿ ಹಲವು ಈಗಾಗಲೇ ಮೂಲ Git ಯೋಜನೆಯಲ್ಲಿವೆ. ಇನ್ನೂ ಅನೇಕವು ನಮ್ಮ ಸಾರ್ವಜನಿಕ ರಿಪೊಸಿಟರಿಯಲ್ಲಿವೆ. ಈ ಸುಧಾರಣೆಗಳು Pando ಹೊರಗೂ ಉಪಯುಕ್ತವಾಗುವಂತೆ Git ಸಮುದಾಯದೊಂದಿಗೆ ಕೆಲಸ ಮುಂದುವರಿಸುತ್ತಿದ್ದೇವೆ. ನಮ್ಮ ಸಾರ್ವಜನಿಕ ತಿದ್ದುಪಡಿ ಟ್ರ್ಯಾಕರ್‌ನಲ್ಲಿ(ಹೊಸ ಕಿಟಕಿಯಲ್ಲಿ ತೆರೆಯುತ್ತದೆ) ಆ ಕೆಲಸದ ಪ್ರಗತಿಯನ್ನು ಅನುಸರಿಸಬಹುದು.
Git ರಿಪೊಸಿಟರಿಗಳನ್ನು ವಿಸ್ತರಿಸುವ ಸಾಂಪ್ರದಾಯಿಕ ತಿಳಿವಳಿಕೆಯನ್ನು ಮರುಪರಿಶೀಲಿಸುವ ಮೂಲಕ, ನಮ್ಮ ಎಂಜಿನಿಯರ್‌ಗಳು ಮತ್ತು ಏಜೆಂಟ್‌ಗಳು ಈಗಾಗಲೇ ಬಳಸುವ Git ಕಾರ್ಯವಿಧಾನಗಳನ್ನು ಬದಲಿಸದೆ ಏಕೀಕೃತ ರಿಪೊಸಿಟರಿಯನ್ನು ವಿಸ್ತರಿಸಲು Pando ನೆರವಾಗುತ್ತದೆ. ನಮ್ಮ ಏಕೀಕೃತ ರಿಪೊಸಿಟರಿಯಲ್ಲಿ Pando ಹೆಚ್ಚಿನ ಸಮಾನಾಂತರ ಕಾರ್ಯಕ್ಕೆ ಅವಕಾಶ ಕಲ್ಪಿಸಿದೆ, ವಿಲೀನದ ವಿಶ್ವಾಸಾರ್ಹತೆಯನ್ನು ಸುಧಾರಿಸಿದೆ ಮತ್ತು ಕೋಡ್ ಬದಲಾವಣೆಗಳನ್ನು ಪ್ರಕಟಿಸಲು ಬೇಕಾಗುವ ಸಮಯವನ್ನು ಕಡಿಮೆ ಮಾಡಿದೆ. ನಮ್ಮ ಏಕೀಕೃತ ರಿಪೊಸಿಟರಿಯ ಹೊರತಾಗಿಯೂ, OpenAI ನಲ್ಲಿ Pando ಗೆ ಇತರ ಬಳಕೆಗಳನ್ನು ಪರಿಶೀಲಿಸುತ್ತಿದ್ದೇವೆ. ಅನೇಕ ಏಜೆಂಟ್‌ಗಳು ಹಂಚಿದ Git ರಿಪೊಸಿಟರಿಯಲ್ಲಿ ಸಹಕರಿಸಬೇಕಾದ ಕಾರ್ಯಭಾರಗಳೂ ಇವುಗಳಲ್ಲಿ ಸೇರಿವೆ.
ಎಂಜಿನಿಯರ್‌ಗಳು ಮತ್ತು ಏಜೆಂಟ್‌ಗಳು ಹೆಚ್ಚು ತಂತ್ರಾಂಶ ರಚಿಸಿದಂತೆ, ಮೂಲ ಕೋಡ್ ನಿಯಂತ್ರಣದಲ್ಲಿ ನಾವು ಎದುರಿಸಿದ ಮಿತಿಗಳನ್ನು OpenAI ಹೊರಗಿನ ಇನ್ನಷ್ಟು ತಂಡಗಳೂ ಎದುರಿಸಲಿವೆ. Pando ಸಾಧ್ಯವಾಗಿಸುವ ತಂತ್ರಜ್ಞಾನವನ್ನು ನಮ್ಮ ಬಳಕೆದಾರರೊಂದಿಗೆ ಹಂಚಿಕೊಳ್ಳುವ ಮಾರ್ಗಗಳನ್ನು ಈಗ ಪರಿಶೀಲಿಸುತ್ತಿದ್ದೇವೆ.
Git ರಿಪೊಸಿಟರಿಗಳ ಬಳಕೆದಾರರು ಮತ್ತು ನಿರ್ವಾಹಕರ ಎರಡು ದಶಕಗಳ ಅನುಭವದ ಮೇಲೆ Pando ನಿರ್ಮಾಣವಾಗಿದೆ. Pando ಅಭಿವೃದ್ಧಿಯನ್ನು ಮುಂದುವರಿಸುತ್ತಲೇ, ವ್ಯಾಪಕವಾಗಿ Git ಬಳಕೆದಾರರಿಗೆ ಉಪಯುಕ್ತವಾಗುವ ಸುಧಾರಣೆಗಳನ್ನು ಹಂಚಿಕೊಳ್ಳಲು ಮುಕ್ತಮೂಲ Git ಸಮುದಾಯದೊಂದಿಗೆ ಕೆಲಸ ಮಾಡುತ್ತೇವೆ.
