CobbleDB: ಕಡಿಮೆ ಲೇಟೆನ್ಸಿ ಮತ್ತು ವೆಚ್ಚಕ್ಕಾಗಿ AI ಸರ್ಚ್ ಸ್ಟೋರೇಜ್ ಅನ್ನು ಮರುನಿರ್ಮಾಣ ಮಾಡಲಾಗುತ್ತಿದೆ

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

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

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

ಹೊಸ ಆಂತರಿಕ ಕೋಡಿಂಗ್ ಏಜೆಂಟ್ ಸಮೂಹದಿಂದ ಸಹಾಯದೊಂದಿಗೆ, ನಾವು ಈ ಲೇಯರ್ ಅನ್ನು ಕೀ-ವ್ಯಾಲ್ಯೂ ಹಾಟ್ ಸ್ಟೋರ್ ಆದ CobbleDB ಸುತ್ತಲೂ ಮರುನಿರ್ಮಾಣ ಮಾಡಿದ್ದೇವೆ, ಇದು ಡ್ಯುರೇಬಲ್ ಡಾಕ್ಯುಮೆಂಟ್ ಸ್ಥಿತಿ ಮತ್ತು ಪಬ್ಲಿಷಿಂಗ್‌ಗಾಗಿ Pillar ನಿಂದ ಹಾಗೂ ಬ್ಯಾಚ್ ಮಾಡಿದ ಅಪ್‌ಡೇಟ್‌ಗಳಿಗಾಗಿ Lorry ನಿಂದ ಬೆಂಬಲಿಸಲ್ಪಟ್ಟಿದೆ. ಮರುವಿನ್ಯಾಸವು ಡಾಕ್ಯುಮೆಂಟ್ ಪ್ರೊಸೆಸಿಂಗ್ ಅನ್ನು ಹಾಟ್-ಸ್ಟೋರ್ ಇಂಜೆಷನ್‌ನಿಂದ ಪ್ರತ್ಯೇಕಿಸುತ್ತದೆ ಮತ್ತು ನಮ್ಮ ವರ್ಕ್‌ಲೋಡ್‌ಗೆ ಸರ್ವಿಂಗ್ ಅನ್ನು ಟ್ಯೂನ್ ಮಾಡಲು ನಮಗೆ ಅನುಮತಿಸುತ್ತದೆ. ಪ್ರೊಡಕ್ಷನ್ ಮುಂಚಿನ ಮತ್ತು ನಂತರದ ಅಳತೆಗಳು ಸರಿಸುಮಾರು 5× ಕಡಿಮೆ ಬ್ಯಾಚ್-ರೀಡ್ ಲೇಟೆನ್ಸಿಯನ್ನು ತೋರಿಸುತ್ತವೆ, ಮತ್ತು ನಮ್ಮ ಆಂತರಿಕ ವೆಚ್ಚದ ಮಾದರಿಯು DynamoDB ಗೆ ಸಂಬಂಧಿಸಿದಂತೆ ಕನಿಷ್ಠ 20% ಉಳಿತಾಯವನ್ನು ಅಂದಾಜು ಮಾಡುತ್ತದೆ.

AI-ನೇಟಿವ್ ಸರ್ಚ್‌ಗಾಗಿ ಸ್ಟೋರೇಜ್ ಇನ್‌ಫ್ರಾಸ್ಟ್ರಕ್ಚರ್

ಕ್ಲಾಸಿಕ್ ಸರ್ಚ್ ಸ್ಟ್ಯಾಕ್ ಅನ್ನು ಭಾಷಾ ಮಾದರಿಗಾಗಿ ಅಲ್ಲ, ಮಾನವ ಓದುಗರಿಗಾಗಿ ನಿರ್ಮಿಸಲಾಗಿದೆ. ಆ ವ್ಯತ್ಯಾಸವು ವೆಬ್ ಕಂಟೆಂಟ್ ಅನ್ನು ಸಿದ್ಧಪಡಿಸಲು, ಸ್ಟೋರ್ ಮಾಡಲು ಮತ್ತು ಸರ್ವ್ ಮಾಡಲು ಸಿಸ್ಟಮ್‌ಗೆ ಅಗತ್ಯವಿರುವ ಗ್ರ್ಯಾನ್ಯುಲಾರಿಟಿಯನ್ನು ಬದಲಾಯಿಸುತ್ತದೆ.

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

ಎರಡು ವಿಭಿನ್ನ ಕಾರ್ಯಪ್ರವಾಹಗಳು

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

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

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

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

ಮ್ಯಾನೇಜ್ಡ್ ಡೇಟಾಬೇಸ್ ಎಲ್ಲಿ ವಿಫಲಗೊಳ್ಳುತ್ತದೆ

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

ಎರಡನೆಯದಾಗಿ, ಬಳಕೆ-ಆಧಾರಿತ ಬೆಲೆಯು ಓದಲಾದ ಅಥವಾ ಬರೆಯಲಾದ ಪ್ರತಿ ಬೈಟ್‌ಗೆ ಶುಲ್ಕ ವಿಧಿಸುತ್ತದೆ. ಒಂದೇ ಸರ್ಚ್ API ವಿನಂತಿಯು ನಾವು ಪಡೆದುಕೊಳ್ಳಬೇಕಾದ ಪೇಜ್‌ಗಳಿಗೆ ಅನುರೂಪವಾಗಿರುವ 100-120 ಕೀಗಳನ್ನು ಹೊಂದಿದೆ. ಡೇಟಾ ಮರುಪಡೆಯುವಿಕೆ ಪ್ರಕ್ರಿಯೆಯು ವಿನಂತಿಯನ್ನು ಪ್ರತಿ ಐಟಂನ ಸರಾಸರಿ ಗಾತ್ರವು ಸುಮಾರು 50 KB ಇರುವ 10-20 ಪೇಜ್ ಕೀಗಳ ಸಣ್ಣ ಬ್ಯಾಚ್‌ಗಳಾಗಿ ವಿಭಜಿಸುತ್ತದೆ. ಆ ರೆಕಾರ್ಡ್‌ಗಳನ್ನು ಪದೇ ಪದೇ ಓದುವುದರಿಂದ ಗಣನೀಯ ಸಾಮರ್ಥ್ಯವು ಬಳಕೆಯಾಯಿತು, ಆದರೆ ನಿರಂತರ ಕ್ರಾಲ್‌ಗಳು ಹಾಗೂ ಚಂಕಿಂಗ್ ಅಥವಾ ಎಂಬೆಡಿಂಗ್ ಮಾದರಿಗಳಲ್ಲಿನ ಬದಲಾವಣೆಗಳು ಹೆಚ್ಚಿನ ರೈಟ್‌ಗಳನ್ನು ಉತ್ಪಾದಿಸಿದವು. ಅರ್ಥಶಾಸ್ತ್ರವು API ಕೀಲುಗಳ ಸಂಖ್ಯೆಯನ್ನು ಮಾತ್ರವಲ್ಲದೆ ರೆಕಾರ್ಡ್‌ಗಳ ಗಾತ್ರ ಮತ್ತು ಆವರ್ತನವನ್ನೂ ಅವಲಂಬಿಸಿದೆ.

ಎರಡನೆಯದಾಗಿ, ಕಾರ್ಯಕ್ಷಮತೆ ಟ್ಯೂನಿಂಗ್‌ಗಾಗಿ ನಮಗೆ ಅಗತ್ಯವಿರುವ ನಮ್ಯತೆ ಮ್ಯಾನೇಜ್ಡ್ ಸೇವೆಯಲ್ಲಿ ಇಲ್ಲ. ನಮಗೆ ಅಗತ್ಯವಿರುವ ಕಾರ್ಯಾಚರಣೆಯು ಕಿರಿದಾಗಿತ್ತು: ಪೇಜ್ ಐಡೆಂಟಿಫೈಯರ್‌ಗಳ ಬ್ಯಾಚ್ ಅನ್ನು ನೀಡಿದರೆ, ಅವುಗಳ ಪ್ರಿಪೇರ್ಡ್ ಕಂಟೆಂಟ್‌ಗಳನ್ನು ತ್ವರಿತವಾಗಿ ಹಿಂತಿರುಗಿಸಿ. ಯಾವ ಯಂತ್ರವು ಪಾರ್ಟಿಷನ್ ಅನ್ನು ಹೊಂದಿದೆ, ಅದರ ಕ್ಯಾಶ್‌ಗೆ ಎಷ್ಟು ಮೆಮೊರಿಯನ್ನು ಮೀಸಲಿಡಲಾಗಿದೆ ಮತ್ತು ಯಾವ ಪ್ರತಿನಿಧಿಯು ವಿನಂತಿಯನ್ನು ನಿರ್ವಹಿಸಿದೆ ಎಂಬುದರ ಮೇಲೆ ನಮಗೆ ನಿಯಂತ್ರಣ ಬೇಕಿತ್ತು. ಕ್ಯಾಶ್ ಮಾಡದ ರೀಡ್, ಕ್ರಾಸ್-ಝೋನ್ ಹಾಪ್ ಅಥವಾ ನಿಧಾನವಾದ ಪ್ರತಿನಿಧಿಯು ಸಂಪೂರ್ಣ ಬ್ಯಾಚ್ ಅನ್ನು ವಿಳಂಬಗೊಳಿಸಬಹುದಾದ್ದರಿಂದ ಆ ನಿಯಂತ್ರಣಗಳು ಮುಖ್ಯ2ವಾಗಿವೆ. DynamoDB API ಹಿಂದೆ ತನ್ನದೇ ಆದ ಸ್ಟೋರೇಜ್ ಮತ್ತು ಪ್ರತಿನಿಧಿ ನಡವಳಿಕೆಯನ್ನು ನಿರ್ವಹಿಸುತ್ತದೆ. ನಮಗೆ ಸೇವೆಯನ್ನು ಕಾನ್ಫಿಗರ್ ಮಾಡಲು ಸಾಧ್ಯವಾಯಿತು, ಆದರೆ ನಮ್ಮ ವರ್ಕ್‌ಲೋಡ್ ಸುತ್ತಲೂ ಅದರ ಆಂತರಿಕ ಪ್ಲೇಸ್‌ಮೆಂಟ್, ಸ್ಟೋರೇಜ್-ಎಂಜಿನ್ ಕ್ಯಾಶ್‌ಗಳು ಅಥವಾ ಪ್ರತಿನಿಧಿ-ಆಯ್ಕೆ ಪಾಲಿಸಿಯನ್ನು ಟ್ಯೂನ್ ಮಾಡಲು ನಮಗೆ ಸಾಧ್ಯವಾಗಲಿಲ್ಲ.

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

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

ಪ್ರತ್ಯೇಕ ಡಾಕ್ಯುಮೆಂಟ್ ಸ್ಥಿತಿ, ಅಪ್‌ಡೇಟ್ ಡೆಲಿವರಿ ಮತ್ತು ಸರ್ವಿಂಗ್

ಹೊಸ ಆರ್ಕಿಟೆಕ್ಚರ್ ಪ್ರತಿ ಜವಾಬ್ದಾರಿಯನ್ನು ವಿಭಿನ್ನ ಘಟಕಕ್ಕೆ ನಿಯೋಜಿಸುತ್ತದೆ. Pillar ಯು ಡ್ಯುರೇಬಲ್ ಡಾಕ್ಯುಮೆಂಟ್ ಸ್ಥಿತಿಯನ್ನು ನಿರ್ವಹಿಸುತ್ತದೆ ಮತ್ತು ಏನು ಪ್ರಕಟಿಸಬೇಕು ಎಂಬುದನ್ನು ನಿರ್ಧರಿಸುತ್ತದೆ. Lorry ಯು ಆ ಎಕ್ಸ್‌ಪೋರ್ಟ್‌ಗಳನ್ನು ಪಾರ್ಟಿಷನ್ ಮಾಡಿದ ಬ್ಯಾಚ್‌ಗಳಾಗಿ ಪರಿವರ್ತಿಸುತ್ತದೆ. CobbleDB ಯು ಬ್ಯಾಚ್‌ಗಳನ್ನು ಇಂಜೆಸ್ಟ್ ಮಾಡುತ್ತದೆ ಮತ್ತು ಪೇಜ್ ಕೀ ಮೂಲಕ ಪ್ರಿಪೇರ್ಡ್ ರೆಕಾರ್ಡ್‌ಗಳನ್ನು ಸರ್ವ್ ಮಾಡುತ್ತದೆ.

ವಿಸ್ತರಿಸಿ

CobbleDB: ಟ್ಯೂನಬಲ್ ರೀಡ್ ಪಾತ್

CobbleDB ಎಂಬುದು ಕ್ವೆರಿ ಸಮಯದಲ್ಲಿ ಪ್ರಿಪೇರ್ಡ್ ರೆಕಾರ್ಡ್‌ಗಳನ್ನು ಸರ್ವ್ ಮಾಡಲು ಆಪ್ಟಿಮೈಸ್ ಮಾಡಲಾದ ನಮ್ಮ ಹಾಟ್ ಸ್ಟೋರ್ ಆಗಿದೆ. ಇದು ವಿತರಿತ ಕೀ-ವ್ಯಾಲ್ಯೂ ಸ್ಟೋರ್ ಆಗಿದೆ: ಕೀಗಳು ಪೇಜ್ ಐಡೆಂಟಿಫೈಯರ್‌ಗಳಾಗಿವೆ (ಹ್ಯಾಶ್ ಮಾಡಿದ URL ಗಳು), ಮತ್ತು ವ್ಯಾಲ್ಯೂಗಳು ಪೇಜ್‌ನ ಪ್ರೊಸೆಸ್ ಮಾಡಿದ ಪ್ರತಿನಿಧಿತ್ವವಾಗಿವೆ (ಅವುಗಳ ಪ್ರಿ-ಚಂಕ್ ಮಾಡಿದ ಪ್ಯಾಸೇಜ್‌ಗಳು ಮತ್ತು ಪ್ರತಿ ಚಂಕ್‌ನ ವೆಕ್ಟರ್ ಎಂಬೆಡಿಂಗ್‌ಗಳು).

ಪ್ರಮುಖ ಬದಲಾವಣೆಯೆಂದರೆ ಸ್ಟೋರೇಜ್ ಕಾನ್ಫಿಗರೇಶನ್ ಮೇಲೆ ನಮ್ಮ ನಿಯಂತ್ರಣ.

ಡೇಟಾವನ್ನು ವಿಭಜಿಸಿ ಡೇಟಾ ನೋಡ್‌ಗಳಲ್ಲಿ ಹಂಚಲಾಗುತ್ತದೆ. ಈ ವಿತರಿತ ಫಾರ್ಮ್ಯಾಟ್ ಡೇಟಾಬೇಸ್ ಪ್ರೊಸೆಸ್ ಮಾಡಿದ ಪೇಜ್‌ಗಳ ಅಗಾಧವಾದ ಕಾರ್ಪಸ್ ಅನ್ನು ಸರಿಹೊಂದಿಸಲು ಅಡ್ಡಡ್ಡಲಾಗಿ (horizontally) ಸ್ಕೇಲ್ ಮಾಡಬಹುದು ಎಂದು ಖಚಿತಪಡಿಸುತ್ತದೆ. ಪ್ರತಿ ಪಾರ್ಟಿಷನ್ ಮೂರು ಬೇರೆ ಬೇರೆ ನೋಡ್‌ಗಳಲ್ಲಿ ಮೂರು ಪ್ರತಿನಿಧಿಗಳನ್ನು ಹೊಂದಿದೆ; ಒಂದು ಕಾಪಿ ಲಭ್ಯವಿಲ್ಲದಿದ್ದರೆ, ಉಳಿದವುಗಳು ರೀಡ್‌ಗಳನ್ನು ಸರ್ವ್ ಮಾಡುವುದನ್ನು ಮುಂದುವರಿಸಬಹುದು.

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

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

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

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

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

ವಿಸ್ತರಿಸಿ

Pillar ಮತ್ತು Lorry: ಡ್ಯುರೇಬಲ್ ರೈಟ್ ಪಾತ್

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

Pillar ಅನ್ನು YTsaurus ಬೆಂಬಲಿಸುತ್ತದೆ. ಇದು ಪೇಜ್ ಘಟಕಗಳನ್ನು (ಮೆಟಾಡೇಟಾ, ಚಂಕ್‌ಗಳು ಮತ್ತು ಎಂಬೆಡಿಂಗ್‌ಗಳಂತಹವು) ಪ್ರತ್ಯೇಕ YTsaurus ಟೇಬಲ್ ಫ್ಯಾಮಿಲಿಗಳಲ್ಲಿ ಸ್ಟೋರ್ ಮಾಡುತ್ತದೆ. ಇದು ಚಂಕ್‌ಗಳು ಮತ್ತು ಎಂಬೆಡಿಂಗ್‌ಗಳ ವರ್ಷನ್‌ಗಳನ್ನು ಸಹ ಟ್ರ್ಯಾಕ್ ಮಾಡುತ್ತದೆ, ಇದರಿಂದಾಗಿ ಮೂಲ ಮಾದರಿಗಳು ಬದಲಾಗಲು ಅನುವು ಮಾಡಿಕೊಡಲು ಒಂದರ ಮೇಲೊಂದನ್ನು ಓವರ್‌ರೈಟ್ ಮಾಡದೆ ಅನೇಕ ಪ್ರತಿನಿಧಿತ್ವಗಳು ಒಟ್ಟಿಗೆ ಅಸ್ತಿತ್ವದಲ್ಲಿರಬಹುದು. Pillar ಮತ್ತು YTsaurus ಅಗ್ಗದ HDD ಸ್ಟೋರೇಜ್ ಅನ್ನು ಬಳಸುವುದರಿಂದ, ನಾವು ಹಿಂದೆ DynamoDB ಯಲ್ಲಿ ಸ್ಟೋರ್ ಮಾಡಿದ್ದಕ್ಕಿಂತ ಹೆಚ್ಚಿನ ಡಾಕ್ಯುಮೆಂಟ್‌ಗಳನ್ನು ಸ್ಟೋರ್ ಮಾಡಬಹುದು.

Pillar ಯು ಉಪವಿಭಾಗಗಳನ್ನು ಟ್ರ್ಯಾಕ್ ಮಾಡುತ್ತದೆ, ಅಥವಾ ತಾಜಾ ಪೇಜ್‌ಗಳು ಅಥವಾ ಹೆಚ್ಚಿನ ಮೌಲ್ಯದ ಪೇಜ್‌ಗಳಂತಹ ಪೇಜ್‌ಗಳ ಪಾಲಿಸಿ-ವ್ಯಾಖ್ಯಾನಿತ ಗುಂಪುಗಳನ್ನು ಟ್ರ್ಯಾಕ್ ಮಾಡುತ್ತದೆ. ಉಪವಿಭಾಗದ ಸದಸ್ಯತ್ವವು ಯಾವ ಅಪ್‌ಡೇಟ್‌ಗಳನ್ನು CobbleDB ನಂತಹ ಡೌನ್‌ಸ್ಟ್ರೀಮ್ ಘಟಕಗಳಿಗೆ ರವಾನಿಸಬೇಕು ಎಂಬುದನ್ನು ನಿರ್ಧರಿಸುತ್ತದೆ. CobbleDB ಹೆಚ್ಚು ದುಬಾರಿಯಾದ NVMe ಸ್ಟೋರೇಜ್ ಅನ್ನು ಬಳಸುತ್ತದೆ, ಆದ್ದರಿಂದ ನಾವು ಸರ್ಚ್ ಫಲಿತಾಂಶಗಳಲ್ಲಿ ಬಳಸಲು ಬಯಸುವ ಡಾಕ್ಯುಮೆಂಟ್‌ಗಳನ್ನು ಮಾತ್ರ ಎಕ್ಸ್‌ಪೋರ್ಟ್ ಮಾಡುತ್ತೇವೆ. ಪೇಜ್‌ನ ಕಂಟೆಂಟ್‌ಗಳು ಅಪ್‌ಡೇಟ್ ಆದಾಗ, ಅಥವಾ ಅದನ್ನು ಉಪವಿಭಾಗಕ್ಕೆ ಸೇರಿಸಿದಾಗ ಅಥವಾ ತೆಗೆದುಹಾಕಿದಾಗ, ಅನುಗುಣವಾದ ಎಕ್ಸ್‌ಪೋರ್ಟ್ ಕೆಲಸವನ್ನು ಕ್ಯೂ ಮಾಡುವ ಜವಾಬ್ದಾರಿ Pillar ಗೆ ಇರುತ್ತದೆ.

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

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

Lorry ಮತ್ತು Cobble ನಡುವೆ, ಹೆಚ್ಚುವರಿ ಪ್ರೋಟೋಕಾಲ್ ಡೇಟಾ ಪ್ಲೇನ್ (S3) ಅನ್ನು ಕಂಟ್ರೋಲ್ ಪ್ಲೇನ್‌ನಿಂದ ಪ್ರತ್ಯೇಕಿಸುತ್ತದೆ. Lorry ಯು S3 ನಲ್ಲಿ ವಿಶಿಷ್ಟ ಐಡೆಂಟಿಫೈಯರ್ ಅಡಿಯಲ್ಲಿ ಬ್ಯಾಚ್ ಅನ್ನು ಬರೆಯುತ್ತದೆ ಮತ್ತು Cobble ಒಳಗೆ ಬ್ಯಾಚ್ ಅನ್ನು ರಿಜಿಸ್ಟರ್ ಮಾಡುತ್ತದೆ. Cobble ಪಾರ್ಟಿಷನ್ ಪ್ರತಿನಿಧಿಗಳು ಇಂಜೆಸ್ಟ್ ಮಾಡಲು ಮುಂದಿನ S3 ಬ್ಯಾಚ್‌ಗಾಗಿ ಬ್ಯಾಚ್ ಅಥವಾ ಕಂಟ್ರೋಲ್ ಪ್ಲೇನ್ API ಅನ್ನು ಸ್ವತಂತ್ರವಾಗಿ ಕ್ವೆರಿ ಮಾಡುತ್ತಾರೆ ಮತ್ತು ಕಾಲಾನುಕ್ರಮದಲ್ಲಿ ಬ್ಯಾಚ್ ಅಪ್‌ಡೇಟ್‌ಗಳನ್ನು ಅಸಿಂಕ್ರೋನಸ್ ಆಗಿ ಅನ್ವಯಿಸುತ್ತಾರೆ. ಇದರರ್ಥ ನಿಧಾನವಾದ ಅಥವಾ ಚೇತರಿಸಿಕೊಳ್ಳುತ್ತಿರುವ ನೋಡ್ ಸಿಸ್ಟಮ್‌ನ ಉಳಿದ ಭಾಗವನ್ನು ನಿಧಾನಗೊಳಿಸುವ ಬದಲು ತನ್ನದೇ ಆದ ವೇಗದಲ್ಲಿ ಕ್ಯಾಚ್ ಅಪ್ ಆಗಬಹುದು.

ವಿಸ್ತರಿಸಿ

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

ಮೌಲ್ಯಮಾಪನ

5x ವೇಗವಾಗಿ

ಹಾಟ್ ಸ್ಟೋರ್ ಅನ್ನು ಮೈಗ್ರೇಟ್ ಮಾಡಿದ ನಂತರ, ಮಧ್ಯಮ ಬ್ಯಾಚ್-ರೀಡ್ ಲೇಟೆನ್ಸಿ 31.4 ms ನಿಂದ 5.60 ms ಗೆ ಇಳಿಯಿತು. p90 ಯು 56.7 ms ನಿಂದ 9.77 ms ಗೆ ಇಳಿಯಿತು, ಮತ್ತು p99 ಯು 123 ms ನಿಂದ 24.2 ms ಗೆ ಇಳಿಯಿತು. ಮಾದರಿ ವಿನಂತಿಗಳು ಮತ್ತು ಟೈಲ್ ಎರಡರಲ್ಲೂ ಸುಧಾರಣೆಗಳೊಂದಿಗೆ ಅನುಪಾತಗಳು 5.08× ನಿಂದ 5.80× ವರೆಗೆ ಇರುತ್ತವೆ.

ವಿಸ್ತರಿಸಿ

ಈ ಸಂಖ್ಯೆಗಳನ್ನು ಬ್ಯಾಚ್ ಮಾಡಿದ ರೀಡ್‌ಗಳಿಂದ ಪಡೆಯಲಾಗಿದೆ, ಇಲ್ಲಿ ಪ್ರತಿ ಕ್ವೆರಿಯು ಸರಿಸುಮಾರು 10-15 ಕೀಗಳನ್ನು ವಿನಂತಿಸುತ್ತದೆ. ಸರಾಸರಿ ಪೇಲೋಡ್ ಐಟಂ ಗಾತ್ರ 50KB ಆಗಿದೆ. ಯಾವುದೇ ಕ್ಷೀಣತೆಯಿಲ್ಲದೆ ನಾವು 500k rps ವರೆಗಿನ ಲೋಡ್ ಟೆಸ್ಟ್‌ಗಳನ್ನು ರನ್ ಮಾಡಿದ್ದರೂ, ಎರಡೂ ಸಿಸ್ಟಮ್‌ಗಳನ್ನು ಸರಿಸುಮಾರು 200k rps ನಲ್ಲಿ ಕ್ವೆರಿ ಮಾಡಲಾಗಿದೆ.

CobbleDB ನ ಕೊಡುಗೆಯನ್ನು ಪ್ರತ್ಯೇಕಿಸಲು, ಸೆಟಪ್‌ನ ಇತರ ಎಲ್ಲಾ ಅಂಶಗಳನ್ನು ಸ್ಥಿರವಾಗಿರಿಸಲಾಗಿದೆ. ಆದಾಗ್ಯೂ, ಇದು ಕೇವಲ ವೀಕ್ಷಣಾತ್ಮಕ ಮುಂಚಿನ ಮತ್ತು ನಂತರದ ಹೋಲಿಕೆಯಾಗಿದೆ; ಸಿಸ್ಟಮ್‌ಗಳು ಒಂದೇ ರೀತಿಯ ವಿನಂತಿಗಳನ್ನು ನಿಯಂತ್ರಿತ ಪರಿಸ್ಥಿತಿಗಳಲ್ಲಿ ಪೂರೈಸುವ ಬದಲು ವಿಭಿನ್ನ ಸಮಯಗಳಲ್ಲಿ ಲೈವ್ ಪ್ರೊಡಕ್ಷನ್ ಟ್ರಾಫಿಕ್ ಅನ್ನು ಪೂರೈಸಿವೆ. ಆದ್ದರಿಂದ ನಾವು ಸಿಂಥೆಟಿಕ್ ಬೆಂಚ್‌ಮಾರ್ಕ್‌ನಲ್ಲಿ ಎರಡೂ ಸಿಸ್ಟಮ್‌ಗಳ ಕಾರ್ಯಕ್ಷಮತೆಯನ್ನು ಅಳತೆ ಮಾಡಿದ್ದೇವೆ. ಪ್ರೊಡಕ್ಷನ್‌ನಲ್ಲಿ ಕಂಡುಬರುವ ವಿನಂತಿಗಳನ್ನು ಅಂದಾಜು ಮಾಡಲು, ನಾವು 10-15 ಕೀಗಳು ಮತ್ತು 100B ಯಿಂದ 100 KiB ವರೆಗಿನ ವ್ಯಾಲ್ಯೂಗಳ ಬ್ಯಾಚ್‌ಗಳೊಂದಿಗೆ ಎರಡನ್ನೂ ಪ್ರಶ್ನಿಸಿದ್ದೇವೆ.

ವಿಸ್ತರಿಸಿ

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

20% ಅಗ್ಗವಾಗಿದೆ

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

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

AI ಏಜೆಂಟ್‌ಗಳ ಸಮೂಹವು ಅದನ್ನು ನಿರ್ಮಿಸಲು ನಮಗೆ ಹೇಗೆ ಸಹಾಯ ಮಾಡುತ್ತದೆ

CobbleDB ಮತ್ತು ಸುತ್ತಮುತ್ತಲಿನ ಇನ್‌ಫ್ರಾಸ್ಟ್ರಕ್ಚರ್ ಅನ್ನು ನಿರ್ಮಿಸುವುದು ಸುಲಭವೇನಲ್ಲ. CobbleDB ಯ ಕೋರ್ ಡೇಟಾಬೇಸ್ ಮಾತ್ರ ಸರಿಸುಮಾರು 40,000 ಸಾಲುಗಳ Rust ಅನ್ನು ಹೊಂದಿದೆ, ಮತ್ತು ಪ್ರೊಡಕ್ಷನ್ ಮಾಪಕದಲ್ಲಿ ಸರಿಯಾದತೆ ಮತ್ತು ವೈಫಲ್ಯದ ನಡವಳಿಕೆಯನ್ನು ಪರಿಶೀಲಿಸಲು, CobbleDB ಅನ್ನು ಪ್ರೊಸೆಸಿಂಗ್ ಮತ್ತು ಸರ್ವಿಂಗ್ ಪಾತ್‌ಗಳೊಂದಿಗೆ ಸಂಯೋಜಿಸಲು ಹಾಗೂ ಲೈವ್ ಟ್ರಾಫಿಕ್ ಅನ್ನು ಸುರಕ್ಷಿತವಾಗಿ ಪರಿವರ್ತಿಸಲು ಮೈಗ್ರೇಶನ್‌ಗೆ ವ್ಯಾಪಕವಾದ ಕೆಲಸದ ಅಗತ್ಯವಿತ್ತು.

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

ನಾವು ಅಂತಹ ಪೂರ್ವಭಾವಿಯಾದ, ಯಾವಾಗಲೂ ಆನ್ ಆಗಿರುವ ಏಜೆಂಟ್‌ಗಳ ಸಮೂಹವನ್ನು CobbleDB ಪ್ರಾಜೆಕ್ಟ್‌ಗೆ ನಿಯೋಜಿಸಿದ್ದೇವೆ. ಅವರ ಮೊದಲ ಕೆಲಸವೆಂದರೆ ಈಗಾಗಲೇ ನಡೆಯುತ್ತಿರುವ ಕೆಲಸದ ನಿಖರವಾದ ಮಾದರಿಯನ್ನು ನಿರ್ಮಿಸುವುದು. ಅವರು ಪ್ರಾಜೆಕ್ಟ್ ಚಾನೆಲ್ ಮತ್ತು ಸಕ್ರಿಯ ಥ್ರೆಡ್‌ಗಳನ್ನು ಆಡಿಟ್ ಮಾಡಿದರು, ಬಾಕಿ ಉಳಿದಿರುವ ಐಟಂಗಳನ್ನು ಅವುಗಳ pull request‌ಗಳು ಮತ್ತು ಮಾಲೀಕರೊಂದಿಗೆ ಸಂಪರ್ಕಿಸಿದರು, ಹಾಗೂ ಸಿಸ್ಟಮ್ ಆರೋಗ್ಯ ಮತ್ತು ಮುಂದಿನ ಕ್ರಮಗಳ ಪ್ರಸ್ತುತ ವರದಿಯನ್ನು ತಯಾರಿಸಿದರು. ಅಲ್ಲಿಂದ, ಅವರು ಇಂಜಿನಿಯರಿಂಗ್ ಲೂಪ್‌ನ ಹಲವು ಭಾಗಗಳಲ್ಲಿ ಕಾರ್ಯನಿರ್ವಹಿಸಿದರು:

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

ಇಂಜಿನಿಯರ್‌ಗಳು ಇನ್ನೂ ವಾಸ್ತುಶಿಲ್ಪವನ್ನು ನಿರ್ಧರಿಸಿದರು, ಪರಿಣಾಮಕಾರಿ ಬದಲಾವಣೆಗಳನ್ನು ಪರಿಶೀಲಿಸಿದರು, ಮತ್ತು ಉತ್ಪಾದನಾ ಕಾರ್ಯಾಚರಣೆಗಳಿಗೆ ಅನುಮೋದನೆ ನೀಡಿದರು. ಏಜೆಂಟ್‌ಗಳು ಆ ನಿರ್ಣಯಗಳ ನಡುವೆ ನಡೆದ ನಿರಂತರ ಪರಿಶೀಲನೆ ಮತ್ತು ಮುಂದುವರಿಕೆಯಲ್ಲಿ ಬಹುಭಾಗವನ್ನು ನಿರ್ವಹಿಸಿದರು. ಇದರಿಂದ ಒಂದು ಚಿಕ್ಕ ತಂಡವು ಯೋಜನೆಯನ್ನು ದಕ್ಷವಾಗಿ ಮುನ್ನಡೆಸಲು ಸಾಧ್ಯವಾಯಿತು—ಮೂಲ CobbleDB ಮೂಲಸೌಕರ್ಯವನ್ನು ಎರಡು ಮಾನವ ಇಂಜಿನಿಯರ್‌ಗಳು ಮತ್ತು ನೂರಾರು AI ಏಜೆಂಟ್‌ಗಳು ಎರಡು ತಿಂಗಳಲ್ಲಿ ನಿರ್ಮಿಸಿದರು.

ತೀರ್ಮಾನ

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

ನಾವು ಇನ್-ಹೌಸ್ AI-ನೇಟಿವ್ ಇನ್‌ಫ್ರಾಸ್ಟ್ರಕ್ಚರ್ ಅನ್ನು ಅಭಿವೃದ್ಧಿಪಡಿಸುವುದನ್ನು ಮುಂದುವರಿಸುತ್ತಿದ್ದಂತೆ, ಮೂರನೇ পক্ষের ಇಂಪ್ಲಿಮೆಂಟೇಶನ್‌ಗಳು ಮತ್ತು ಪ್ರೈಸಿಂಗ್ ಮಾದರಿಗಳಿಗೆ ನಾವು ಬದ್ಧರಾಗಿರುವಾಗ ಸಾಧ್ಯವಿಲ್ಲದ ರೀತಿಯಲ್ಲಿ ನಾವು ಕಾರ್ಯಕ್ಷಮತೆ ಮತ್ತು ವೆಚ್ಚವನ್ನು ಆಪ್ಟಿಮೈಸ್ ಮಾಡಬಹುದು. ಶಕ್ತಿಶಾಲಿ AI ಏಜೆಂಟ್‌ಗಳು ಖರೀದಿಸುವುದಕ್ಕಿಂತ ನಿರ್ಮಿಸುವುದರ ಪರವಾಗಿ ಲೆಕ್ಕಾಚಾರವನ್ನು ಮತ್ತಷ್ಟು ಬದಲಾಯಿಸುತ್ತವೆ.

AI-ನೇಟಿವ್ ಸರ್ಚ್ ಸಿಸ್ಟಮ್‌ಗಳನ್ನು ನಿರ್ಮಿಸುವ ಇತರ ತಂಡಗಳು ನಮ್ಮ ಉತ್ಪನ್ನಗಳ ಒಳಗೆ ಹುಡುಕಾಟವನ್ನು ವೇಗವಾಗಿ ಮತ್ತು ಅಗ್ಗವಾಗಿಸುವ ಅದೇ ಸ್ಟೋರೇಜ್ ಲೇಯರ್‌ನಿಂದ ಪ್ರಯೋಜನ ಪಡೆಯಲು ನಾವು ಶೀಘ್ರದಲ್ಲೇ CobbleDB ಅನ್ನು ಓಪನ್-ಸೋರ್ಸ್ ಮಾಡಲು ಯೋಜಿಸುತ್ತೇವೆ.

ಉಲ್ಲೇಖ

@online{perplexity2026Cobbledb,
  author = {{Perplexity} and Alexandr Yarats and Marco Montagna and Aleksei Bykov and Alexey Gusev and Ali Abdullaev and Amir Mokhammed-Ali and Andrey Zosimov and Denis Kremko and Gleb Vishnevsky and Micah Zirn and Phi Hoang and Claire Beamer and Jeremy Yang and Jerry Ma and Denis Yarats},
  title = {{CobbleDB: Rebuilding AI search storage for lower latency and cost}},
  date = {2026-09-14},
  url = {https://www.perplexity.ai/hub/blog/cobbledb}
}