מסד נתונים KDB+: מפיננסים לפורמולה 1

KDB+, מוצר חברה KX הוא מסד נתונים עמודי, ידוע במעגלים צרים, מהיר במיוחד, המיועד לאחסון סדרות זמן וחישובים אנליטיים המבוססים עליהם. בתחילה, זה היה (והוא) מאוד פופולרי בתעשייה הפיננסית - הוא משמש את כל 10 בנקי ההשקעות המובילים וקרנות גידור רבות, בורסות וארגונים אחרים ידועים. לאחרונה החליטה KX להרחיב את בסיס הלקוחות שלה וכעת להציע פתרונות בתחומים נוספים בהם יש כמות גדולה של נתונים, מאורגנים לפי זמן או אחרת - טלקום, ביואינפורמטיקה, ייצור וכו'. הם גם הפכו לשותפים של קבוצת Aston Martin Red Bull Racing בפורמולה 1, שם הם עוזרים לאסוף ולעבד נתונים מחיישני מכוניות ולנתח מבחני מנהרות רוח. במאמר זה, אני רוצה לספר לכם אילו תכונות של KDB+ הופכות אותו לסופר-ביצועים, מדוע חברות מוכנות להוציא עליו הרבה כסף, ולבסוף, מדוע זה לא באמת מסד נתונים.
 

 
במאמר זה אנסה לספר לכם באופן כללי מה זה KDB+, אילו יכולות ומגבלות יש לו, ומה היתרונות שלו לחברות שרוצות לעבד כמויות גדולות של נתונים. לא אכנס לפרטי היישום של +KDB או לפרטי שפת התכנות שלו Q. שני הנושאים הללו רחבים מאוד וראויים למאמרים נפרדים. מידע רב על נושאים אלה ניתן למצוא ב-code.kx.com, כולל ספר על Q - Q For Mortals (ראה קישור למטה).

כמה מונחים

• מסד נתונים בזיכרון. מסד נתונים המאחסן נתונים ב-RAM לגישה מהירה יותר. היתרונות של מסד נתונים כזה ברורים, אך החסרונות הם האפשרות לאובדן נתונים והצורך להחזיק זיכרון רב בשרת.
• מסד נתונים עמודות. מסד נתונים שבו הנתונים מאוחסנים עמודה אחר עמודה במקום רשומה אחר רשומה. היתרון העיקרי של מסד נתונים כזה הוא שהנתונים מעמודה אחת מאוחסנים יחד בדיסק ובזיכרון, מה שמאיץ משמעותית את הגישה אליו. אין צורך לטעון עמודות שאינן בשימוש בשאילתה. החיסרון העיקרי הוא שקשה לשנות ולמחוק רשומות.
• סדרת זמן. נתונים עם עמודת תאריך או שעה. בדרך כלל, סדר הזמן חשוב עבור נתונים כאלה, כך שתוכל לקבוע בקלות איזו רשומה קודמת לרשומה הנוכחית או אחריה, או להחיל פונקציות שתוצאותיהן תלויות בסדר הרשומות. מאגרי מידע קלאסיים בנויים על עיקרון אחר לגמרי - המייצגים אוסף רשומות כסט, כאשר סדר הרשומות, באופן עקרוני, אינו מוגדר.
• וֶקטוֹר. בהקשר של KDB+, זוהי רשימה של יסודות מאותו סוג אטומי, למשל, מספרים. במילים אחרות, מערך של אלמנטים. ניתן לאחסן מערכים, בניגוד לרשימות, בצורה קומפקטית ולעבד באמצעות הוראות מעבד וקטור.

 

היסטוריה

KX נוסדה בשנת 1993 על ידי ארתור ויטני, שעבד בעבר בבנק מורגן סטנלי על שפת A+, היורשת של APL - שפה מקורית מאוד ולעתים פופולרית בעולם הפיננסי. כמובן, ב-KX, ארתור המשיך באותה רוח ויצר את השפה הווקטורית-פונקציונלית K, המונחה על ידי רעיונות המינימליזם הרדיקלי. תוכניות K נראות כמו ערבוביה של סימני פיסוק ותווים מיוחדים, המשמעות של סימנים ופונקציות תלויה בהקשר, ולכל פעולה יש הרבה יותר משמעות מאשר בשפות תכנות קונבנציונליות. בשל כך, תוכנית K תופסת מקום מינימלי - כמה שורות יכולות להחליף דפי טקסט בשפה מילולית כמו Java - והיא יישום סופר מרוכז של האלגוריתם.
 
פונקציה ב-K המיישמת את רוב מחולל הנתח LL1 לפי דקדוק נתון:

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),"]";""]]}  

 ארתור גילם את הפילוסופיה הזו של יעילות קיצונית עם מינימום תנועות גוף ב-KDB+, שהופיעה ב-2003 (אני חושב שעכשיו ברור מאיפה באה האות K בשם) והיא לא יותר מאשר מתורגמן של הגרסה הרביעית של ה-K שפה נוספה גרסה ידידותית יותר למשתמש על גבי K K בשם Q. Q הוסיפה גם תמיכה בניב ספציפי של SQL - QSQL, והמתורגמן - תמיכה בטבלאות כסוג נתוני מערכת, כלים לעבודה עם טבלאות בזיכרון ובדיסק וכו'.
 
אז מנקודת מבט של משתמש, KDB+ הוא פשוט מתורגמן לשפת Q עם תמיכה בטבלאות וביטויים בסגנון LINQ דמויי SQL מ-C#. זהו ההבדל החשוב ביותר בין KDB+ לבין מסדי נתונים אחרים והיתרון התחרותי העיקרי שלו, שלעתים קרובות מתעלמים ממנו. זו אינה מסד נתונים + שפת עזר מושבתת, אלא שפת תכנות חזקה מלאה + תמיכה מובנית בפונקציות מסד נתונים. הבחנה זו תמלא תפקיד מכריע ברשימת כל היתרונות של KDB+. לדוגמה…
 

גודל

בסטנדרטים מודרניים, KDB+ הוא פשוט בגודל מיקרוסקופי. זה ממש קובץ הפעלה אחד של תת מגה-בייט וקובץ טקסט קטן אחד עם כמה פונקציות מערכת. במציאות - פחות ממגה-בייט אחד, ועל התוכנית הזו משלמות חברות עשרות אלפי דולרים בשנה על מעבד אחד בשרת.

• גודל זה מאפשר ל-KDB+ להרגיש נהדר בכל חומרה - ממיקרו-מחשב Pi ועד לשרתים עם טרה-בייט של זיכרון. זה לא משפיע בשום צורה על הפונקציונליות; יתר על כן, Q מתחיל באופן מיידי, מה שמאפשר להשתמש בו, בין היתר, כשפת סקריפט.
• בגודל זה, מתורגמן Q מתאים לחלוטין למטמון המעבד, מה שמאיץ את ביצוע התוכנית.
• עם גודל זה של קובץ ההפעלה, תהליך Q תופס מקום זניח בזיכרון; אתה יכול להפעיל מאות מהם. יתרה מכך, במידת הצורך, Q יכול לפעול עם עשרות או מאות גיגה-בייט של זיכרון בתוך תהליך בודד.

צדדיות

Q נהדר עבור מגוון רחב של יישומים. Process Q יכול לפעול כמסד נתונים היסטורי ולספק גישה מהירה לטרה-בייט של מידע. לדוגמה, יש לנו עשרות מאגרי מידע היסטוריים, שבחלקם יום אחד לא דחוס של נתונים תופס יותר מ-100 גיגה-בייט. עם זאת, תחת הגבלות סבירות, שאילתה למסד הנתונים תושלם תוך עשרות עד מאות אלפיות שניות. באופן כללי, יש לנו פסק זמן אוניברסלי לבקשות משתמשים - 30 שניות - וזה עובד לעתים רחוקות מאוד.
 
Q יכול באותה קלות להיות מסד נתונים בזיכרון. נתונים חדשים מתווספים לטבלאות בזיכרון כל כך מהר עד שבקשות משתמשים הן הגורם המגביל. הנתונים בטבלאות מאוחסנים בעמודות, מה שאומר שכל פעולה בעמודה תשתמש במטמון המעבד בקיבולת מלאה. בנוסף לכך, KX ניסתה ליישם את כל הפעולות הבסיסיות כגון חשבון באמצעות הוראות וקטוריות של המעבד, ולמקסם את מהירותן. Q יכול גם לבצע משימות שאינן אופייניות לבסיסי נתונים - למשל, לעבד נתונים זורמים ולחשב ב"זמן אמת" (בהשהייה מעשרות אלפיות שניות למספר שניות בהתאם למשימה) פונקציות צבירה שונות עבור מכשירים פיננסיים לזמן שונה מרווחים או לבנות מודל להשפעה של עסקאות מושלמות לשוק ולבצע את הפרופיל שלו כמעט מיד לאחר השלמתו. במשימות כאלה, לרוב עיכוב הזמן העיקרי אינו Q, אלא הצורך לסנכרן נתונים ממקורות שונים. מהירות גבוהה מושגת בשל העובדה שהנתונים והפונקציות המעבדות אותם נמצאים בתהליך אחד, והעיבוד מצטמצם לביצוע מספר ביטויי QSQL ו-Joins, שאינם מתפרשים, אלא מבוצעים על ידי קוד בינארי.
 
לבסוף, אתה יכול לכתוב כל תהליכי שירות ב-Q. לדוגמה, תהליכי Gateway שמפיצים באופן אוטומטי בקשות משתמשים לבסיסי הנתונים והשרתים הדרושים. למתכנת יש חופש מוחלט ליישם כל אלגוריתם לאיזון, תעדוף, סובלנות תקלות, זכויות גישה, מכסות ובעצם כל דבר אחר שלבו חפץ. הבעיה העיקרית כאן היא שתצטרכו ליישם את כל זה בעצמכם.
 
כדוגמה, אפרט אילו סוגי תהליכים יש לנו. כולם נמצאים בשימוש פעיל ועובדים יחד, משלבים עשרות מסדי נתונים שונים לאחד, מעבדים נתונים ממספר מקורות ומשרתים מאות משתמשים ויישומים.

• מחברים (feedhandler) למקורות נתונים. תהליכים אלו משתמשים בדרך כלל בספריות חיצוניות הנטענות לתוך Q. ממשק C ב-Q פשוט ביותר ומאפשר לך ליצור בקלות פונקציות פרוקסי עבור כל ספריית C/C++. Q מהיר מספיק כדי לטפל, למשל, בעיבוד מבול של הודעות FIX מכל הבורסות באירופה בו זמנית.
• מפיצי נתונים (טיקרצמח), המשמשים כקשר ביניים בין מחברים לצרכנים. במקביל, הם כותבים נתונים נכנסים ליומן בינארי מיוחד, ומספקים חוסן לצרכנים מפני אובדן חיבור או הפעלה מחדש.
• מסד נתונים בזיכרון (rdb). מסדי נתונים אלה מספקים את הגישה המהירה ביותר לנתונים גולמיים ורעננים על ידי אחסוןם בזיכרון. בדרך כלל, הם צוברים נתונים בטבלאות במהלך היום ומאפסים אותם בלילה.
• מסד נתונים מתמיד (pdb). מאגרי מידע אלו מבטיחים שהנתונים להיום מאוחסנים במסד נתונים היסטורי. ככלל, בניגוד ל-rdb, הם לא אוגרים נתונים בזיכרון, אלא משתמשים במטמון מיוחד בדיסק במהלך היום ומעתיקים את הנתונים בחצות למסד הנתונים ההיסטורי.
• מאגרי מידע היסטוריים (hdb). מאגרי מידע אלו מספקים גישה לנתונים של ימים, חודשים ושנים קודמים. הגודל שלהם (בימים) מוגבל רק על ידי גודל הכוננים הקשיחים. ניתן לאתר נתונים בכל מקום, במיוחד בדיסקים שונים כדי להאיץ את הגישה. ניתן לדחוס נתונים באמצעות מספר אלגוריתמים לבחירה. מבנה מסד הנתונים מתועד היטב ופשוט, הנתונים מאוחסנים טור אחר טור בקבצים רגילים, כך שניתן לעבד אותם, כולל באמצעות מערכת ההפעלה.
• מאגרי מידע עם מידע מצטבר. הם מאחסנים צבירות שונות, בדרך כלל עם, מקובצות לפי שם המכשיר ומרווח זמן. מסדי נתונים בזיכרון מעדכנים את מצבם עם כל הודעה נכנסת, ומסדי נתונים היסטוריים מאחסנים נתונים מחושבים מראש כדי להאיץ את הגישה לנתונים היסטוריים.
• לבסוף, תהליכי שערשירות אפליקציות ומשתמשים. Q מאפשרת ליישם עיבוד אסינכרוני לחלוטין של הודעות נכנסות, הפצתן בין מסדי נתונים, בדיקת זכויות גישה וכו'. שימו לב שהודעות אינן מוגבלות ולרוב אינן ביטויי SQL, כפי שקורה במסדי נתונים אחרים. לרוב, ביטוי ה-SQL מוסתר בפונקציה מיוחדת והוא בנוי על סמך הפרמטרים המבוקש על ידי המשתמש - הזמן מומר, מסונן, מנורמל נתונים (לדוגמה, מחיר המניה משתווה אם שולמו דיבידנדים) וכו'.

ארכיטקטורה אופיינית לסוג נתונים אחד:

מהירות

למרות ש-Q היא שפה מתפרשת, היא גם שפה וקטורית. המשמעות היא שהרבה פונקציות מובנות, במיוחד אריתמטיות, לובשות ארגומנטים מכל צורה שהיא - מספרים, וקטורים, מטריצות, רשימות - והמתכנת צפוי ליישם את התוכנית כפעולות מערך. בשפה כזו, אם מוסיפים שני וקטורים של מיליון אלמנטים, זה כבר לא משנה שהשפה תתפרש, התוספת תתבצע על ידי פונקציה בינארית סופר-אופטימלית. מכיוון שחלק הארי של הזמן בתוכניות Q מושקע בפעולות עם טבלאות המשתמשות בפונקציות הווקטוריות הבסיסיות הללו, הפלט הוא מהירות פעולה הגונה מאוד, המאפשרת לנו לעבד כמות עצומה של נתונים אפילו בתהליך אחד. זה דומה לספריות מתמטיות ב-Python - למרות ש-Python עצמה היא שפה מאוד איטית, יש לה הרבה ספריות מצוינות כמו numpy שמאפשרות לעבד נתונים מספריים במהירות של שפה מהודרת (אגב, numpy קרובה אידיאולוגית ל-Q ).
 
בנוסף, KX נקטה בגישה זהירה מאוד לעיצוב טבלאות וייעול העבודה איתן. ראשית, נתמכים מספר סוגים של אינדקסים, הנתמכים על ידי פונקציות מובנות וניתן להחיל אותם לא רק על עמודות טבלה, אלא גם על כל וקטור - קיבוץ, מיון, תכונת ייחודיות וקיבוץ מיוחד עבור מסדי נתונים היסטוריים. האינדקס מיושם בפשטות והוא מותאם אוטומטית בעת הוספת אלמנטים לעמודה/וקטור. ניתן להחיל את האינדקסים בהצלחה באותה מידה על עמודות טבלה הן בזיכרון והן בדיסק. בעת ביצוע שאילתת QSQL, נעשה שימוש אוטומטי באינדקסים במידת האפשר. שנית, העבודה עם נתונים היסטוריים נעשית באמצעות מנגנון הצגת קבצי מערכת ההפעלה (מפת זיכרון). טבלאות גדולות לעולם אינן נטענות לזיכרון; במקום זאת, העמודות הנחוצות ממפות ישירות לזיכרון ורק אותו חלק מהן נטען בפועל (אינדקסים עוזרים גם כאן) הדרושים. זה לא משנה למתכנת אם הנתונים נמצאים בזיכרון או לא; מנגנון העבודה עם mmap חבוי לחלוטין במעמקי ה-Q.
 
KDB+ אינו מסד נתונים יחסי; טבלאות יכולות להכיל נתונים שרירותיים, בעוד שסדר השורות בטבלה אינו משתנה כאשר אלמנטים חדשים מתווספים ואפשר וצריך להשתמש בהם בעת כתיבת שאילתות. תכונה זו נחוצה בדחיפות לעבודה עם סדרות זמן (נתונים ממרכזיות, טלמטריה, יומני אירועים), מכיוון שאם הנתונים ממוינים לפי זמן, אז המשתמש לא צריך להשתמש בשום טריקים של SQL כדי למצוא את השורה הראשונה או האחרונה או N שורות בטבלה , קבע איזו שורה אחרי הקו ה-N' וכו'. צירוף טבלאות מפושט עוד יותר, למשל, מציאת הצעת המחיר האחרונה עבור 16000 עסקאות VOD.L (Vodafone) בטבלה של 500 מיליון אלמנטים לוקחת בערך שניה בדיסק ועשרות אלפיות שניות בזיכרון.
 
דוגמה ל-time join - טבלת הציטוטים ממופה לזיכרון, כך שאין צורך לציין VOD.L היכן, נעשה שימוש מרומז באינדקס בעמודת sym ובעובדה שהנתונים ממוינים לפי זמן. כמעט כל הצירופים ב-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, החל מארתור ויטני עצמו, באמת אובססיביים ליעילות ועושים מאמצים רבים כדי להפיק את המרב מהתכונות הסטנדרטיות של ה-Q ולייעל את דפוסי השימוש הנפוצים ביותר.
 

סך הכל

KDB+ פופולרי בקרב עסקים בעיקר בזכות הרבגוניות יוצאת הדופן שלו - הוא משמש באותה מידה כמסד נתונים בזיכרון, כמסד נתונים לאחסון טרה-בייט של נתונים היסטוריים וכפלטפורמה לניתוח נתונים. בשל העובדה שעיבוד הנתונים מתרחש ישירות במסד הנתונים, מושגת מהירות גבוהה של עבודה וחיסכון במשאבים. שפת תכנות מלאה המשולבת בפונקציות מסד הנתונים מאפשרת לך ליישם את כל ערימת התהליכים הדרושים בפלטפורמה אחת - מקבלת נתונים ועד לעיבוד בקשות משתמשים.
 

לקבלת מידע נוסף,

מגבלות

חסרון משמעותי של KDB+/Q הוא סף הכניסה הגבוה. לשפה יש תחביר מוזר, חלק מהפונקציות עומסות יתר על המידה (לערך, למשל, יש בערך 11 מקרי שימוש). והכי חשוב, זה דורש גישה שונה בתכלית לכתיבת תוכניות. בשפה וקטורית, עליך תמיד לחשוב במונחים של טרנספורמציות של מערכים, ליישם את כל הלולאות דרך מספר וריאנטים של פונקציות המפה/הפחתות (הנקראות פתגמים ב-Q), ולעולם לא לנסות לחסוך כסף על ידי החלפת פעולות וקטוריות באטומיות. לדוגמה, כדי למצוא את האינדקס של המופע ה-N של אלמנט במערך, עליך לכתוב:

1. (where element=vector)[N]  

למרות שזה נראה מאוד לא יעיל לפי תקני C/Java (= יוצר וקטור בוליאני, שבו מחזיר את האינדקסים האמיתיים של האלמנטים בו). אבל הסימון הזה מבהיר את משמעות הביטוי ואתה משתמש בפעולות וקטוריות מהירות במקום באטומיות איטיות. ההבדל הרעיוני בין שפה וקטורית לאחרות דומה להבדל בין גישות ציווי ופונקציונליות לתכנות, ואתה צריך להיות מוכן לכך.
 
חלק מהמשתמשים גם לא מרוצים מ-QSQL. הנקודה היא שזה נראה רק כמו SQL אמיתי. במציאות, זהו רק מתורגמן של ביטויים דמויי SQL שאינו תומך באופטימיזציה של שאילתות. המשתמש חייב לכתוב שאילתות אופטימליות בעצמו, וב-Q, שרבים לא מוכנים להן. מצד שני, כמובן, אתה תמיד יכול לכתוב את השאילתה האופטימלית בעצמך, במקום להסתמך על מייעל קופסה שחורה.
 
בתור יתרון, ספר על Q - Q For Mortals זמין בחינם בכתובת אתר החברה, יש גם הרבה חומרים שימושיים אחרים שנאספו שם.
 
חיסרון גדול נוסף הוא עלות הרישיון. זה עשרות אלפי דולרים בשנה למעבד. רק חברות גדולות יכולות לעמוד בהוצאות כאלה. לאחרונה, KX הגמישה את מדיניות הרישוי שלה ומספקת את האפשרות לשלם רק עבור זמן השימוש או לשכור את KDB+ בעננים של גוגל ואמזון. KX מציעה גם להורדה גרסה חינמית למטרות לא מסחריות (גרסת 32 סיביות או 64 סיביות לפי בקשה).
 

המתחרה

ישנם לא מעט מסדי נתונים מיוחדים הבנויים על עקרונות דומים - עמודים, בזיכרון, ממוקדים בכמויות גדולות מאוד של נתונים. הבעיה היא שמדובר במאגרי מידע מיוחדים. דוגמה בולטת היא Clickhouse. למסד נתונים זה יש עיקרון דומה מאוד ל-KDB+ עבור אחסון נתונים בדיסק ובניית אינדקס; הוא מבצע כמה שאילתות מהר יותר מ- KDB+, אם כי לא באופן משמעותי. אבל גם בתור מסד נתונים, Clickhouse מתמחה יותר מ-KDB+ – Web Analytics לעומת סדרות זמן שרירותיות (ההבדל הזה חשוב מאוד – בגללו, למשל, ב-Clickhouse לא ניתן להשתמש בסידור הרשומות). אבל, והכי חשוב, ל- Clickhouse אין את הרבגוניות של KDB+, שפה שתאפשר עיבוד נתונים ישירות במסד הנתונים, במקום לטעון אותם תחילה לאפליקציה נפרדת, בניית ביטויי SQL שרירותיים, יישום פונקציות שרירותיות בשאילתה, יצירת תהליכים לא קשור לביצוע פונקציות של מסד נתונים היסטורי. לכן, קשה להשוות את KDB+ עם מסדי נתונים אחרים; הם עשויים להיות טובים יותר במקרים מסוימים של שימוש או פשוט טובים יותר כשמדובר במשימות מסד נתונים קלאסיות, אבל אני לא מכיר עוד כלי יעיל ורב-תכליתי לא פחות לעיבוד נתונים זמניים.
 

אינטגרציה של פייתון

כדי להקל על השימוש ב-KDB+ עבור אנשים שאינם מכירים את הטכנולוגיה, KX יצרה ספריות לשילוב הדוק עם Python בתוך תהליך אחד. אתה יכול לקרוא לכל פונקציה של Python מ-Q, או להיפך - לקרוא לכל פונקציה Q מ-Python (בפרט, ביטויי QSQL). ספריות ממירות, במידת הצורך (לא תמיד למען היעילות), נתונים מפורמט של שפה אחת לפורמט של שפה אחרת. כתוצאה מכך, Q ו-Python חיים בסימביוזה כה קרובה עד שהגבולות ביניהם מטושטשים. כתוצאה מכך, למתכנת, מצד אחד, יש גישה מלאה למספר רב של ספריות 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/
ספר Q עבור בני תמותה (באנגלית) - https://code.kx.com/q4m3/
מאמרים על יישומי KDB+/Q מעובדי kx - https://code.kx.com/v2/wp/

מקור: www.habr.com