ຖານຂໍ້ມູນ KDB+: ຈາກການເງິນເຖິງສູດ 1

KDB+, ຜະລິດຕະພັນຂອງບໍລິສັດ KX ເປັນທີ່ຮູ້ຈັກຢ່າງກວ້າງຂວາງໃນວົງແຄບ, ໄວທີ່ສຸດ, ຖານຂໍ້ມູນ columnar ອອກແບບມາສໍາລັບການເກັບຮັກສາຊຸດເວລາແລະການຄິດໄລ່ການວິເຄາະໂດຍອີງໃສ່ພວກມັນ. ໃນເບື້ອງຕົ້ນ, ມັນແມ່ນ (ແລະ) ເປັນທີ່ນິຍົມຫຼາຍໃນອຸດສາຫະກໍາການເງິນ - ມັນຖືກນໍາໃຊ້ໂດຍທະນາຄານການລົງທຶນທັງຫມົດ 10 ອັນດັບຕົ້ນແລະກອງທຶນ hedge ທີ່ມີຊື່ສຽງຫຼາຍ, ການແລກປ່ຽນແລະອົງການຈັດຕັ້ງອື່ນໆ. ບໍ່ດົນມານີ້, KX ຕັດສິນໃຈຂະຫຍາຍຖານລູກຄ້າຂອງຕົນແລະປະຈຸບັນສະເຫນີການແກ້ໄຂໃນພື້ນທີ່ອື່ນໆທີ່ມີຂໍ້ມູນຈໍານວນຫລາຍ, ຈັດຕັ້ງໂດຍເວລາຫຼືທາງອື່ນ - ໂທລະຄົມ, ຊີວະວິທະຍາ, ການຜະລິດ, ແລະອື່ນໆ. ພວກເຂົາຍັງກາຍເປັນຄູ່ຮ່ວມງານຂອງທີມ Aston Martin Red Bull Racing ໃນ Formula 1, ບ່ອນທີ່ພວກເຂົາຊ່ວຍເກັບກໍາແລະປະມວນຜົນຂໍ້ມູນຈາກເຊັນເຊີລົດແລະວິເຄາະການທົດສອບອຸໂມງລົມ. ໃນບົດຄວາມນີ້, ຂ້າພະເຈົ້າຢາກບອກທ່ານວ່າຄຸນລັກສະນະໃດແດ່ຂອງ KDB+ ເຮັດໃຫ້ມັນມີປະສິດທິພາບສູງ, ເປັນຫຍັງບໍລິສັດຈຶ່ງເຕັມໃຈທີ່ຈະໃຊ້ເງິນຫຼາຍໃນມັນ, ແລະສຸດທ້າຍ, ເປັນຫຍັງມັນບໍ່ແມ່ນຖານຂໍ້ມູນແທ້ໆ.
 

 
ໃນບົດຄວາມນີ້ຂ້າພະເຈົ້າຈະພະຍາຍາມບອກທ່ານໂດຍທົ່ວໄປວ່າ KDB+ ແມ່ນຫຍັງ, ຄວາມສາມາດແລະຂໍ້ຈໍາກັດຂອງມັນແມ່ນຫຍັງ, ແລະຜົນປະໂຫຍດຂອງມັນແມ່ນຫຍັງສໍາລັບບໍລິສັດທີ່ຕ້ອງການປະມວນຜົນຂໍ້ມູນຈໍານວນຫລາຍ. ຂ້າພະເຈົ້າຈະບໍ່ເຂົ້າໄປໃນລາຍລະອຽດຂອງການປະຕິບັດ KDB+ ຫຼືລາຍລະອຽດຂອງພາສາການຂຽນໂປລແກລມ Q ຂອງມັນ. ທັງສອງຫົວຂໍ້ນີ້ແມ່ນກວ້າງຫຼາຍແລະສົມຄວນໄດ້ຮັບບົດຄວາມແຍກຕ່າງຫາກ. ຂໍ້ມູນຫຼາຍຢ່າງກ່ຽວກັບຫົວຂໍ້ເຫຼົ່ານີ້ສາມາດພົບໄດ້ທີ່ code.kx.com, ລວມທັງປື້ມກ່ຽວກັບ Q - Q For Mortals (ເບິ່ງການເຊື່ອມຕໍ່ຂ້າງລຸ່ມນີ້).

ບາງເງື່ອນໄຂ

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

 

ພື້ນຫລັງປະຫວັດສາດ

KX ໄດ້ຖືກສ້າງຕັ້ງຂຶ້ນໃນປີ 1993 ໂດຍ Arthur Whitney, ຜູ້ທີ່ເຄີຍເຮັດວຽກຢູ່ທະນາຄານ Morgan Stanley ໃນພາສາ A+, ຜູ້ສືບທອດຂອງ APL - ເປັນພາສາຕົ້ນສະບັບຫຼາຍແລະມີຄວາມນິຍົມໃນໂລກການເງິນ. ແນ່ນອນ, ໃນ KX, Arthur ສືບຕໍ່ຢູ່ໃນຈິດໃຈດຽວກັນແລະສ້າງພາສາ vector-function K, ນໍາພາໂດຍແນວຄວາມຄິດຂອງ minimalism ຮາກ. ໂປຣແກຣມ K ມີລັກສະນະເປັນເຄື່ອງໝາຍວັກຕອນ ແລະຕົວອັກສອນພິເສດ, ຄວາມໝາຍຂອງເຄື່ອງໝາຍ ແລະໜ້າທີ່ແມ່ນຂຶ້ນກັບບໍລິບົດ, ແລະການດຳເນີນການແຕ່ລະອັນມີຄວາມໝາຍຫຼາຍກວ່າມັນໃນພາສາການຂຽນໂປຣແກຣມທຳມະດາ. ດ້ວຍເຫດນີ້, ໂປຣແກຣມ K ໃຊ້ພື້ນທີ່ໜ້ອຍ-ສອງສາມແຖວສາມາດປ່ຽນໜ້າຂອງຂໍ້ຄວາມໃນພາສາ verbose ເຊັ່ນ Java- ແລະເປັນການປະຕິບັດທີ່ເຂັ້ມຂຸ້ນຂອງ algorithm.
 
ຟັງຊັນໃນ K ທີ່ປະຕິບັດສ່ວນໃຫຍ່ຂອງ LL1 parser generator ຕາມໄວຍະກອນທີ່ໃຫ້ໄວ້:

1. pp:{q:{(x;p3(),y)};r:$[-11=@x;$x;11=@x;q[`N;$*x];10=abs@@x;q[`N;x]  
2.   ($)~*x;(`P;p3 x 1);(1=#x)&11=@*x;pp[{(1#x;$[2=#x;;,:]1_x)}@*x]  
3.      (?)~*x;(`Q;pp[x 1]);(*)~*x;(`M;pp[x 1]);(+)~*x;(`MP;pp[x 1]);(!)~*x;(`Y;p3 x 1)  
4.      (2=#x)&(@x 1)in 100 101 107 7 -7h;($[(@x 1)in 100 101 107h;`Ff;`Fi];p3 x 1;pp[*x])  
5.      (|)~*x;`S,(pp'1_x);2=#x;`C,{@[@[x;-1+#x;{x,")"}];0;"(",]}({$[".s.C"~4#x;6_-2_x;x]}'pp'x);'`pp];  
6.   $[@r;r;($[1<#r;".s.";""],$*r),$[1<#r;"[",(";"/:1_r),"]";""]]}  

 Arthur embodied ປັດຊະຍາຂອງປະສິດທິພາບທີ່ສຸດກັບການເຄື່ອນໄຫວຂອງຮ່າງກາຍຕໍາ່ສຸດທີ່ໃນ KDB +, ເຊິ່ງປະກົດຢູ່ໃນ 2003 (ຂ້າພະເຈົ້າຄິດວ່າໃນປັດຈຸບັນມັນເປັນທີ່ຈະແຈ້ງວ່າຕົວອັກສອນ K ໃນຊື່ມາຈາກ) ແລະບໍ່ມີຫຍັງຫຼາຍກ່ວານາຍພາສາຂອງ K ສະບັບທີສີ່. ພາສາ. ສະບັບທີ່ເປັນມິດກັບຜູ້ໃຊ້ຫຼາຍໄດ້ຖືກເພີ່ມໃສ່ເທິງຂອງ K K ທີ່ເອີ້ນວ່າ Q. Q ຍັງໄດ້ເພີ່ມການສະຫນັບສະຫນູນສໍາລັບພາສາສະເພາະຂອງ SQL - QSQL, ແລະນາຍພາສາ - ສະຫນັບສະຫນູນຕາຕະລາງເປັນປະເພດຂໍ້ມູນລະບົບ, ເຄື່ອງມືສໍາລັບການເຮັດວຽກກັບຕາຕະລາງ. ໃນຫນ່ວຍຄວາມຈໍາແລະໃນແຜ່ນ, ແລະອື່ນໆ.
 
ດັ່ງນັ້ນ, ຈາກທັດສະນະຂອງຜູ້ໃຊ້, KDB+ ແມ່ນພຽງແຕ່ນາຍພາສາ Q ທີ່ມີການສະຫນັບສະຫນູນຕາຕະລາງແລະ SQL-like LINQ-style expressions ຈາກ C#. ນີ້ແມ່ນຄວາມແຕກຕ່າງທີ່ສໍາຄັນທີ່ສຸດລະຫວ່າງ KDB+ ແລະຖານຂໍ້ມູນອື່ນໆແລະຜົນປະໂຫຍດດ້ານການແຂ່ງຂັນຕົ້ນຕໍຂອງມັນ, ເຊິ່ງມັກຈະຖືກມອງຂ້າມ. ນີ້ບໍ່ແມ່ນຖານຂໍ້ມູນ + ພາສາຊ່ວຍເຫຼືອທີ່ຖືກປິດໃຊ້ງານ, ແຕ່ເປັນພາສາການຂຽນໂປລແກລມທີ່ມີປະສິດທິພາບເຕັມຮູບແບບ + ສະຫນັບສະຫນູນໃນຕົວສໍາລັບຫນ້າທີ່ຖານຂໍ້ມູນ. ຄວາມແຕກຕ່າງນີ້ຈະມີບົດບາດຕັດສິນຊີ້ບອກຜົນປະໂຫຍດທັງໝົດຂອງ KDB+. ຍົກ​ຕົວ​ຢ່າງ…
 

ຂະຫນາດ

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

• ຂະໜາດນີ້ເຮັດໃຫ້ KDB+ ຮູ້ສຶກດີເລີດໃນຮາດແວຕ່າງໆ - ຈາກໄມໂຄຄອມພິວເຕີ Pi ໄປຫາເຊີບເວີທີ່ມີໜ່ວຍຄວາມຈຳ terabytes. ນີ້ບໍ່ມີຜົນຕໍ່ການເຮັດວຽກໃນທາງໃດກໍ່ຕາມ, ນອກຈາກນັ້ນ, Q ເລີ່ມຕົ້ນທັນທີ, ເຊິ່ງອະນຸຍາດໃຫ້ນໍາໃຊ້, ໃນບັນດາສິ່ງອື່ນໆ, ເປັນພາສາສະຄິບ.
• ໃນຂະຫນາດນີ້, ນາຍພາສາ Q ເຫມາະທັງຫມົດເຂົ້າໄປໃນຖານຄວາມຈໍາຂອງໂປເຊດເຊີ, ເຊິ່ງເລັ່ງການປະຕິບັດໂຄງການ.
• ດ້ວຍຂະຫນາດຂອງໄຟລ໌ທີ່ປະຕິບັດໄດ້ນີ້, ຂະບວນການ Q ໃຊ້ພື້ນທີ່ຫວ່າງໃນຫນ່ວຍຄວາມຈໍາ; ທ່ານສາມາດດໍາເນີນການໄດ້ຫຼາຍຮ້ອຍໄຟລ໌. ຍິ່ງໄປກວ່ານັ້ນ, ຖ້າຈໍາເປັນ, Q ສາມາດດໍາເນີນການກັບຫນ່ວຍຄວາມຈໍາຫຼາຍສິບຫຼືຫຼາຍຮ້ອຍ gigabytes ພາຍໃນຂະບວນການດຽວ.

Versatility

Q ແມ່ນດີເລີດສໍາລັບຄໍາຮ້ອງສະຫມັກທີ່ຫລາກຫລາຍ. ຂະບວນການ Q ສາມາດເຮັດຫນ້າທີ່ເປັນຖານຂໍ້ມູນປະຫວັດສາດແລະສະຫນອງການເຂົ້າເຖິງໄວຂອງຂໍ້ມູນ terabytes. ຕົວຢ່າງ, ພວກເຮົາມີຖານຂໍ້ມູນປະຫວັດສາດຫລາຍສິບ, ໃນບາງມື້ທີ່ບໍ່ໄດ້ບີບອັດຂໍ້ມູນໃຊ້ເວລາຫຼາຍກວ່າ 100 gigabytes. ຢ່າງໃດກໍ່ຕາມ, ພາຍໃຕ້ຂໍ້ຈໍາກັດທີ່ສົມເຫດສົມຜົນ, ການສອບຖາມກັບຖານຂໍ້ມູນຈະສໍາເລັດໃນສິບຫາຮ້ອຍ milliseconds. ໂດຍທົ່ວໄປ, ພວກເຮົາມີການຫມົດເວລາທົ່ວໄປສໍາລັບການຮ້ອງຂໍຂອງຜູ້ໃຊ້ - 30 ວິນາທີ - ແລະມັນເຮັດວຽກຫນ້ອຍຫຼາຍ.
 
Q ສາມາດເປັນຖານຂໍ້ມູນໃນຫນ່ວຍຄວາມຈໍາໄດ້ຢ່າງງ່າຍດາຍ. ຂໍ້ມູນໃຫມ່ຖືກເພີ່ມໃສ່ຕາຕະລາງໃນຫນ່ວຍຄວາມຈໍາຢ່າງໄວວາເພື່ອໃຫ້ຄໍາຮ້ອງຂໍຂອງຜູ້ໃຊ້ເປັນປັດໃຈຈໍາກັດ. ຂໍ້ມູນໃນຕາຕະລາງຖືກເກັບໄວ້ໃນຖັນ, ຊຶ່ງຫມາຍຄວາມວ່າການດໍາເນີນການໃດໆໃນຖັນຈະໃຊ້ cache ຂອງໂປເຊດເຊີຢ່າງເຕັມທີ່. ນອກເຫນືອໄປຈາກນີ້, KX ພະຍາຍາມປະຕິບັດການດໍາເນີນການພື້ນຖານທັງຫມົດເຊັ່ນ: ເລກຄະນິດສາດໂດຍຜ່ານຄໍາແນະນໍາ vector ຂອງໂປເຊດເຊີ, ເພີ່ມຄວາມໄວສູງສຸດ. Q ຍັງສາມາດປະຕິບັດວຽກງານທີ່ບໍ່ປົກກະຕິສໍາລັບຖານຂໍ້ມູນ - ຕົວຢ່າງເຊັ່ນ, ຂະບວນການຖ່າຍທອດຂໍ້ມູນແລະຄິດໄລ່ໃນ "ເວລາຈິງ" (ມີຄວາມລ່າຊ້າຈາກສິບ milliseconds ຫາຫຼາຍວິນາທີໂດຍອີງຕາມຫນ້າວຽກ) ຫນ້າທີ່ລວບລວມຕ່າງໆສໍາລັບເຄື່ອງມືທາງດ້ານການເງິນສໍາລັບເວລາທີ່ແຕກຕ່າງກັນ. intervals ຫຼືສ້າງຕົວແບບຂອງອິດທິພົນຂອງການເຮັດທຸລະກໍາທີ່ສົມບູນແບບກັບຕະຫຼາດແລະດໍາເນີນການ profileing ເກືອບທັນທີຫຼັງຈາກການສໍາເລັດຂອງຕົນ. ໃນວຽກງານດັ່ງກ່າວ, ສ່ວນຫຼາຍມັກຈະຊັກຊ້າທີ່ໃຊ້ເວລາຕົ້ນຕໍບໍ່ແມ່ນ Q, ແຕ່ຄວາມຕ້ອງການທີ່ຈະ synchronize ຂໍ້ມູນຈາກແຫຼ່ງທີ່ແຕກຕ່າງກັນ. ຄວາມໄວສູງແມ່ນບັນລຸໄດ້ເນື່ອງຈາກຄວາມຈິງທີ່ວ່າຂໍ້ມູນແລະຫນ້າທີ່ປະຕິບັດພວກມັນຢູ່ໃນຂະບວນການດຽວ, ແລະການປຸງແຕ່ງໄດ້ຖືກຫຼຸດລົງເພື່ອປະຕິບັດການສະແດງອອກຂອງ QSQL ຫຼາຍແລະການເຂົ້າຮ່ວມ, ເຊິ່ງບໍ່ໄດ້ຖືກຕີຄວາມຫມາຍ, ແຕ່ຖືກປະຕິບັດໂດຍລະຫັດສອງ.
 
ສຸດທ້າຍ, ທ່ານສາມາດຂຽນຂະບວນການບໍລິການໃດໆໃນ Q. ຕົວຢ່າງ, ຂະບວນການ Gateway ທີ່ແຈກຢາຍການຮ້ອງຂໍຂອງຜູ້ໃຊ້ໂດຍອັດຕະໂນມັດກັບຖານຂໍ້ມູນແລະເຄື່ອງແມ່ຂ່າຍທີ່ຈໍາເປັນ. ຜູ້ຂຽນໂປລແກລມມີສິດເສລີພາບຢ່າງສົມບູນໃນການປະຕິບັດລະບົບການດຸ່ນດ່ຽງ, ການຈັດລໍາດັບຄວາມສໍາຄັນ, ຄວາມທົນທານຕໍ່ຄວາມຜິດພາດ, ສິດທິໃນການເຂົ້າເຖິງ, ໂຄຕາແລະສິ່ງອື່ນໃດທີ່ຫົວໃຈຂອງລາວຕ້ອງການ. ບັນຫາຕົ້ນຕໍນີ້ແມ່ນວ່າທ່ານຈະຕ້ອງປະຕິບັດທັງຫມົດນີ້ຕົວທ່ານເອງ.
 
ເປັນຕົວຢ່າງ, ຂ້ອຍຈະບອກສິ່ງທີ່ປະເພດຂອງຂະບວນການທີ່ພວກເຮົາມີ. ພວກມັນທັງຫມົດແມ່ນຖືກນໍາໃຊ້ຢ່າງຫ້າວຫັນແລະເຮັດວຽກຮ່ວມກັນ, ປະສົມປະສານຫລາຍສິບຖານຂໍ້ມູນທີ່ແຕກຕ່າງກັນເຂົ້າໄປໃນຫນຶ່ງ, ການປຸງແຕ່ງຂໍ້ມູນຈາກຫຼາຍແຫຼ່ງແລະໃຫ້ບໍລິການຜູ້ໃຊ້ແລະຄໍາຮ້ອງສະຫມັກຫຼາຍຮ້ອຍຄົນ.

• ຕົວເຊື່ອມຕໍ່ ( feedhandler) ກັບແຫຼ່ງຂໍ້ມູນ. ຂະບວນການເຫຼົ່ານີ້ປົກກະຕິແລ້ວໃຊ້ຫ້ອງສະຫມຸດພາຍນອກທີ່ຖືກໂຫລດເຂົ້າໄປໃນ Q. ການໂຕ້ຕອບ C ໃນ Q ແມ່ນງ່າຍດາຍທີ່ສຸດແລະຊ່ວຍໃຫ້ທ່ານສ້າງຫນ້າທີ່ຕົວແທນໄດ້ຢ່າງງ່າຍດາຍສໍາລັບຫ້ອງສະຫມຸດ C / C++ ໃດໆ. Q ແມ່ນໄວພໍທີ່ຈະຈັດການ, ຕົວຢ່າງ, ການປະມວນຜົນຂໍ້ຄວາມ FIX ທີ່ມີນ້ໍາຖ້ວມຈາກການແລກປ່ຽນຫຼັກຊັບເອີຣົບທັງຫມົດພ້ອມໆກັນ.
• ຕົວແທນຈໍາຫນ່າຍຂໍ້ມູນ (tickerplant), ເຊິ່ງເຮັດຫນ້າທີ່ເປັນຕົວເຊື່ອມຕໍ່ລະຫວ່າງຕົວເຊື່ອມຕໍ່ແລະຜູ້ບໍລິໂພກ. ໃນເວລາດຽວກັນ, ພວກເຂົາຂຽນຂໍ້ມູນຂາເຂົ້າໄປຫາບັນທຶກຄູ່ພິເສດ, ສະຫນອງຄວາມຫມັ້ນຄົງສໍາລັບຜູ້ບໍລິໂພກຕໍ່ກັບການສູນເສຍການເຊື່ອມຕໍ່ຫຼືການເລີ່ມຕົ້ນໃຫມ່.
• ຖານຂໍ້ມູນໃນຫນ່ວຍຄວາມຈໍາ (rdb). ຖານຂໍ້ມູນເຫຼົ່ານີ້ສະຫນອງການເຂົ້າເຖິງໄວທີ່ສຸດທີ່ຈະເປັນວັດຖຸດິບ, ຂໍ້ມູນສົດໂດຍການເກັບຮັກສາໄວ້ໃນຫນ່ວຍຄວາມຈໍາ. ໂດຍປົກກະຕິ, ພວກມັນສະສົມຂໍ້ມູນໃນຕາຕະລາງໃນລະຫວ່າງມື້ແລະຕັ້ງຄ່າຄືນໃຫມ່ໃນຕອນກາງຄືນ.
• ຖານຂໍ້ມູນຄົງທີ່ (pdb). ຖານຂໍ້ມູນເຫຼົ່ານີ້ຮັບປະກັນວ່າຂໍ້ມູນສໍາລັບມື້ນີ້ຖືກເກັບໄວ້ໃນຖານຂໍ້ມູນປະຫວັດສາດ. ຕາມກົດລະບຽບ, ບໍ່ເຫມືອນກັບ rdb, ພວກມັນບໍ່ເກັບຂໍ້ມູນໃນຫນ່ວຍຄວາມຈໍາ, ແຕ່ໃຊ້ cache ພິເສດໃນແຜ່ນໃນລະຫວ່າງມື້ແລະຄັດລອກຂໍ້ມູນໃນເວລາທ່ຽງຄືນໄປຫາຖານຂໍ້ມູນປະຫວັດສາດ.
• ຖານຂໍ້ມູນປະຫວັດສາດ (hdb). ຖານຂໍ້ມູນເຫຼົ່ານີ້ສະຫນອງການເຂົ້າເຖິງຂໍ້ມູນສໍາລັບມື້ທີ່ຜ່ານມາ, ເດືອນແລະປີ. ຂະຫນາດຂອງພວກມັນ (ໃນມື້) ຖືກຈໍາກັດພຽງແຕ່ຂະຫນາດຂອງຮາດດິດເທົ່ານັ້ນ. ຂໍ້​ມູນ​ສາ​ມາດ​ຕັ້ງ​ຢູ່​ທຸກ​ແຫ່ງ​ຫົນ​, ໂດຍ​ສະ​ເພາະ​ແມ່ນ​ຢູ່​ໃນ​ແຜ່ນ​ທີ່​ແຕກ​ຕ່າງ​ກັນ​ເພື່ອ​ເລັ່ງ​ການ​ເຂົ້າ​ເຖິງ​. ມັນເປັນໄປໄດ້ທີ່ຈະບີບອັດຂໍ້ມູນໂດຍໃຊ້ algorithms ຫຼາຍທາງເລືອກ. ໂຄງສ້າງຂອງຖານຂໍ້ມູນແມ່ນເປັນເອກະສານທີ່ດີແລະງ່າຍດາຍ, ຂໍ້ມູນຖືກເກັບໄວ້ໂດຍຄໍລໍາໃນໄຟລ໌ປົກກະຕິ, ດັ່ງນັ້ນເຂົາເຈົ້າສາມາດດໍາເນີນການໄດ້, ລວມທັງວິທີການຂອງລະບົບປະຕິບັດການ.
• ຖານຂໍ້ມູນທີ່ມີຂໍ້ມູນລວມ. ພວກມັນເກັບຮັກສາການລວບລວມຕ່າງໆ, ໂດຍປົກກະຕິແລ້ວມີ, ຈັດກຸ່ມຕາມຊື່ເຄື່ອງມືແລະຊ່ວງເວລາ. ຖານຂໍ້ມູນໃນຫນ່ວຍຄວາມຈໍາປັບປຸງສະຖານະຂອງເຂົາເຈົ້າກັບແຕ່ລະຂໍ້ຄວາມທີ່ເຂົ້າມາ, ແລະຖານຂໍ້ມູນປະຫວັດສາດເກັບຮັກສາຂໍ້ມູນກ່ອນການຄິດໄລ່ເພື່ອເລັ່ງການເຂົ້າເຖິງຂໍ້ມູນປະຫວັດສາດ.
• ສຸດທ້າຍ ຂະບວນການປະຕູຄໍາຮ້ອງສະຫມັກການບໍລິການແລະຜູ້ໃຊ້. Q ອະນຸຍາດໃຫ້ທ່ານປະຕິບັດການປະມວນຜົນ asynchronous ຢ່າງສົມບູນຂອງຂໍ້ຄວາມທີ່ເຂົ້າມາ, ແຈກຢາຍໃຫ້ເຂົາເຈົ້າໃນທົ່ວຖານຂໍ້ມູນ, ການກວດສອບສິດການເຂົ້າເຖິງ, ແລະອື່ນໆ. ໃຫ້ສັງເກດວ່າຂໍ້ຄວາມບໍ່ຈໍາກັດແລະສ່ວນຫຼາຍແມ່ນບໍ່ແມ່ນການສະແດງອອກ SQL, ເຊັ່ນດຽວກັນກັບຖານຂໍ້ມູນອື່ນໆ. ສ່ວນຫຼາຍມັກ, ການສະແດງອອກ SQL ຖືກເຊື່ອງໄວ້ໃນຫນ້າທີ່ພິເສດແລະກໍ່ສ້າງໂດຍອີງໃສ່ຕົວກໍານົດການຮ້ອງຂໍໂດຍຜູ້ໃຊ້ - ເວລາຖືກປ່ຽນ, ການກັ່ນຕອງ, ຂໍ້ມູນຖືກປັບປຸງເປັນປົກກະຕິ (ຕົວຢ່າງ, ລາຄາຫຼັກຊັບແມ່ນເທົ່າທຽມກັນຖ້າເງິນປັນຜົນຈ່າຍ), ແລະອື່ນໆ.

ສະຖາປັດຕະຍະກໍາປົກກະຕິສໍາລັບປະເພດຂໍ້ມູນຫນຶ່ງ:

ຄວາມໄວ

ເຖິງແມ່ນວ່າ Q ເປັນພາສາທີ່ຖືກຕີຄວາມຫມາຍ, ມັນຍັງເປັນພາສາ vector. ນີ້ຫມາຍຄວາມວ່າຫຼາຍຫນ້າທີ່ສ້າງໃນ, ໂດຍສະເພາະເລກເລກ, ເອົາການໂຕ້ຖຽງຂອງຮູບແບບໃດກໍ່ຕາມ - ຕົວເລກ, vectors, matrices, lists - ແລະນັກຂຽນໂປລແກລມຄາດວ່າຈະປະຕິບັດໂຄງການເປັນການດໍາເນີນງານ array. ໃນພາສາດັ່ງກ່າວ, ຖ້າທ່ານເພີ່ມສອງ vectors ຂອງລ້ານອົງປະກອບ, ມັນບໍ່ສໍາຄັນອີກຕໍ່ໄປວ່າພາສາໄດ້ຖືກຕີຄວາມ; ການເພີ່ມເຕີມຈະຖືກປະຕິບັດໂດຍຟັງຊັນ binary ທີ່ດີທີ່ສຸດ. ນັບຕັ້ງແຕ່ສ່ວນແບ່ງຂອງຊ້າງຂອງເວລາໃນໂຄງການ Q ແມ່ນໃຊ້ໃນການດໍາເນີນງານກັບຕາຕະລາງທີ່ໃຊ້ຫນ້າທີ່ vectorized ພື້ນຖານເຫຼົ່ານີ້, ຜົນຜະລິດແມ່ນຄວາມໄວໃນການດໍາເນີນງານທີ່ເຫມາະສົມ, ເຮັດໃຫ້ພວກເຮົາສາມາດປຸງແຕ່ງຂໍ້ມູນຈໍານວນຫຼວງຫຼາຍເຖິງແມ່ນວ່າໃນຂະບວນການດຽວ. ນີ້ແມ່ນຄ້າຍຄືກັນກັບຫ້ອງສະຫມຸດຄະນິດສາດໃນ Python - ເຖິງແມ່ນວ່າ Python ຕົວຂອງມັນເອງເປັນພາສາທີ່ຊ້າຫຼາຍ, ມັນມີຫ້ອງສະຫມຸດທີ່ດີເລີດຫຼາຍເຊັ່ນ numpy ທີ່ຊ່ວຍໃຫ້ທ່ານສາມາດປຸງແຕ່ງຂໍ້ມູນຕົວເລກດ້ວຍຄວາມໄວຂອງພາສາທີ່ລວບລວມ (ໂດຍວິທີທາງການ, numpy ແມ່ນ ideologically ໃກ້ກັບ Q. ).
 
ນອກຈາກນັ້ນ, KX ໄດ້ໃຊ້ວິທີການທີ່ລະມັດລະວັງຫຼາຍໃນການອອກແບບຕາຕະລາງແລະການເພີ່ມປະສິດທິພາບການເຮັດວຽກກັບພວກມັນ. ກ່ອນອື່ນ ໝົດ, ດັດສະນີຫຼາຍປະເພດໄດ້ຮັບການສະຫນັບສະຫນູນ, ເຊິ່ງໄດ້ຮັບການສະຫນັບສະຫນູນຈາກຫນ້າທີ່ສ້າງແລະສາມາດນໍາໃຊ້ບໍ່ພຽງແຕ່ກັບຖັນຕາຕະລາງ, ແຕ່ຍັງກັບ vectors ໃດ - ການຈັດກຸ່ມ, ການຈັດລຽງ, ຄຸນລັກສະນະທີ່ເປັນເອກະລັກແລະການຈັດກຸ່ມພິເສດສໍາລັບຖານຂໍ້ມູນປະຫວັດສາດ. ດັດຊະນີແມ່ນໃຊ້ແບບງ່າຍໆ ແລະຖືກປັບອັດຕະໂນມັດເມື່ອເພີ່ມອົງປະກອບໃສ່ຖັນ/ vector. ດັດຊະນີສາມາດຖືກນຳໃຊ້ຢ່າງເທົ່າທຽມກັນກັບຖັນຕາຕະລາງທັງໃນໜ່ວຍຄວາມຈຳ ແລະໃນແຜ່ນ. ເມື່ອປະຕິບັດການສອບຖາມ QSQL, ດັດສະນີຖືກນໍາໃຊ້ໂດຍອັດຕະໂນມັດຖ້າເປັນໄປໄດ້. ອັນທີສອງ, ການເຮັດວຽກກັບຂໍ້ມູນປະຫວັດສາດແມ່ນເຮັດໂດຍຜ່ານກົນໄກສໍາລັບການສະແດງໄຟລ໌ OS (ແຜນທີ່ຫນ່ວຍຄວາມຈໍາ). ຕາຕະລາງຂະຫນາດໃຫຍ່ບໍ່ເຄີຍຖືກໂຫລດເຂົ້າໄປໃນຫນ່ວຍຄວາມຈໍາ; ແທນທີ່ຈະ, ຄໍລໍາທີ່ຈໍາເປັນແມ່ນຖືກຈັດໃສ່ໂດຍກົງໃນຫນ່ວຍຄວາມຈໍາແລະພຽງແຕ່ສ່ວນຫນຶ່ງຂອງພວກມັນຖືກໂຫລດ (ດັດສະນີຍັງຊ່ວຍຢູ່ທີ່ນີ້) ທີ່ຈໍາເປັນ. ມັນບໍ່ມີຄວາມແຕກຕ່າງກັນກັບນັກຂຽນໂປລແກລມວ່າຂໍ້ມູນຢູ່ໃນຫນ່ວຍຄວາມຈໍາຫຼືບໍ່; ກົນໄກສໍາລັບການເຮັດວຽກກັບ mmap ໄດ້ຖືກເຊື່ອງໄວ້ຢ່າງສົມບູນໃນຄວາມເລິກຂອງ Q.
 
KDB+ ບໍ່ແມ່ນຖານຂໍ້ມູນທີ່ກ່ຽວຂ້ອງ; ຕາຕະລາງສາມາດມີຂໍ້ມູນ arbitrary, ໃນຂະນະທີ່ລໍາດັບຂອງແຖວໃນຕາຕະລາງບໍ່ປ່ຽນແປງເມື່ອອົງປະກອບໃຫມ່ຖືກເພີ່ມແລະສາມາດແລະຄວນຈະຖືກນໍາໃຊ້ໃນເວລາຂຽນຄໍາຖາມ. ຄຸນນະສົມບັດນີ້ແມ່ນຈໍາເປັນດ່ວນສໍາລັບການເຮັດວຽກກັບຊຸດເວລາ (ຂໍ້ມູນຈາກການແລກປ່ຽນ, telemetry, ບັນທຶກເຫດການ), ເພາະວ່າຖ້າຂໍ້ມູນຖືກຈັດຮຽງຕາມເວລາ, ຜູ້ໃຊ້ບໍ່ຈໍາເປັນຕ້ອງໃຊ້ tricks SQL ໃດໆເພື່ອຊອກຫາແຖວທໍາອິດຫຼືສຸດທ້າຍຫຼື N. ແຖວໃນຕາຕະລາງ, ກໍານົດວ່າເສັ້ນໃດປະຕິບັດຕາມເສັ້ນ Nth, ແລະອື່ນໆ. ການເຂົ້າຮ່ວມຕາຕະລາງແມ່ນງ່າຍດາຍຕື່ມອີກ, ສໍາລັບຕົວຢ່າງ, ການຊອກຫາຄໍາອ້າງອີງສຸດທ້າຍສໍາລັບການເຮັດທຸລະກໍາ 16000 VOD.L (Vodafone) ໃນຕາຕະລາງ 500 ລ້ານອົງປະກອບໃຊ້ເວລາປະມານຫນຶ່ງວິນາທີໃນແຜ່ນແລະສິບ milliseconds ໃນຫນ່ວຍຄວາມຈໍາ.
 
ຕົວຢ່າງຂອງການເຂົ້າຮ່ວມທີ່ໃຊ້ເວລາ - ຕາຕະລາງ quote ແມ່ນແຜນທີ່ກັບຫນ່ວຍຄວາມຈໍາ, ດັ່ງນັ້ນບໍ່ຈໍາເປັນຕ້ອງລະບຸ VOD.L ໃນບ່ອນທີ່, ດັດສະນີໃນຖັນ sym ແລະຄວາມຈິງທີ່ວ່າຂໍ້ມູນຖືກຈັດຮຽງຕາມເວລາຖືກນໍາໃຊ້ໂດຍ implicitly. ເກືອບທັງຫມົດເຂົ້າຮ່ວມໃນ Q ແມ່ນຫນ້າທີ່ປົກກະຕິ, ບໍ່ແມ່ນສ່ວນຫນຶ່ງຂອງການສະແດງອອກທີ່ເລືອກ:

1. aj[`sym`time;select from trade where date=2019.03.26, sym=`VOD.L;select from quote where date=2019.03.26]  

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

ຜົນໄດ້ຮັບ

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

ສໍາລັບຂໍ້ມູນເພີ່ມເຕີມ

ຂໍ້ບົກພ່ອງ

ຂໍ້ເສຍທີ່ສໍາຄັນຂອງ KDB+/Q ແມ່ນເກນເຂົ້າສູງ. ພາສາມີ syntax ທີ່ແປກປະຫລາດ, ບາງຫນ້າແມ່ນ overloaded ຢ່າງຫຼວງຫຼາຍ (ຄ່າ, ຕົວຢ່າງ, ມີປະມານ 11 ກໍລະນີທີ່ໃຊ້). ສິ່ງທີ່ ສຳ ຄັນທີ່ສຸດ, ມັນຮຽກຮ້ອງໃຫ້ມີວິທີການຂຽນໂປແກຼມທີ່ແຕກຕ່າງກັນຫຼາຍ. ໃນພາສາ vector, ທ່ານສະເຫມີຕ້ອງຄິດໃນແງ່ຂອງການຫັນເປັນ array, ປະຕິບັດ loops ທັງຫມົດໂດຍຜ່ານ variants ຂອງແຜນທີ່ / ຫນ້າທີ່ຫຼຸດລົງ (ຊຶ່ງເອີ້ນວ່າ adverbs ໃນ Q), ແລະບໍ່ເຄີຍພະຍາຍາມປະຫຍັດເງິນໂດຍການທົດແທນການດໍາເນີນການ vector ກັບປະລໍາມະນູ. ຕົວຢ່າງ, ເພື່ອຊອກຫາດັດຊະນີຂອງການປະກົດຕົວ Nth ຂອງອົງປະກອບໃນ array, ທ່ານຄວນຂຽນ:

1. (where element=vector)[N]  

ເຖິງແມ່ນວ່ານີ້ເບິ່ງຄືວ່າບໍ່ມີປະສິດຕິພາບຫຼາຍໂດຍມາດຕະຖານ C/Java (= ສ້າງ vector boolean, ບ່ອນທີ່ສົ່ງຄືນດັດຊະນີທີ່ແທ້ຈິງຂອງອົງປະກອບໃນມັນ). ແຕ່ຫມາຍເຫດນີ້ເຮັດໃຫ້ຄວາມຫມາຍຂອງການສະແດງອອກທີ່ຊັດເຈນກວ່າແລະທ່ານໃຊ້ vector ການດໍາເນີນງານໄວແທນທີ່ຈະເປັນປະລໍາມະນູຊ້າ. ຄວາມແຕກຕ່າງທາງດ້ານແນວຄິດລະຫວ່າງພາສາ vector ແລະພາສາອື່ນໆແມ່ນປຽບທຽບກັບຄວາມແຕກຕ່າງລະຫວ່າງວິທີການທີ່ມີຄວາມຈໍາເປັນແລະເປັນປະໂຫຍດຕໍ່ການດໍາເນີນໂຄງການ, ແລະທ່ານຈໍາເປັນຕ້ອງກຽມພ້ອມສໍາລັບການນີ້.
 
ຜູ້ໃຊ້ບາງຄົນກໍ່ບໍ່ພໍໃຈກັບ QSQL. ຈຸດແມ່ນວ່າມັນພຽງແຕ່ຄ້າຍຄື SQL ທີ່ແທ້ຈິງ. ໃນຄວາມເປັນຈິງ, ມັນເປັນພຽງແຕ່ນາຍພາສາຂອງການສະແດງອອກຄ້າຍຄື SQL ທີ່ບໍ່ສະຫນັບສະຫນູນການເພີ່ມປະສິດທິພາບແບບສອບຖາມ. ຜູ້ໃຊ້ຕ້ອງຂຽນຄໍາຖາມທີ່ດີທີ່ສຸດຂອງຕົນເອງ, ແລະໃນ Q, ເຊິ່ງຫຼາຍຄົນບໍ່ກຽມພ້ອມ. ໃນທາງກົງກັນຂ້າມ, ແນ່ນອນ, ທ່ານສາມາດຂຽນຄໍາຖາມທີ່ດີທີ່ສຸດດ້ວຍຕົນເອງ, ແທນທີ່ຈະອີງໃສ່ຕົວເພີ່ມປະສິດທິພາບກ່ອງສີດໍາ.
 
ເປັນບວກ, ປຶ້ມກ່ຽວກັບ Q - Q For Mortals ແມ່ນມີໃຫ້ຟຣີຢູ່ ເວັບໄຊທ໌ຂອງບໍລິສັດ, ຍັງມີຫຼາຍຂອງອຸປະກອນທີ່ເປັນປະໂຫຍດອື່ນໆເກັບກໍາຢູ່ທີ່ນັ້ນ.
 
ຂໍ້ເສຍອັນໃຫຍ່ອີກອັນຫນຶ່ງແມ່ນຄ່າໃຊ້ຈ່າຍຂອງໃບອະນຸຍາດ. ນັ້ນແມ່ນຫລາຍສິບພັນໂດລາຕໍ່ປີຕໍ່ CPU. ພຽງແຕ່ບໍລິສັດຂະຫນາດໃຫຍ່ສາມາດຈ່າຍຄ່າໃຊ້ຈ່າຍດັ່ງກ່າວ. ບໍ່ດົນມານີ້, KX ໄດ້ເຮັດໃຫ້ນະໂຍບາຍການອະນຸຍາດຂອງຕົນມີຄວາມຍືດຫຍຸ່ນຫຼາຍແລະໃຫ້ໂອກາດທີ່ຈະຈ່າຍພຽງແຕ່ສໍາລັບເວລາຂອງການນໍາໃຊ້ຫຼືເຊົ່າ KDB+ ໃນ Google ແລະ Amazon clouds. KX ຍັງສະເຫນີໃຫ້ດາວໂຫລດ ສະບັບຟຣີສໍາລັບຈຸດປະສົງທີ່ບໍ່ແມ່ນການຄ້າ (ສະບັບ 32 bit ຫຼື 64 bit ຕາມການຮ້ອງຂໍ).
 

ຄູ່ແຂ່ງ

ມີຖານຂໍ້ມູນພິເສດຈໍານວນຫນ້ອຍທີ່ສ້າງຂຶ້ນໃນຫຼັກການທີ່ຄ້າຍຄືກັນ - columnar, in-memory, ສຸມໃສ່ຂໍ້ມູນຈໍານວນຫລາຍ. ບັນຫາແມ່ນວ່າເຫຼົ່ານີ້ແມ່ນຖານຂໍ້ມູນພິເສດ. ຕົວຢ່າງທີ່ໂດດເດັ່ນແມ່ນ Clickhouse. ຖານຂໍ້ມູນນີ້ມີຫຼັກການຄ້າຍຄືກັນກັບ KDB + ສໍາລັບການເກັບຮັກສາຂໍ້ມູນໃນແຜ່ນແລະສ້າງດັດສະນີ; ມັນດໍາເນີນການສອບຖາມບາງຢ່າງໄວກວ່າ KDB +, ເຖິງແມ່ນວ່າບໍ່ສໍາຄັນ. ແຕ່ເຖິງແມ່ນວ່າເປັນຖານຂໍ້ມູນ, Clickhouse ມີຄວາມຊ່ຽວຊານຫຼາຍກ່ວາ KDB + - ການວິເຄາະເວັບທຽບກັບຊຸດເວລາ arbitrary (ຄວາມແຕກຕ່າງນີ້ມີຄວາມສໍາຄັນຫຼາຍ - ເພາະວ່າມັນ, ສໍາລັບຕົວຢ່າງ, ໃນ Clickhouse ມັນບໍ່ສາມາດໃຊ້ຄໍາສັ່ງຂອງບັນທຶກ). ແຕ່, ສໍາຄັນທີ່ສຸດ, Clickhouse ບໍ່ມີ versatility ຂອງ KDB +, ພາສາທີ່ຈະຊ່ວຍໃຫ້ການປະມວນຜົນຂໍ້ມູນໂດຍກົງໃນຖານຂໍ້ມູນ, ແທນທີ່ຈະກ່ວາການໂຫຼດມັນທໍາອິດເຂົ້າໄປໃນຄໍາຮ້ອງສະຫມັກແຍກຕ່າງຫາກ, ການກໍ່ສ້າງການສະແດງອອກ SQL arbitrary, ນໍາໃຊ້ຫນ້າທີ່ arbitrary ໃນການສອບຖາມ, ການສ້າງຂະບວນການ. ບໍ່ກ່ຽວຂ້ອງກັບການປະຕິບັດຫນ້າທີ່ຖານຂໍ້ມູນປະຫວັດສາດ . ດັ່ງນັ້ນ, ມັນເປັນການຍາກທີ່ຈະປຽບທຽບ KDB + ກັບຖານຂໍ້ມູນອື່ນໆ; ພວກເຂົາເຈົ້າອາດຈະດີກວ່າໃນບາງກໍລະນີການນໍາໃຊ້ຫຼືພຽງແຕ່ດີກວ່າໃນເວລາທີ່ມັນມາກັບວຽກງານຖານຂໍ້ມູນຄລາສສິກ, ແຕ່ຂ້າພະເຈົ້າບໍ່ຮູ້ເຄື່ອງມືອື່ນທີ່ມີປະສິດທິພາບເທົ່າທຽມກັນແລະຫລາກຫລາຍສໍາລັບການປະມວນຜົນຂໍ້ມູນຊົ່ວຄາວ.
 

ການເຊື່ອມໂຍງ Python

ເພື່ອເຮັດໃຫ້ KDB+ ງ່າຍຕໍ່ການໃຊ້ສໍາລັບຄົນທີ່ບໍ່ຄຸ້ນເຄີຍກັບເຕັກໂນໂລຢີ, KX ໄດ້ສ້າງຫ້ອງສະຫມຸດເພື່ອປະສົມປະສານຢ່າງແຫນ້ນຫນາກັບ Python ພາຍໃນຂະບວນການດຽວ. ທ່ານສາມາດໂທຫາຟັງຊັນ Python ໃດໆຈາກ Q, ຫຼືໃນທາງກັບກັນ - ໂທຫາຟັງຊັນ Q ໃດຈາກ Python (ໂດຍສະເພາະ, ການສະແດງອອກ QSQL). ຫ້ອງສະຫມຸດແປງ, ຖ້າຈໍາເປັນ (ບໍ່ສະເຫມີໄປສໍາລັບ sake ຂອງປະສິດທິພາບ), ຂໍ້ມູນຈາກຮູບແບບຂອງພາສາຫນຶ່ງກັບຮູບແບບຂອງພາສາອື່ນ. ດັ່ງນັ້ນ, Q ແລະ Python ອາໄສຢູ່ໃນ symbiosis ໃກ້ຊິດທີ່ເຂດແດນລະຫວ່າງພວກມັນຖືກມົວ. ດັ່ງນັ້ນ, ໃນດ້ານຫນຶ່ງ, ນັກຂຽນໂປລແກລມໄດ້ເຂົ້າເຖິງຫ້ອງສະຫມຸດ Python ທີ່ເປັນປະໂຫຍດຈໍານວນຫລາຍ, ໃນທາງກົງກັນຂ້າມ, ລາວໄດ້ຮັບພື້ນຖານໄວສໍາລັບການເຮັດວຽກກັບຂໍ້ມູນໃຫຍ່ທີ່ປະສົມປະສານເຂົ້າໃນ Python, ເຊິ່ງເປັນປະໂຫຍດໂດຍສະເພາະສໍາລັບຜູ້ທີ່ມີສ່ວນຮ່ວມໃນການຮຽນຮູ້ເຄື່ອງຈັກ. ຫຼືການສ້າງແບບຈໍາລອງ.
 
ເຮັດວຽກກັບ Q ໃນ Python:

1. >>> q()  
2.q)trade:([]date:();sym:();qty:())  
3. q)  
4. >>> q.insert('trade', (date(2006,10,6), 'IBM', 200))  
5. k(',0')  
6. >>> q.insert('trade', (date(2006,10,6), 'MSFT', 100))  
7. k(',1')  

ເອກະສານ

ສະຖານທີ່ຂອງບໍລິສັດ - https://kx.com/
ເວັບໄຊທ໌ສໍາລັບນັກພັດທະນາ - https://code.kx.com/v2/
Book Q ສໍາລັບມະນຸດ (ໃນພາສາອັງກິດ) - https://code.kx.com/q4m3/
ບົດຄວາມກ່ຽວກັບແອັບພລິເຄຊັນ KDB+/Q ຈາກພະນັກງານ kx - https://code.kx.com/v2/wp/

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