PostgreSQL ແລະ JDBC ບີບນ້ໍາອອກທັງຫມົດ. Vladimir Sitnikov

ຂ້າພະເຈົ້າແນະນໍາໃຫ້ທ່ານອ່ານບົດບັນທຶກຂອງບົດລາຍງານຕົ້ນປີ 2016 ຂອງ Vladimir Sitnikov "PostgreSQL ແລະ JDBC ກໍາລັງບີບນ້ໍາອອກທັງຫມົດ"

ສະ​ບາຍ​ດີ​ຕອນ​ສວາຍ ຂ້ອຍຊື່ Vladimir Sitnikov. ຂ້າພະເຈົ້າໄດ້ເຮັດວຽກສໍາລັບ NetCracker ສໍາລັບ 10 ປີ. ແລະຂ້ອຍສ່ວນຫຼາຍແມ່ນຢູ່ໃນຜົນຜະລິດ. ທຸກສິ່ງທຸກຢ່າງທີ່ກ່ຽວຂ້ອງກັບ Java, ທຸກສິ່ງທຸກຢ່າງທີ່ກ່ຽວຂ້ອງກັບ SQL ແມ່ນສິ່ງທີ່ຂ້ອຍຮັກ.

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

ພວກເຮົາຈະສົນທະນາ:

• ກ່ຽວກັບການເກັບຕົວຢ່າງຂໍ້ມູນ.
• ກ່ຽວກັບການບັນທຶກຂໍ້ມູນ.
• ແລະຍັງກ່ຽວກັບການປະຕິບັດ.
• ແລະກ່ຽວກັບ rakes underwater ທີ່ຖືກຝັງຢູ່ທີ່ນັ້ນ.

ໃຫ້ເລີ່ມຕົ້ນດ້ວຍຄໍາຖາມງ່າຍໆ. ພວກເຮົາເລືອກຫນຶ່ງແຖວຈາກຕາຕະລາງໂດຍອີງໃສ່ລະຫັດຕົ້ນຕໍ.

ຖານຂໍ້ມູນແມ່ນຕັ້ງຢູ່ໃນໂຮດດຽວກັນ. ແລະການກະສິກໍາທັງຫມົດນີ້ໃຊ້ເວລາ 20 milliseconds.

20 milliseconds ເຫຼົ່ານີ້ແມ່ນຫຼາຍ. ຖ້າທ່ານມີ 100 ຄໍາຮ້ອງຂໍດັ່ງກ່າວ, ຫຼັງຈາກນັ້ນທ່ານໃຊ້ເວລາຕໍ່ວິນາທີເລື່ອນຜ່ານຄໍາຮ້ອງຂໍເຫຼົ່ານີ້, i.e. ພວກເຮົາກໍາລັງເສຍເວລາ.

ພວກເຮົາບໍ່ມັກເຮັດສິ່ງນີ້ແລະເບິ່ງສິ່ງທີ່ພື້ນຖານສະເຫນີໃຫ້ພວກເຮົາສໍາລັບການນີ້. ຖານຂໍ້ມູນສະເຫນີໃຫ້ພວກເຮົາສອງທາງເລືອກໃນການດໍາເນີນການສອບຖາມ.

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

https://github.com/pgjdbc/pgjdbc/pull/478

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

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

ແລະສິ່ງທີ່ພວກເຮົາສາມາດເຮັດໄດ້ແມ່ນການສອບຖາມແບບງ່າຍດາຍແລະການສອບຖາມຂະຫຍາຍ.

ແມ່ນຫຍັງພິເສດກ່ຽວກັບແຕ່ລະວິທີການ?

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

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

ຂໍໃຫ້ກ້າວໄປສູ່ການປະຕິບັດ. ນີ້ແມ່ນສິ່ງທີ່ຄໍາຮ້ອງສະຫມັກທົ່ວໄປເບິ່ງຄືວ່າ. ມັນອາດຈະເປັນ Java, ແລະອື່ນໆ.

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

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

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

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

ພວກເຮົາສາມາດບັນລຸສິ່ງນີ້ໄດ້ແນວໃດ?

ມັນງ່າຍດາຍຫຼາຍ - ບໍ່ຈໍາເປັນຕ້ອງປິດຄໍາຖະແຫຼງການ. ພວກເຮົາຂຽນແບບນີ້: "ກະກຽມ" "ປະຕິບັດ".

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

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

ວິທີການເຮັດວຽກຢ່າງຖືກຕ້ອງ? ພວກເຮົາຈໍາເປັນຕ້ອງເຮັດແນວໃດສໍາລັບການນີ້?

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

ແລະ PostgreSQL ບໍ່ຮູ້ວິທີ cache queries. ມັນເປັນສິ່ງຈໍາເປັນທີ່ແຕ່ລະກອງປະຊຸມຈະສ້າງ cache ນີ້ສໍາລັບຕົວມັນເອງ.

ແລະພວກເຮົາບໍ່ຕ້ອງການທີ່ຈະເສຍເວລາໃນການວິເຄາະຄືກັນ.

ແລະຕາມປົກກະຕິພວກເຮົາມີສອງທາງເລືອກ.

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

ພວກເຮົາມີທາງເລືອກທີສອງ - ເອົາມັນແລະຕັດມັນເອງ. ພວກເຮົາເປີດແຫຼ່ງແລະເລີ່ມຕັດ. ພວກເຮົາໄດ້ເຫັນແລະໄດ້ເຫັນ. ມັນໄດ້ຫັນອອກວ່າມັນບໍ່ມີຄວາມຫຍຸ້ງຍາກຫຼາຍທີ່ຈະເຮັດ.

https://github.com/pgjdbc/pgjdbc/pull/319

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

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

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

ການສອບຖາມຂອງພວກເຮົາແມ່ນແບບນັ້ນທີ່ພວກເຮົາໃຊ້ເວລາປະມານ 20 ມິນລິວິນາທີໃນການວິເຄາະກ່ຽວກັບຄໍາຖາມ OLTP. ມີ 0,5 milliseconds ສໍາລັບການປະຕິບັດ, 20 milliseconds ສໍາລັບ parsing. ຮ້ອງຂໍ - 10 KiB ຂອງຂໍ້ຄວາມ, 170 ເສັ້ນຂອງແຜນການ. ນີ້ແມ່ນຄຳຮ້ອງຂໍ OLTP. ມັນຮ້ອງຂໍ 1, 5, 10 ແຖວ, ບາງຄັ້ງຫຼາຍ.

ແຕ່ພວກເຮົາບໍ່ຢາກເສຍເວລາ 20 ມິນລິວິນາທີເລີຍ. ພວກເຮົາຫຼຸດລົງເປັນ 0. ທຸກຢ່າງດີເລີດ.

ເຈົ້າສາມາດເອົາຫຍັງໄປຈາກນີ້? ຖ້າທ່ານມີ Java, ຫຼັງຈາກນັ້ນທ່ານເອົາຮຸ່ນທີ່ທັນສະໄຫມຂອງໄດເວີແລະປິຕິຍິນດີ.

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

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

ຖ້າຄໍາຮ້ອງຂໍຖືກສ້າງແບບເຄື່ອນໄຫວ. ມັນ​ເກີດ​ຂື້ນ. ບາງຄົນກາວສາຍເຂົ້າກັນ, ສົ່ງຜົນໃຫ້ມີການສອບຖາມ SQL.

ເປັນຫຍັງລາວຈຶ່ງບໍ່ດີ? ມັນບໍ່ດີເພາະວ່າແຕ່ລະຄັ້ງທີ່ພວກເຮົາຈົບລົງດ້ວຍສາຍທີ່ແຕກຕ່າງກັນ.

ແລະ hashCode ຂອງ string ທີ່ແຕກຕ່າງກັນນີ້ຕ້ອງໄດ້ຮັບການອ່ານອີກເທື່ອຫນຶ່ງ. ນີ້ແມ່ນວຽກ CPU ແທ້ໆ - ການຊອກຫາຂໍ້ຄວາມທີ່ຮ້ອງຂໍຍາວໃນແມ້ກະທັ້ງ hash ທີ່ມີຢູ່ກໍ່ບໍ່ແມ່ນເລື່ອງງ່າຍ. ດັ່ງນັ້ນ, ການສະຫລຸບແມ່ນງ່າຍດາຍ - ບໍ່ສ້າງຄໍາຮ້ອງຂໍ. ເກັບຮັກສາພວກມັນໄວ້ໃນຕົວແປດຽວ. ແລະປິຕິຍິນດີ.

ບັນຫາຕໍ່ໄປ. ປະເພດຂໍ້ມູນແມ່ນສໍາຄັນ. ມີ ORMs ທີ່ເວົ້າວ່າມັນບໍ່ສໍາຄັນວ່າປະເພດຂອງ NULL ແມ່ນຫຍັງ, ໃຫ້ມີບາງປະເພດ. ຖ້າ Int, ຫຼັງຈາກນັ້ນພວກເຮົາເວົ້າວ່າ setInt. ແລະຖ້າ NULL, ໃຫ້ມັນເປັນ VARCHAR ສະເໝີ. ແລະມັນມີຄວາມແຕກຕ່າງກັນແນວໃດໃນທີ່ສຸດສິ່ງທີ່ NULL ຢູ່ທີ່ນັ້ນ? ຖານຂໍ້ມູນຕົວມັນເອງຈະເຂົ້າໃຈທຸກຢ່າງ. ແລະຮູບນີ້ໃຊ້ບໍ່ໄດ້.

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

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

ຕົກລົງ, ເປີດແລ້ວ. ບາງທີພວກເຂົາເອົາຄົນຂັບ. ແລະຜົນຜະລິດຫຼຸດລົງ. ສິ່ງຕ່າງໆບໍ່ດີ.

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

https://gist.github.com/vlsi/df08cbef370b2e86a5c1

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

ຖ້າພວກເຮົາເລີ່ມປະຕິບັດດ້ວຍຕົວແປທີ່ຜູກມັດ, i.e. ພວກເຮົາປະຕິບັດ "?" ຫຼື “$1” ສໍາລັບຄໍາຮ້ອງຂໍຂອງພວກເຮົາ, ພວກເຮົາຈະໄດ້ຮັບຫຍັງ?

https://gist.github.com/vlsi/df08cbef370b2e86a5c1

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

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

ເຈົ້າສາມາດເຮັດແນວໃດກ່ຽວກັບມັນ? ທີ່ນີ້, ແນ່ນອນ, ມັນເປັນການຍາກທີ່ຈະສົມມຸດຫຍັງ. ມີການແກ້ໄຂງ່າຍໆທີ່ພວກເຮົາໃຊ້. ນີ້ແມ່ນ +0, OFFSET 0. ແນ່ນອນເຈົ້າຮູ້ວິທີແກ້ໄຂດັ່ງກ່າວ. ພວກເຮົາພຽງແຕ່ເອົາມັນແລະເພີ່ມ "+0" ໃນການຮ້ອງຂໍແລະທຸກສິ່ງທຸກຢ່າງແມ່ນດີ. ຂ້ອຍຈະສະແດງໃຫ້ເຈົ້າເຫັນໃນພາຍຫຼັງ.

ແລະມີທາງເລືອກອື່ນ - ເບິ່ງແຜນການຢ່າງລະມັດລະວັງ. ນັກພັດທະນາບໍ່ພຽງແຕ່ຂຽນຄໍາຮ້ອງຂໍ, ແຕ່ຍັງເວົ້າວ່າ "ອະທິບາຍການວິເຄາະ" 6 ເທື່ອ. ຖ້າມັນເປັນ 5, ມັນຈະບໍ່ເຮັດວຽກ.

ແລະມີທາງເລືອກທີສາມ - ຂຽນຈົດຫມາຍຫາ pgsql-hackers. ຂ້າພະເຈົ້າໄດ້ຂຽນ, ຢ່າງໃດກໍຕາມ, ມັນຍັງບໍ່ຊັດເຈນວ່ານີ້ແມ່ນ bug ຫຼືລັກສະນະ.

https://gist.github.com/vlsi/df08cbef370b2e86a5c1

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

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

ມັນເບິ່ງຄືວ່າ, ເປັນໄປໄດ້ຫຼາຍປານໃດ? ແມງໄມ້ຢູ່ທີ່ນີ້, ແມງໄມ້ຢູ່ທີ່ນັ້ນ. ໃນຄວາມເປັນຈິງ, ແມງໄມ້ມີຢູ່ທົ່ວທຸກແຫ່ງ.

ລອງເບິ່ງໃກ້ໆ. ຕົວຢ່າງ, ພວກເຮົາມີສອງ schemas. ແຜນຜັງ A ກັບຕາຕະລາງ S ແລະແຜນວາດ B ກັບຕາຕະລາງ S. Query - ເລືອກຂໍ້ມູນຈາກຕາຕະລາງ. ພວກເຮົາຈະມີຫຍັງແດ່ໃນກໍລະນີນີ້? ພວກເຮົາຈະມີຂໍ້ຜິດພາດ. ພວກເຮົາຈະມີທັງຫມົດຂ້າງເທິງ. ກົດລະບຽບແມ່ນ - ແມງໄມ້ມີຢູ່ທົ່ວທຸກແຫ່ງ, ພວກເຮົາຈະມີທັງຫມົດຂ້າງເທິງ.

ໃນປັດຈຸບັນຄໍາຖາມແມ່ນ: "ເປັນຫຍັງ?" ມັນເບິ່ງຄືວ່າມີເອກະສານວ່າຖ້າພວກເຮົາມີ schema, ຫຼັງຈາກນັ້ນມີຕົວແປ "search_path" ທີ່ບອກພວກເຮົາວ່າຈະຊອກຫາຕາຕະລາງ. ມັນຈະເບິ່ງຄືວ່າມີຕົວແປ.

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

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

ກໍານົດ search_path + server-prepared statements =
ແຜນການທີ່ເກັບໄວ້ໃນຖານຄວາມຈໍາຕ້ອງບໍ່ປ່ຽນປະເພດຜົນໄດ້ຮັບ

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

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

ແລະຂ້າພະເຈົ້າຈະເນັ້ນຫນັກອີກເທື່ອຫນຶ່ງ - ນີ້ແມ່ນບາງສິ່ງບາງຢ່າງທີ່ບໍ່ປົກກະຕິສໍາລັບ Java. ພວກເຮົາຈະເຫັນສິ່ງດຽວກັນໃນ PL / pgSQL ຫນຶ່ງຫາຫນຶ່ງ. ແຕ່ມັນຈະຖືກແຜ່ພັນຢູ່ທີ່ນັ້ນ.

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

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

ຖ້າທ່ານມີແຖວເປັນລ້ານ, ທ່ານບໍ່ສາມາດພຽງແຕ່ເລືອກແລະເລືອກ. ຕ້ອງການ OFFSET/LIMIT. ໃຜເປັນທາງເລືອກນີ້? ແລະຜູ້ທີ່ມັກຫຼີ້ນກັບ autoCommit?

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

ແຕ່ໂດຍຄ່າເລີ່ມຕົ້ນ, ລູກຄ້າທັງຫມົດທີ່ເຊື່ອມຕໍ່ກັບຖານຂໍ້ມູນ Postgres ດຶງຂໍ້ມູນທັງຫມົດ. PgJDBC ບໍ່ມີຂໍ້ຍົກເວັ້ນໃນເລື່ອງນີ້; ມັນເລືອກແຖວທັງຫມົດ.

ມີຄວາມແຕກຕ່າງກັນກ່ຽວກັບຫົວຂໍ້ FetchSize, i.e. ທ່ານສາມາດເວົ້າໄດ້ໃນລະດັບຂອງຄໍາຖະແຫຼງທີ່ແຍກຕ່າງຫາກວ່າໃນທີ່ນີ້, ກະລຸນາເລືອກຂໍ້ມູນໂດຍ 10, 50. ແຕ່ນີ້ບໍ່ໄດ້ເຮັດວຽກຈົນກວ່າທ່ານຈະປິດ autoCommit. ປິດ autoCommit - ມັນເລີ່ມເຮັດວຽກ.

ແຕ່ການຜ່ານລະຫັດແລະການຕັ້ງຄ່າ setFetchSize ຢູ່ທົ່ວທຸກແຫ່ງແມ່ນບໍ່ສະດວກ. ດັ່ງນັ້ນ, ພວກເຮົາສ້າງການຕັ້ງຄ່າທີ່ຈະເວົ້າວ່າຄ່າເລີ່ມຕົ້ນສໍາລັບການເຊື່ອມຕໍ່ທັງຫມົດ.

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

ໂດຍຫລັກການແລ້ວ, ແນ່ນອນ, ທ່ານຍັງຕ້ອງຮຽນຮູ້ວິທີການຈໍາກັດມັນໃນ bytes, ແຕ່ສູດນີ້ແມ່ນ: ຕັ້ງຄ່າ defaultRowFetchSize ຫຼາຍກວ່າຫນຶ່ງຮ້ອຍແລະມີຄວາມສຸກ.

ໃຫ້ກ້າວໄປສູ່ການໃສ່ຂໍ້ມູນ. ການແຊກແມ່ນງ່າຍຂຶ້ນ, ມີທາງເລືອກທີ່ແຕກຕ່າງກັນ. ຕົວຢ່າງ, INSERT, VALUES. ນີ້ແມ່ນທາງເລືອກທີ່ດີ. ທ່ານສາມາດເວົ້າວ່າ "INSERT SELECT". ໃນທາງປະຕິບັດ, ມັນແມ່ນສິ່ງດຽວກັນ. ບໍ່ມີຄວາມແຕກຕ່າງໃນການປະຕິບັດ.

ປື້ມບອກວ່າທ່ານຈໍາເປັນຕ້ອງປະຕິບັດຄໍາສັ່ງ Batch, ຫນັງສືບອກວ່າທ່ານສາມາດປະຕິບັດຄໍາສັ່ງທີ່ສັບສົນຫຼາຍດ້ວຍວົງເລັບຫຼາຍ. ແລະ Postgres ມີຄຸນສົມບັດທີ່ດີເລີດ - ທ່ານສາມາດເຮັດ COPY, i.e. ເຮັດມັນໄວຂຶ້ນ.

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

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

ແລະດັ່ງນັ້ນ, ລູກຄ້າໄດ້ຖືກບັງຄັບໃຫ້ສົ່ງຊອງ synchronization ເປັນໄລຍະ. ການໂຕ້ຕອບເຄືອຂ່າຍພິເສດ, ການເສຍເວລາພິເສດ.

ແລະຫຼາຍພວກເຮົາເພີ່ມໃຫ້ເຂົາເຈົ້າ, ມັນຮ້າຍແຮງຂຶ້ນ. ໄດເວີແມ່ນຂ້ອນຂ້າງຈືດໆແລະເພີ່ມພວກມັນເລື້ອຍໆ, ປະມານຫນຶ່ງຄັ້ງໃນ 200 ເສັ້ນ, ຂຶ້ນກັບຂະຫນາດຂອງສາຍ, ແລະອື່ນໆ.

https://github.com/pgjdbc/pgjdbc/pull/380

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

Java microbenchmark harness

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

ໃຫ້ລອງມັນເບິ່ງ. ພວກເຮົາວັດແທກ InsertBatch ງ່າຍດາຍ. ພວກເຮົາວັດແທກ InsertBatch ຫຼາຍຄັ້ງ, i.e. ສິ່ງດຽວກັນ, ແຕ່ມີຄ່າຫຼາຍ. ການເຄື່ອນໄຫວ tricky. ບໍ່ແມ່ນທຸກຄົນສາມາດເຮັດໄດ້, ແຕ່ມັນເປັນການເຄື່ອນໄຫວທີ່ງ່າຍດາຍ, ງ່າຍກວ່າການສຳເນົາຫຼາຍ.

ທ່ານສາມາດເຮັດ COPY ໄດ້.

ແລະທ່ານສາມາດເຮັດສິ່ງນີ້ໃນໂຄງສ້າງ. ປະກາດປະເພດຜູ້ໃຊ້ເລີ່ມຕົ້ນ, pass array ແລະ INSERT ໂດຍກົງໃສ່ຕາຕະລາງ.

ຖ້າທ່ານເປີດລິ້ງ: pgjdbc/ubenchmsrk/InsertBatch.java, ຫຼັງຈາກນັ້ນລະຫັດນີ້ແມ່ນຢູ່ໃນ GitHub. ທ່ານ​ສາ​ມາດ​ເບິ່ງ​ໂດຍ​ສະ​ເພາະ​ວ່າ​ຄໍາ​ຮ້ອງ​ສະ​ຫມັກ​ທີ່​ຖືກ​ສ້າງ​ຕັ້ງ​ຂຶ້ນ​ທີ່​ນັ້ນ​. ມັນບໍ່ສໍາຄັນ.

ພວກເຮົາເປີດຕົວ. ແລະສິ່ງທໍາອິດທີ່ພວກເຮົາຮັບຮູ້ແມ່ນວ່າບໍ່ໃຊ້ batch ແມ່ນເປັນໄປບໍ່ໄດ້. ທາງເລືອກໃນ batching ທັງໝົດແມ່ນສູນ, i.e. ເວລາປະຕິບັດຕົວຈິງແມ່ນສູນເມື່ອທຽບກັບການປະຕິບັດຄັ້ງດຽວ.

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

ນີ້ແມ່ນເວລາທີ່ພວກເຮົາໃສ່ຕ່ອນ. ເມື່ອພວກເຮົາບອກວ່າໜຶ່ງຄ່າ VALUES, ສອງຄ່າ VALUES, ສາມຄ່າ VALUES, ຫຼືພວກເຮົາຊີ້ 10 ຂອງມັນແຍກກັນດ້ວຍເຄື່ອງໝາຍຈຸດ. ນີ້ແມ່ນພຽງແຕ່ແນວນອນໃນປັດຈຸບັນ. 1, 2, 4, 128. ສາມາດເຫັນໄດ້ວ່າ Batch Insert, ເຊິ່ງແຕ້ມດ້ວຍສີຟ້າ, ເຮັດໃຫ້ລາວຮູ້ສຶກດີຂຶ້ນຫຼາຍ. ນັ້ນແມ່ນ, ເມື່ອທ່ານໃສ່ຫນຶ່ງຄັ້ງຫຼືແມ້ກະທັ້ງໃສ່ສີ່ຄັ້ງ, ມັນຈະກາຍເປັນສອງເທົ່າທີ່ດີ, ເພາະວ່າພວກເຮົາຕື່ມຂໍ້ມູນໃສ່ VALUES ຕື່ມອີກ. ປະຕິບັດການ EXECUTE ໜ້ອຍລົງ.

ການ​ນໍາ​ໃຊ້ COPY ໃນ​ປະ​ລິ​ມານ​ຂະ​ຫນາດ​ນ້ອຍ​ແມ່ນ unpromising ທີ່​ສຸດ. ຂ້ອຍບໍ່ໄດ້ແຕ້ມສອງອັນທຳອິດ. ພວກເຂົາເຈົ້າໄປສະຫວັນ, ນັ້ນແມ່ນ, ຕົວເລກສີຂຽວເຫຼົ່ານີ້ສໍາລັບ COPY.

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

ພວກເຮົາຈະເຮັດແນວໃດຕໍ່ໄປ? ພວກເຮົາພະຍາຍາມມັນ. ພວກເຮົາເຂົ້າໃຈວ່າພວກເຮົາຈໍາເປັນຕ້ອງໃຊ້ໂຄງສ້າງຫຼື bath ສະຫລາດທີ່ປະສົມປະສານຫຼາຍຄວາມຫມາຍ.

ເຈົ້າຄວນເອົາຫຍັງອອກຈາກບົດລາຍງານຂອງມື້ນີ້?

• ຖະແຫຼງການການກະກຽມແມ່ນທຸກສິ່ງທຸກຢ່າງຂອງພວກເຮົາ. ນີ້ເຮັດໃຫ້ຫຼາຍສໍາລັບຜົນຜະລິດ. ມັນຜະລິດເປັນ flop ໃຫຍ່ໃນຢາຂີ້ເຜິ້ງ.
• ແລະທ່ານຈໍາເປັນຕ້ອງເຮັດ EXPLAIN ANALYZE 6 ເທື່ອ.
• ແລະພວກເຮົາຈໍາເປັນຕ້ອງເຈືອຈາງ OFFSET 0, ແລະ tricks ເຊັ່ນ +0 ເພື່ອແກ້ໄຂສ່ວນທີ່ຍັງເຫຼືອຂອງການສອບຖາມທີ່ມີບັນຫາຂອງພວກເຮົາ.

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