ຖານຂໍ້ມູນນີ້ແມ່ນໄຟໄຫມ້ ...

ໃຫ້ຂ້ອຍບອກເລື່ອງດ້ານວິຊາການ.

ຫລາຍປີກ່ອນ, ຂ້ອຍກໍາລັງພັດທະນາແອັບພລິເຄຊັນທີ່ມີລັກສະນະການຮ່ວມມືທີ່ສ້າງຂຶ້ນໃນມັນ. ມັນແມ່ນຊຸດທົດລອງທີ່ເປັນມິດກັບຜູ້ໃຊ້ທີ່ໃຊ້ປະໂຫຍດຈາກທ່າແຮງອັນເຕັມທີ່ຂອງ React ແລະ CouchDB ຕົ້ນ. ມັນ synchronized ຂໍ້ມູນໃນເວລາຈິງຜ່ານ JSON OT. ມັນຖືກນໍາໃຊ້ພາຍໃນບໍລິສັດ, ແຕ່ການນໍາໃຊ້ຢ່າງກວ້າງຂວາງແລະທ່າແຮງຂອງມັນໃນຂົງເຂດອື່ນໆແມ່ນຈະແຈ້ງ.

ໃນຂະນະທີ່ພະຍາຍາມຂາຍເຕັກໂນໂລຢີນີ້ໃຫ້ກັບລູກຄ້າທີ່ມີທ່າແຮງ, ພວກເຮົາພົບກັບອຸປະສັກທີ່ບໍ່ຄາດຄິດ. ໃນວິດີໂອສາທິດ, ເທັກໂນໂລຍີຂອງພວກເຮົາເບິ່ງ ແລະເຮັດວຽກໄດ້ດີ, ບໍ່ມີບັນຫາຫຍັງເລີຍ. ວິດີໂອສະແດງໃຫ້ເຫັນຢ່າງແນ່ນອນວ່າມັນເຮັດວຽກແນວໃດແລະບໍ່ໄດ້ຮຽນແບບອັນໃດເລີຍ. ພວກ​ເຮົາ​ໄດ້​ມາ​ເຖິງ​ແລະ​ລະ​ຫັດ​ສະ​ຖາ​ນະ​ການ​ທີ່​ເປັນ​ຈິງ​ສໍາ​ລັບ​ການ​ນໍາ​ໃຊ້​ໂຄງ​ການ​.


ໃນຄວາມເປັນຈິງ, ນີ້ໄດ້ກາຍເປັນບັນຫາ. ການສາທິດຂອງພວກເຮົາໃຊ້ໄດ້ຢ່າງແນ່ນອນວ່າທຸກຄົນຈຳລອງແອັບພລິເຄຊັນຂອງເຂົາເຈົ້າ. ໂດຍສະເພາະ, ຂໍ້ມູນໄດ້ຖືກໂອນທັນທີຈາກ A ຫາ B, ເຖິງແມ່ນວ່າມັນເປັນໄຟລ໌ສື່ມວນຊົນຂະຫນາດໃຫຍ່. ຫຼັງຈາກເຂົ້າສູ່ລະບົບ, ຜູ້ໃຊ້ແຕ່ລະຄົນໄດ້ເຫັນລາຍການໃຫມ່. ການນໍາໃຊ້ຄໍາຮ້ອງສະຫມັກ, ຜູ້ໃຊ້ທີ່ແຕກຕ່າງກັນສາມາດເຮັດວຽກຮ່ວມກັນຢ່າງຊັດເຈນໃນໂຄງການດຽວກັນ, ເຖິງແມ່ນວ່າການເຊື່ອມຕໍ່ອິນເຕີເນັດຖືກຂັດຂວາງຢູ່ບ່ອນໃດຫນຶ່ງໃນບ້ານ. ນີ້ແມ່ນ implicitly implitly ໃນວິດີໂອຜະລິດຕະພັນໃດໆຕັດໃນ After Effects.

ເຖິງແມ່ນວ່າທຸກຄົນຮູ້ວ່າປຸ່ມ Refresh ແມ່ນຫຍັງ, ບໍ່ມີໃຜເຂົ້າໃຈແທ້ໆວ່າຄໍາຮ້ອງສະຫມັກເວັບທີ່ພວກເຂົາຂໍໃຫ້ພວກເຮົາສ້າງໂດຍປົກກະຕິແມ່ນຂຶ້ນກັບຂໍ້ຈໍາກັດຂອງຕົນເອງ. ແລະວ່າຖ້າພວກເຂົາບໍ່ຈໍາເປັນ, ປະສົບການຂອງຜູ້ໃຊ້ຈະແຕກຕ່າງກັນຫມົດ. ສ່ວນຫຼາຍເຂົາເຈົ້າສັງເກດເຫັນວ່າເຂົາເຈົ້າສາມາດ “ສົນທະນາ” ໄດ້ໂດຍການປະບັນທຶກໃຫ້ຄົນທີ່ເຂົາເຈົ້າລົມກັນຢູ່, ດັ່ງນັ້ນເຂົາເຈົ້າຈຶ່ງສົງໄສວ່າອັນນີ້ແຕກຕ່າງຈາກ Slack ແນວໃດ. ຟີວ!

ການອອກແບບຂອງ syncs ປະຈໍາວັນ

ຖ້າທ່ານມີປະສົບການໃນການພັດທະນາຊອບແວ, ມັນຕ້ອງເປັນຕາຢ້ານທີ່ຈະຈື່ໄວ້ວ່າຄົນສ່ວນໃຫຍ່ບໍ່ພຽງແຕ່ເບິ່ງຮູບພາບຂອງການໂຕ້ຕອບແລະເຂົ້າໃຈສິ່ງທີ່ມັນຈະເຮັດໃນເວລາທີ່ພົວພັນກັບມັນ. ບໍ່ໄດ້ກ່າວເຖິງສິ່ງທີ່ເກີດຂື້ນພາຍໃນໂຄງການເອງ. ຄວາມຮູ້ນັ້ນ ສາມາດເຮັດໄດ້ ເກີດຂຶ້ນສ່ວນໃຫຍ່ເປັນຜົນມາຈາກການຮູ້ວ່າສິ່ງທີ່ບໍ່ສາມາດເກີດຂຶ້ນແລະສິ່ງທີ່ບໍ່ຄວນເກີດຂຶ້ນ. ນີ້ຮຽກຮ້ອງໃຫ້ມີ ແບບ​ຈໍາ​ລອງ​ຈິດ​ໃຈ​ ບໍ່ ພຽງ ແຕ່ ສິ່ງ ທີ່ ຊອບ ແວ ເຮັດ ໄດ້, ແຕ່ ຍັງ ວິ ທີ ການ ສ່ວນ ບຸກ ຄົນ ຂອງ ຕົນ ແມ່ນ ການ ປະ ສານ ງານ ແລະ ການ ຕິດ ຕໍ່ ກັນ ແລະ ກັນ.

ຕົວຢ່າງຄລາສສິກຂອງເລື່ອງນີ້ແມ່ນຜູ້ໃຊ້ກໍາລັງເບິ່ງ a spinnergif, ສົງໄສວ່າວຽກງານສຸດທ້າຍຈະສໍາເລັດເມື່ອໃດ. ນັກພັດທະນາຈະຮູ້ວ່າຂະບວນການອາດຈະຕິດຢູ່ແລະ gif ຈະບໍ່ຫາຍໄປຈາກຫນ້າຈໍ. ອະນິເມຊັນນີ້ຈຳລອງການປະຕິບັດວຽກ, ແຕ່ບໍ່ກ່ຽວຂ້ອງກັບສະຖານະຂອງມັນ. ໃນກໍລະນີດັ່ງກ່າວ, ບາງ techies ມັກມ້ວນຕາຂອງເຂົາເຈົ້າ, ປະຫລາດໃຈໃນຂອບເຂດຂອງຄວາມສັບສົນຂອງຜູ້ໃຊ້. ຢ່າງໃດກໍຕາມ, ສັງເກດເຫັນວ່າມີຈໍານວນເທົ່າໃດທີ່ຊີ້ໄປຫາໂມງ rotating ແລະເວົ້າວ່າມັນແມ່ນ stationary?

ນີ້ແມ່ນຄວາມສໍາຄັນຂອງມູນຄ່າໃນເວລາທີ່ແທ້ຈິງ. ໃນມື້ນີ້, ຖານຂໍ້ມູນທີ່ໃຊ້ເວລາທີ່ແທ້ຈິງແມ່ນຍັງຖືກນໍາໃຊ້ຫນ້ອຍຫຼາຍແລະປະຊາຊົນຈໍານວນຫຼາຍເບິ່ງພວກເຂົາດ້ວຍຄວາມສົງໃສ. ຖານຂໍ້ມູນເຫຼົ່ານີ້ສ່ວນຫຼາຍແມ່ນອີງໃສ່ແບບ NoSQL, ນັ້ນແມ່ນເຫດຜົນທີ່ພວກເຂົາມັກຈະໃຊ້ວິທີແກ້ໄຂທີ່ອີງໃສ່ Mongo, ເຊິ່ງຖືກລືມທີ່ດີທີ່ສຸດ. ຢ່າງໃດກໍຕາມ, ສໍາລັບຂ້າພະເຈົ້ານີ້ຫມາຍຄວາມວ່າມີຄວາມສະດວກສະບາຍໃນການເຮັດວຽກກັບ CouchDB, ເຊັ່ນດຽວກັນກັບການຮຽນຮູ້ການອອກແບບໂຄງສ້າງທີ່ຫຼາຍກ່ວາບາງ bureaucrat ສາມາດຕື່ມຂໍ້ມູນໃສ່. ຂ້ອຍຄິດວ່າຂ້ອຍໃຊ້ເວລາຂອງຂ້ອຍດີກວ່າ.

ແຕ່ຫົວຂໍ້ທີ່ແທ້ຈິງຂອງຫົວຂໍ້ນີ້ແມ່ນສິ່ງທີ່ຂ້ອຍໃຊ້ໃນມື້ນີ້. ບໍ່ແມ່ນໂດຍທາງເລືອກ, ແຕ່ເນື່ອງຈາກວ່ານະໂຍບາຍຂອງບໍລິສັດ indifferent ແລະ blindly ນໍາໃຊ້. ດັ່ງນັ້ນຂ້າພະເຈົ້າຈະສະຫນອງການປຽບທຽບຢ່າງສົມບູນແບບຍຸດຕິທໍາແລະບໍ່ລໍາອຽງຂອງສອງຜະລິດຕະພັນຖານຂໍ້ມູນທີ່ໃຊ້ເວລາທີ່ແທ້ຈິງຂອງ Google ທີ່ກ່ຽວຂ້ອງຢ່າງໃກ້ຊິດ.

ທັງສອງມີຄໍາວ່າໄຟຢູ່ໃນຊື່ຂອງເຂົາເຈົ້າ. ສິ່ງໜຶ່ງທີ່ຂ້ອຍຈື່ໄດ້ດ້ວຍຄວາມຮັກ. ສິ່ງທີສອງສໍາລັບຂ້ອຍແມ່ນປະເພດໄຟທີ່ແຕກຕ່າງກັນ. ຂ້າພະເຈົ້າບໍ່ຮີບຮ້ອນທີ່ຈະເວົ້າຊື່ຂອງເຂົາເຈົ້າ, ເພາະວ່າເມື່ອຂ້ອຍເຮັດ, ພວກເຮົາຈະແລ່ນເຂົ້າໄປໃນບັນຫາໃຫຍ່ທໍາອິດ: ຊື່.

ອັນທໍາອິດແມ່ນເອີ້ນວ່າ ຖານຂໍ້ມູນ Firebase ໃນເວລາຈິງ, ແລະຄັ້ງທີສອງ - Firebase Cloud Firestore. ທັງສອງຂອງພວກເຂົາແມ່ນຜະລິດຕະພັນຈາກ ຊຸດ Firebase Google. APIs ຂອງພວກເຂົາຖືກເອີ້ນຕາມລໍາດັບ firebase.database(…) и firebase.firestore(…).

ນີ້ເກີດຂຶ້ນຍ້ອນ ຖານຂໍ້ມູນເວລາຈິງ - ມັນເປັນພຽງແຕ່ຕົ້ນສະບັບ Firebase ກ່ອນການຊື້ໂດຍ Google ໃນປີ 2014. ຫຼັງຈາກນັ້ນ, Google ຕັດສິນໃຈສ້າງເປັນຜະລິດຕະພັນຂະຫນານ ສຳເນົາ Firebase ອີງໃສ່ບໍລິສັດຂໍ້ມູນໃຫຍ່, ແລະເອີ້ນວ່າ Firestore ດ້ວຍເມຄ. ຂ້ອຍຫວັງວ່າເຈົ້າຍັງບໍ່ໄດ້ສັບສົນເທື່ອ. ຖ້າທ່ານຍັງສັບສົນ, ຢ່າກັງວົນ, ຂ້ອຍເອງໄດ້ຂຽນຄືນສ່ວນນີ້ຂອງບົດຄວາມສິບເທື່ອ.

ເນື່ອງຈາກວ່າທ່ານຈໍາເປັນຕ້ອງຊີ້ບອກ Firebase ໃນຄໍາຖາມ Firebase, ແລະ ຮ້ານດັບເພີງ ໃນຄໍາຖາມກ່ຽວກັບ Firebase, ຢ່າງຫນ້ອຍເພື່ອເຮັດໃຫ້ເຈົ້າເຂົ້າໃຈສອງສາມປີກ່ອນກ່ຽວກັບ Stack Overflow.

ຖ້າມີລາງວັນສໍາລັບປະສົບການການຕັ້ງຊື່ຊອບແວທີ່ບໍ່ດີທີ່ສຸດ, ນີ້ແນ່ນອນຈະເປັນຫນຶ່ງໃນຜູ້ແຂ່ງຂັນ. ໄລຍະຫ່າງຂອງ Hamming ລະຫວ່າງຊື່ເຫຼົ່ານີ້ມີຂະຫນາດນ້ອຍຫຼາຍທີ່ມັນເຮັດໃຫ້ສັບສົນເຖິງແມ່ນວິສະວະກອນທີ່ມີປະສົບການທີ່ນິ້ວມືພິມຊື່ຫນຶ່ງໃນຂະນະທີ່ຫົວຂອງພວກເຂົາຄິດກ່ຽວກັບຄົນອື່ນ. ເຫຼົ່ານີ້ແມ່ນແຜນການທີ່ມີເຈດຕະນາດີທີ່ລົ້ມເຫລວຢ່າງໂສກເສົ້າ; ພວກເຂົາເຈົ້າບັນລຸຄໍາພະຍາກອນວ່າຖານຂໍ້ມູນຈະຖືກໄຟໄຫມ້. ແລະຂ້າພະເຈົ້າບໍ່ໄດ້ kidding ທັງຫມົດ. ຜູ້​ທີ່​ໄດ້​ຕັ້ງ​ຊື່​ນີ້​ໄດ້​ເຮັດ​ໃຫ້​ເລືອດ, ເຫື່ອ​ແລະ​ນໍ້າ​ຕາ.

ໄຊຊະນະ Pyrhic

ຄົນຫນຶ່ງຈະຄິດວ່າ Firestore ແມ່ນ ທົດແທນ Firebase, ເຊື້ອສາຍລຸ້ນຕໍ່ໄປ, ແຕ່ນັ້ນຈະເປັນການເຂົ້າໃຈຜິດ. Firestore ບໍ່ໄດ້ຮັບການຮັບປະກັນວ່າເປັນການທົດແທນທີ່ເຫມາະສົມສໍາລັບ Firebase. ມັນເບິ່ງຄືວ່າຜູ້ໃດຜູ້ຫນຶ່ງຕັດທຸກສິ່ງທີ່ຫນ້າສົນໃຈຈາກມັນ, ແລະສັບສົນກັບສ່ວນທີ່ເຫຼືອໃນຫຼາຍວິທີ.

ຢ່າງໃດກໍຕາມ, ການເບິ່ງຢ່າງໄວວາໃນສອງຜະລິດຕະພັນອາດຈະສັບສົນທ່ານ: ພວກເຂົາເຈົ້າເບິ່ງຄືວ່າຈະເຮັດສິ່ງດຽວກັນ, ໂດຍພື້ນຖານແລ້ວ APIs ດຽວກັນແລະແມ້ແຕ່ຢູ່ໃນກອງປະຊຸມຖານຂໍ້ມູນດຽວກັນ. ຄວາມແຕກຕ່າງແມ່ນລະອຽດອ່ອນ ແລະຖືກເປີດເຜີຍໂດຍການສຶກສາປຽບທຽບຢ່າງລະມັດລະວັງຂອງເອກະສານທີ່ກວ້າງຂວາງ. ຫຼືໃນເວລາທີ່ທ່ານກໍາລັງພະຍາຍາມພອດລະຫັດທີ່ເຮັດວຽກຢ່າງສົມບູນໃນ Firebase ເພື່ອໃຫ້ມັນເຮັດວຽກກັບ Firestore. ເຖິງແມ່ນວ່າຫຼັງຈາກນັ້ນທ່ານພົບວ່າການໂຕ້ຕອບຖານຂໍ້ມູນຈະສະຫວ່າງຂຶ້ນທັນທີທີ່ທ່ານພະຍາຍາມລາກແລະວາງດ້ວຍຫນູໃນເວລາຈິງ. ຂ້ອຍເວົ້າຊ້ຳ, ຂ້ອຍບໍ່ໄດ້ເວົ້າຕະຫຼົກ.

ລູກຄ້າ Firebase ມີຄວາມສຸພາບໃນຄວາມຮູ້ສຶກທີ່ມັນ buffers ການປ່ຽນແປງແລະອັດຕະໂນມັດ retries ການປັບປຸງທີ່ໃຫ້ຄວາມສໍາຄັນກັບການດໍາເນີນງານການຂຽນຫຼ້າສຸດ. ຢ່າງໃດກໍຕາມ, Firestore ມີຂອບເຂດຈໍາກັດຂອງ 1 ການດໍາເນີນງານການຂຽນຕໍ່ເອກະສານຕໍ່ຜູ້ໃຊ້ຕໍ່ວິນາທີ, ແລະຂໍ້ຈໍາກັດນີ້ຖືກບັງຄັບໃຊ້ໂດຍເຄື່ອງແມ່ຂ່າຍ. ເມື່ອເຮັດວຽກກັບມັນ, ມັນຂຶ້ນກັບເຈົ້າເພື່ອຊອກຫາວິທີທາງອ້ອມຕົວມັນແລະປະຕິບັດການຈໍາກັດອັດຕາການປັບປຸງ, ເຖິງແມ່ນວ່າທ່ານພຽງແຕ່ພະຍາຍາມສ້າງຄໍາຮ້ອງສະຫມັກຂອງທ່ານ. ນັ້ນແມ່ນ, Firestore ແມ່ນຖານຂໍ້ມູນທີ່ໃຊ້ເວລາທີ່ແທ້ຈິງໂດຍບໍ່ມີລູກຄ້າໃນເວລາທີ່ແທ້ຈິງ, ເຊິ່ງ masquerades ເປັນຫນຶ່ງໂດຍໃຊ້ API.

ໃນທີ່ນີ້ພວກເຮົາເລີ່ມເຫັນສັນຍານທໍາອິດຂອງ Firestore's raison d'être. ຂ້ອຍອາດຈະຜິດ, ແຕ່ຂ້ອຍສົງໃສວ່າຄົນທີ່ສູງໃນການຄຸ້ມຄອງຂອງ Google ເບິ່ງ Firebase ຫຼັງຈາກການຊື້ແລະເວົ້າງ່າຍໆ, "ບໍ່, ໂອ້ພະເຈົ້າ, ບໍ່. ອັນນີ້ແມ່ນບໍ່ສາມາດຍອມຮັບໄດ້. ພຽງແຕ່ບໍ່ໄດ້ຢູ່ພາຍໃຕ້ການນໍາພາຂອງຂ້ອຍ."

ພະອົງ​ໄດ້​ປາກົດ​ຕົວ​ຈາກ​ຫ້ອງ​ຂອງ​ພະອົງ ແລະ​ປະກາດ​ວ່າ:

“ເອກະສານ JSON ໃຫຍ່ອັນໜຶ່ງບໍ? ບໍ່. ທ່ານຈະແບ່ງຂໍ້ມູນອອກເປັນເອກະສານແຍກຕ່າງຫາກ, ແຕ່ລະອັນຈະມີຂະຫນາດບໍ່ເກີນ 1 megabyte.

ມັນເບິ່ງຄືວ່າຂໍ້ຈໍາກັດດັ່ງກ່າວຈະບໍ່ລອດຈາກການພົບຄັ້ງທໍາອິດກັບຖານຜູ້ໃຊ້ທີ່ມີແຮງຈູງໃຈພຽງພໍ. ທ່ານຮູ້ວ່າມັນແມ່ນ. ຕົວຢ່າງ, ໃນບ່ອນເຮັດວຽກ, ພວກເຮົາມີຫຼາຍກວ່າຫນຶ່ງພັນເຄິ່ງຫນຶ່ງພັນການນໍາສະເຫນີ, ແລະນີ້ແມ່ນເລື່ອງປົກກະຕິຢ່າງສົມບູນ.

ດ້ວຍຂໍ້ຈໍາກັດນີ້, ທ່ານຈະຖືກບັງຄັບໃຫ້ຍອມຮັບຄວາມຈິງທີ່ວ່າ "ເອກະສານ" ຫນຶ່ງໃນຖານຂໍ້ມູນຈະບໍ່ຄ້າຍຄືກັບວັດຖຸທີ່ຜູ້ໃຊ້ອາດຈະເອີ້ນວ່າເອກະສານ.

"ອາເຣຂອງອາເຣທີ່ສາມາດ recursively ມີອົງປະກອບອື່ນໆບໍ? ບໍ່. Arrays ຈະມີພຽງແຕ່ວັດຖຸທີ່ມີຄວາມຍາວຄົງທີ່ຫຼືຕົວເລກ, ຕາມທີ່ພຣະເຈົ້າຕັ້ງໃຈ."

ດັ່ງນັ້ນ, ຖ້າທ່ານຫວັງວ່າຈະເອົາ GeoJSON ເຂົ້າໄປໃນ Firestore ຂອງທ່ານ, ທ່ານຈະເຫັນວ່ານີ້ເປັນໄປບໍ່ໄດ້. ບໍ່ມີຫຍັງທີ່ບໍ່ສາມາດຍອມຮັບໄດ້. ຂ້ອຍຫວັງວ່າເຈົ້າຈະມັກ Base64 ແລະ/ຫຼື JSON ພາຍໃນ JSON.

“ການນຳເຂົ້າ ແລະສົ່ງອອກ JSON ຜ່ານ HTTP, ເຄື່ອງມືບັນທັດຄຳສັ່ງ ຫຼືແຜງບໍລິຫານບໍ? ບໍ່. ທ່ານຈະສາມາດສົ່ງອອກ ແລະນໍາເຂົ້າຂໍ້ມູນໄປຍັງ Google Cloud Storage ເທົ່ານັ້ນ. ນັ້ນແມ່ນສິ່ງທີ່ມັນເອີ້ນວ່າໃນປັດຈຸບັນ, ຂ້າພະເຈົ້າຄິດວ່າ. ແລະເມື່ອຂ້ອຍເວົ້າວ່າ "ເຈົ້າ," ຂ້ອຍພຽງແຕ່ເວົ້າກັບຜູ້ທີ່ມີຂໍ້ມູນປະຈໍາຕົວຂອງເຈົ້າຂອງໂຄງການເທົ່ານັ້ນ. ທຸກຄົນສາມາດໄປສ້າງປີ້ໄດ້."

ດັ່ງທີ່ທ່ານສາມາດເຫັນໄດ້, ຮູບແບບຂໍ້ມູນ FireBase ແມ່ນງ່າຍທີ່ຈະອະທິບາຍ. ມັນມີເອກະສານ JSON ໃຫຍ່ອັນໜຶ່ງທີ່ເຊື່ອມໂຍງຄີ JSON ກັບເສັ້ນທາງ URL. ຖ້າທ່ານຂຽນດ້ວຍ HTTP PUT в / FireBase ແມ່ນ​ດັ່ງ​ຕໍ່​ໄປ​ນີ້​:

{
  "hello": "world"
}

ຈາກນັ້ນ GET /hello ຈະກັບຄືນມາ "world". ໂດຍພື້ນຖານແລ້ວມັນເຮັດວຽກແທ້ຕາມທີ່ເຈົ້າຄາດຫວັງ. ການເກັບກໍາວັດຖຸ FireBase /my-collection/:id ທຽບເທົ່າກັບວັດຈະນານຸກົມ JSON {"my-collection": {...}} ໃນຮາກ, ເນື້ອໃນທີ່ມີຢູ່ໃນ /my-collection:

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

ນີ້ເຮັດວຽກໄດ້ດີຖ້າຫາກວ່າແຕ່ລະ insert ມີ ID ທີ່ບໍ່ມີ collision, ທີ່ລະບົບມີການແກ້ໄຂມາດຕະຖານສໍາລັບການ.

ໃນຄໍາສັບຕ່າງໆອື່ນໆ, ຖານຂໍ້ມູນແມ່ນ 100% JSON(*) ເຂົ້າກັນໄດ້ແລະເຮັດວຽກທີ່ດີກັບ HTTP, ເຊັ່ນ CouchDB. ແຕ່ໂດຍພື້ນຖານແລ້ວທ່ານໃຊ້ມັນຜ່ານ API ທີ່ໃຊ້ເວລາທີ່ແທ້ຈິງທີ່ abstracts websockets, ການອະນຸຍາດ, ແລະການສະຫມັກ. ກະດານຜູ້ເບິ່ງແຍງມີຄວາມສາມາດທັງສອງ, ອະນຸຍາດໃຫ້ທັງການແກ້ໄຂໃນເວລາຈິງແລະການນໍາເຂົ້າ / ສົ່ງອອກ JSON. ຖ້າທ່ານເຮັດເຊັ່ນດຽວກັນໃນລະຫັດຂອງທ່ານ, ທ່ານຈະປະຫລາດໃຈວ່າລະຫັດພິເສດຈະເສຍເງິນຫຼາຍປານໃດເມື່ອທ່ານຮູ້ວ່າ patch ແລະຄວາມແຕກຕ່າງ JSON ແກ້ໄຂ 90% ຂອງວຽກງານປົກກະຕິຂອງການຈັດການສະຖານະຄົງທີ່.

ຮູບແບບຂໍ້ມູນ Firestore ແມ່ນຄ້າຍຄືກັນກັບ JSON, ແຕ່ແຕກຕ່າງກັນໃນບາງວິທີທີ່ສໍາຄັນ. ຂ້າພະເຈົ້າໄດ້ກ່າວເຖິງການຂາດ array ພາຍໃນ arrays ແລ້ວ. ຮູບແບບສໍາລັບການລວບລວມຍ່ອຍແມ່ນໃຫ້ພວກເຂົາເປັນແນວຄວາມຄິດຊັ້ນທໍາອິດ, ແຍກຕ່າງຫາກຈາກເອກະສານ JSON ທີ່ມີພວກມັນ. ເນື່ອງຈາກວ່າບໍ່ມີ serialization ທີ່ກຽມພ້ອມສໍາລັບການນີ້, ເສັ້ນທາງລະຫັດພິເສດແມ່ນຈໍາເປັນເພື່ອດຶງຂໍ້ມູນແລະຂຽນຂໍ້ມູນ. ເພື່ອປະມວນຜົນການເກັບກໍາຂອງທ່ານເອງ, ທ່ານຈໍາເປັນຕ້ອງຂຽນສະຄິບແລະເຄື່ອງມືຂອງທ່ານເອງ. ແຜງຄວບຄຸມພຽງແຕ່ອະນຸຍາດໃຫ້ທ່ານເຮັດການປ່ຽນແປງຂະຫນາດນ້ອຍຫນຶ່ງຊ່ອງຂໍ້ມູນໃນເວລານັ້ນ, ແລະບໍ່ມີຄວາມສາມາດນໍາເຂົ້າ / ສົ່ງອອກ.

ພວກເຂົາເຈົ້າໄດ້ເອົາຖານຂໍ້ມູນ NoSQL ໃນເວລາທີ່ແທ້ຈິງແລະປ່ຽນມັນເຂົ້າໄປໃນທີ່ບໍ່ແມ່ນ SQL ຊ້າທີ່ມີການເຂົ້າຮ່ວມອັດຕະໂນມັດແລະຖັນທີ່ບໍ່ແມ່ນ JSON ແຍກຕ່າງຫາກ. ບາງສິ່ງບາງຢ່າງເຊັ່ນ: GraftQL.

Java ຮ້ອນ

ຖ້າ Firestore ຄວນຈະມີຄວາມຫນ້າເຊື່ອຖືແລະສາມາດປັບຂະຫນາດໄດ້, ດັ່ງນັ້ນສິ່ງທີ່ຫນ້າກຽດຊັງແມ່ນວ່າຜູ້ພັດທະນາສະເລ່ຍຈະສິ້ນສຸດດ້ວຍການແກ້ໄຂທີ່ຫນ້າເຊື່ອຖືຫນ້ອຍກວ່າການເລືອກ FireBase ອອກຈາກກ່ອງ. ປະເພດຂອງຊອບແວທີ່ Grumpy Database Administrator ຕ້ອງການຮຽກຮ້ອງໃຫ້ມີລະດັບຂອງຄວາມພະຍາຍາມແລະ calibre ຂອງພອນສະຫວັນທີ່ເປັນພຽງແຕ່ unrealistic ສໍາລັບ niche ຜະລິດຕະພັນແມ່ນ supposed ຈະດີຢູ່. ນີ້ແມ່ນຄ້າຍຄືກັນກັບວິທີການ HTML5 Canvas ບໍ່ແມ່ນການທົດແທນ Flash ທັງຫມົດຖ້າບໍ່ມີເຄື່ອງມືພັດທະນາແລະເຄື່ອງຫຼີ້ນ. ຍິ່ງໄປກວ່ານັ້ນ, Firestore ແມ່ນຕິດຢູ່ໃນຄວາມປາຖະຫນາສໍາລັບຄວາມບໍລິສຸດຂອງຂໍ້ມູນແລະການກວດສອບການເປັນຫມັນທີ່ພຽງແຕ່ບໍ່ສອດຄ່ອງກັບວິທີການຂອງຜູ້ໃຊ້ທຸລະກິດໂດຍສະເລ່ຍ. ຮັກທີ່ຈະເຮັດວຽກ: ສໍາລັບລາວທຸກສິ່ງທຸກຢ່າງແມ່ນທາງເລືອກ, ເພາະວ່າຈົນກ່ວາໃນຕອນທ້າຍຂອງທຸກສິ່ງທຸກຢ່າງແມ່ນເປັນຮ່າງ.

ຂໍ້ເສຍປຽບຕົ້ນຕໍຂອງ FireBase ແມ່ນວ່າລູກຄ້າໄດ້ຖືກສ້າງຂື້ນຫຼາຍປີກ່ອນເວລາຂອງມັນ, ກ່ອນທີ່ຜູ້ພັດທະນາເວັບສ່ວນໃຫຍ່ຮູ້ກ່ຽວກັບຄວາມບໍ່ປ່ຽນແປງ. ເນື່ອງຈາກວ່ານີ້, FireBase ສົມມຸດວ່າທ່ານຈະປ່ຽນແປງຂໍ້ມູນແລະດັ່ງນັ້ນຈິ່ງບໍ່ໄດ້ໃຊ້ປະໂຫຍດຈາກຄວາມບໍ່ປ່ຽນແປງທີ່ຜູ້ໃຊ້ສະຫນອງໃຫ້. ນອກຈາກນັ້ນ, ມັນບໍ່ໄດ້ໃຊ້ຄືນຂໍ້ມູນໃນພາບຖ່າຍທີ່ມັນສົ່ງກັບຜູ້ໃຊ້, ເຊິ່ງເຮັດໃຫ້ຄວາມແຕກຕ່າງມີຄວາມຫຍຸ້ງຍາກຫຼາຍ. ສໍາລັບເອກະສານຂະຫນາດໃຫຍ່, ກົນໄກການເຮັດທຸລະກໍາທີ່ອີງໃສ່ຄວາມແຕກຕ່າງທີ່ສາມາດປ່ຽນແປງໄດ້ແມ່ນບໍ່ພຽງພໍ. guys, ພວກເຮົາມີແລ້ວ WeakMap ໃນ JavaScript. ມັນສະດວກສະບາຍ.

ຖ້າທ່ານໃຫ້ຂໍ້ມູນຮູບຮ່າງທີ່ຕ້ອງການແລະບໍ່ເຮັດໃຫ້ຕົ້ນໄມ້ມີແສງສະຫວ່າງເກີນໄປ, ບັນຫານີ້ສາມາດຫລີກລ້ຽງໄດ້. ແຕ່ຂ້ອຍຢາກຮູ້ຢາກເຫັນຖ້າ FireBase ຈະມີຄວາມຫນ້າສົນໃຈຫຼາຍຖ້າຜູ້ພັດທະນາໄດ້ປ່ອຍ API ລູກຄ້າທີ່ດີແທ້ໆທີ່ໃຊ້ immutability ສົມທົບກັບຄໍາແນະນໍາການປະຕິບັດທີ່ຮຸນແຮງບາງຢ່າງກ່ຽວກັບການອອກແບບຖານຂໍ້ມູນ. ແທນທີ່ຈະ, ເບິ່ງຄືວ່າພວກເຂົາພະຍາຍາມແກ້ໄຂສິ່ງທີ່ບໍ່ແຕກ, ແລະເຮັດໃຫ້ມັນຮ້າຍແຮງກວ່າເກົ່າ.

ຂ້ອຍບໍ່ຮູ້ເຫດຜົນທັງໝົດທີ່ຢູ່ເບື້ອງຫຼັງການສ້າງ Firestore. ການຄາດເດົາກ່ຽວກັບແຮງຈູງໃຈທີ່ເກີດຂື້ນພາຍໃນກ່ອງດໍາກໍ່ເປັນສ່ວນຫນຶ່ງຂອງຄວາມມ່ວນ. ການປຽບທຽບຂອງສອງຖານຂໍ້ມູນທີ່ຄ້າຍຄືກັນທີ່ສຸດແຕ່ບໍ່ສາມາດປຽບທຽບໄດ້ແມ່ນຂ້ອນຂ້າງຫາຍາກ. ມັນຄືກັບຄົນທີ່ຄິດ: "Firebase ແມ່ນພຽງແຕ່ຟັງຊັນທີ່ພວກເຮົາສາມາດເຮັດຕາມໃນ Google Cloud", ແຕ່ຍັງບໍ່ທັນໄດ້ຄົ້ນພົບແນວຄວາມຄິດຂອງການກໍານົດຄວາມຕ້ອງການຂອງໂລກທີ່ແທ້ຈິງຫຼືການສ້າງການແກ້ໄຂທີ່ເປັນປະໂຫຍດທີ່ຕອບສະຫນອງຄວາມຕ້ອງການທັງຫມົດເຫຼົ່ານັ້ນ. "ໃຫ້ນັກພັດທະນາຄິດກ່ຽວກັບມັນ. ພຽງແຕ່ເຮັດໃຫ້ UI ສວຍງາມ ... ເຈົ້າສາມາດເພີ່ມໄຟໄດ້ບໍ?”

ຂ້ອຍເຂົ້າໃຈສອງສາມຢ່າງກ່ຽວກັບໂຄງສ້າງຂໍ້ມູນ. ຂ້າພະເຈົ້າແນ່ນອນເຫັນແນວຄວາມຄິດ "ທຸກສິ່ງທຸກຢ່າງຢູ່ໃນຕົ້ນໄມ້ JSON ໃຫຍ່ຫນຶ່ງ" ເປັນຄວາມພະຍາຍາມທີ່ຈະ abstract ຄວາມຮູ້ສຶກຂອງໂຄງສ້າງຂະຫນາດໃຫຍ່ຈາກຖານຂໍ້ມູນ. ການຄາດຫວັງວ່າຊອບແວທີ່ຈະຮັບມືກັບໂຄງສ້າງຂໍ້ມູນທີ່ຫນ້າສົງໄສໃດໆ fractal ແມ່ນບ້າ. ຂ້ອຍບໍ່ຈໍາເປັນຕ້ອງຈິນຕະນາການວ່າສິ່ງທີ່ບໍ່ດີອາດຈະເປັນແນວໃດ, ຂ້ອຍໄດ້ເຮັດການກວດສອບລະຫັດຢ່າງເຂັ້ມງວດແລະ ຂ້ອຍເຫັນສິ່ງທີ່ເຈົ້າບໍ່ເຄີຍຝັນ. ແຕ່ຂ້ອຍຍັງຮູ້ວ່າໂຄງສ້າງທີ່ດີຈະເປັນແນວໃດ, ວິທີການນໍາໃຊ້ພວກມັນ и ເປັນຫຍັງອັນນີ້ຄວນເຮັດ. ຂ້ອຍສາມາດຈິນຕະນາການໂລກທີ່ Firestore ເບິ່ງຄືວ່າມີເຫດຜົນແລະຄົນທີ່ສ້າງມັນຈະຄິດວ່າພວກເຂົາເຮັດໄດ້ດີ. ແຕ່ພວກເຮົາບໍ່ໄດ້ອາໄສຢູ່ໃນໂລກນີ້.

ການສະຫນັບສະຫນູນການສອບຖາມຂອງ FireBase ແມ່ນບໍ່ດີໂດຍມາດຕະຖານໃດກໍ່ຕາມແລະແມ່ນບໍ່ມີຢູ່. ມັນແນ່ນອນຕ້ອງການການປັບປຸງຫຼືຢ່າງຫນ້ອຍການດັດແກ້. ແຕ່ Firestore ບໍ່ໄດ້ດີກວ່າຫຼາຍເພາະວ່າມັນຈໍາກັດກັບດັດສະນີຫນຶ່ງມິຕິລະດັບດຽວກັນທີ່ພົບໃນ SQL ທໍາມະດາ. ຖ້າທ່ານຕ້ອງການການສອບຖາມທີ່ຜູ້ຄົນດໍາເນີນການກັບຂໍ້ມູນ chaotic, ທ່ານຕ້ອງການການຄົ້ນຫາແບບເຕັມຮູບແບບ, ການກັ່ນຕອງຫຼາຍໄລຍະ, ແລະຄໍາສັ່ງທີ່ຜູ້ໃຊ້ກໍານົດເອງ. ຫຼັງຈາກການກວດກາຢ່າງໃກ້ຊິດ, ຫນ້າທີ່ຂອງ SQL ທໍາມະດາແມ່ນຈໍາກັດເກີນໄປຂອງຕົນເອງ. ນອກຈາກນັ້ນ, ຄໍາຖາມ SQL ເທົ່ານັ້ນທີ່ຄົນສາມາດດໍາເນີນການໃນການຜະລິດແມ່ນການສອບຖາມທີ່ໄວ. ທ່ານຈະຕ້ອງການການແກ້ໄຂດັດສະນີແບບກຳນົດເອງທີ່ມີໂຄງສ້າງຂໍ້ມູນທີ່ຄິດ. ສໍາລັບທຸກສິ່ງທຸກຢ່າງອື່ນ, ຢ່າງຫນ້ອຍຄວນຈະມີແຜນທີ່ incremental-reduce ຫຼືບາງສິ່ງບາງຢ່າງທີ່ຄ້າຍຄືກັນ.

ຖ້າທ່ານຄົ້ນຫາ Google Docs ສໍາລັບຂໍ້ມູນກ່ຽວກັບເລື່ອງນີ້, ທ່ານຫວັງວ່າຈະຖືກຊີ້ໃຫ້ເຫັນໃນທິດທາງຂອງບາງສິ່ງບາງຢ່າງເຊັ່ນ: BigTable ແລະ BigQuery. ຢ່າງໃດກໍຕາມ, ການແກ້ໄຂທັງຫມົດເຫຼົ່ານີ້ແມ່ນປະກອບດ້ວຍຄໍາທີ່ໃຊ້ໃນການຂາຍຂອງບໍລິສັດທີ່ຫນາແຫນ້ນຫຼາຍທີ່ເຈົ້າຈະກັບຄືນຢ່າງໄວວາແລະເລີ່ມຊອກຫາສິ່ງອື່ນ.

ສິ່ງສຸດທ້າຍທີ່ທ່ານຕ້ອງການກັບຖານຂໍ້ມູນທີ່ໃຊ້ເວລາທີ່ແທ້ຈິງແມ່ນບາງສິ່ງບາງຢ່າງທີ່ເຮັດໂດຍແລະສໍາລັບປະຊາຊົນກ່ຽວກັບການຄຸ້ມຄອງການຈ່າຍຄ່າ.

(*) ອັນ​ນີ້​ເປັນ​ເລື່ອງ​ຕະຫຼົກ​ບໍ່​ມີ 100% JSON ເຂົ້າກັນໄດ້.

ກ່ຽວກັບສິດທິຂອງການໂຄສະນາ

ຊອກ​ຫາ VDS ສໍາລັບໂຄງການ debugging, ເຄື່ອງແມ່ຂ່າຍສໍາລັບການພັດທະນາແລະໂຮດຕິ້ງ? ທ່ານແມ່ນລູກຄ້າຂອງພວກເຮົາແນ່ນອນ 🙂 ລາຄາປະຈໍາວັນສໍາລັບເຄື່ອງແມ່ຂ່າຍຂອງການຕັ້ງຄ່າຕ່າງໆ, ໃບອະນຸຍາດຕ້ານ DDoS ແລະ Windows ແມ່ນລວມຢູ່ໃນລາຄາແລ້ວ.

ແຫຼ່ງຂໍ້ມູນ: www.habr.com