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

ຖ້າທ່ານຮູ້ສຶກວ່າຂ້ອຍກໍາລັງປ້ອງກັນ MongoDB, ກະລຸນາອ່ານ ການປະຕິເສດຄວາມຮັບຜິດຊອບ ໃນຕອນທ້າຍຂອງບົດຄວາມ.

ແນວໂນ້ມ ໃໝ່

ຂ້າພະເຈົ້າໄດ້ເຮັດວຽກຢູ່ໃນອຸດສາຫະກໍາຊໍແວສໍາລັບປີຫຼາຍກວ່າທີ່ຂ້ອຍສາມາດເວົ້າໄດ້, ແຕ່ຂ້ອຍຍັງໄດ້ຮັບການເປີດເຜີຍພຽງແຕ່ສ່ວນນ້ອຍໆຂອງແນວໂນ້ມທີ່ຕີອຸດສາຫະກໍາຂອງພວກເຮົາ. ຂ້າພະເຈົ້າໄດ້ເຫັນການເພີ່ມຂຶ້ນຂອງ 4GL, AOP, Agile, SOA, Web 2.0, AJAX, Blockchain ... ບັນຊີລາຍຊື່ແມ່ນບໍ່ມີທີ່ສິ້ນສຸດ. ທຸກໆປີແນວໂນ້ມໃຫມ່ຈະປາກົດ. ບາງຄົນຫາຍໄປຢ່າງໄວວາ, ໃນຂະນະທີ່ຄົນອື່ນປ່ຽນວິທີການພັດທະນາຊອບແວໂດຍພື້ນຖານ.

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

ແຕ່ບາງຄັ້ງການປະດິດສ້າງໃຫມ່ປະກົດຂຶ້ນ (ຫຼືມີການມາຄັ້ງທີສອງ, ເຊັ່ນດຽວກັບໃນກໍລະນີນີ້) ຂັບເຄື່ອນໂດຍການປະຕິບັດສະເພາະຫນຶ່ງເທົ່ານັ້ນ. ໃນກໍລະນີຂອງ NoSQL, hype ໄດ້ຖືກຂັບເຄື່ອນຢ່າງຫນັກໂດຍການເກີດໃຫມ່ແລະການເພີ່ມຂຶ້ນ meteoric ຂອງ MongoDB. MongoDB ບໍ່ໄດ້ເລີ່ມຕົ້ນແນວໂນ້ມນີ້: ໃນຄວາມເປັນຈິງ, ບໍລິສັດອິນເຕີເນັດຂະຫນາດໃຫຍ່ເລີ່ມມີບັນຫາໃນການປຸງແຕ່ງຂໍ້ມູນຈໍານວນຫລາຍ, ເຊິ່ງນໍາໄປສູ່ການກັບຄືນຂອງຖານຂໍ້ມູນທີ່ບໍ່ກ່ຽວຂ້ອງ. ການເຄື່ອນໄຫວໂດຍລວມເລີ່ມຕົ້ນດ້ວຍໂຄງການເຊັ່ນ: Bigtable ຂອງ Google ແລະ Cassandra ຂອງ Facebook, ແຕ່ວ່າມັນແມ່ນ MongoDB ທີ່ໄດ້ກາຍເປັນການປະຕິບັດຖານຂໍ້ມູນ NoSQL ທີ່ມີຊື່ສຽງແລະສາມາດເຂົ້າເຖິງໄດ້ຫຼາຍທີ່ສຸດທີ່ນັກພັດທະນາສ່ວນໃຫຍ່ສາມາດເຂົ້າເຖິງໄດ້.

ໝາຍເຫດ: ເຈົ້າອາດຄິດວ່າຂ້ອຍສັບສົນກັບຖານຂໍ້ມູນຂອງຖັນແຖວ, ເກັບຮັກສາຂໍ້ມູນສຳຄັນ ຫຼື ປະເພດອື່ນຈຳນວນຫຼາຍທີ່ຢູ່ພາຍໃຕ້ຄຳນິຍາມ NoSQL ທົ່ວໄປ. ແລະເຈົ້າເວົ້າຖືກ. ແຕ່ໃນເວລານັ້ນ chaos ໄດ້ປົກຄອງ. ບຸກຄົນທຸກຄົນແມ່ນ obsessed ກັບ NoSQL, ມັນໄດ້ກາຍເປັນທຸກຄົນ ຢ່າງແທ້ຈິງ ມີຄວາມຈໍາເປັນ, ເຖິງແມ່ນວ່າຈໍານວນຫຼາຍບໍ່ໄດ້ເຫັນຄວາມແຕກຕ່າງໃນເຕັກໂນໂລຢີທີ່ແຕກຕ່າງກັນ. ສໍາລັບຈໍານວນຫຼາຍ, MongoDB ໄດ້ກາຍເປັນ ຄ້າຍຄືກັນ NoSQL.

ແລະ​ຜູ້​ພັດ​ທະ​ນາ pounced ສຸດ​ມັນ​. ແນວຄວາມຄິດຂອງຖານຂໍ້ມູນ schemaless ທີ່ magically scales ເພື່ອແກ້ໄຂບັນຫາໃດຫນຶ່ງແມ່ນຂ້ອນຂ້າງ tempting. ປະມານປີ 2014, ມັນເບິ່ງຄືວ່າຢູ່ທົ່ວທຸກແຫ່ງຂອງປີທີ່ຜ່ານມາໄດ້ນໍາໃຊ້ຖານຂໍ້ມູນທີ່ກ່ຽວຂ້ອງເຊັ່ນ MySQL, Postgres ຫຼື SQL Server ໄດ້ເລີ່ມຕົ້ນທີ່ຈະນໍາໃຊ້ຖານຂໍ້ມູນ MongoDB. ເມື່ອຖືກຖາມວ່າເປັນຫຍັງ, ເຈົ້າສາມາດໄດ້ຮັບຄໍາຕອບຈາກ banal "ນີ້ແມ່ນຂະຫນາດຂອງເວັບໄຊຕ໌" ກັບຄວາມຄິດຫຼາຍ "ຂໍ້ມູນຂອງຂ້ອຍມີໂຄງສ້າງວ່າງຫຼາຍແລະເຫມາະກັບຖານຂໍ້ມູນທີ່ບໍ່ມີ schema."

ມັນເປັນສິ່ງສໍາຄັນທີ່ຈະຈື່ຈໍາວ່າ MongoDB, ແລະຖານຂໍ້ມູນເອກະສານໂດຍທົ່ວໄປ, ແກ້ໄຂບັນຫາຈໍານວນຫນຶ່ງກັບຖານຂໍ້ມູນທີ່ກ່ຽວຂ້ອງແບບດັ້ງເດີມ:

• ໂຄງການທີ່ເຄັ່ງຄັດ: ດ້ວຍຖານຂໍ້ມູນທີ່ກ່ຽວຂ້ອງ, ຖ້າທ່ານມີຂໍ້ມູນສ້າງແບບເຄື່ອນໄຫວ, ທ່ານຖືກບັງຄັບໃຫ້ສ້າງຄໍລໍາ "ອື່ນໆ" ແບບສຸ່ມຂອງຂໍ້ມູນ, ເລື່ອນຂໍ້ມູນໃນບ່ອນນັ້ນ, ຫຼືໃຊ້ການຕັ້ງຄ່າ. EAV...ທັງໝົດນີ້ມີຂໍ້ບົກຜ່ອງອັນສຳຄັນ.
• ການ​ປັບ​ຂະ​ຫນາດ​ຄວາມ​ຫຍຸ້ງ​ຍາກ​: ຖ້າມີຂໍ້ມູນຫຼາຍທີ່ມັນບໍ່ເຫມາະສົມກັບເຄື່ອງແມ່ຂ່າຍດຽວ, MongoDB ສະເຫນີກົນໄກເພື່ອໃຫ້ມັນສາມາດຂະຫຍາຍໄດ້ໃນທົ່ວເຄື່ອງຈັກຫຼາຍເຄື່ອງ.
• ການປ່ຽນແປງວົງຈອນສະລັບສັບຊ້ອນ: ບໍ່ມີການເຄື່ອນຍ້າຍ! ໃນຖານຂໍ້ມູນທີ່ກ່ຽວຂ້ອງ, ການປ່ຽນແປງໂຄງສ້າງຖານຂໍ້ມູນສາມາດເປັນບັນຫາໃຫຍ່ (ໂດຍສະເພາະເມື່ອມີຂໍ້ມູນຫຼາຍ). MongoDB ສາມາດເຮັດໃຫ້ຂະບວນການງ່າຍຂຶ້ນຫຼາຍ. ແລະມັນເຮັດໃຫ້ມັນງ່າຍຫຼາຍທີ່ທ່ານພຽງແຕ່ສາມາດປັບປຸງວົງຈອນໃນຂະນະທີ່ທ່ານໄປແລະຍ້າຍອອກໄປຢ່າງໄວວາ.
• ການປະຕິບັດການບັນທຶກ: ການປະຕິບັດ MongoDB ແມ່ນດີ, ໂດຍສະເພາະເມື່ອມີການຕັ້ງຄ່າຢ່າງຖືກຕ້ອງ. ເຖິງແມ່ນວ່າການຕັ້ງຄ່ານອກກ່ອງຂອງ MongoDB, ເຊິ່ງມັນມັກຈະຖືກວິພາກວິຈານ, ສະແດງໃຫ້ເຫັນຕົວເລກການປະຕິບັດທີ່ຫນ້າປະທັບໃຈ.

ຄວາມສ່ຽງທັງຫມົດແມ່ນຢູ່ໃນທ່ານ

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

ເພື່ອໃຫ້ມີຄວາມຍຸຕິທໍາ, ບໍ່ມີໃຜຢູ່ 10gen / MongoDB Inc. ຈະບໍ່ເວົ້າວ່າຕໍ່ໄປນີ້ບໍ່ແມ່ນຄວາມຈິງ, ເຫຼົ່ານີ້ແມ່ນພຽງແຕ່ການປະນີປະນອມ.

• ການເຮັດທຸລະກໍາທີ່ສູນເສຍ: ການເຮັດທຸລະກໍາເປັນລັກສະນະຫຼັກຂອງຖານຂໍ້ມູນທີ່ກ່ຽວຂ້ອງຫຼາຍ (ບໍ່ແມ່ນທັງຫມົດ, ແຕ່ຫຼາຍທີ່ສຸດ). ການເຮັດທຸລະກໍາຫມາຍຄວາມວ່າທ່ານສາມາດດໍາເນີນການຫຼາຍປະລໍາມະນູແລະສາມາດຮັບປະກັນວ່າຂໍ້ມູນຍັງຄົງສອດຄ່ອງ. ແນ່ນອນ, ດ້ວຍຖານຂໍ້ມູນ NoSQL, ການເຮັດທຸລະກໍາສາມາດຢູ່ໃນເອກະສານດຽວ, ຫຼືທ່ານສາມາດນໍາໃຊ້ຄໍາຫມັ້ນສັນຍາສອງໄລຍະເພື່ອໃຫ້ໄດ້ຄໍາສັນຍາການເຮັດທຸລະກໍາ. ແຕ່ທ່ານຈະຕ້ອງປະຕິບັດຫນ້າທີ່ນີ້ຕົວທ່ານເອງ ... ເຊິ່ງອາດຈະເປັນວຽກທີ່ຫຍຸ້ງຍາກແລະໃຊ້ເວລາຫຼາຍ. ເລື້ອຍໆທ່ານບໍ່ຮູ້ວ່າມີບັນຫາຈົນກ່ວາທ່ານຈະເຫັນຂໍ້ມູນໃນຖານຂໍ້ມູນສິ້ນສຸດລົງຢູ່ໃນສະຖານະທີ່ບໍ່ຖືກຕ້ອງເພາະວ່າປະລໍາມະນູຂອງການດໍາເນີນງານບໍ່ສາມາດຮັບປະກັນໄດ້. ຫມາຍເຫດ: ຫຼາຍຄົນບອກຂ້ອຍວ່າ MongoDB 4.0 ໄດ້ນໍາສະເຫນີການເຮັດທຸລະກໍາໃນປີກາຍນີ້, ແຕ່ມີຂໍ້ຈໍາກັດບາງຢ່າງ. ເອົາອອກຈາກບົດຄວາມຍັງຄົງຢູ່ຄືກັນ: ປະເມີນວ່າເຕັກໂນໂລຢີຕອບສະຫນອງຄວາມຕ້ອງການຂອງເຈົ້າດີເທົ່າໃດ.
• ການສູນເສຍຄວາມສົມບູນຂອງຄວາມສໍາພັນ (ກະແຈຕ່າງປະເທດ): ຖ້າຂໍ້ມູນຂອງທ່ານມີຄວາມສໍາພັນ, ຫຼັງຈາກນັ້ນທ່ານຈະຕ້ອງໃຊ້ພວກມັນໃນແອັບພລິເຄຊັນ. ການມີຖານຂໍ້ມູນທີ່ເຄົາລົບຄວາມສໍາພັນເຫຼົ່ານີ້ຈະໃຊ້ເວລາຫຼາຍຂອງການເຮັດວຽກອອກຈາກຄໍາຮ້ອງສະຫມັກແລະດັ່ງນັ້ນຜູ້ຂຽນໂປລແກລມຂອງທ່ານ.
• ການຂາດຄວາມສາມາດໃນການນໍາໃຊ້ໂຄງສ້າງຂໍ້ມູນ: schemas ທີ່ເຄັ່ງຄັດບາງຄັ້ງສາມາດເປັນບັນຫາໃຫຍ່, ແຕ່ພວກມັນຍັງເປັນກົນໄກທີ່ມີປະສິດທິພາບສໍາລັບໂຄງສ້າງຂໍ້ມູນທີ່ດີຖ້າໃຊ້ຢ່າງສະຫລາດ. ຖານຂໍ້ມູນເອກະສານເຊັ່ນ MongoDB ສະຫນອງຄວາມຍືດຫຍຸ່ນ schema ທີ່ບໍ່ຫນ້າເຊື່ອ, ແຕ່ຄວາມຍືດຫຍຸ່ນນີ້ເອົາຄວາມຮັບຜິດຊອບໃນການຮັກສາຂໍ້ມູນໃຫ້ສະອາດ. ຖ້າທ່ານບໍ່ດູແລພວກມັນ, ທ່ານຈະສິ້ນສຸດການຂຽນລະຫັດຈໍານວນຫລາຍໃນແອັບພລິເຄຊັນຂອງທ່ານເພື່ອບັນຊີຂໍ້ມູນທີ່ບໍ່ໄດ້ເກັບໄວ້ໃນຮູບແບບທີ່ທ່ານຄາດຫວັງ. ດັ່ງທີ່ພວກເຮົາມັກຈະເວົ້າຢູ່ບໍລິສັດ Simple Thread ຂອງພວກເຮົາ ... ແອັບພລິເຄຊັນຈະຖືກຂຽນຄືນໃຫມ່, ແຕ່ຂໍ້ມູນຈະມີຊີວິດຢູ່ຕະຫຼອດໄປ. ຫມາຍເຫດ: MongoDB ສະຫນັບສະຫນູນການກວດສອບ schema: ມັນເປັນປະໂຫຍດ, ແຕ່ບໍ່ໄດ້ສະຫນອງການຄໍ້າປະກັນຄືກັນກັບໃນຖານຂໍ້ມູນທີ່ກ່ຽວຂ້ອງ. ກ່ອນອື່ນ ໝົດ, ການເພີ່ມຫຼືການປ່ຽນແປງການກວດສອບ schema ບໍ່ມີຜົນກະທົບຕໍ່ຂໍ້ມູນທີ່ມີຢູ່ໃນການເກັບກໍາ. ມັນຂຶ້ນກັບທ່ານເພື່ອຮັບປະກັນວ່າທ່ານປັບປຸງຂໍ້ມູນຕາມ schema ໃຫມ່. ຕັດ​ສິນ​ໃຈ​ດ້ວຍ​ຕົວ​ທ່ານ​ເອງ​ວ່າ​ນີ້​ແມ່ນ​ພຽງ​ພໍ​ສໍາ​ລັບ​ຄວາມ​ຕ້ອງ​ການ​ຂອງ​ທ່ານ​.
• ພາສາແບບສອບຖາມພື້ນເມືອງ / ການສູນເສຍລະບົບນິເວດຂອງເຄື່ອງມື: ການມາເຖິງຂອງ SQL ແມ່ນການປະຕິວັດຢ່າງແທ້ຈິງແລະບໍ່ມີຫຍັງປ່ຽນແປງຕັ້ງແຕ່ນັ້ນມາ. ມັນເປັນພາສາທີ່ມີອໍານາດຢ່າງບໍ່ຫນ້າເຊື່ອ, ແຕ່ຍັງສັບສົນຫຼາຍ. ຄວາມຕ້ອງການທີ່ຈະສ້າງການສອບຖາມຖານຂໍ້ມູນໃນພາສາໃຫມ່ທີ່ປະກອບດ້ວຍ JSON fragments ຖືວ່າເປັນບາດກ້າວອັນໃຫຍ່ຫຼວງກັບຄືນໄປບ່ອນໂດຍຜູ້ທີ່ມີປະສົບການເຮັດວຽກກັບ SQL. ມີຈັກກະວານທັງຫມົດຂອງເຄື່ອງມືທີ່ພົວພັນກັບຖານຂໍ້ມູນ SQL, ຈາກ IDEs ໄປຫາເຄື່ອງມືລາຍງານ. ການເຄື່ອນຍ້າຍໄປຫາຖານຂໍ້ມູນທີ່ບໍ່ສະຫນັບສະຫນູນ SQL ຫມາຍຄວາມວ່າທ່ານບໍ່ສາມາດໃຊ້ເຄື່ອງມືເຫຼົ່ານີ້ສ່ວນໃຫຍ່ຫຼືທ່ານຕ້ອງແປຂໍ້ມູນເປັນ SQL ເພື່ອໃຊ້ພວກມັນ, ເຊິ່ງອາດຈະມີຄວາມຫຍຸ້ງຍາກຫຼາຍກ່ວາທີ່ທ່ານຄິດ.

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

ສິ່ງທີ່ສາມາດເຮັດໄດ້ແຕກຕ່າງກັນ?

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

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

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

ຖ້າທ່ານບໍ່ໄດ້ປະເຊີນກັບບັນຫາໃດກໍ່ຕາມ, ທ່ານບໍ່ຈໍາເປັນຕ້ອງມີເຄື່ອງມືໃຫມ່. ຈຸດ.

ຄໍາຖາມທີ 1: ຂ້ອຍພະຍາຍາມແກ້ໄຂບັນຫາໃດແດ່?

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

ຄຳຖາມທີ 2: ຂ້ອຍຂາດຫຍັງ?

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

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

ປະຊາຊົນສະເຫມີທໍາລາຍທຸກສິ່ງທຸກຢ່າງ

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

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

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

Summary

ເມື່ອໃດກໍ່ຕາມການປະດິດສ້າງປະກົດຂຶ້ນ, ສອງຄໍາຖາມຕ້ອງໄດ້ຮັບການຕອບດ້ວຍຄວາມລະມັດລະວັງ:

• ເຄື່ອງມືນີ້ແກ້ໄຂບັນຫາທີ່ແທ້ຈິງບໍ?
• ພວກ​ເຮົາ​ເຂົ້າ​ໃຈ​ການ​ແລກ​ປ່ຽນ​ໄດ້​ດີ?

ຖ້າເຈົ້າບໍ່ສາມາດຕອບສອງຄຳຖາມນີ້ຢ່າງໝັ້ນໃຈໄດ້, ໃຫ້ເອົາສອງສາມຂັ້ນຕອນກັບຄືນແລ້ວຄິດ.

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

ປະຕິເສດຄວາມຮັບຜິດຊອບ

ຂ້ອຍຕ້ອງການໃຫ້ຄວາມກະຈ່າງແຈ້ງວ່າຂ້ອຍບໍ່ມີຄວາມສໍາພັນກັບຄວາມຮັກຫຼືຄວາມກຽດຊັງກັບ MongoDB. ພວກເຮົາພຽງແຕ່ບໍ່ມີປະເພດຂອງບັນຫາທີ່ MongoDB ເຫມາະສົມທີ່ສຸດທີ່ຈະແກ້ໄຂ. ຂ້ອຍຮູ້ວ່າ 10gen/MongoDB Inc. ມີຄວາມກ້າຫານຫຼາຍໃນຕອນທໍາອິດ, ກໍານົດຄ່າເລີ່ມຕົ້ນທີ່ບໍ່ປອດໄພແລະສົ່ງເສີມ MongoDB ຢູ່ທົ່ວທຸກແຫ່ງ (ໂດຍສະເພາະໃນ hackathons) ເປັນການແກ້ໄຂທົ່ວໄປສໍາລັບການເຮັດວຽກກັບຂໍ້ມູນໃດໆ. ມັນອາດຈະເປັນການຕັດສິນໃຈທີ່ບໍ່ດີ. ແຕ່ມັນຢືນຢັນວິທີການທີ່ອະທິບາຍຢູ່ທີ່ນີ້: ບັນຫາເຫຼົ່ານີ້ສາມາດຖືກກວດພົບໄດ້ໄວເຖິງແມ່ນວ່າຈະມີການປະເມີນດ້ານເຕັກໂນໂລຢີຢ່າງເລິກເຊິ່ງ.

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