ಈ ಡೇಟಾಬೇಸ್ ಬೆಂಕಿಯಲ್ಲಿದೆ...

ನಾನು ತಾಂತ್ರಿಕ ಕಥೆಯನ್ನು ಹೇಳುತ್ತೇನೆ.

ಹಲವು ವರ್ಷಗಳ ಹಿಂದೆ, ನಾನು ಅದರೊಳಗೆ ನಿರ್ಮಿಸಲಾದ ಸಹಯೋಗದ ವೈಶಿಷ್ಟ್ಯಗಳೊಂದಿಗೆ ಅಪ್ಲಿಕೇಶನ್ ಅನ್ನು ಅಭಿವೃದ್ಧಿಪಡಿಸುತ್ತಿದ್ದೆ. ಇದು ಬಳಕೆದಾರ ಸ್ನೇಹಿ ಪ್ರಾಯೋಗಿಕ ಸ್ಟಾಕ್ ಆಗಿದ್ದು ಅದು ಆರಂಭಿಕ ರಿಯಾಕ್ಟ್ ಮತ್ತು ಕೌಚ್‌ಡಿಬಿಯ ಸಂಪೂರ್ಣ ಸಾಮರ್ಥ್ಯದ ಪ್ರಯೋಜನವನ್ನು ಪಡೆದುಕೊಂಡಿತು. ಇದು JSON ಮೂಲಕ ನೈಜ ಸಮಯದಲ್ಲಿ ಡೇಟಾವನ್ನು ಸಿಂಕ್ರೊನೈಸ್ ಮಾಡಿದೆ OT. ಇದನ್ನು ಕಂಪನಿಯೊಳಗೆ ಆಂತರಿಕವಾಗಿ ಬಳಸಲಾಗುತ್ತಿತ್ತು, ಆದರೆ ಇತರ ಕ್ಷೇತ್ರಗಳಲ್ಲಿ ಅದರ ವಿಶಾಲವಾದ ಅನ್ವಯಿಸುವಿಕೆ ಮತ್ತು ಸಾಮರ್ಥ್ಯವು ಸ್ಪಷ್ಟವಾಗಿತ್ತು.

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


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

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

ದೈನಂದಿನ ಸಿಂಕ್‌ಗಳ ವಿನ್ಯಾಸ

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

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

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

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

ಇಬ್ಬರ ಹೆಸರಲ್ಲೂ ಫೈರ್ ಎಂಬ ಪದವಿದೆ. ಒಂದು ವಿಷಯವನ್ನು ನಾನು ಪ್ರೀತಿಯಿಂದ ನೆನಪಿಸಿಕೊಳ್ಳುತ್ತೇನೆ. ನನಗೆ ಎರಡನೆಯ ವಿಷಯವೆಂದರೆ ವಿಭಿನ್ನ ರೀತಿಯ ಬೆಂಕಿ. ಅವರ ಹೆಸರುಗಳನ್ನು ಹೇಳಲು ನನಗೆ ಯಾವುದೇ ಆತುರವಿಲ್ಲ, ಏಕೆಂದರೆ ಒಮ್ಮೆ ನಾನು ಮಾಡಿದರೆ, ನಾವು ಮೊದಲ ದೊಡ್ಡ ಸಮಸ್ಯೆಗೆ ಸಿಲುಕುತ್ತೇವೆ: ಹೆಸರುಗಳು.

ಮೊದಲನೆಯದನ್ನು ಕರೆಯಲಾಗುತ್ತದೆ ಫೈರ್‌ಬೇಸ್ ರಿಯಲ್-ಟೈಮ್ ಡೇಟಾಬೇಸ್, ಮತ್ತು ಎರಡನೇ - ಫೈರ್‌ಬೇಸ್ ಕ್ಲೌಡ್ ಫೈರ್‌ಸ್ಟೋರ್. ಇವೆರಡೂ ಉತ್ಪನ್ನಗಳಾಗಿವೆ ಫೈರ್‌ಬೇಸ್ ಸೂಟ್ ಗೂಗಲ್. ಅವರ API ಗಳನ್ನು ಕ್ರಮವಾಗಿ ಕರೆಯಲಾಗುತ್ತದೆ firebase.database(…) и firebase.firestore(…).

ಏಕೆಂದರೆ ಇದು ಸಂಭವಿಸಿತು ರಿಯಲ್-ಟೈಮ್ ಡೇಟಾಬೇಸ್ - ಇದು ಕೇವಲ ಮೂಲವಾಗಿದೆ ಫೈರ್ಬೇಸ್ 2014 ರಲ್ಲಿ Google ನಿಂದ ಅದನ್ನು ಖರೀದಿಸುವ ಮೊದಲು. ನಂತರ Google ಒಂದು ಸಮಾನಾಂತರ ಉತ್ಪನ್ನವಾಗಿ ರಚಿಸಲು ನಿರ್ಧರಿಸಿತು ಒಂದು ಪ್ರತಿ ಫೈರ್‌ಬೇಸ್ ದೊಡ್ಡ ಡೇಟಾ ಕಂಪನಿಯನ್ನು ಆಧರಿಸಿದೆ ಮತ್ತು ಅದನ್ನು ಕ್ಲೌಡ್‌ನೊಂದಿಗೆ ಫೈರ್‌ಸ್ಟೋರ್ ಎಂದು ಕರೆದಿದೆ. ನೀವು ಇನ್ನೂ ಗೊಂದಲಕ್ಕೀಡಾಗಿಲ್ಲ ಎಂದು ನಾನು ಭಾವಿಸುತ್ತೇನೆ. ನೀವು ಇನ್ನೂ ಗೊಂದಲಕ್ಕೊಳಗಾಗಿದ್ದರೆ, ಚಿಂತಿಸಬೇಡಿ, ನಾನು ಲೇಖನದ ಈ ಭಾಗವನ್ನು ಹತ್ತು ಬಾರಿ ಪುನಃ ಬರೆದಿದ್ದೇನೆ.

ಏಕೆಂದರೆ ನೀವು ಸೂಚಿಸಬೇಕಾಗಿದೆ ಫೈರ್ಬೇಸ್ Firebase ಪ್ರಶ್ನೆಯಲ್ಲಿ, ಮತ್ತು ಅಗ್ನಿಶಾಮಕ ಫೈರ್‌ಬೇಸ್ ಕುರಿತ ಪ್ರಶ್ನೆಯಲ್ಲಿ, ಸ್ಟಾಕ್ ಓವರ್‌ಫ್ಲೋ ಕುರಿತು ಕೆಲವು ವರ್ಷಗಳ ಹಿಂದೆ ನಿಮಗೆ ಅರ್ಥವಾಗುವಂತೆ.

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

ಪಿರಿಕ್ ಗೆಲುವು

ಫೈರ್‌ಸ್ಟೋರ್ ಎಂದು ಒಬ್ಬರು ಭಾವಿಸುತ್ತಾರೆ ಸಮ್ಮೇಳನ ಫೈರ್‌ಬೇಸ್, ಅದರ ಮುಂದಿನ ಪೀಳಿಗೆಯ ವಂಶಸ್ಥರು, ಆದರೆ ಅದು ತಪ್ಪುದಾರಿಗೆಳೆಯುತ್ತದೆ. ಫೈರ್‌ಸ್ಟೋರ್ ಫೈರ್‌ಬೇಸ್‌ಗೆ ಸೂಕ್ತವಾದ ಬದಲಿ ಎಂದು ಖಾತರಿಪಡಿಸಲಾಗಿಲ್ಲ. ಯಾರೋ ಅದರಿಂದ ಆಸಕ್ತಿದಾಯಕವಾದ ಎಲ್ಲವನ್ನೂ ಕತ್ತರಿಸಿದಂತೆ ತೋರುತ್ತಿದೆ ಮತ್ತು ಉಳಿದವುಗಳನ್ನು ವಿವಿಧ ರೀತಿಯಲ್ಲಿ ಗೊಂದಲಗೊಳಿಸಿದೆ.

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

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

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

ಅವನು ತನ್ನ ಕೋಣೆಯಿಂದ ಕಾಣಿಸಿಕೊಂಡನು ಮತ್ತು ಘೋಷಿಸಿದನು:

“ಒಂದು ದೊಡ್ಡ JSON ಡಾಕ್ಯುಮೆಂಟ್? ಸಂ. ನೀವು ಡೇಟಾವನ್ನು ಪ್ರತ್ಯೇಕ ದಾಖಲೆಗಳಾಗಿ ವಿಭಜಿಸುತ್ತೀರಿ, ಪ್ರತಿಯೊಂದೂ 1 ಮೆಗಾಬೈಟ್ ಗಾತ್ರಕ್ಕಿಂತ ಹೆಚ್ಚಿಲ್ಲ.

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

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

"ಪುನರಾವರ್ತಿತವಾಗಿ ಇತರ ಅಂಶಗಳನ್ನು ಒಳಗೊಂಡಿರುವ ಅರೇಗಳ ಸರಣಿಗಳು? ಸಂ. ಅರೇಗಳು ದೇವರ ಉದ್ದೇಶದಂತೆ ಸ್ಥಿರ-ಉದ್ದದ ವಸ್ತುಗಳು ಅಥವಾ ಸಂಖ್ಯೆಗಳನ್ನು ಮಾತ್ರ ಒಳಗೊಂಡಿರುತ್ತವೆ."

ಹಾಗಾಗಿ ನಿಮ್ಮ Firestore ಗೆ GeoJSON ಅನ್ನು ಹಾಕಲು ನೀವು ಆಶಿಸುತ್ತಿದ್ದರೆ, ಇದು ಸಾಧ್ಯವಿಲ್ಲ ಎಂದು ನೀವು ಕಂಡುಕೊಳ್ಳುತ್ತೀರಿ. ಏಕ ಆಯಾಮವಲ್ಲದ ಯಾವುದೂ ಸ್ವೀಕಾರಾರ್ಹವಲ್ಲ. ನೀವು JSON ನಲ್ಲಿ Base64 ಮತ್ತು/ಅಥವಾ JSON ಅನ್ನು ಇಷ್ಟಪಡುತ್ತೀರಿ ಎಂದು ನಾನು ಭಾವಿಸುತ್ತೇನೆ.

"HTTP, ಕಮಾಂಡ್ ಲೈನ್ ಪರಿಕರಗಳು ಅಥವಾ ನಿರ್ವಾಹಕ ಫಲಕದ ಮೂಲಕ JSON ಆಮದು ಮತ್ತು ರಫ್ತು ಮಾಡುವುದೇ? ಸಂ. ನೀವು Google ಮೇಘ ಸಂಗ್ರಹಣೆಗೆ ಡೇಟಾವನ್ನು ರಫ್ತು ಮಾಡಲು ಮತ್ತು ಆಮದು ಮಾಡಲು ಮಾತ್ರ ಸಾಧ್ಯವಾಗುತ್ತದೆ. ಅದನ್ನೇ ಈಗ ಕರೆಯಲಾಗುತ್ತದೆ, ನಾನು ಭಾವಿಸುತ್ತೇನೆ. ಮತ್ತು ನಾನು "ನೀವು" ಎಂದು ಹೇಳಿದಾಗ ನಾನು ಪ್ರಾಜೆಕ್ಟ್ ಮಾಲೀಕರ ರುಜುವಾತುಗಳನ್ನು ಹೊಂದಿರುವವರನ್ನು ಮಾತ್ರ ಉದ್ದೇಶಿಸುತ್ತಿದ್ದೇನೆ. ಉಳಿದವರೆಲ್ಲರೂ ಹೋಗಿ ಟಿಕೆಟ್‌ಗಳನ್ನು ರಚಿಸಬಹುದು."

ನೀವು ನೋಡುವಂತೆ, ಫೈರ್‌ಬೇಸ್ ಡೇಟಾ ಮಾದರಿಯನ್ನು ವಿವರಿಸಲು ಸುಲಭವಾಗಿದೆ. ಇದು JSON ಕೀಗಳನ್ನು URL ಪಥಗಳೊಂದಿಗೆ ಸಂಯೋಜಿಸುವ ಒಂದು ದೊಡ್ಡ JSON ಡಾಕ್ಯುಮೆಂಟ್ ಅನ್ನು ಒಳಗೊಂಡಿದೆ. ನೀವು ಬರೆದರೆ HTTP PUT в / ಫೈರ್‌ಬೇಸ್ ಈ ಕೆಳಗಿನಂತಿದೆ:

{
  "hello": "world"
}

ದಿ GET /hello ಹಿಂತಿರುಗುತ್ತಾರೆ "world". ಮೂಲಭೂತವಾಗಿ ಇದು ನೀವು ನಿರೀಕ್ಷಿಸಿದಂತೆ ನಿಖರವಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ. ಫೈರ್‌ಬೇಸ್ ವಸ್ತುಗಳ ಸಂಗ್ರಹ /my-collection/:id JSON ನಿಘಂಟಿಗೆ ಸಮನಾಗಿರುತ್ತದೆ {"my-collection": {...}} ಮೂಲದಲ್ಲಿ, ಅದರಲ್ಲಿನ ವಿಷಯಗಳು ಲಭ್ಯವಿದೆ /my-collection:

{
  "id1": {...object},
  "id2": {...object},
  "id3": {...object},
  // ...
}

ಪ್ರತಿ ಇನ್ಸರ್ಟ್ ಘರ್ಷಣೆ-ಮುಕ್ತ ID ಹೊಂದಿದ್ದರೆ, ಸಿಸ್ಟಮ್ ಪ್ರಮಾಣಿತ ಪರಿಹಾರವನ್ನು ಹೊಂದಿದ್ದರೆ ಇದು ಉತ್ತಮವಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ.

ಬೇರೆ ರೀತಿಯಲ್ಲಿ ಹೇಳುವುದಾದರೆ, ಡೇಟಾಬೇಸ್ 100% JSON(*) ಹೊಂದಿಕೆಯಾಗುತ್ತದೆ ಮತ್ತು CouchDB ಯಂತಹ HTTP ಯೊಂದಿಗೆ ಉತ್ತಮವಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ. ಆದರೆ ಮೂಲಭೂತವಾಗಿ ನೀವು ವೆಬ್‌ಸಾಕೆಟ್‌ಗಳು, ದೃಢೀಕರಣ ಮತ್ತು ಚಂದಾದಾರಿಕೆಗಳನ್ನು ಅಮೂರ್ತಗೊಳಿಸುವ ನೈಜ-ಸಮಯದ API ಮೂಲಕ ಬಳಸುತ್ತೀರಿ. ನಿರ್ವಾಹಕ ಫಲಕವು ಎರಡೂ ಸಾಮರ್ಥ್ಯಗಳನ್ನು ಹೊಂದಿದೆ, ನೈಜ-ಸಮಯದ ಸಂಪಾದನೆ ಮತ್ತು JSON ಆಮದು/ರಫ್ತು ಎರಡನ್ನೂ ಅನುಮತಿಸುತ್ತದೆ. ನಿಮ್ಮ ಕೋಡ್‌ನಲ್ಲಿ ನೀವು ಅದೇ ರೀತಿ ಮಾಡಿದರೆ, ಪ್ಯಾಚ್ ಮತ್ತು ಡಿಫ್ JSON ನಿರಂತರ ಸ್ಥಿತಿಯನ್ನು ನಿರ್ವಹಿಸುವ 90% ವಾಡಿಕೆಯ ಕಾರ್ಯಗಳನ್ನು ಪರಿಹರಿಸುತ್ತದೆ ಎಂದು ನೀವು ತಿಳಿದುಕೊಂಡಾಗ ಎಷ್ಟು ವಿಶೇಷ ಕೋಡ್ ವ್ಯರ್ಥವಾಗುತ್ತದೆ ಎಂದು ನಿಮಗೆ ಆಶ್ಚರ್ಯವಾಗುತ್ತದೆ.

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

ಅವರು ನೈಜ-ಸಮಯದ NoSQL ಡೇಟಾಬೇಸ್ ಅನ್ನು ತೆಗೆದುಕೊಂಡರು ಮತ್ತು ಅದನ್ನು ಸ್ವಯಂ-ಸೇರುವಿಕೆ ಮತ್ತು ಪ್ರತ್ಯೇಕವಾದ JSON ಅಲ್ಲದ ಕಾಲಮ್‌ನೊಂದಿಗೆ ನಿಧಾನವಾದ SQL ಅಲ್ಲದ ಆಗಿ ಪರಿವರ್ತಿಸಿದರು. GraftQL ನಂತಹವು.

ಬಿಸಿ ಜಾವಾ

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

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

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

ಫೈರ್‌ಸ್ಟೋರ್ ರಚನೆಯ ಹಿಂದಿನ ಎಲ್ಲಾ ತರ್ಕಗಳು ನನಗೆ ತಿಳಿದಿಲ್ಲ. ಕಪ್ಪು ಪೆಟ್ಟಿಗೆಯೊಳಗೆ ಉದ್ಭವಿಸುವ ಉದ್ದೇಶಗಳ ಬಗ್ಗೆ ಊಹಾಪೋಹ ಮಾಡುವುದು ಸಹ ಮೋಜಿನ ಭಾಗವಾಗಿದೆ. ಎರಡು ಅತ್ಯಂತ ಸಮಾನವಾದ ಆದರೆ ಹೋಲಿಸಲಾಗದ ಡೇಟಾಬೇಸ್‌ಗಳ ಈ ಸಂಯೋಜನೆಯು ಸಾಕಷ್ಟು ಅಪರೂಪವಾಗಿದೆ. ಯಾರೋ ಯೋಚಿಸಿದ ಹಾಗೆ: "ಫೈರ್‌ಬೇಸ್ ನಾವು Google ಕ್ಲೌಡ್‌ನಲ್ಲಿ ಅನುಕರಿಸಬಹುದಾದ ಒಂದು ಕಾರ್ಯವಾಗಿದೆ", ಆದರೆ ನೈಜ-ಪ್ರಪಂಚದ ಅವಶ್ಯಕತೆಗಳನ್ನು ಗುರುತಿಸುವ ಅಥವಾ ಆ ಎಲ್ಲಾ ಅವಶ್ಯಕತೆಗಳನ್ನು ಪೂರೈಸುವ ಉಪಯುಕ್ತ ಪರಿಹಾರಗಳನ್ನು ರಚಿಸುವ ಪರಿಕಲ್ಪನೆಯನ್ನು ಇನ್ನೂ ಕಂಡುಹಿಡಿದಿಲ್ಲ. "ಅಭಿವರ್ಧಕರು ಅದರ ಬಗ್ಗೆ ಯೋಚಿಸಲಿ. UI ಅನ್ನು ಸುಂದರವಾಗಿಸಿ... ನೀವು ಇನ್ನಷ್ಟು ಬೆಂಕಿಯನ್ನು ಸೇರಿಸಬಹುದೇ?"

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

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

ಈ ಕುರಿತು ಮಾಹಿತಿಗಾಗಿ ನೀವು Google ಡಾಕ್ಸ್‌ನಲ್ಲಿ ಹುಡುಕಿದರೆ, ನೀವು ಆಶಾದಾಯಕವಾಗಿ BigTable ಮತ್ತು BigQuery ಯಂತಹ ದಿಕ್ಕಿನಲ್ಲಿ ತೋರಿಸಲ್ಪಡುತ್ತೀರಿ. ಆದಾಗ್ಯೂ, ಈ ಎಲ್ಲಾ ಪರಿಹಾರಗಳು ತುಂಬಾ ದಟ್ಟವಾದ ಕಾರ್ಪೊರೇಟ್ ಮಾರಾಟದ ಪರಿಭಾಷೆಯೊಂದಿಗೆ ಇರುತ್ತವೆ, ನೀವು ಬೇಗನೆ ಹಿಂತಿರುಗಿ ಬೇರೆ ಯಾವುದನ್ನಾದರೂ ಹುಡುಕಲು ಪ್ರಾರಂಭಿಸುತ್ತೀರಿ.

ನೈಜ-ಸಮಯದ ಡೇಟಾಬೇಸ್‌ನೊಂದಿಗೆ ನಿಮಗೆ ಬೇಕಾದ ಕೊನೆಯ ವಿಷಯವೆಂದರೆ ನಿರ್ವಹಣಾ ವೇತನ ಮಾಪಕಗಳಲ್ಲಿರುವ ಜನರು ಮತ್ತು ಅವರಿಗಾಗಿ ರಚಿಸಲಾಗಿದೆ.

(*) ಇದು ತಮಾಷೆ, ಅಂತಹ ವಿಷಯವಿಲ್ಲ 100% JSON ಹೊಂದಾಣಿಕೆ.

ಜಾಹೀರಾತು ಹಕ್ಕುಗಳ ಮೇಲೆ

ಹುಡುಕುವುದು ವಿಡಿಎಸ್ ಡೀಬಗ್ ಮಾಡುವ ಯೋಜನೆಗಳಿಗಾಗಿ, ಅಭಿವೃದ್ಧಿ ಮತ್ತು ಹೋಸ್ಟಿಂಗ್‌ಗಾಗಿ ಸರ್ವರ್? ನೀವು ಖಂಡಿತವಾಗಿಯೂ ನಮ್ಮ ಕ್ಲೈಂಟ್ ಆಗಿದ್ದೀರಿ 🙂 ವಿವಿಧ ಕಾನ್ಫಿಗರೇಶನ್‌ಗಳ ಸರ್ವರ್‌ಗಳಿಗೆ ದೈನಂದಿನ ಬೆಲೆ, ವಿರೋಧಿ DDoS ಮತ್ತು ವಿಂಡೋಸ್ ಪರವಾನಗಿಗಳನ್ನು ಈಗಾಗಲೇ ಬೆಲೆಯಲ್ಲಿ ಸೇರಿಸಲಾಗಿದೆ.

ಮೂಲ: www.habr.com