ພື້ນຖານການອອກແບບຖານຂໍ້ມູນ - ການປຽບທຽບ PostgreSQL, Cassandra ແລະ MongoDB

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

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

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

ຄວາມແຕກຕ່າງລະຫວ່າງ SQL ແລະ NoSQL ແມ່ນຫຍັງ?

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

ເນື່ອງຈາກສະຖາປັດຕະຍະກໍາ monolithic/single-node ຂອງເຂົາເຈົ້າ ແລະການນໍາໃຊ້ແບບຈໍາລອງການຈໍາລອງແບບແມ່ບົດ-slave ສໍາລັບການຊໍ້າຊ້ອນ, ຖານຂໍ້ມູນ SQL ແບບດັ້ງເດີມຂາດສອງລັກສະນະທີ່ສໍາຄັນ - ການຂະຫຍາຍການຂຽນເສັ້ນ (i.e. ການແບ່ງສ່ວນອັດຕະໂນມັດໃນທົ່ວຫຼາຍ nodes) ແລະການສູນເສຍຂໍ້ມູນອັດຕະໂນມັດ / ສູນ. ນີ້ຫມາຍຄວາມວ່າຈໍານວນຂໍ້ມູນທີ່ໄດ້ຮັບບໍ່ສາມາດເກີນຂອບເຂດການຂຽນສູງສຸດຂອງໂຫນດດຽວ. ນອກຈາກນັ້ນ, ບາງການສູນເສຍຂໍ້ມູນຊົ່ວຄາວຕ້ອງໄດ້ຮັບການພິຈາລະນາໃນຄວາມທົນທານຕໍ່ຄວາມຜິດພາດ (ໃນສະຖາປັດຕະຍະກໍາທີ່ບໍ່ມີການແບ່ງປັນ). ໃນທີ່ນີ້ທ່ານຈໍາເປັນຕ້ອງຈື່ໄວ້ວ່າຄໍາຫມັ້ນສັນຍາທີ່ຜ່ານມາຍັງບໍ່ທັນໄດ້ສະທ້ອນໃຫ້ເຫັນຢູ່ໃນສໍາເນົາສໍາລອງ. ການປັບປຸງທີ່ບໍ່ແມ່ນເວລາຢຸດແມ່ນຍັງຍາກທີ່ຈະບັນລຸໃນຖານຂໍ້ມູນ SQL.

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

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

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

ຕາຕະລາງຕໍ່ໄປນີ້ສະແດງໃຫ້ເຫັນວິທີການສ້າງແບບຈໍາລອງຂໍ້ມູນໃນ NoSQL ແຕກຕ່າງຈາກ SQL.

SQL ແລະ NoSQL: ເປັນຫຍັງທັງສອງຕ້ອງການ?

ຄໍາຮ້ອງສະຫມັກໃນໂລກທີ່ແທ້ຈິງທີ່ມີຈໍານວນຜູ້ໃຊ້ຈໍານວນຫລາຍ, ເຊັ່ນ Amazon.com, Netflix, Uber, ແລະ Airbnb, ໄດ້ຖືກມອບຫມາຍໃຫ້ປະຕິບັດວຽກງານທີ່ສັບສົນ, ຫຼາຍດ້ານ. ຕົວຢ່າງເຊັ່ນ, ແອັບພລິເຄຊັນອີຄອມເມີຊເຊັ່ນ Amazon.com ຕ້ອງການເກັບຂໍ້ມູນທີ່ມີນ້ໍາຫນັກເບົາ, ຄວາມສໍາຄັນສູງເຊັ່ນ: ຂໍ້ມູນຜູ້ໃຊ້, ຜະລິດຕະພັນ, ຄໍາສັ່ງ, ໃບເກັບເງິນ, ພ້ອມກັບຂໍ້ມູນຫນັກ, ອ່ອນໄຫວຫນ້ອຍເຊັ່ນ: ການທົບທວນຄືນຜະລິດຕະພັນ, ຂໍ້ຄວາມສະຫນັບສະຫນູນ, ກິດຈະກໍາຂອງຜູ້ໃຊ້, ການທົບທວນຄືນຂອງຜູ້ໃຊ້ແລະຄໍາແນະນໍາ. ຕາມທໍາມະຊາດ, ຄໍາຮ້ອງສະຫມັກເຫຼົ່ານີ້ອີງໃສ່ຢ່າງຫນ້ອຍຫນຶ່ງຖານຂໍ້ມູນ SQL ພ້ອມກັບຢ່າງຫນ້ອຍຫນຶ່ງຖານຂໍ້ມູນ NoSQL. ໃນລະບົບຂ້າມພາກພື້ນແລະທົ່ວໂລກ, ຖານຂໍ້ມູນ NoSQL ດໍາເນີນການເປັນ cache ແຈກຢາຍທາງພູມສາດສໍາລັບຂໍ້ມູນທີ່ເກັບໄວ້ໃນຖານຂໍ້ມູນ SQL ແຫຼ່ງທີ່ເຊື່ອຖືໄດ້ທີ່ເຮັດວຽກຢູ່ໃນພາກພື້ນສະເພາະໃດຫນຶ່ງ.

YugaByte DB ປະສົມປະສານ SQL ແລະ NoSQL ແນວໃດ?

ສ້າງຂຶ້ນໃນເຄື່ອງຈັກການເກັບຮັກສາແບບປະສົມແບບບັນທຶກ, ການແບ່ງປັນອັດຕະໂນມັດ, ການຈໍາລອງແບບເປັນເອກະສັນກັນແຈກຢາຍ sharded ແລະການເຮັດທຸລະກໍາທີ່ແຈກຢາຍ ACID (ດົນໃຈໂດຍ Google Spanner), YugaByte DB ແມ່ນຖານຂໍ້ມູນແຫຼ່ງເປີດທໍາອິດຂອງໂລກທີ່ເຂົ້າກັນໄດ້ພ້ອມໆກັນກັບ NoSQL (Cassandra & Redis ) ແລະ SQL (PostgreSQL). ດັ່ງທີ່ສະແດງຢູ່ໃນຕາຕະລາງຂ້າງລຸ່ມນີ້, YCQL, YugaByte DB API ທີ່ເຂົ້າກັນໄດ້ກັບ Cassandra, ເພີ່ມແນວຄວາມຄິດຂອງການເຮັດທຸລະກໍາ ACID ດຽວແລະຫຼາຍທີ່ສໍາຄັນແລະດັດສະນີຮອງທົ່ວໂລກກັບ NoSQL API, ດັ່ງນັ້ນຈຶ່ງນໍາໄປສູ່ຍຸກຂອງຖານຂໍ້ມູນ NoSQL ການເຮັດທຸລະກໍາ. ນອກຈາກນັ້ນ, YCQL, YugaByte DB API ທີ່ເຂົ້າກັນໄດ້ກັບ PostgreSQL, ເພີ່ມແນວຄວາມຄິດຂອງການປັບຂະຫນາດການຂຽນເສັ້ນແລະຄວາມທົນທານຕໍ່ຄວາມຜິດພາດອັດຕະໂນມັດໃຫ້ກັບ SQL API, ນໍາຖານຂໍ້ມູນ SQL ທີ່ແຈກຢາຍໄປທົ່ວໂລກ. ເນື່ອງຈາກວ່າ YugaByte DB ແມ່ນການເຮັດທຸລະກໍາໃນລັກສະນະ, NoSQL API ປະຈຸບັນສາມາດຖືກນໍາໃຊ້ໃນສະພາບການຂອງຂໍ້ມູນພາລະກິດທີ່ສໍາຄັນ.

ດັ່ງທີ່ໄດ້ກ່າວກ່ອນຫນ້ານີ້ໃນບົດຄວາມ "ແນະນຳ YSQL: A PostgreSQL Compatible Distributed SQL API for YugaByte DB", ທາງເລືອກລະຫວ່າງ SQL ຫຼື NoSQL ໃນ YugaByte DB ແມ່ນຂຶ້ນກັບຄຸນລັກສະນະຂອງການເຮັດວຽກທີ່ຕິດພັນ:

• ຖ້າວຽກຕົ້ນຕໍຂອງທ່ານແມ່ນການປະຕິບັດການ JOIN ຫຼາຍກະແຈ, ເມື່ອເລືອກ YSQL, ເຂົ້າໃຈວ່າກະແຈຂອງທ່ານອາດຈະຖືກແຈກຢາຍໃນທົ່ວຫຼາຍໂຫນດ, ສົ່ງຜົນໃຫ້ຄວາມລ່າຊ້າສູງແລະ / ຫຼືການສົ່ງຜ່ານຕ່ໍາກວ່າ NoSQL.
• ຖ້າບໍ່ດັ່ງນັ້ນ, ເລືອກທັງສອງ NoSQL APIs, ຈົ່ງຈື່ໄວ້ວ່າທ່ານຈະໄດ້ຮັບການປະຕິບັດທີ່ດີກວ່າເປັນຜົນມາຈາກການສອບຖາມທີ່ໄດ້ຮັບການບໍລິການຈາກຫນຶ່ງ node ໃນເວລານັ້ນ. YugaByte DB ສາມາດຮັບໃຊ້ເປັນຖານຂໍ້ມູນປະຕິບັດການດຽວສໍາລັບໂລກທີ່ແທ້ຈິງ, ຄໍາຮ້ອງສະຫມັກທີ່ຊັບຊ້ອນທີ່ຕ້ອງການຈັດການຫຼາຍວຽກພ້ອມໆກັນ.

ຫ້ອງທົດລອງສ້າງແບບຈໍາລອງຂໍ້ມູນໃນພາກຕໍ່ໄປແມ່ນອີງໃສ່ຖານຂໍ້ມູນ PostgreSQL ແລະ Cassandra API ທີ່ເຂົ້າກັນໄດ້ກັບ YugaByte DB, ກົງກັນຂ້າມກັບຖານຂໍ້ມູນພື້ນເມືອງ. ວິທີການນີ້ເນັ້ນຫນັກໃສ່ຄວາມງ່າຍຂອງການພົວພັນກັບສອງ APIs ທີ່ແຕກຕ່າງກັນ (ໃນສອງພອດທີ່ແຕກຕ່າງກັນ) ຂອງກຸ່ມຖານຂໍ້ມູນດຽວກັນ, ກົງກັນຂ້າມກັບການນໍາໃຊ້ກຸ່ມເອກະລາດຢ່າງສົມບູນຂອງສອງຖານຂໍ້ມູນທີ່ແຕກຕ່າງກັນ.
ໃນພາກຕໍ່ໄປນີ້, ພວກເຮົາຈະເບິ່ງຫ້ອງທົດລອງສ້າງແບບຈໍາລອງຂໍ້ມູນເພື່ອສະແດງໃຫ້ເຫັນເຖິງຄວາມແຕກຕ່າງແລະຄວາມຄ້າຍຄືກັນບາງຢ່າງຂອງຖານຂໍ້ມູນທີ່ກວມເອົາ.

ຫ້ອງທົດລອງສ້າງແບບຈໍາລອງຂໍ້ມູນ

ການຕິດຕັ້ງຖານຂໍ້ມູນ

ໂດຍເນັ້ນໃສ່ການອອກແບບຕົວແບບຂໍ້ມູນ (ແທນທີ່ຈະເປັນສະຖາປັດຕະຍະກຳການນຳໃຊ້ທີ່ຊັບຊ້ອນ), ພວກເຮົາຈະຕິດຕັ້ງຖານຂໍ້ມູນໃນ Docker containers ຢູ່ໃນເຄື່ອງທ້ອງຖິ່ນ ແລະຫຼັງຈາກນັ້ນພົວພັນກັບພວກມັນໂດຍໃຊ້ shell line commands ຂອງເຂົາເຈົ້າ.

ຖານຂໍ້ມູນ PostgreSQL & Cassandra ເຂົ້າກັນໄດ້ YugaByte DB

mkdir ~/yugabyte && cd ~/yugabyte
wget https://downloads.yugabyte.com/yb-docker-ctl && chmod +x yb-docker-ctl
docker pull yugabytedb/yugabyte
./yb-docker-ctl create --enable_postgres

MongoDB

docker run --name my-mongo -d mongo:latest

ການເຂົ້າເຖິງເສັ້ນຄໍາສັ່ງ

ໃຫ້ເຊື່ອມຕໍ່ກັບຖານຂໍ້ມູນໂດຍໃຊ້ shell ເສັ້ນຄໍາສັ່ງສໍາລັບ APIs ທີ່ສອດຄ້ອງກັນ.

PostgreSQL

psql ແມ່ນ Shell ເສັ້ນຄໍາສັ່ງສໍາລັບການພົວພັນກັບ PostgreSQL. ເພື່ອຄວາມສະດວກໃນການນໍາໃຊ້, YugaByte DB ມາພ້ອມກັບ psql ຢູ່ໃນໂຟເດີ bin.

docker exec -it yb-postgres-n1 /home/yugabyte/postgres/bin/psql -p 5433 -U postgres

Cassandra

cqlsh ເປັນແກະເສັ້ນຄໍາສັ່ງສໍາລັບການພົວພັນກັບ Cassandra ແລະຖານຂໍ້ມູນທີ່ເຂົ້າກັນໄດ້ໂດຍຜ່ານ CQL (ພາສາ Cassandra Query). ເພື່ອຄວາມສະດວກໃນການນໍາໃຊ້, YugaByte DB ມາພ້ອມກັບ cqlsh ໃນລາຍການ bin.
ໃຫ້ສັງເກດວ່າ CQL ໄດ້ຮັບການດົນໃຈໂດຍ SQL ແລະມີແນວຄວາມຄິດທີ່ຄ້າຍຄືກັນຂອງຕາຕະລາງ, ແຖວ, ຖັນແລະດັດສະນີ. ຢ່າງໃດກໍຕາມ, ເປັນພາສາ NoSQL, ມັນເພີ່ມຂໍ້ຈໍາກັດສະເພາະໃດຫນຶ່ງ, ສ່ວນໃຫຍ່ທີ່ພວກເຮົາຍັງຈະກວມເອົາໃນບົດຄວາມອື່ນໆ.

docker exec -it yb-tserver-n1 /home/yugabyte/bin/cqlsh

MongoDB

Mongo ແມ່ນ shell ເສັ້ນຄໍາສັ່ງສໍາລັບການພົວພັນກັບ MongoDB. ມັນສາມາດພົບໄດ້ໃນ bin directory ຂອງການຕິດຕັ້ງ MongoDB.

docker exec -it my-mongo bash 
cd bin
mongo

ສ້າງຕາຕະລາງ

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

PostgreSQL

CREATE TABLE Music (
    Artist VARCHAR(20) NOT NULL, 
    SongTitle VARCHAR(30) NOT NULL,
    AlbumTitle VARCHAR(25),
    Year INT,
    Price FLOAT,
    Genre VARCHAR(10),
    CriticRating FLOAT,
    Tags TEXT,
    PRIMARY KEY(Artist, SongTitle)
);	

Cassandra

ການສ້າງຕາຕະລາງໃນ Cassandra ແມ່ນຄ້າຍຄືກັນກັບ PostgreSQL. ຫນຶ່ງໃນຄວາມແຕກຕ່າງຕົ້ນຕໍແມ່ນການຂາດຄວາມສົມບູນຂອງຂໍ້ຈໍາກັດ (ເຊັ່ນ: ບໍ່ແມ່ນ NULL), ແຕ່ນີ້ແມ່ນຄວາມຮັບຜິດຊອບຂອງແອັບພລິເຄຊັນ, ບໍ່ແມ່ນຖານຂໍ້ມູນ NoSQL.. ກະແຈຫຼັກປະກອບດ້ວຍກະແຈພາທິຊັນ (ຖັນສິນລະປິນໃນຕົວຢ່າງຂ້າງລຸ່ມນີ້) ແລະຊຸດຂອງຖັນກຸ່ມ (ຖັນ SongTitle ໃນຕົວຢ່າງຂ້າງລຸ່ມນີ້). ກະແຈການແບ່ງພາທິຊັນຈະກຳນົດວ່າແຖວໃດຄວນວາງພາທິຊັນ/ແບ່ງແຖວ, ແລະຖັນກຸ່ມຊີ້ບອກວິທີການຈັດລຽງຂໍ້ມູນພາຍໃນ shard ປະຈຸບັນ.

CREATE KEYSPACE myapp;
USE myapp;
CREATE TABLE Music (
    Artist TEXT, 
    SongTitle TEXT,
    AlbumTitle TEXT,
    Year INT,
    Price FLOAT,
    Genre TEXT,
    CriticRating FLOAT,
    Tags TEXT,
    PRIMARY KEY(Artist, SongTitle)
);

MongoDB

MongoDB ຈັດລະບຽບຂໍ້ມູນເຂົ້າໄປໃນຖານຂໍ້ມູນ (Database) (ຄ້າຍກັບ Keyspace ໃນ Cassandra), ບ່ອນທີ່ມີ Collections (ຄ້າຍຄືກັນກັບຕາຕະລາງ) ທີ່ມີ Documents (ຄ້າຍຄືກັນກັບແຖວໃນຕາຕະລາງ). ໃນ MongoDB, ໂດຍພື້ນຖານແລ້ວບໍ່ຈໍາເປັນຕ້ອງກໍານົດ schema ເບື້ອງຕົ້ນ. ທີມງານ "ໃຊ້ຖານຂໍ້ມູນ", ສະແດງໃຫ້ເຫັນຂ້າງລຸ່ມນີ້, instantiates ຖານຂໍ້ມູນກ່ຽວກັບການໂທຫາຄັ້ງທໍາອິດແລະການປ່ຽນແປງສະພາບການສໍາລັບຖານຂໍ້ມູນທີ່ສ້າງຂຶ້ນໃຫມ່. ເຖິງແມ່ນວ່າການເກັບລວບລວມບໍ່ຈໍາເປັນຕ້ອງສ້າງຢ່າງຈະແຈ້ງ; ພວກມັນຖືກສ້າງຂື້ນໂດຍອັດຕະໂນມັດ, ພຽງແຕ່ເມື່ອທ່ານເພີ່ມເອກະສານທໍາອິດໃສ່ຄໍເລັກຊັນໃຫມ່. ໃຫ້ສັງເກດວ່າ MongoDB ໃຊ້ຖານຂໍ້ມູນການທົດສອບໂດຍຄ່າເລີ່ມຕົ້ນ, ດັ່ງນັ້ນການປະຕິບັດລະດັບການເກັບກໍາໃດໆໂດຍບໍ່ມີການລະບຸຖານຂໍ້ມູນສະເພາະຈະດໍາເນີນການກັບມັນໂດຍຄ່າເລີ່ມຕົ້ນ.

use myNewDatabase;

ໄດ້ຮັບຂໍ້ມູນກ່ຽວກັບຕາຕະລາງ
PostgreSQL

d Music
Table "public.music"
    Column    |         Type          | Collation | Nullable | Default 
--------------+-----------------------+-----------+----------+--------
 artist       | character varying(20) |           | not null | 
 songtitle    | character varying(30) |           | not null | 
 albumtitle   | character varying(25) |           |          | 
 year         | integer               |           |          | 
 price        | double precision      |           |          | 
 genre        | character varying(10) |           |          | 
 criticrating | double precision      |           |          | 
 tags         | text                  |           |          | 
Indexes:
    "music_pkey" PRIMARY KEY, btree (artist, songtitle)

Cassandra

DESCRIBE TABLE MUSIC;
CREATE TABLE myapp.music (
    artist text,
    songtitle text,
    albumtitle text,
    year int,
    price float,
    genre text,
    tags text,
    PRIMARY KEY (artist, songtitle)
) WITH CLUSTERING ORDER BY (songtitle ASC)
    AND default_time_to_live = 0
    AND transactions = {'enabled': 'false'};

MongoDB

use myNewDatabase;
show collections;

ການປ້ອນຂໍ້ມູນເຂົ້າໃນຕາຕະລາງ
PostgreSQL

INSERT INTO Music 
    (Artist, SongTitle, AlbumTitle, 
    Year, Price, Genre, CriticRating, 
    Tags)
VALUES(
    'No One You Know', 'Call Me Today', 'Somewhat Famous',
    2015, 2.14, 'Country', 7.8,
    '{"Composers": ["Smith", "Jones", "Davis"],"LengthInSeconds": 214}'
);
INSERT INTO Music 
    (Artist, SongTitle, AlbumTitle, 
    Price, Genre, CriticRating)
VALUES(
    'No One You Know', 'My Dog Spot', 'Hey Now',
    1.98, 'Country', 8.4
);
INSERT INTO Music 
    (Artist, SongTitle, AlbumTitle, 
    Price, Genre)
VALUES(
    'The Acme Band', 'Look Out, World', 'The Buck Starts Here',
    0.99, 'Rock'
);
INSERT INTO Music 
    (Artist, SongTitle, AlbumTitle, 
    Price, Genre, 
    Tags)
VALUES(
    'The Acme Band', 'Still In Love', 'The Buck Starts Here',
    2.47, 'Rock', 
    '{"radioStationsPlaying": ["KHCR", "KBQX", "WTNR", "WJJH"], "tourDates": { "Seattle": "20150625", "Cleveland": "20150630"}, "rotation": Heavy}'
);

Cassandra

ການສະແດງອອກໂດຍລວມ INSERT ໃນ Cassandra ມີລັກສະນະຄ້າຍຄືກັນກັບໃນ PostgreSQL. ຢ່າງໃດກໍຕາມ, ມີຄວາມແຕກຕ່າງກັນຢ່າງຫຼວງຫຼາຍໃນ semantics. ໃນ Cassandra INSERT ຕົວຈິງແລ້ວແມ່ນການດໍາເນີນງານ UPSERT, ບ່ອນທີ່ຄ່າສຸດທ້າຍຖືກເພີ່ມໃສ່ແຖວຖ້າແຖວນັ້ນມີຢູ່ແລ້ວ.

ການປ້ອນຂໍ້ມູນແມ່ນຄ້າຍຄືກັນກັບ PostgreSQL INSERT ສູງ

.

MongoDB

ເຖິງແມ່ນວ່າ MongoDB ເປັນຖານຂໍ້ມູນ NoSQL ເຊັ່ນ Cassandra, ການປະຕິບັດການແຊກຂອງມັນບໍ່ມີຫຍັງຄ້າຍຄືກັນກັບພຶດຕິກໍາ semantic ຂອງ Cassandra. ໃນ MongoDB ໃສ່ () ບໍ່ມີໂອກາດ UPSERT, ເຊິ່ງເຮັດໃຫ້ມັນຄ້າຍຄືກັນກັບ PostgreSQL. ເພີ່ມຂໍ້ມູນເລີ່ມຕົ້ນໂດຍບໍ່ມີການ _idspecified ຈະເຮັດໃຫ້ເອກະສານໃໝ່ຖືກເພີ່ມໃສ່ຄໍເລັກຊັນ.

db.music.insert( {
artist: "No One You Know",
songTitle: "Call Me Today",
albumTitle: "Somewhat Famous",
year: 2015,
price: 2.14,
genre: "Country",
tags: {
Composers: ["Smith", "Jones", "Davis"],
LengthInSeconds: 214
}
}
);
db.music.insert( {
artist: "No One You Know",
songTitle: "My Dog Spot",
albumTitle: "Hey Now",
price: 1.98,
genre: "Country",
criticRating: 8.4
}
);
db.music.insert( {
artist: "The Acme Band",
songTitle: "Look Out, World",
albumTitle:"The Buck Starts Here",
price: 0.99,
genre: "Rock"
}
);
db.music.insert( {
artist: "The Acme Band",
songTitle: "Still In Love",
albumTitle:"The Buck Starts Here",
price: 2.47,
genre: "Rock",
tags: {
radioStationsPlaying:["KHCR", "KBQX", "WTNR", "WJJH"],
tourDates: {
Seattle: "20150625",
Cleveland: "20150630"
},
rotation: "Heavy"
}
}
);

ຕາຕະລາງສອບຖາມ

ບາງທີຄວາມແຕກຕ່າງທີ່ ສຳ ຄັນທີ່ສຸດລະຫວ່າງ SQL ແລະ NoSQL ໃນແງ່ຂອງການກໍ່ສ້າງແບບສອບຖາມແມ່ນພາສາທີ່ໃຊ້ FROM и WHERE. SQL ອະນຸຍາດໃຫ້ຫຼັງຈາກການສະແດງອອກ FROM ເລືອກຕາຕະລາງຫຼາຍ, ແລະສະແດງອອກດ້ວຍ WHERE ສາມາດມີຄວາມສັບສົນໃດໆ (ລວມທັງການດໍາເນີນງານ JOIN ລະຫວ່າງຕາຕະລາງ). ຢ່າງໃດກໍຕາມ, NoSQL ມັກຈະກໍານົດຂໍ້ຈໍາກັດທີ່ຮຸນແຮງ FROM, ແລະເຮັດວຽກພຽງແຕ່ກັບຕາຕະລາງຫນຶ່ງທີ່ກໍານົດໄວ້, ແລະໃນ WHERE, ຕ້ອງລະບຸລະຫັດຫຼັກສະເໝີ. ນີ້ກ່ຽວຂ້ອງກັບການຊຸກຍູ້ການປະຕິບັດ NoSQL ທີ່ພວກເຮົາໄດ້ເວົ້າກ່ຽວກັບກ່ອນຫນ້ານີ້. ຄວາມປາຖະຫນານີ້ນໍາໄປສູ່ການຫຼຸດລົງທີ່ເປັນໄປໄດ້ໃນການໂຕ້ຕອບຂ້າມຕາຕະລາງແລະຂ້າມທີ່ສໍາຄັນ. ມັນ​ສາ​ມາດ​ນໍາ​ສະ​ເຫນີ​ການ​ຊັກ​ຊ້າ​ຂະ​ຫນາດ​ໃຫຍ່​ໃນ​ການ​ສື່​ສານ​ລະ​ຫວ່າງ node ໃນ​ເວ​ລາ​ທີ່​ຕອບ​ສະ​ຫນອງ​ການ​ຮ້ອງ​ຂໍ​ແລະ​ດັ່ງ​ນັ້ນ​ແມ່ນ​ເພື່ອ​ຫຼີກ​ເວັ້ນ​ການ​ທີ່​ດີ​ທີ່​ສຸດ​ໂດຍ​ທົ່ວ​ໄປ​. ຕົວຢ່າງ, Cassandra ຮຽກຮ້ອງໃຫ້ມີການສອບຖາມທີ່ຈໍາກັດກັບຜູ້ປະຕິບັດການສະເພາະໃດຫນຶ່ງ (ເທົ່ານັ້ນ =, IN, <, >, =>, <=) ໃນກະແຈພາທິຊັນ, ຍົກເວັ້ນເມື່ອຮ້ອງຂໍດັດສະນີຮອງ (ພຽງແຕ່ຕົວປະຕິບັດການ = ອະນຸຍາດໃຫ້ຢູ່ທີ່ນີ້).

PostgreSQL

ຂ້າງລຸ່ມນີ້ແມ່ນສາມຕົວຢ່າງຂອງການສອບຖາມທີ່ສາມາດປະຕິບັດໄດ້ຢ່າງງ່າຍດາຍໂດຍຖານຂໍ້ມູນ SQL.

• ສະແດງເພງທັງໝົດໂດຍນັກສິລະປິນ;
• ສະແດງເພງທັງໝົດໂດຍນັກສິລະປິນທີ່ກົງກັບພາກສ່ວນທໍາອິດຂອງຫົວຂໍ້;
• ສະແດງເພງທັງໝົດໂດຍສິນລະປິນທີ່ມີຄໍາທີ່ແນ່ນອນໃນຊື່ ແລະລາຄາຕໍ່າກວ່າ 1.00.

SELECT * FROM Music
WHERE Artist='No One You Know';
SELECT * FROM Music
WHERE Artist='No One You Know' AND SongTitle LIKE 'Call%';
SELECT * FROM Music
WHERE Artist='No One You Know' AND SongTitle LIKE '%Today%'
AND Price > 1.00;

Cassandra

ຂອງການສອບຖາມ PostgreSQL ທີ່ລະບຸໄວ້ຂ້າງເທິງ, ພຽງແຕ່ອັນທໍາອິດທີ່ຈະເຮັດວຽກບໍ່ປ່ຽນແປງໃນ Cassandra, ນັບຕັ້ງແຕ່ຜູ້ປະກອບການ LIKE ບໍ່​ສາ​ມາດ​ຖືກ​ນໍາ​ໃຊ້​ກັບ​ຖັນ​ກຸ່ມ​ເຊັ່ນ​:​ SongTitle. ໃນກໍລະນີນີ້, ພຽງແຕ່ຜູ້ປະຕິບັດການໄດ້ຖືກອະນຸຍາດໃຫ້ = и IN.

SELECT * FROM Music
WHERE Artist='No One You Know';
SELECT * FROM Music
WHERE Artist='No One You Know' AND SongTitle IN ('Call Me Today', 'My Dog Spot')
AND Price > 1.00;

MongoDB

ດັ່ງທີ່ສະແດງຢູ່ໃນຕົວຢ່າງທີ່ຜ່ານມາ, ວິທີການຕົ້ນຕໍສໍາລັບການສ້າງແບບສອບຖາມໃນ MongoDB ແມ່ນ db.collection.find(). ວິທີການນີ້ມີຊື່ຂອງຄໍເລັກຊັນຢ່າງຈະແຈ້ງ (music ໃນຕົວຢ່າງຂ້າງລຸ່ມນີ້), ດັ່ງນັ້ນການສອບຖາມການລວບລວມຫຼາຍແມ່ນຫ້າມ.

db.music.find( {
  artist: "No One You Know"
 } 
);
db.music.find( {
  artist: "No One You Know",
  songTitle: /Call/
 } 
);

ກຳລັງອ່ານແຖວທັງໝົດຂອງຕາຕະລາງ

ການອ່ານແຖວທັງໝົດແມ່ນພຽງແຕ່ເປັນກໍລະນີພິເສດຂອງຮູບແບບການສອບຖາມທີ່ພວກເຮົາເບິ່ງກ່ອນໜ້ານີ້.

PostgreSQL

SELECT * 
FROM Music;

Cassandra

ຄ້າຍຄືກັນກັບຕົວຢ່າງ PostgreSQL ຂ້າງເທິງ.

MongoDB

db.music.find( {} );

ການແກ້ໄຂຂໍ້ມູນໃນຕາຕະລາງ

PostgreSQL

PostgreSQL ໃຫ້ຄໍາແນະນໍາ UPDATE ການ​ປ່ຽນ​ແປງ​ຂໍ້​ມູນ​. ນາງບໍ່ມີໂອກາດ UPSERT, ດັ່ງນັ້ນຄໍາຖະແຫຼງນີ້ຈະລົ້ມເຫລວຖ້າແຖວນັ້ນບໍ່ມີຢູ່ໃນຖານຂໍ້ມູນ.

UPDATE Music
SET Genre = 'Disco'
WHERE Artist = 'The Acme Band' AND SongTitle = 'Still In Love';

Cassandra

Cassandra ມີ UPDATE ຄ້າຍຄືກັນກັບ PostgreSQL. UPDATE ມີ semantics ດຽວກັນ UPSERT, ຄ້າຍຄືກັນ INSERT.

ຄ້າຍຄືກັນກັບຕົວຢ່າງ PostgreSQL ຂ້າງເທິງ.

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

db.music.update(
  {"artist": "The Acme Band"},
  { 
    $set: {
      "genre": "Disco"
    }
  },
  {"multi": true, "upsert": true}
);

ການເອົາຂໍ້ມູນອອກຈາກຕາຕະລາງ

PostgreSQL

DELETE FROM Music
WHERE Artist = 'The Acme Band' AND SongTitle = 'Look Out, World';

Cassandra

ຄ້າຍຄືກັນກັບຕົວຢ່າງ PostgreSQL ຂ້າງເທິງ.

MongoDB

MongoDB ມີ​ສອງ​ປະ​ເພດ​ຂອງ​ການ​ດໍາ​ເນີນ​ງານ​ເພື່ອ​ລົບ​ເອ​ກະ​ສານ − ລຶບຫນຶ່ງ() /deleteMany() и ເອົາ (). ທັງສອງປະເພດລຶບເອກະສານແຕ່ໃຫ້ຜົນໄດ້ຮັບທີ່ແຕກຕ່າງກັນ.

db.music.deleteMany( {
        artist: "The Acme Band"
    }
);

ການລຶບຕາຕະລາງ

PostgreSQL

DROP TABLE Music;

Cassandra

ຄ້າຍຄືກັນກັບຕົວຢ່າງ PostgreSQL ຂ້າງເທິງ.

MongoDB

db.music.drop();

ສະຫລຸບ

ການໂຕ້ວາທີກ່ຽວກັບການເລືອກລະຫວ່າງ SQL ແລະ NoSQL ໄດ້ເກີດຂຶ້ນມາເປັນເວລາຫຼາຍກວ່າ 10 ປີແລ້ວ. ມີສອງລັກສະນະຕົ້ນຕໍໃນການໂຕ້ວາທີນີ້: ສະຖາປັດຕະຍະກໍາຖານຂໍ້ມູນ (monolithic, ການເຮັດທຸລະກໍາ SQL vs ແຈກຢາຍ, NoSQL ທີ່ບໍ່ແມ່ນການເຮັດທຸລະກໍາ) ແລະວິທີການອອກແບບຖານຂໍ້ມູນ (ການສ້າງແບບຈໍາລອງຂໍ້ມູນຂອງທ່ານໃນ SQL vs ການສ້າງແບບຈໍາລອງການສອບຖາມຂອງທ່ານໃນ NoSQL).

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

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

ກັບຄືນໄປບ່ອນການສົນທະນາການອອກແບບຖານຂໍ້ມູນ, ມັນເປັນການຍຸຕິທໍາທີ່ຈະເວົ້າວ່າທັງສອງວິທີການອອກແບບ (SQL ແລະ NoSQL) ແມ່ນມີຄວາມຈໍາເປັນສໍາລັບຄໍາຮ້ອງສະຫມັກທີ່ແທ້ຈິງທີ່ສະລັບສັບຊ້ອນ. ວິທີການ SQL "ສ້າງແບບຈໍາລອງຂໍ້ມູນ" ຊ່ວຍໃຫ້ນັກພັດທະນາສາມາດຕອບສະຫນອງຄວາມຕ້ອງການທາງທຸລະກິດທີ່ປ່ຽນແປງໄດ້ງ່າຍ, ໃນຂະນະທີ່ວິທີການ "ແບບສອບຖາມ" ຂອງ NoSQL ຊ່ວຍໃຫ້ຜູ້ພັດທະນາດຽວກັນສາມາດປະຕິບັດຂໍ້ມູນຈໍານວນຫລາຍທີ່ມີ latency ຕ່ໍາແລະສູງ. ມັນແມ່ນຍ້ອນເຫດຜົນນີ້ YugaByte DB ສະຫນອງ SQL ແລະ NoSQL APIs ຢູ່ໃນຫຼັກທົ່ວໄປ, ແທນທີ່ຈະສົ່ງເສີມວິທີການຫນຶ່ງ. ນອກຈາກນັ້ນ, ໂດຍການສະຫນອງຄວາມເຂົ້າກັນໄດ້ກັບພາສາຖານຂໍ້ມູນທີ່ນິຍົມລວມທັງ PostgreSQL ແລະ Cassandra, YugaByte DB ຮັບປະກັນວ່ານັກພັດທະນາບໍ່ຈໍາເປັນຕ້ອງຮຽນຮູ້ພາສາອື່ນເພື່ອເຮັດວຽກກັບເຄື່ອງຈັກຖານຂໍ້ມູນທີ່ແຈກຢາຍ, ມີຄວາມສອດຄ່ອງສູງ.

ໃນບົດຄວາມນີ້, ພວກເຮົາໄດ້ເບິ່ງວິທີການພື້ນຖານການອອກແບບຖານຂໍ້ມູນແຕກຕ່າງກັນລະຫວ່າງ PostgreSQL, Cassandra, ແລະ MongoDB. ໃນບົດຄວາມໃນອະນາຄົດ, ພວກເຮົາຈະເຂົ້າໄປໃນແນວຄວາມຄິດການອອກແບບຂັ້ນສູງເຊັ່ນ: ດັດສະນີ, ການເຮັດທຸລະກໍາ, ເຂົ້າຮ່ວມ, ຄໍາສັ່ງ TTL, ແລະເອກະສານ JSON.

ພວກເຮົາຕ້ອງການໃຫ້ທ່ານພັກຜ່ອນທີ່ດີຂອງທ້າຍອາທິດແລະເຊີນທ່ານໄປ webinar ຟຣີ​ເຊິ່ງຈະ​ໄຂ​ຂຶ້ນ​ໃນ​ວັນ​ທີ 14 ພຶດສະພາ​ນີ້.

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