मैं आने वाले डेटा और स्थानीय आरडीबी टेबल पर यूनियन में शामिल होने का समर्थन करने के लिए केडीबी-टिक आर्किटेक्चर को संशोधित करने की कोशिश कर रहा हूं। मैंने टिक फ़ाइल में upd फ़ंक्शन को निम्न में संशोधित किया है:

ups:{[t;x]ts"d"$a:.z.P;
    if[not -16=type first first x;a:"n"$a;x:$[0>type first x;a,x;(enlist(count first x)#a),x]];
    f:key flip value t;pub[t;$[0>type first x;enlist f!x;flip f!x]];if[l;l enlist (`ups;t;x);i+:1];};

ups:uj बाद में सब्सक्राइबर फाइलों में सेट होने के साथ। मेरा प्रश्न इस बात से संबंधित है कि कोई तालिका पंक्ति को .u.ups[] फ़ंक्शन में प्रकाशित करने से पहले उसे क्रमबद्ध कैसे कर सकता है। अर्थात। एक टेबल दिया:

second     |  amount price 
-----------|----------------
02:46:01   |  54     9953.5
02:46:02   |  54     9953.5
02:46:03   |  54     9953.5
02:46:04   |  150    9953.5    
02:46:05   |  150    9954.5

किसी को पहली पंक्ति 02:46:01 | 54 9953.5 को कैसे क्रमबद्ध करना चाहिए ताकि इसे .u.ups फ़ंक्शन के माध्यम से ग्राहकों को भेजा जा सके जिससे ग्राहकों पर पंक्ति और स्थानीय तालिका के बीच uj चलाया जा सके। सलाह के लिए आपको अग्रिम शुक्रिया।

kdb
0
James 5 सितंबर 2019, 04:56

2 जवाब

इसमें से कुछ मदद कर सकते हैं:

  1. आप ग्राहकों में ups:uj सेट नहीं कर सकते क्योंकि तालिका का नाम एक प्रतीक के रूप में पारित किया जा रहा है, इसलिए ग्राहक प्रभावी ढंग से ऐसा करने का प्रयास करेगा

uj[`tab1;tab2]

जो काम नहीं करेगा क्योंकि uj इनपुट के रूप में टेबल नामों (प्रतीकों) को स्वीकार नहीं करता है। इसके बजाय आपको ups को . पर सेट करना होगा

ups:{x set value[x] uj y}

  1. एक मानक टिकरप्लांट को परिवर्तनीय/बदलती स्कीमा को संभालने के लिए डिज़ाइन नहीं किया गया है - अच्छे कारण के लिए, आमतौर पर एक स्कीमा होना अच्छा नहीं है जो इंट्राडे बदलता है। हालाँकि, आपकी स्थिति इसकी गारंटी दे सकती है, इसलिए उस स्थिति में आपको अपने .u.ups फ़ंक्शन को कुछ इस तरह संशोधित करने की आवश्यकता होगी
\d .u
ups:{[t;x]ts"d"$a:.z.P;
    x:`time xcols update time:"n"$a from x;
    pub[t;$[98h=type x;x;1=count last x;enlist x;flip x]];if[l;l enlist (`ups;t;x);i+:1];};
\d .

और आपकी फीडर प्रक्रिया को केडीबी टेबल या केडीबी डिक्शनरी को .u.ups फंक्शन में भेजना होगा। चूंकि फीडहैंडलर प्रक्रिया आमतौर पर केडीबी प्रक्रिया नहीं होती है, टिकरप्लांट को टेबल/डिक्शनरी भेजना संभव हो भी सकता है और नहीं भी, क्योंकि आमतौर पर फीडहैंडलर सूचियां भेजता है (स्तंभ मेटाडेटा के बिना)। आपके मामले में आपको प्रत्येक अपडेट पर टिकरप्लांट को कॉलम मेटाडेटा की आपूर्ति करने की ज़रूरत है (या शायद आप इसे पहले से ही कर रहे हैं?), अन्यथा यह नहीं पता होगा कि कौन से कॉलम हैं।

दूसरे शब्दों में आपकी फीडर प्रक्रिया निम्नलिखित में से कोई एक भेज सकती है:

(`.u.upd;`tab;([]col1:`a`b`c;col2:1 2 3))
(`.u.upd;`tab;`col1`col2!(`a;1))
(`.u.upd;`tab;`col1`col2!(`a`b;1 2))
1
terrylynch 5 सितंबर 2019, 10:59
धन्यवाद फिर से टेरी, उपरोक्त के विश्लेषण में मूल रूप से मैं जो करने की कोशिश कर रहा हूं वह एक फीचर टेबल बनाना है जो कई स्रोतों का प्रतिनिधि है, यानी भावना, बाजार डेटा इत्यादि। यह वह जगह है जहां कई तालिकाओं में एकत्रीकरण किया जाएगा, और इसके लिए हद तक उच्च I/O (1/सेकंड) की आवश्यकता नहीं है, हालांकि मेरे विश्लेषण से इसे एक गतिशील स्कीमा की आवश्यकता होगी, आपकी राय में इसे पूरा करने का एक प्रभावी तरीका क्या होगा?
 – 
Brad
6 सितंबर 2019, 01:25
स्कीमा अनिवार्य रूप से इंट्राडे नहीं बदलती है, लेकिन स्वाभाविक रूप से इनपुट फ़ीड के कॉन्फ़िगरेशन से जुड़ी होती है
 – 
Brad
6 सितंबर 2019, 01:27
मैंने एक स्कीमा जांच को लागू करने के बारे में सोचा है जो यह जांच करेगा कि क्या .u.upd से प्राप्त सूची का स्कीमा एकत्रीकरण तालिका से अलग है और फिर उस मामले में स्कीमा को अपडेट कर रहा है, हालांकि मैं कार्यान्वयन विवरण के बारे में अनिश्चित हूं। . क्या मुझे प्रश्न को इस प्रकार खोलना/संपादित करना चाहिए जिससे मेरी समस्या का और विवरण दिया जा सके?
 – 
Brad
6 सितंबर 2019, 01:30

मुझे लगता है कि यह असमान स्कीमा के बारे में आपके पिछले कुछ प्रश्नों से संबंधित है। मैं एक वैकल्पिक समाधान सुझाना चाहता हूं, जो केवल तभी व्यवहार्य है जब आप केडीबी संस्करण 3.6 का उपयोग कर रहे हैं, जो किसी भी मैप का उपयोग करता है। यदि आप अपने स्कीमा को सामान्य स्तंभों की न्यूनतम सूची तक सीमित कर सकते हैं, तो अन्य सभी स्तंभों को एक सामान्य स्तंभ में शब्दकोशों के रूप में रखा जा सकता है।

q)tab:([]sym:`$();col1:`float$();colGeneral:(::))
q)`tab upsert (`AAPL;3.454;(`colX`colY`colZ!(1;2.3;"abc")))
`tab
q)`tab upsert (`MSFT;3.0;(`colX`colY!(2;100.0)))
`tab
q)`tab upsert (`AMZN;100.0;((enlist `colX)!(enlist 10)))
`tab
q)tab
sym  col1  colGeneral
----------------------------------------
AAPL 3.454 `colX`colY`colZ!(1;2.3;"abc")
MSFT 3     `colX`colY!(2;100f)
AMZN 100   (,`colX)!,10
q)select colGeneral from tab
colGeneral
-----------------------------
`colX`colY`colZ!(1;2.3;"abc")
`colX`colY!(2;100f)
(,`colX)!,10
q)select sym, colGeneral @\: `colX from tab
sym  x
-------
AAPL 1
MSFT 2
AMZN 10
q)select sym, colGeneral @\: `colY from tab
sym  x
---------
AAPL 2.3
MSFT 100f
AMZN 0N

3.6 के साथ आप इसे किसी भी स्प्लेड प्रारूप (स्प्लेड, विभाजित, खंडित) में डिस्क पर सहेज सकते हैं और फिर भी आसानी से डेटा को क्वेरी कर सकते हैं। सामान्य कॉलम की खराब संपीड़न विशेषताओं (मान लीजिए कि आप डेटा को संपीड़ित करना चाहते हैं) के कारण ऐसी तालिका का भंडारण उप-इष्टतम होगा, लेकिन यह पूरी तरह कार्यात्मक होगा।

प्रत्येक अद्यतन के साथ uj को मानक अंतर्ग्रहण प्रक्रिया में एकीकृत करना कम्प्यूटेशनल रूप से महंगा होगा। एक सामान्य कॉलम और डिक्शनरी पद्धति का उपयोग करने से आपकी अंतर्ग्रहण गति में व्यापक रूप से सुधार होगा। नीचे मैंने आपके संबंधित प्रश्न का पिछला उत्तर दिए गए उदाहरण का उपयोग करके एक प्रदर्शन दिया है

q)table:()
q)row1:enlist `x`y`colX!(`AMZN;100.0;10)
q)table:table uj row
q)\ts:100000 table:table uj row1
13828 6292352
q)\ts:100000 `tab upsert (`AMZN;100.0;((enlist `colX)!(enlist 10)))
117   12746880
1
Callum Biggs 5 सितंबर 2019, 12:56
फिर से धन्यवाद कैलम, उपरोक्त के विश्लेषण में मूल रूप से मैं जो करने की कोशिश कर रहा हूं वह एक फीचर टेबल बनाना है जो कई स्रोतों का प्रतिनिधि है, यानी भावना, बाजार डेटा इत्यादि। यह वह जगह है जहां कई तालिकाओं में एकत्रीकरण किया जाएगा, और इसके लिए हद तक उच्च I/O (1/सेकंड) की आवश्यकता नहीं है, हालांकि मेरे विश्लेषण से इसे एक गतिशील स्कीमा की आवश्यकता होगी, आपकी राय में इसे पूरा करने का एक प्रभावी तरीका क्या होगा?
 – 
Brad
6 सितंबर 2019, 01:25
स्कीमा अनिवार्य रूप से इंट्राडे नहीं बदलती है, लेकिन स्वाभाविक रूप से इनपुट फ़ीड के कॉन्फ़िगरेशन से जुड़ी होती है
 – 
Brad
6 सितंबर 2019, 01:27
मैंने एक स्कीमा जांच को लागू करने के बारे में सोचा है जो यह जांच करेगा कि क्या .u.upd से प्राप्त सूची का स्कीमा एकत्रीकरण तालिका से अलग है और फिर उस मामले में स्कीमा को अपडेट कर रहा है, हालांकि मैं कार्यान्वयन विवरण के बारे में अनिश्चित हूं। . क्या मुझे प्रश्न को इस प्रकार खोलना/संपादित करना चाहिए जिससे मेरी समस्या का और विवरण दिया जा सके?
 – 
Brad
6 सितंबर 2019, 01:29