Firestore JOIN ಬಲೆ
ನೀವು ಸಾಮಾನ್ಯವಾದ Firestore ಸಮಸ್ಯೆಯನ್ನು ಎದುರಿಸುತ್ತೀರಿ. ನಿಮ್ಮ Firebase function ಗರಿಷ್ಠ batch size ದೋಷವನ್ನು (error) ತೋರಿಸುತ್ತದೆ. ಡ್ಯಾಶ್ಬೋರ್ಡ್ಗಾಗಿ ನೀವು orders ಮತ್ತು customers ಅನ್ನು join ಮಾಡಬೇಕಾಗುತ್ತದೆ. ಇದನ್ನು ಸರಿಪಡಿಸಲು ನೀವು ಸಾಮಾನ್ಯವಾಗಿ ಡೇಟಾವನ್ನು ಡೂಪ್ಲಿಕೇಟ್ ಮಾಡುತ್ತೀರಿ. ಆದರೆ ಈಗ ನಿಮ್ಮ ಡೇಟಾ ಹಳೆಯದಾಗಿದೆ (stale) ಮತ್ತು ಅಸಂಗತವಾಗಿದೆ (inconsistent).
ಇದನ್ನು ಪರಿಹರಿಸಲು Google Pipelines API ಅನ್ನು ಘೋಷಿಸಿದೆ. ಇದು ಡೇಟಾವನ್ನು ಡೂಪ್ಲಿಕೇಟ್ ಮಾಡದೆ ವಿವಿಧ collections ನಡುವೆ JOIN ಕಾರ್ಯಾಚರಣೆಗಳನ್ನು ಮಾಡಲು ಅನುಮತಿಸುತ್ತದೆ. ಕೆಲವು ಡೆವಲಪರ್ಗಳು ಸಣ್ಣ ಪರೀಕ್ಷೆಗಳಲ್ಲಿ ವೇಗದ ಕ್ವೇರಿ ಸಮಯವನ್ನು ವರದಿ ಮಾಡಿದ್ದಾರೆ.
ನಾನು ಹೆಚ್ಚಿನ ಲೋಡ್ ಅಡಿಯಲ್ಲಿ ಈ API ಅನ್ನು ಪರೀಕ್ಷಿಸಲು ಒಂದು ವಾರ ಕಳೆದಿದ್ದೇನೆ. ಡಾಕ್ಯುಮೆಂಟೇಶನ್ ನಿಮಗೆ ಹೇಳದ ವಿಷಯಗಳು ಇಲ್ಲಿವೆ.
ಹೆಚ್ಚಿನ ವೆಚ್ಚಗಳು ಪ್ರತಿಯೊಂದು pipeline ಕಾರ್ಯಗತಗೊಳಿಸುವಿಕೆಯು (execution) ಒಳಗೊಂಡಿರುವ ಎಲ್ಲಾ collections ನಿಂದ ಡೇಟಾವನ್ನು ಓದುತ್ತದೆ. ಎರಡು collections ನಡುವಿನ JOIN ಕಾರ್ಯಾಚರಣೆಯು ಎರಡರಲ್ಲೂ ಮಾಡುವ 'reads' ಗಾಗಿ ನಿಮಗೆ ಬಿಲ್ ಮಾಡುತ್ತದೆ. ನೀವು 50,000 ಡಾಕ್ಯುಮೆಂಟ್ಗಳಿರುವ ಎರಡು collections ಅನ್ನು join ಮಾಡಿದರೆ, ನಿಮ್ಮ ವೆಚ್ಚವು ಅತಿಯಾಗಿ ಹೆಚ್ಚಾಗುತ್ತದೆ. ಇದು ಸರಳವಾದ ಲೀನಿಯರ್ ವೆಚ್ಚವಲ್ಲ.
ಕಾರ್ಯಕ್ಷಮತೆಯ ಮಿತಿಗಳು ನನ್ನ ಪರೀಕ್ಷೆಗಳಲ್ಲಿ, 10,000 ಡಾಕ್ಯುಮೆಂಟ್ಗಳ ವಿರುದ್ಧದ pipeline ಗೆ 380ms ಬೇಕಾಯಿತು. ನಾನು 100,000 ಡಾಕ್ಯುಮೆಂಟ್ಗಳನ್ನು ಪರೀಕ್ಷಿಸಿದಾಗ, ಕ್ವೇರಿಯು 30 ಸೆಕೆಂಡುಗಳಲ್ಲಿ 타임 ಔಟ್ (timeout) ಆಯಿತು. ನೀವು ಸಮಸ್ಯೆಯನ್ನು ಸರಿಪಡಿಸುತ್ತಿಲ್ಲ; ನೀವು ಕೇವಲ batch error ಅನ್ನು timeout error ಆಗಿ ಬದಲಾಯಿಸುತ್ತಿದ್ದೀರಿ ಅಷ್ಟೆ.
Cold Start ಸಮಸ್ಯೆಗಳು Pipelines ಒಂದು ಪ್ರತ್ಯೇಕ execution context ಅನ್ನು ರಚಿಸುತ್ತವೆ. Cloud Functions ನಂತಹ serverless ಪರಿಸರಗಳಲ್ಲಿ, ಇದು 2 ರಿಂದ 4 ಸೆಕೆಂಡುಗಳ ವಿಳಂಬವನ್ನು ಉಂಟುಮಾಡುತ್ತದೆ. ನಿಮ್ಮ ಅಪ್ಲಿಕೇಶನ್ ನಿಧಾನವಾಗಿದೆ ಎಂದು ನಿಮ್ಮ ಬಳಕೆದಾರರು ಭಾವಿಸುತ್ತಾರೆ.
Pipelines API ಎಂಬುದು ಪ್ರೊಟೊಟೈಪಿಂಗ್ ಅಥವಾ 5,000 ಕ್ಕಿಂತ ಕಡಿಮೆ ಡಾಕ್ಯುಮೆಂಟ್ಗಳಿರುವ ಸಣ್ಣ collections ಗಾಗಿ ಇರುವ ಒಂದು ಸಾಧನವಾಗಿದೆ. ಇದು relational database ಗೆ ಪರ್ಯಾಯವಲ್ಲ. ನೀವು PostgreSQL ಅಥವಾ Spanner ಗೆ ಬದಲಾಗುವ ಬದಲು Firebase ecosystem ನಲ್ಲೇ ಇರಲು ಸಹಾಯ ಮಾಡಲು Google ಇದನ್ನು ಒದಗಿಸಿದೆ.
ನೀವು Pipelines ಬಳಸುವುದಾದರೆ, ಈ ನಿಯಮಗಳನ್ನು ಅನುಸರಿಸಿ:
• ನಿಮ್ಮ collection ಗಾತ್ರವನ್ನು ಪರಿಶೀಲಿಸಿ (Audit). ಒಂದು collection 20,000 ಡಾಕ್ಯುಮೆಂಟ್ಗಳನ್ನು ಮೀರಿದರೆ, ಮೊದಲು JOIN ವೆಚ್ಚವನ್ನು ಲೆಕ್ಕಹಾಕಿ. • ಸಂಕೀರ್ಣತೆಯನ್ನು ಮಿತಿಗೊಳಿಸಿ. ಮೂರು ಅಥವಾ ಅದಕ್ಕಿಂತ ಹೆಚ್ಚು collections ನಡುವಿನ JOIN ಒಂದು ಕೆಟ್ಟ ಸೂಚನೆಯಾಗಿದೆ. • ವಾರಕ್ಕೊಮ್ಮೆ read ವೆಚ್ಚಗಳನ್ನು ಟ್ರ್ಯಾಕ್ ಮಾಡಿ. Pipeline reads ನಿಮ್ಮ ಬಿಲ್ನಲ್ಲಿ ವಿಭಿನ್ನವಾಗಿ ಕಾಣಿಸಿಕೊಳ್ಳುತ್ತವೆ. • ನಿಮ್ಮ denormalized ಡೇಟಾವನ್ನು ಇಟ್ಟುಕೊಳ್ಳಿ. Pipelines ಅನ್ನು ಪೂರಕವಾಗಿ ಬಳಸಿ, ಸಂಪೂರ್ಣ ಪರ್ಯಾಯವಾಗಿ ಅಲ್ಲ. • ನೈಜ ಟ್ರಾಫಿಕ್ನೊಂದಿಗೆ ಪರೀಕ್ಷಿಸಿ. ನಿಶ್ಯಬ್ದ collections ಮೇಲಿನ benchmarks ಉತ್ಪಾದನಾ ವಾಸ್ತವವನ್ನು (production reality) ಪ್ರತಿಬಿಂಬಿಸುವುದಿಲ್ಲ.
ನೈಜ ವಾಸ್ತುಶಿಲ್ಪದ ನಿರ್ಧಾರವನ್ನು (architectural decision) ತಪ್ಪಿಸಲು ಕೇವಲ ತಾತ್ಕಾಲಿಕ ಪರಿಹಾರವನ್ನು (band-aid) ಬಳಸಬೇಡಿ.
ನೀವು Firestore ನಲ್ಲಿ ಸಂಬಂಧಗಳನ್ನು (relationships) ಹೇಗೆ ನಿರ್ವಹಿಸುತ್ತೀರಿ? ನೀವು denormalization ಅಥವಾ client-side joins ಬಳಸುತ್ತೀರಾ? ಕಾಮೆಂಟ್ನಲ್ಲಿ ನನಗೆ ತಿಳಿಸಿ.