100 ಕೋಟಿಗೂ ಹೆಚ್ಚು ChatGPT ಬಳಕೆದಾರರಿಗಾಗಿ ಆನ್‌ಲೈನ್ ಸಂಗ್ರಹಣೆಯ ವೇಗದ ಸ್ಕೇಲಿಂಗ್

ಯಾರಾದರೂ ಲಾಗಿನ್ ಆಗುತ್ತಿರಲಿ, ತಮ್ಮ Codex ಸೆಟ್ಟಿಂಗ್‌ಗಳನ್ನು ಪರಿಶೀಲಿಸುತ್ತಿರಲಿ ಅಥವಾ ChatGPT ಯಲ್ಲಿ ಹೊಸ ಸಂಭಾಷಣೆ ಆರಂಭಿಸುತ್ತಿರಲಿ, ಪ್ರತಿಯೊಂದು OpenAI ಉತ್ಪನ್ನವೂ ಡೇಟಾಗೆ ವೇಗವಾದ, ವಿಶ್ವಾಸಾರ್ಹ ಪ್ರವೇಶವನ್ನು ಅವಲಂಬಿಸಿದೆ. ಉತ್ಪನ್ನವು ಪ್ರತಿಕ್ರಿಯಿಸುವ ಮೊದಲು ಈ ಪ್ರತಿಯೊಂದು ಕ್ರಿಯೆಗೂ ಹಲವು ಪ್ರತ್ಯೇಕ ಡೇಟಾ ಹುಡುಕಾಟಗಳು ಬೇಕಾಗಬಹುದು. ಆ ವಿನಂತಿಗಳು ನಿಧಾನವಾದರೆ, ಉತ್ಪನ್ನವೂ ನಿಧಾನವೆನಿಸುತ್ತದೆ. ಆ ವಿನಂತಿಗಳು ವಿಫಲವಾದರೆ, ಉತ್ಪನ್ನವು ಸಂಪೂರ್ಣವಾಗಿ ಕೆಲಸ ನಿಲ್ಲಿಸುತ್ತದೆ.

OpenAI ಉತ್ಪನ್ನಗಳು ಅಗತ್ಯ ಮಾಹಿತಿಯನ್ನು ವೇಗವಾಗಿ ಮತ್ತು ವಿಶ್ವಾಸಾರ್ಹವಾಗಿ ಪಡೆಯಲು ನಾವು ನಿರ್ಮಿಸಿದ ಆನ್‌ಲೈನ್ ಸಂಗ್ರಹಣಾ ಪ್ಲಾಟ್‌ಫಾರ್ಮ್ Habitat ಆಗಿದೆ. Habitat ಈಗ ಸುಮಾರು 40 ಭೌಗೋಳಿಕ ಪ್ರದೇಶಗಳಲ್ಲಿ, ಪ್ರತಿ ವಾರ 100 ಕೋಟಿಗೂ ಹೆಚ್ಚಿನ ಜನರು ಬಳಸುವ ಉತ್ಪನ್ನಗಳಿಗೆ ಬೆಂಬಲವಾಗಿ, ಪ್ರತಿ ಸೆಕೆಂಡ್‌ಗೆ 7 ಕೋಟಿಗೂ ಹೆಚ್ಚು ವಿನಂತಿಗಳನ್ನು ನಿರ್ವಹಿಸುತ್ತದೆ. Habitat ಅನ್ನು ಮೊದಲು DevDay 2023 ರಲ್ಲಿ GPT ಗಳಿಗೆ ಬೆಂಬಲ ನೀಡಲು ಬಿಡುಗಡೆ ಮಾಡಲಾಯಿತು. ಅದು ಒಂದೇ ಡೇಟಾಬೇಸ್‌ಗೆ ಸಂಪರ್ಕಿತವಾದ ಸರಳ Python ಕ್ಲೈಂಟ್-ಬದಿಯ ಲೈಬ್ರರಿಯಾಗಿ ಆರಂಭವಾಯಿತು. ಇಂದು ಅದು 500 ಪೆಟಾಬೈಟ್‌ಗೂ ಹೆಚ್ಚು ಡೇಟಾ ಒದಗಿಸುವ ಸಂಕೀರ್ಣ ವಿತರಿತ ವ್ಯವಸ್ಥೆಯಾಗಿದೆ.

ಈ ಪ್ರಮಾಣದ ಮೂಲಸೌಕರ್ಯ ನಿರ್ಮಿಸಿ ನಿರ್ವಹಿಸುವುದು ಸುಲಭವಲ್ಲ; ಆದರೆ ಅದೇನು ವಿಶೇಷವಾಗಿ ಕಷ್ಟಕರವೂ ಅಲ್ಲ. ಅಚ್ಚರಿಗೊಳಿಸುವ ಬಳಕೆದಾರರ ಬೆಳವಣಿಗೆ ಮತ್ತು ಉತ್ಪನ್ನ ಬೇಡಿಕೆಯನ್ನು ಬೆಂಬಲಿಸುತ್ತಲೇ ಪ್ರೌಢ ಪ್ಲಾಟ್‌ಫಾರ್ಮ್ ನಿರ್ಮಿಸಲು ನಾವು ಹಿಂದೆಂದೂ ಕಾಣದ ವೇಗದಲ್ಲಿ ಸ್ಕೇಲ್ ಮಾಡಬೇಕಾದದ್ದು ನಮ್ಮ ಪರಿಸ್ಥಿತಿಯನ್ನು ವಿಶಿಷ್ಟವಾಗಿಸಿತು. ಸಾಮಾನ್ಯವಾಗಿ ವ್ಯವಸ್ಥೆಯ ಎಂಜಿನಿಯರ್‌ಗಳು 10 ಪಟ್ಟು ಪ್ರಮಾಣಕ್ಕಾಗಿ ನಿರ್ಮಿಸಿ, ಮುಂದಿನ 10 ಪಟ್ಟು ಬೆಳವಣಿಗೆಗೆ ಸಿದ್ಧರಾಗುವಾಗ ಅದು ಕೆಲವು ವರ್ಷ ತಾಳುತ್ತದೆಂದು ಆಶಿಸುತ್ತಾರೆ. ನಮ್ಮಲ್ಲಿ ಕಳೆದ ಮೂರು ವರ್ಷಗಳಿಂದ ವರ್ಷದಿಂದ ವರ್ಷಕ್ಕೆ 10 ಪಟ್ಟಿಗೂ ಹೆಚ್ಚು ಬೆಳವಣಿಗೆಯಾಗಿದೆ. ಹೀಗಾಗಿ Habitat ನಿರ್ಮಾಣ ಮತ್ತು ಕಾರ್ಯಾಚರಣೆ ಹಲವು ಕಾರ್ಯತಂತ್ರದ ನಿರ್ಧಾರಗಳ ಸರಣಿಯಾಯಿತು: ಈಗಿರುವ ತಂತ್ರಜ್ಞಾನದಿಂದ ಗರಿಷ್ಠ ಪ್ರಯೋಜನ ಪಡೆಯಲು ಪ್ರತಿಯೊಂದು ಘಟಕವನ್ನೂ ತಳಮಟ್ಟದಲ್ಲಿ ಅರ್ಥಮಾಡಿಕೊಳ್ಳುವುದು, ಜೊತೆಗೆ ಮೂಲಭೂತ ಹೂಡಿಕೆಗಳಿಗೆ ಸಮಯ ಗಳಿಸಲು ಸಂಗ್ರಹಣೆ ಮತ್ತು ಕಂಪ್ಯೂಟ್ ಸಾಮರ್ಥ್ಯದ ಕೊರತೆಯನ್ನು ನಿಭಾಯಿಸುವುದು.

OpenAI ಬೆಳೆದಂತೆ Habitat ಕೂಡ ಬೆಳೆಯಬೇಕಾಯಿತು: ಮೊದಲು ನಿರ್ಣಾಯಕ ಉತ್ಪನ್ನ ಟ್ರಾಫಿಕ್‌ಗೆ ಸಾಕಷ್ಟು ವಿಶ್ವಾಸಾರ್ಹವಾಗಿ, ನಂತರ ಜಾಗತಿಕ ಬಳಕೆದಾರರಿಗೆ ಸಾಕಷ್ಟು ವೇಗವಾಗಿ ಮತ್ತು ಕೊನೆಗೆ ಭಾರಿ ಪ್ರಮಾಣದಲ್ಲಿ ಸಮರ್ಥವಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುವಂತೆ. ಆನ್‌ಲೈನ್ ಸಂಗ್ರಹಣೆಯನ್ನು ನಾವು ಹೇಗೆ ಸ್ಕೇಲ್ ಮಾಡಿದೆವು ಎಂಬ ಎರಡು ಭಾಗಗಳ ಸರಣಿಯಲ್ಲಿ ಇದು ಮೊದಲ ಲೇಖನ. ಈ ಲೇಖನದಲ್ಲಿ Habitat ಹೇಗೆ ವಿಕಸಿಸಿತು, ಅದನ್ನು ಲೈಬ್ರರಿಯಿಂದ ಸೇವೆಯಾಗಿ ಏಕೆ ಬದಲಿಸಿದೆವು ಮತ್ತು ಸೇವಾ ತಂತ್ರಜ್ಞಾನದಲ್ಲಿ ಅಪರೂಪದ ಭಾಷೆಯಾದ Python ನಲ್ಲಿ ಬರೆದ ಸೇವೆಯನ್ನು ವಿಶ್ವಾಸಾರ್ಹ ಸಂಗ್ರಹಣಾ ಪ್ಲಾಟ್‌ಫಾರ್ಮ್ ಪದರವಾಗಿ ಹೇಗೆ ವಿಸ್ತರಿಸಿದೆವು ಎಂಬುದನ್ನು ಹಂಚಿಕೊಳ್ಳುತ್ತೇವೆ.

ಮುಂದಿನ ಲೇಖನದಲ್ಲಿ ದೊಡ್ಡ ಪ್ರಮಾಣದಲ್ಲಿ ಬಹು-ಬಾಡಿಗೆದಾರr ವಿಶ್ವಾಸಾರ್ಹತೆ ಸಾಧಿಸಿದ ರೀತಿ, ಓದುವಿಕೆ ಕಾರ್ಯಕ್ಷಮತೆಯ ಸುಧಾರಣೆಗೆ ನಮ್ಮ ಬಹುಪದರ ಕಾರ್ಯತಂತ್ರ ಮತ್ತು ಹಿಂದೆಂದೂ ಕಾಣದ ಬೇಡಿಕೆಯನ್ನು ವಿಶ್ವಾಸಾರ್ಹವಾಗಿ ನಿರ್ವಹಿಸಲು Azure Cosmos DB ಜೊತೆಗಿನ ಪಾಲುದಾರಿಕೆಯನ್ನು ಸ್ಕೇಲ್ ಮಾಡಿದ ಬಗೆಯನ್ನು ವಿವರಿಸುತ್ತೇವೆ.

ಉತ್ಪನ್ನ ಎಂಜಿನಿಯರ್‌ಗಳು ಡೇಟಾಬೇಸ್ ನಿರ್ವಹಣೆ ಬಗ್ಗೆ ಯೋಚಿಸಬೇಕಾಗಬಾರದು ಎಂಬ ಸರಳ ಕಲ್ಪನೆಯಿಂದ Habitat ಆರಂಭವಾಯಿತು. ChatGPT ಯ ಮುಖ್ಯ ಸರ್ವರ್ ಜೊತೆge ಸಂವಹನ ನಡೆಸುವ ಸಣ್ಣ Python ಲೈಬ್ರರಿಯಾಗಿ, GPTಗಳಿಗೆ ಬೆಂಬಲ ನೀಡಲು Habitat ಮೊದಲು DevDay 2023 ರಲ್ಲಿ ಬಿಡುಗಡೆಯಾಯಿತು. ಅದು ಆಂತರಿಕವಾಗಿ Azure Cosmos DB ಡೇಟಾಬೇಸ್ ಅಪ್ಲಿಕೇಶನ್‌ಗೆ ಮ್ಯಾಪ್ ಮಾಡಲಾದ ಕೆಲವೇ ಕಾರ್ಯಾಚರಣೆಗಳನ್ನು ಬೆಂಬಲಿಸಿತು.

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

ಉತ್ಪನ್ನ ಎಂಜಿನಿಯರ್‌ಗಳು ಸ್ಕೀಮಾ ಹುಡುಕಾಟ, ರೂಟಿಂಗ್, ದೃಢೀಕರಣ, ಎನ್‌ಕ್ರಿಪ್ಶನ್, ಸೀರಿಯಲೈಸೇಶನ್, ವಿನಂತಿ ರೂಪಿಸುವಿಕೆ ಮತ್ತು ಸಂಪರ್ಕ ಪೂಲಿಂಗ್ ಬಗ್ಗೆ ಚಿಂತಿಸಬೇಕಾಗಿರಲಿಲ್ಲ. ಡೇಟಾ Azure Cosmos DB, ಕ್ಯಾಶ್‌ಗಳು ಅಥವಾ ಬೇರೆ ಸಂಗ್ರಹಣಾ ಪ್ರಕಾರಗಳಲ್ಲಿ ಎಲ್ಲಿಂದ ಬರುತ್ತದೆ ಎಂಬುದನ್ನೂ ಅವರು ಪರಿಗಣಿಸಬೇಕಿರಲಿಲ್ಲ.

ಸ್ವಯಂಸೇವಾ Postgres ಮತ್ತು Azure Cosmos DB ಬಳಕೆಯಿಂದ ದೂರ ಸರಿಸಲು ಕೇಂದ್ರೀಕೃತ ಪ್ರಯತ್ನವಿಲ್ಲದಿದ್ದರೂ, ಈ Python ಲೈಬ್ರರಿ ಚೆನ್ನಾಗಿ ಕೆಲಸ ಮಾಡಿತು ಮತ್ತು OpenAI ನ ಉತ್ಪನ್ನ ಎಂಜಿನಿಯರ್‌ಗಳು Habitat ಅನ್ನು ವೇಗವಾಗಿ ಅಳವಡಿಸಿಕೊಂಡರು.

ಉತ್ಪನ್ನದ ಅಗತ್ಯಗಳು ಬದಲಾದಂತೆ ಕ್ಲೈಂಟ್-ಬದಿಯ ಕ್ಯಾಶಿಂಗ್, ಕಂಪ್ರೆಶನ್ ಅಥವಾ ಎನ್‌ಕ್ರಿಪ್ಶನ್‌ನಂತಹ ವೈಶಿಷ್ಟ್ಯಗಳಿಗೆ ಬೆಂಬಲವನ್ನು ಹಂಚಿಕೆಯ ಲೈಬ್ರರಿಗೆ ಸೇರಿಸುವುದೂ ಉತ್ಪನ್ನ ಡೆವಲಪರ್‌ಗಳಿಗೆ ಸುಲಭವಾಗಿತ್ತು.

2025 ರ ಮಧ್ಯಭಾಗದ ವೇಳೆಗೆ ಕ್ಲೈಂಟ್-ಬದಿಯ ಇಂಪ್ಲಿಮೆಂಟೇಶನ್‌ಗಾಗಿ Habitat ತನ್ನ ಮಿತಿಗಳನ್ನು ತಲುಪಿತ್ತು. Habitat ಪದರ ಹೆಚ್ಚು ಸಂಕೀರ್ಣಗೊಂಡು OpenAI ಸೇವೆಗಳ ಸಂಖ್ಯೆ ಹೆಚ್ಚಿದಂತೆ, ಹಿಂದಿನ ಆವೃತ್ತಿಗಳಿಗೆ ಹೊಂದುವ ಪ್ರೋಟೋಕಾಲ್ ಬದಲಾವಣೆಗಳು ಕಾರ್ಯಸಾಧ್ಯವಲ್ಲದಂತಾಗಿದ್ದವು.

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

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

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

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

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

ನಮಗೆ ಸೇವೆಯ ಅಗತ್ಯವಿದೆ ಎಂದು ತಿಳಿದಿತ್ತು. ಆದರೆ ಸೇವೆಯಾಗಿ Python ಹೆಚ್ಚುವರಿ ಹೊರೆ ತಂದರೂ, ಆಗಲೇ ಅದರಿಂದ ವರ್ಗಾಯಿಸಲು ನಾವು ಬಯಸಲಿಲ್ಲ. ಹೆಚ್ಚಿನ ಥ್ರೂಪುಟ್ ಸೇವೆಗೆ Python ಬಳಸಿದಾಗ, ಸ್ಥಳೀಯ ಲೈಬ್ರರಿ ಕಾರ್ಯಗತಗೊಳಿಸುವಿಕೆಗೆ ಹೋಲಿಸಿದರೆ ನೆಟ್‌ವರ್ಕ್ ವಿಳಂಬ ಹಾಗೂ CPU ಮತ್ತು ಮೆಮೊರಿ ಸ್ಕೇಲಿಂಗ್ ವೆಚ್ಚ ಗಣನೀಯವಾಗಿ ಹೆಚ್ಚಿತು. ಜೊತೆಗೆ, 100 ಪಟ್ಟು ಪ್ರಮಾಣದಲ್ಲಿ Python ನ ಅಸಮರ್ಥತೆಗಳು ಸ್ವೀಕಾರಾರ್ಹವಾಗುವುದಿಲ್ಲ ಮತ್ತು ಅಂತಿಮವಾಗಿ ಮರುಬರವಣಿಗೆ ಬಹುತೇಕ ಅನಿವಾರ್ಯವೆಂದು ನಾವು ಅರಿತಿದ್ದೆವು.

ಆದರೂ, ತಾಂತ್ರಿಕ ಋಣವನ್ನು ಉದ್ದೇಶಪೂರ್ವಕವಾಗಿ ತೆಗೆದುಕೊಳ್ಳುವ ಕಾರ್ಯತಂತ್ರವಾಗಿ ನಾವು ಇದನ್ನು ನೋಡಿದೆವು. ಆಗ ನಮ್ಮ ಮುಖ್ಯ ಗುರಿ ವೆಚ್ಚ ಅಥವಾ ಸಂಪನ್ಮೂಲ ಸುಧಾರಣೆಯಾಗಿರಲಿಲ್ಲ; ಉತ್ಪನ್ನ ಡೆವಲಪರ್‌ಗಳ ಅಡೆತಡೆ ನಿವಾರಿಸಿ, ಪ್ಲಾಟ್‌ಫಾರ್ಮ್ ಸ್ಥಿರತೆ ಸಾಧಿಸುವುದಾಗಿತ್ತು. ಅಲ್ಪಾವಧಿಯಲ್ಲಿ Python ಸೇವೆಯ ಕಾರ್ಯಕ್ಷಮತೆಯ ರಾಜಿಗಳನ್ನು ಒಪ್ಪಿಕೊಂಡಿದ್ದರಿಂದ, ತಕ್ಷಣದ ಸವಾಲುಗಳಿಗೆ ಆದ್ಯತೆ ನೀಡಿ, ನಮ್ಮ ಪ್ರಮುಖ API ಗಳನ್ನು ಸ್ಥಾಪಿಸಿ, ದೃಢವಾದ ಮೂಲಸೌಕರ್ಯ ನಿರ್ಮಿಸಲು ಸಾಧ್ಯವಾಯಿತು.

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

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

I/O ಆಧಾರಿತ ಕೆಲಸಗಳನ್ನು ಏಕಕಾಲದಲ್ಲಿ ನಡೆಸಲು Asyncio, Python ಗೆ ನೆರವಾಗುತ್ತದೆ. ಆದರೆ Python GIL ಅನ್ನು ಮೀರಿ CPU ಸಮಾನಾಂತರತೆಯನ್ನು ಒದಗಿಸುವುದಿಲ್ಲ. I/O-ಭಾರಿತ ವಿನಂತಿ ಪ್ರಾಕ್ಸಿಯ ಜೊತೆಗೆ, Habitat ಅನೇಕ CPU-ಭಾರಿತ ಹೊಣೆಗಾರಿಕೆಗಳು ಮತ್ತು ಹಿನ್ನೆಲೆ ಕಾರ್ಯಗಳನ್ನು ನಿರ್ವಹಿಸುತ್ತದೆ: ರೂಟಿಂಗ್, ಸಂಕುಚನ, ಎನ್‌ಕ್ರಿಪ್ಶನ್, ಚೆಕ್‌ಸಮ್ ಲೆಕ್ಕಾಚಾರ, ಕೆಳಹಂತದ ಆರೋಗ್ಯ ಪರಿಶೀಲನೆ, ವಿನಂತಿ ಶ್ಯಾಡೋಯಿಂಗ್ ಮತ್ತು ಹೆಡ್ಜಿಂಗ್.

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

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

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

ಹೀಗಾಗಿ ಪ್ರತಿ ಪ್ರಕ್ರಿಯೆಯು ಕೆಲವೇ ಸಮಕಾಲೀನ ವಿನಂತಿಗಳನ್ನು ನಿರ್ವಹಿಸುವಂತೆ ಮಾಡಿ, ಬದಲಿಗೆ Python ನೌಕರರ ಪ್ರಕ್ರಿಯೆಗಳ ಸಂಖ್ಯೆಯನ್ನು ಭಾರೀ ಪ್ರಮಾಣದಲ್ಲಿ ಹೆಚ್ಚಿಸುತ್ತೇವೆ.

ಆರಂಭಿಕ ಸೇವಾ ಬಿಡುಗಡೆಯಲ್ಲಿ ನೇರ ಸೇವೆಯ CPU ಪ್ರೊಫೈಲಿಂಗ್ ಮೂಲಕ ಅಧಿಕ Asyncio ವಿಳಂಬದ ಮತ್ತು ಪರಿಣಾಮವಾಗಿ ಅಧಿಕ ಕೊನೆಯ ಅಂಚಿನ ವಿಳಂಬಗಳ ಒಂದು ಮೂಲ ಕಾರಣವನ್ನು ಕಂಡುಬಂದಿದೆ: Statsig ಮೂಲಕ ನಮ್ಮ ವೈಶಿಷ್ಟ್ಯ ಫ್ಲ್ಯಾಗ್ ಸಂರಚನೆಗಳನ್ನು ನಿಯತಕಾಲಿಕವಾಗಿ JSON ಪಾರ್ಸ್ ಮಾಡುವುದು. Statsig ವೈಶಿಷ್ಟ್ಯ ಫ್ಲ್ಯಾಗ್‌ಗಳನ್ನು ನಿರ್ವಹಿಸುವ ಮತ್ತು A/B ಪರೀಕ್ಷೆ ಮುಂತಾದವುಗಳನ್ನು ನಡೆಸುವ ಸಾಧನವಾಗಿದೆ.

ಪೂರ್ವನಿಯೋಜಿತವಾಗಿ, Statsig ಯಾವುದೇ ವ್ಯತ್ಯಯವಿಲ್ಲದೆ ಪ್ರತಿ ನಿಮಿಷವೂ ರಿಫ್ರೆಶ್ ಆಗುವ ಕಾನ್ಫಿಗ್‌ಗಳನ್ನು ಪರಿಶೀಲಿಸುವಂತೆ ಕಾನ್ಫಿಗರ್ ಮಾಡಲಾಗಿತ್ತು ಮತ್ತು ಆ ಕಾನ್ಫಿಗ್‌ನಲ್ಲಿ ಎಲ್ಲಾ ಸೇವೆಗಳ ಪ್ರತಿಯೊಂದು ಉತ್ಪಾದನಾ ನಿಯಮವೂ ಸೇರಿತ್ತು. ಮತ್ತೊಂದೆಡೆ, CPU ಬಳಕೆಯನ್ನು ಹೆಚ್ಚಿಸಿ ಕಡಿಮೆ ವಿಳಂಬ ಒದಗಿಸಲು ಪ್ರತಿ ಪಾಡ್‌ನಲ್ಲಿ ಗರಿಷ್ಠ 8 Python ಪ್ರಕ್ರಿಯೆಗಳನ್ನು ನಡೆಸುವ ವಾಸ್ತುಶಿಲ್ಪದ ನಿರ್ಧಾರ ಮಾಡಲಾಗಿತ್ತು. ಇವೆರಡರಿಂದಾಗಿ, ಪ್ರತಿ ನಿಮಿಷವೂ ಪ್ರತಿಯೊಂದು ಪಾಡ್‌ನ ಎಲ್ಲಾ ವರ್ಕರ್‌ಗಳು ಚಾಲನೆಯಲ್ಲಿರುವ ವಿನಂತಿಗಳ ಪ್ರಕ್ರಿಯೆಗೊಳಿಸುವುದನ್ನು ನಿಲ್ಲಿಸಿ, ಬೃಹತ್ ಕಾನ್ಫಿಗರೇಶನ್ ಫೈಲ್ ಪಾರ್ಸ್ ಮಾಡಲು CPU ಸೈಕಲ್‌ಗಳನ್ನು ಬಳಸುವ ಕ್ಷಣ ಎದುರಾಗುತ್ತಿತ್ತು.

CPU ಪ್ರೊಫೈಲಿಂಗ್ ಸಮಸ್ಯೆಯ ಮೂಲ ಕಾರಣ ಪತ್ತೆಹಚ್ಚಿದ ಬಳಿಕ ಪರಿಹಾರ ಸರಳವಾಗಿತ್ತು: ಸಣ್ಣದಾದ ಉದ್ದೇಶಿತ ಕಾನ್ಫಿಗ್ ಅನ್ನು ನಿಯೋಜಿಸುವುದು, ರಿಫ್ರೆಶ್ ಮಾಡುವ ಮಧ್ಯಂತರವನ್ನು ಹೆಚ್ಚಿಸುವುದು ಮತ್ತು ಇಂತಹ ಹಿನ್ನೆಲೆ ಕಾರ್ಯಗಳಿಗೆ ಸ್ವಲ್ಪ ವೇಳಾಪಟ್ಟಿ ವ್ಯತ್ಯಯ ಸೇರಿಸುವುದು.

ಕಡಿಮೆ asyncio ವಿಳಂಬ ಉಳಿಸಿಕೊಳ್ಳಲು ಸರ್ವರ್ ಪ್ರಕ್ರಿಯೆಗಳಾದ್ಯಂತ ವಿನಂತಿಗಳ ಉತ್ತಮ ಲೋಡ್ ಸಮತೋಲನವೂ ಅತ್ಯಂತ ಮುಖ್ಯ. ಸರಿಯಾಗಿ ಹೊಂದಿಸದಿದ್ದರೆ ಸಂಪರ್ಕ ಪೂಲಿಂಗ್ ಇದಕ್ಕೆ ವಿರುದ್ಧವಾಗಿ ಕೆಲಸ ಮಾಡಬಹುದು.

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

ನಮ್ಮ ಸೇವೆಯ ಒಂದು ಭಾಗಕ್ಕೆ ಅತಿಯಾದ ಹೊರೆ ತರುತ್ತಿದ್ದ ಕ್ಲೈಂಟ್ ಅನ್ನು ನಿಲ್ಲಿಸಿದರೂ, ಹಠಾತ್ ಟ್ರಾಫಿಕ್ ಕಡಿಮೆಯಾದ ಬಹಳ ಸಮಯದ ನಂತರವೂ ಕೆಲವು ಪ್ರಕ್ರಿಯೆಗಳು ಕುಸಿದ ಸ್ಥಿತಿಯಲ್ಲೇ ಉಳಿದ ಆಕಸ್ಮಿಕ ಘಟನೆಯಲ್ಲಿ ಇದನ್ನು ಕಂಡುಕೊಂಡೆವು. ವಾಸ್ತವವಾಗಿ, ಆ ಪ್ರಕ್ರಿಯೆಗಳನ್ನು ಮರುಪ್ರಾರಂಭಿಸುವವರೆಗೂ ಅವುಗಳ ನಿಯಂತ್ರಣ ತಪ್ಪಿ ಕುಸಿಯುತ್ತಾ, ಹೆಚ್ಚು ಹೆಚ್ಚು ವಿನಂತಿಗಳನ್ನು ಸ್ವೀಕರಿಸುತ್ತಿದ್ದವು. ಪಾಡ್ ಓವರ್‌ಲೋಡ್ ಆದರೆ, ಯಾವುದೋ ನಡವಳಿಕೆ ಹೆಚ್ಚಿನ ಟ್ರಾಫಿಕ್ ಅನ್ನು ಅದೇ ಪಾಡ್‌ಗೆ ಕಟ್ಟಿಹಾಕುತ್ತಿತ್ತು. ನಮ್ಮ ಕೆಲವು ಸಹೋದ್ಯೋಗಿಗಳು ಹಿಂದಿನ ಕೆಲಸದಿಂದ ಚೆನ್ನಾಗಿ ಪರಿಚಿತರಾಗಿದ್ದ ವೈಫಲ್ಯಗಳ ವರ್ಗ ಇದಾಗಿತ್ತು: ಮೆಟಾಸ್ಟೇಬಲ್ ವೈಫಲ್ಯ⁠(ಹೊಸ ಕಿಟಕಿಯಲ್ಲಿ ತೆರೆಯುತ್ತದೆ).

ಸಂಪರ್ಕ ಪೂಲ್ ಕಾರಣವಾಗಿರಬಹುದು ಎಂದು ಶಂಕಿಸಿ, ಗರಿಷ್ಠ ಸಂಪರ್ಕ ಮರುಬಳಕೆ ಅವಧಿಗೆ ಮಿತಿ ಹಾಕಿ ಪರೀಕ್ಷಿಸಿದೆವು. ಇದರಿಂದ ಕುಸಿತ ನಿಜಕ್ಕೂ ಸೀಮಿತವಾಗಿ, ನಮ್ಮ ತನಿಖೆಯ ದಿಕ್ಕು ಸರಿಯೆಂದು ದೃಢಪಟ್ಟಿತು. ಹೆಚ್ಚಿನ ತನಿಖೆಯಲ್ಲಿ Python ನ aiohttp TCPConnector ಡೀಫಾಲ್ಟ್ ಆಗಿ LIFO ಸಂಪರ್ಕ ಮರುಬಳಕೆ ಮಾಡುತ್ತದೆ ಎಂದು ಕಂಡುಬಂದಿದೆ: ಮುಂದಿನ ವಿನಂತಿಗೆ ಇತ್ತೀಚೆಗೆ ಮರಳಿದ ಸಂಪರ್ಕವನ್ನು ಆಯ್ಕೆ ಮಾಡಲಾಗುತ್ತದೆ. ಸಾಮಾನ್ಯವಾಗಿ ಇದು ಸಮಂಜಸ ಪೂರ್ವನಿಯೋಜನೆ: ಇತ್ತೀಚಿನ ಸಂಪರ್ಕಗಳನ್ನು ಮರುಬಳಸುವುದರಿಂದ ಹಠಾತ್ ಟ್ರಾಫಿಕ್ ನಿಭಾಯಿಸಲು ರಚಿಸಿದ ಹೆಚ್ಚುವರಿ ಸಂಪರ್ಕಗಳು ನಿಷ್ಕ್ರಿಯ ಸಮಯಮಿತಿ ತಲುಪುತ್ತವೆ; ಹೀಗಾಗಿ ಅವುಗಳನ್ನು ಉಳಿಸಿಕೊಳ್ಳುವ ಹೆಚ್ಚುವರಿ ಹೊರೆ ಕಡಿಮೆಯಾಗುತ್ತದೆ. ಈ ಸಂದರ್ಭದಲ್ಲಿ ಅದು ನಮಗೆ ಮೆಟಾಸ್ಟೇಬಲ್ ವೈಫಲ್ಯ ಉಂಟುಮಾಡಿತು. ವಿನಂತಿಗಳ ಹಠಾತ್ ಏರಿಕೆಯ ಸಮಯದಲ್ಲಿ, ನಿಧಾನ ಮತ್ತು ಓವರ್‌ಲೋಡ್ ಆದ ಸರ್ವರ್‌ಗಳಿಗೆ ಹೋದ ವಿನಂತಿಗಳು ಸಂಪರ್ಕಗಳನ್ನು ಪೂಲ್‌ಗೆ ತಡವಾಗಿ ಹಿಂತಿರುಗಿಸಿವೆ. ಹೀಗಾಗಿ ನಂತರದ ವಿನಂತಿಗಳು ಅವನ್ನೇ ಹೆಚ್ಚಾಗಿ ಆಯ್ದು, ಈಗಾಗಲೇ ಹೆಣಗುತ್ತಿದ್ದ ಪಾಡ್‌ಗಳ ಮೇಲೆ ಕ್ರಮೇಣ ಹೆಚ್ಚು ಟ್ರಾಫಿಕ್ ಕೇಂದ್ರೀಕರಿಸಿದವು. FIFO ಮರುಬಳಕೆ ಮಾಡುವಂತೆ ಸಂಪರ್ಕ ಪೂಲ್‌ಗೆ ತಿದ್ದುಪಡಿ ಮಾಡಿದಾಗ ಈ ಪ್ರತಿಕ್ರಿಯಾ ಚಕ್ರ ಮುರಿಯಿತು ಮತ್ತು ನಮ್ಮ ಸ್ಥಿರ ಸ್ಥಿತಿಯ ವಿನಂತಿ ವ್ಯತ್ಯಾಸವೂ ಕಡಿಮೆಯಾಯಿತು.

ಇಂದು OpenAI ಮೂಲಸೌಕರ್ಯದಾದ್ಯಂತ ಸಂಪರ್ಕ ಪೂಲಿಂಗ್ ಮತ್ತು ಸರ್ವರ್ ಹೊರೆಯನ್ನು ಉತ್ತಮವಾಗಿ ಪರಿಗಣಿಸುವ ಸಮತೋಲನ ಕಾರ್ಯತಂತ್ರಗಳಿಗಾಗಿ ಮುಖ್ಯವಾಗಿ Istio ಮತ್ತು Envoy ಅನ್ನು ಅವಲಂಬಿಸಿ, ಈ ಸಮಸ್ಯೆಯನ್ನು ಸಂಪೂರ್ಣವಾಗಿ ತಪ್ಪಿಸುತ್ತೇವೆ.

ಕಡಿಮೆ asyncio ವಿಳಂಬಕ್ಕಾಗಿ ಹೊಂದಿಸಿ, ಇಷ್ಟೊಂದು Python ಪ್ರಕ್ರಿಯೆಗಳನ್ನು ಹೊಂದಿರುವುದರ ಒಂದು ಅಡ್ಡಪರಿಣಾಮವೆಂದರೆ ಅಪಾರ ಸಂಖ್ಯೆಯ ಸಂಪರ್ಕಗಳಿಂದ ಕೆಳಹಂತದ ಅವಲಂಬನೆಗಳನ್ನು ಸುಲಭವಾಗಿ ಮುಳುಗಿಸಬಹುದು (ಇದನ್ನು “ಥಂಡರಿಂಗ್ ಹರ್ಡ್” ಎಂದು ಕರೆಯಲಾಗುತ್ತದೆ).

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

ಸಂಪರ್ಕಗಳ ಒಗ್ಗೂಡಿಕೆಯನ್ನು ಗರಿಷ್ಠಗೊಳಿಸಲು Envoy ಮೇಲೆಯೂ ಅವಲಂಬಿಸಿದ್ದೇವೆ. ಮಲ್ಟಿಪ್ಲೆಕ್ಸಿಂಗ್ ಪ್ರಯೋಜನ ಪಡೆಯಲು Pythonನ HTTP/1 ಸಂಪರ್ಕಗಳನ್ನು HTTP/2ಗೆ ಉನ್ನತೀಕರಿಸಿ, ನಂತರ ಆ ಸಂಪರ್ಕಗಳನ್ನು ಪೂಲ್ ಮಾಡಿ ಅವುಗಳ ಜೀವಿತಾವಧಿ ವಿಸ್ತರಿಸಲು ಅದನ್ನು ಬಳಸುತ್ತೇವೆ. ಪ್ರತಿ ಸ್ವತಂತ್ರ Python ಪ್ರಕ್ರಿಯೆಯಲ್ಲಿ ಕಡಿಮೆ ಪರಿಣಾಮಕಾರಿಯಾಗಬಹುದಾದ ದರ ಮಿತಿಗಳು ಮತ್ತು ಸರ್ಕ್ಯೂಟ್ ಬ್ರೇಕರ್‌ಗಳನ್ನು ಜಾರಿಗೊಳಿಸಲು Envoy ನಮಗೆ ಕೇಂದ್ರೀಯ ಸ್ಥಳವನ್ನೂ ನೀಡುತ್ತದೆ.

Python ಅನ್ನು ಇಷ್ಟು ಪ್ರಮಾಣಕ್ಕೆ ಸ್ಕೇಲ್ ಮಾಡಲು ಸಾಧ್ಯವಾದ ಒಂದು ಕಾರಣ, ವಿನಂತಿಯ ವೆಚ್ಚವನ್ನು ಊಹಿಸಬಹುದಾಗಿಡುವ Habitat ನ ಸೀಮಿತ API. ದೊಡ್ಡ ಟೇಬಲ್ ಸ್ಕ್ಯಾನ್‌ಗಳು ಅಥವಾ ಹಲವು ಟೇಬಲ್‌ಗಳ ನಡುವಿನ ಜೋಡಣೆಗಳಿಗೆ ಕಾರಣವಾಗಬಹುದಾದ ಅನಿಯಂತ್ರಿತ SQL ಪ್ರಶ್ನೆಗಳನ್ನು ಕ್ಲೈಂಟ್‌ಗಳು ರಚಿಸಲು ಬಿಡುವ ಬದಲು, Habitat ಸರಳ NoSQL API ಒದಗಿಸುತ್ತದೆ. ಶಕ್ತಿಯುತ API ಇಲ್ಲದಿರುವುದು Habitat ವಿನ್ಯಾಸದಲ್ಲಿ ಉದ್ದೇಶಪೂರ್ವಕ ರಾಜಿಯಾಗಿದೆ.

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

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

ಇಲ್ಲಿನ ಸಮಸ್ಯೆ ವೆಚ್ಚದ ಅಸಮತೋಲನ: ಕಾರ್ಯಗತಗೊಳಿಸಲು ದುಬಾರಿ ಮತ್ತು ಕಷ್ಟವಾದ SQL ಪ್ರಶ್ನೆಗಳನ್ನು ಬರೆಯುವುದು ಅಗ್ಗ ಮತ್ತು ಸುಲಭವಾಗಿದೆ. Habitat ನಲ್ಲಿ ಇದನ್ನು ತಪ್ಪಿಸಿ, ದುಬಾರಿ ಪ್ರಶ್ನೆಗಳು ಕ್ಲೈಂಟ್ ಬದಿಯಲ್ಲೇ ಅತ್ಯಂತ ಸ್ಪಷ್ಟವಾಗಿ ಕಾಣುವಂತೆ ಮಾಡುತ್ತೇವೆ. Habitatಗೆ ಅತಿಯಾದ ಹೊರೆ ತರುವ ಮಿತಿಯಿಲ್ಲದ ಪ್ರಶ್ನೆಗಳಿಲ್ಲ. ಸಂಕೀರ್ಣ ಜೋಡಣೆಗಳು ಮತ್ತು ಗ್ರಾಫ್ ಸಂಚರಣೆಗಳಿಗೆ ಉತ್ಪನ್ನ ತಂಡಗಳು ಹೆಚ್ಚಿನ ಕೆಲಸ ಮಾಡಬೇಕಾಗುತ್ತದೆ; ಇದು ಒಟ್ಟಾರೆ ಹೆಚ್ಚು ದಕ್ಷ ವಿನ್ಯಾಸಗಳಿಗೆ ಅನುಕೂಲ ಮಾಡುತ್ತದೆ.

TAO⁠(ಹೊಸ ಕಿಟಕಿಯಲ್ಲಿ ತೆರೆಯುತ್ತದೆ) ದಿಂದ ಪ್ರೇರಿತವಾಗಿ, ಕ್ಲೈಂಟ್ ವ್ಯಾಖ್ಯಾನಿಸುವ ಆಬ್ಜೆಕ್ಟ್ ಮತ್ತು ಎಡ್ಜ್ ಪ್ರಕಾರಗಳ ಸುತ್ತ ರೂಪಿಸಿದ NoSQL API ಅನ್ನು Habitat ಒದಗಿಸುತ್ತದೆ. ಕ್ಲೈಂಟ್‌ಗಳು ಆಬ್ಜೆಕ್ಟ್‌ಗಳು, ಎಡ್ಜ್‌ಗಳು ಮತ್ತು ಅವುಗಳ ಪರಸ್ಪರ ಸಂಬಂಧವನ್ನು ಮುಂಚಿತವಾಗಿ ವ್ಯಾಖ್ಯಾನಿಸುತ್ತವೆ; ಆದರೆ ಪ್ರತಿ ಪ್ರಕಾರದ ವಿಷಯವನ್ನಲ್ಲ. ಪರಿಣಾಮವಾಗಿ ಸಿಗುವ ಸಂಬಂಧಗಳು ಗ್ರಾಫ್‌ನಂತಿರುತ್ತವೆ. ಆದರೆ ನಿರ್ದಿಷ್ಟ ಆಬ್ಜೆಕ್ಟ್‌ನ ನೇರ ಎಡ್ಜ್‌ಗಳನ್ನು ಪ್ರಶ್ನಿಸುವುದನ್ನು ಹೊರತುಪಡಿಸಿ, ಸಾಮಾನ್ಯ ಗ್ರಾಫ್ ಸಂಚರಣೆ ಪ್ರಶ್ನೆಗಳನ್ನು Habitat ಬೆಂಬಲಿಸುವುದಿಲ್ಲ.

ಪ್ರತಿ ಆಬ್ಜೆಕ್ಟ್ ಮತ್ತು ಅದರ ಸಂಬಂಧಿತ ಎಡ್ಜ್‌ಗಳು ಸಂಗ್ರಹಣಾ ಮಟ್ಟದ ಒಂದೇ ವಿಭಾಗದಲ್ಲಿರುವಂತೆ ಈ ಗ್ರಾಫ್ ಅನ್ನು ವಿಭಜಿಸುತ್ತೇವೆ. ಆದರೆ ಆಬ್ಜೆಕ್ಟ್‌ಗಳು ಮತ್ತು ಅವುಗಳ ಎಡ್ಜ್‌ಗಳು ಸೂಚಿಸುವ ದೂರದ ಆಬ್ಜೆಕ್ಟ್‌ಗಳನ್ನು ಒಟ್ಟಿಗಿಡಲು ಡೇಟಾಬೇಸ್ ಮಟ್ಟದಲ್ಲಿ ವಿಶೇಷ ಪ್ರಯತ್ನ ಮಾಡುವುದಿಲ್ಲ. ಇದರಿಂದ ಮಾಡೆಲ್ ಅನ್ನು ಸಮತಲ ಸ್ಕೇಲಿಂಗ್‌ಗಾಗಿ ಸುಲಭವಾಗಿ ವಿಭಜಿಸಬಹುದು. ಆದರೆ ಆಬ್ಜೆಕ್ಟ್‌ಗಳ ನಡುವಿನ ಯಾವುದೇ ಹಂತಕ್ಕೆ ಬೇರೆ ಪ್ರದೇಶಗಳಲ್ಲಿ ಸಂಗ್ರಹಿಸಲಾದ ಎರಡು ಸಂಪೂರ್ಣ ವಿಭಿನ್ನ Azure Cosmos DB ಖಾತೆಗಳಿಂದ ಡೇಟಾ ತರಬೇಕಾಗಬಹುದು; ಹೀಗಾಗಿ ಗ್ರಾಫ್ ಸಂಚರಣೆ ಅಸಮರ್ಥವಾಗುತ್ತದೆ.

ಹೆಚ್ಚು ಸಂಕೀರ್ಣ ಪ್ರಶ್ನೆಗಳ ಅಗತ್ಯವಿರುವ ಕ್ಲೈಂಟ್‌ಗಳಿಗೆ Rockset ಮೂಲಕ ಲಭ್ಯವಾಗುವ Habitat ನ ಆಫ್‌ಲೈನ್ ದ್ವಿತೀಯ ನೋಟವನ್ನೂ ಒದಗಿಸುತ್ತೇವೆ. ಆನ್‌ಲೈನ್ ಸಂಗ್ರಹಣೆಯ ಬದಲಾವಣೆಗಳನ್ನು ಪ್ರತ್ಯೇಕ Rockset ನಿದರ್ಶನಗಳಿಗೆ ಬಹುತೇಕ ನೈಜ ಸಮಯದಲ್ಲಿ ಹರಿಸಲು ಬದಲಾವಣೆ ಡೇಟಾ ಸೆರೆಹಿಡಿಯುವಿಕೆ (CDC) ಬಳಸುತ್ತೇವೆ. ಪ್ರತಿ ಕ್ಲೈಂಟ್ ತಂಡವೂ ತನ್ನ ಸಂಕೀರ್ಣ ಪ್ರಶ್ನೆಗಳ ಅಗತ್ಯಕ್ಕೆ ತಕ್ಕಂತೆ ತನ್ನದೇ Rockset ನಿದರ್ಶನವನ್ನು ಸ್ಕೇಲ್ ಮಾಡುವ ಹೊಣೆ ಹೊರುತ್ತದೆ.

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

Python ಮರುಬರವಣಿಗೆಯನ್ನು ಒಂದು ವರ್ಷ ಮುಂದೂಡಿದ್ದರಿಂದ, ಅತಿವೇಗದ ಬೆಳವಣಿಗೆಯ ಸಮಯದಲ್ಲಿ ಹೆಚ್ಚು ತುರ್ತು ಮತ್ತು ಪರಿಣಾಮಕಾರಿ ಸವಾಲುಗಳತ್ತ ಗಮನಹರಿಸಲು ಸಾಧ್ಯವಾಯಿತು. ಪ್ಲಾಟ್‌ಫಾರ್ಮ್ ಪ್ರೌಢವಾಗುತ್ತಾ ಬೆಳವಣಿಗೆ ಇನ್ನಷ್ಟು ವೇಗಗೊಂಡಿತು. ಕೋರ್ ಸಂಖ್ಯೆಯಲ್ಲಿ ಇದು OpenAI ನ ಎರಡನೇ ಅತಿ ದೊಡ್ಡ ಸೇವೆಯಾಗಿದ್ದು, Envoy ವ್ಯಾಪ್ತಿಯಲ್ಲಿ ನಾಲ್ಕನೆಯದಾಗಿದ್ದರಿಂದ, ಕೊನೆಗೂ Python ನಿಂದ ಮುಂದುವರಿಯುವ ಸಮಯ ಬಂದಿತ್ತು. ತನ್ನ ಗರಿಷ್ಠ ಹಂತದಲ್ಲಿ Python ಪ್ರತಿ ಸೆಕೆಂಡ್‌ಗೆ 2 ಕೋಟಿಗೂ ಹೆಚ್ಚು ವಿನಂತಿಗಳನ್ನು ನಿರ್ವಹಿಸಲು ನೆರವಾಯಿತು.

2026 ರ ಎರಡನೇ ತ್ರೈಮಾಸಿಕದಲ್ಲಿ ಕೇವಲ 2 ಎಂಜಿನಿಯರ್‌ಗಳು, Codex ಮತ್ತು GPT‑5.5 ನೆರವಿನಿಂದ ಸಂಪೂರ್ಣ ಸೇವೆಯನ್ನು Rust ನಲ್ಲಿ ಮರುಬರೆಯಲು ಸಾಧ್ಯವಾಯಿತು. ಈ ಹೊಸ Rust ಸೇವೆಯು ಈಗ ನಮ್ಮ ಉತ್ಪಾದನಾ ವಿನಂತಿಗಳಲ್ಲಿ 95% ನಿರ್ವಹಿಸುತ್ತಿದೆ. ಮುಂದಿನ ಕೆಲವು ವಾರಗಳಲ್ಲಿ Python ಅನ್ನು ಸಂಪೂರ್ಣವಾಗಿ ಸ್ಥಗಿತಗೊಳಿಸುತ್ತೇವೆ. Python ಆವೃತ್ತಿಗಿಂತ Rust ಸೇವೆಯು CPU ಬಳಕೆಯಲ್ಲಿ 6 ಪಟ್ಟು ಮತ್ತು ಮೆಮೊರಿ ಬಳಕೆಯಲ್ಲಿ 15 ಪಟ್ಟು ಹೆಚ್ಚು ದಕ್ಷವಾಗಿದ್ದು, ಸರಾಸರಿ ಹಾಗೂ ಕೊನೆಯ ಅಂಚಿನ ವಿಳಂಬಗಳೂ ಗಣನೀಯವಾಗಿ ಕಡಿಮೆ ಎಂದು ನಮ್ಮ ಡೇಟಾ ತೋರಿಸುತ್ತದೆ. ಭವಿಷ್ಯದ ಬ್ಲಾಗ್‌ನಲ್ಲಿ ಇನ್ನಷ್ಟು ಕಲಿಕೆಗಳನ್ನು ಹಂಚಿಕೊಳ್ಳಲು ಯೋಜಿಸಿದ್ದೇವೆ.

Python ಮತ್ತು ಈಗ Rust ಸೇವೆಯು Habitat ನ ಒಂದು ಭಾಗ ಮಾತ್ರ ಆಘಿದೆ. 100 ಕೋಟಿಗೂ ಹೆಚ್ಚಿನ ChatGPT ಬಳಕೆದಾರರಿಗೆ ಸೇವೆ ನೀಡಲು ನಮ್ಮ ಆನ್‌ಲೈನ್ ಸಂಗ್ರಹಣೆಯನ್ನು ಹೇಗೆ ವೇಗವಾಗಿ ಸ್ಕೇಲ್ ಮಾಡಿದೆವು ಎಂಬ ಸರಣಿಯ ಎರಡನೇ ಭಾಗದಲ್ಲಿ, ಸಂಗ್ರಹಣಾ ಪದರ ಹಾಗೂ Habitat 500 ಪೆಟಾಬೈಟ್‌ಗೂ ಹೆಚ್ಚು ಡೇಟಾ ಮತ್ತು ಪ್ರತಿ ಸೆಕೆಂಡ್‌ಗೆ 7 ಕೋಟಿಗೂ ಹೆಚ್ಚು ವಿನಂತಿಗಳನ್ನು ಹೇಗೆ ನಿರ್ವಹಿಸುತ್ತದೆ ಎಂಬುದನ್ನು ಚರ್ಚಿಸುತ್ತೇವೆ.

ಅತ್ಯಾಧುನಿಕ ಪ್ರಮಾಣದ OLTP ವ್ಯವಸ್ಥೆಗಳಲ್ಲಿ ಕೆಲಸ ಮಾಡಲು ಬಯಸಿದರೆ ಮತ್ತು ಇಂತಹ ಎಂಜಿನಿಯರಿಂಗ್‌ನಲ್ಲಿ ಆಸಕ್ತಿಯಿದ್ದರೆ, ನಮ್ಮ ತಂಡದಲ್ಲಿನ ಈ ಖಾಲಿ ಹುದ್ದೆಯನ್ನು ನೋಡಿ⁠.