KDB+, yrityksen tuote on ahtaissa piireissä laajalti tunnettu, erittäin nopea sarakepohjainen tietokanta, joka on suunniteltu aikasarjojen ja niihin perustuvien analyyttisten laskelmien tallentamiseen. Alun perin se oli (ja on) erittäin suosittu rahoitusalalla - sitä käyttävät kaikki kymmenen parasta investointipankkia ja monet tunnetut hedge-rahastot, pörssit ja muut organisaatiot. Äskettäin KX päätti laajentaa asiakaskuntaansa ja tarjota nyt ratkaisuja muilla aloilla, joilla on paljon dataa, ajan tai muuten järjestyneenä - tietoliikenne, bioinformatiikka, valmistus jne. Heistä tuli myös Aston Martin Red Bull Racing -tiimin kumppani Formula 10:ssä, jossa he auttavat keräämään ja käsittelemään tietoja auton antureista ja analysoimaan tuulitunnelien testejä. Tässä artikkelissa haluan kertoa sinulle, mitkä KDB+:n ominaisuudet tekevät siitä erittäin suorituskykyisen, miksi yritykset ovat valmiita käyttämään siihen paljon rahaa, ja lopuksi, miksi se ei todellakaan ole tietokanta.
Tässä artikkelissa yritän kertoa sinulle yleisesti, mitä KDB+ on, mitä ominaisuuksia ja rajoituksia sillä on ja mitä hyötyä siitä on yrityksille, jotka haluavat käsitellä suuria tietomääriä. En mene KDB+:n toteutuksen yksityiskohtiin tai sen Q-ohjelmointikielen yksityiskohtiin. Molemmat aiheet ovat hyvin laajoja ja ansaitsevat erilliset artikkelit. Paljon tietoa näistä aiheista löytyy osoitteesta code.kx.com, mukaan lukien kirja Q - Q Fortalsista (katso linkki alla).
Jotkut termit
- Muistissa oleva tietokanta. Tietokanta, joka tallentaa tiedot RAM-muistiin nopeampaa pääsyä varten. Tällaisen tietokannan edut ovat selvät, mutta haittoja ovat tietojen katoamisen mahdollisuus ja tarve olla paljon muistia palvelimella.
- Saraketietokanta. Tietokanta, jossa tiedot tallennetaan sarake sarakkeelta tietueen sijaan. Tällaisen tietokannan tärkein etu on, että yhden sarakkeen tiedot tallennetaan yhdessä levylle ja muistiin, mikä nopeuttaa merkittävästi pääsyä siihen. Ei tarvitse ladata sarakkeita, joita ei käytetä kyselyssä. Suurin haittapuoli on, että tietueita on vaikea muokata ja poistaa.
- Aikasarja. Tiedot päivämäärä- tai aikasarakkeella. Tyypillisesti aikajärjestys on tärkeä tällaisille tiedoille, jotta voit helposti määrittää, mikä tietue edeltää tai seuraa nykyistä, tai käyttää toimintoja, joiden tulokset riippuvat tietueiden järjestyksestä. Klassiset tietokannat on rakennettu täysin erilaiselle periaatteelle - edustavat tietueiden kokoelmaa joukkona, jossa tietueiden järjestystä ei periaatteessa ole määritelty.
- Vektori. KDB+:n yhteydessä tämä on luettelo saman atomityypin elementeistä, esimerkiksi numeroista. Toisin sanoen joukko elementtejä. Matriisit, toisin kuin listat, voidaan tallentaa tiiviisti ja käsitellä vektoriprosessorin ohjeiden avulla.
Historialliset tiedot
KX:n perusti vuonna 1993 Arthur Whitney, joka työskenteli aiemmin Morgan Stanley Bankissa A+-kielellä, joka on APL:n seuraaja - erittäin omaperäinen ja aikoinaan suosittu kieli finanssimaailmassa. Tietysti KX:ssä Arthur jatkoi samassa hengessä ja loi vektorifunktionaalisen kielen K radikaalin minimalismin ajatusten ohjaamana. K-ohjelmat näyttävät välimerkkien ja erikoismerkkien sekamelskaalta, merkkien ja funktioiden merkitys riippuu kontekstista, ja jokaisella toiminnolla on paljon enemmän merkitystä kuin perinteisissä ohjelmointikielissä. Tästä johtuen K-ohjelma vie vähän tilaa – muutamalla rivillä voi korvata tekstisivuja monisanaisella kielellä, kuten Java – ja on algoritmin supertiivistetty toteutus.
K:n funktio, joka toteuttaa suurimman osan LL1-jäsenningeneraattorista tietyn kieliopin mukaisesti:
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 ilmensi tätä filosofiaa äärimmäisestä tehokkuudesta ja kehon liikkeistä mahdollisimman vähän KDB+:ssa, joka ilmestyi vuonna 2003 (luulen, että nyt on selvää, mistä nimessä oleva K-kirjain tulee) ja on vain K:n neljännen version tulkki. K K:n päälle on lisätty käyttäjäystävällisempi versio nimeltä Q. Q lisäsi myös tuen tietylle SQL:n murteelle - QSQL ja tulkki - tuki taulukoille järjestelmätietotyyppinä, työkalut taulukoiden kanssa työskentelyyn muistissa ja levyllä jne.
Joten käyttäjän näkökulmasta KDB+ on yksinkertaisesti Q-kielen tulkki, joka tukee taulukoita ja SQL:n kaltaisia LINQ-tyylisiä lausekkeita C#:sta. Tämä on tärkein ero KDB+:n ja muiden tietokantojen välillä ja sen tärkein kilpailuetu, joka usein unohdetaan. Tämä ei ole tietokanta + käytöstä poistettu apukieli, vaan täysimittainen tehokas ohjelmointikieli + sisäänrakennettu tuki tietokantatoiminnoille. Tällä erottelulla on ratkaiseva rooli KDB+:n kaikkien etujen luettelemisessa. Esimerkiksi…
koko
Nykyaikaisten standardien mukaan KDB+ on kooltaan yksinkertaisesti mikroskooppinen. Se on kirjaimellisesti yksi megatavua pienempi suoritettava tiedosto ja yksi pieni tekstitiedosto, jossa on joitain järjestelmätoimintoja. Todellisuudessa - alle yksi megatavu, ja tästä ohjelmasta yritykset maksavat kymmeniä tuhansia dollareita vuodessa yhdestä palvelimen prosessorista.
- Tämän koon ansiosta KDB+ tuntuu hyvältä millä tahansa laitteistolla – Pi-mikrotietokoneesta teratavuja muistia sisältäviin palvelimiin. Tämä ei vaikuta toimivuuteen millään tavalla, lisäksi Q käynnistyy välittömästi, jolloin sitä voidaan käyttää muun muassa komentosarjakielenä.
- Tässä koossa Q-tulkki mahtuu kokonaan prosessorin välimuistiin, mikä nopeuttaa ohjelman suorittamista.
- Tällä suoritettavan tiedoston koolla Q-prosessi vie mitättömän vähän tilaa muistista; voit suorittaa niitä satoja. Lisäksi Q voi tarvittaessa toimia kymmenien tai satojen gigatavujen muistilla yhdessä prosessissa.
monipuolisuus
Q sopii erinomaisesti monenlaisiin sovelluksiin. Prosessi Q voi toimia historiallisena tietokantana ja tarjota nopean pääsyn teratavuihin tietoa. Meillä on esimerkiksi kymmeniä historiallisia tietokantoja, joista joissakin yksi pakkaamaton päivä vie yli 100 gigatavua. Kuitenkin kohtuullisin rajoituksin tietokantaan tehtävä kysely suoritetaan kymmenissä tai sadoissa millisekunneissa. Yleensä meillä on yleinen aikakatkaisu käyttäjien pyyntöille - 30 sekuntia - ja se toimii hyvin harvoin.
Q voisi yhtä helposti olla muistissa oleva tietokanta. Uutta dataa lisätään muistitaulukoihin niin nopeasti, että käyttäjien pyynnöt ovat rajoittava tekijä. Taulukoiden tiedot tallennetaan sarakkeisiin, mikä tarkoittaa, että kaikki sarakkeen toiminnot käyttävät suorittimen välimuistia täydellä kapasiteetilla. Tämän lisäksi KX yritti toteuttaa kaikki perustoiminnot, kuten aritmetiikka, prosessorin vektorikäskyjen avulla maksimoimalla niiden nopeuden. Q voi myös suorittaa tehtäviä, jotka eivät ole tyypillisiä tietokannoille - esimerkiksi käsitellä suoratoistodataa ja laskea "reaaliajassa" (viiveellä kymmenistä millisekunneista useisiin sekunteihin tehtävästä riippuen) erilaisia aggregointitoimintoja rahoitusinstrumenteille eri ajalle aikavälein tai rakentaa malli täydellisten transaktioiden vaikutuksesta markkinoille ja suorittaa sen profilointi lähes välittömästi sen valmistumisen jälkeen. Tällaisissa tehtävissä pääasiallinen aikaviive ei ole useimmiten Q, vaan tarve synkronoida tietoja eri lähteistä. Suuri nopeus saavutetaan sillä, että data ja niitä käsittelevät toiminnot ovat yhdessä prosessissa ja käsittely rajoittuu useiden QSQL-lausekkeiden ja liitosten suorittamiseen, joita ei tulkita, vaan jotka suoritetaan binäärikoodilla.
Lopuksi voit kirjoittaa mitä tahansa palveluprosessia Q:ssa. Esimerkiksi Gateway-prosessit jakavat käyttäjien pyynnöt automaattisesti tarvittaviin tietokantoihin ja palvelimiin. Ohjelmoijalla on täysi vapaus toteuttaa mikä tahansa algoritmi tasapainottamiseen, priorisointiin, vikasietoisuuteen, käyttöoikeuksiin, kiintiöihin ja periaatteessa kaikkeen muuhun, mitä hänen sydämensä haluaa. Suurin ongelma tässä on, että sinun on toteutettava kaikki tämä itse.
Esimerkkinä luettelen, minkä tyyppisiä prosesseja meillä on. Niitä kaikkia käytetään aktiivisesti ja ne toimivat yhdessä yhdistäen kymmeniä erilaisia tietokantoja yhdeksi, käsittelemällä tietoja useista lähteistä ja palvelemalla satoja käyttäjiä ja sovelluksia.
- Liittimet (syöttökäsittelijä) tietolähteisiin. Nämä prosessit käyttävät yleensä ulkoisia kirjastoja, jotka ladataan Q:iin. Q:n C-liitäntä on erittäin yksinkertainen ja sen avulla voit helposti luoda välityspalvelintoimintoja mille tahansa C/C++-kirjastolle. Q on riittävän nopea käsittelemään esimerkiksi FIX-viestien tulvan kaikilta Euroopan pörsseiltä samanaikaisesti.
- Tiedonjakelijat (tickerplant), jotka toimivat välilinkkinä liittimien ja kuluttajien välillä. Samalla ne kirjoittavat saapuvat tiedot erityiseen binaarilokiin, mikä tarjoaa kuluttajille kestävyyttä yhteyden katkeamista tai uudelleenkäynnistystä vastaan.
- Muistissa oleva tietokanta (rdb). Nämä tietokannat tarjoavat nopeimman mahdollisen pääsyn tuoreisiin raakatietoihin tallentamalla ne muistiin. Tyypillisesti ne keräävät tietoja taulukoihin päivän aikana ja nollaavat ne yöllä.
- Pysy tietokanta (pdb). Nämä tietokannat varmistavat, että tämän päivän tiedot tallennetaan historialliseen tietokantaan. Pääsääntöisesti, toisin kuin rdb, ne eivät tallenna tietoja muistiin, vaan käyttävät erityistä välimuistia levyllä päivällä ja kopioivat tiedot keskiyöllä historialliseen tietokantaan.
- Historialliset tietokannat (hdb). Nämä tietokannat tarjoavat pääsyn aikaisempien päivien, kuukausien ja vuosien tietoihin. Niiden kokoa (päivissä) rajoittaa vain kiintolevyjen koko. Tiedot voidaan sijoittaa mihin tahansa, erityisesti eri levyille pääsyn nopeuttamiseksi. On mahdollista pakata tietoja käyttämällä useita valittavissa olevia algoritmeja. Tietokannan rakenne on hyvin dokumentoitu ja yksinkertainen, tiedot tallennetaan sarake sarakkeelta tavallisiin tiedostoihin, joten niitä voidaan käsitellä myös käyttöjärjestelmän avulla.
- Tietokannat koostetuilla tiedoilla. Ne tallentavat erilaisia aggregaatioita, yleensä ryhmiteltyinä instrumentin nimen ja aikavälin mukaan. Muistissa olevat tietokannat päivittävät tilansa jokaisen saapuvan viestin yhteydessä, ja historialliset tietokannat tallentavat esilaskettuja tietoja nopeuttaakseen pääsyä historiallisiin tietoihin.
- Lopuksi yhdyskäytäväprosessitpalvelevat sovelluksia ja käyttäjiä. Q:n avulla voit toteuttaa saapuvien viestien täysin asynkronisen käsittelyn, niiden jakamisen tietokantoihin, käyttöoikeuksien tarkistamisen jne. Huomaa, että viestit eivät ole rajoitettuja eivätkä useimmiten ole SQL-lausekkeita, kuten muissa tietokannoissa. Useimmiten SQL-lauseke on piilotettu erikoistoimintoon ja se muodostetaan käyttäjän pyytämien parametrien perusteella - aika muunnetaan, suodatetaan, tiedot normalisoidaan (esimerkiksi osakekurssi tasoitetaan, jos osinkoja maksetaan) jne.
Tyypillinen arkkitehtuuri yhdelle tietotyypille:
Nopeus
Vaikka Q on tulkittu kieli, se on myös vektorikieli. Tämä tarkoittaa, että monet sisäänrakennetut funktiot, erityisesti aritmeettiset, ottavat minkä tahansa muotoisia argumentteja - lukuja, vektoreita, matriiseja, listoja - ja ohjelmoijan odotetaan toteuttavan ohjelman taulukkooperaatioina. Jos tällaisessa kielessä lisäät kaksi miljoonan elementin vektoria, kielen tulkinnalla ei ole enää väliä, vaan lisäyksen suorittaa superoptimoitu binäärifunktio. Koska leijonanosa Q-ohjelmien ajasta kuluu operaatioihin taulukoilla, jotka käyttävät näitä perusvektorisoituja funktioita, tulos on erittäin kohtuullinen toimintanopeus, jonka avulla voimme käsitellä valtavan määrän dataa jopa yhdessä prosessissa. Tämä on samanlainen kuin Pythonin matemaattiset kirjastot - vaikka Python itsessään on erittäin hidas kieli, siinä on monia erinomaisia kirjastoja, kuten numpy, joiden avulla voit käsitellä numeerista dataa käännetyn kielen nopeudella (muuten, numpy on ideologisesti lähellä Q:ta ).
Lisäksi KX otti erittäin huolellisen lähestymistavan taulukoiden suunnitteluun ja niiden kanssa työskentelyn optimointiin. Ensinnäkin tuetaan usean tyyppisiä indeksejä, joita tukevat sisäänrakennetut toiminnot ja joita voidaan soveltaa paitsi taulukon sarakkeisiin, myös kaikkiin vektoreihin - ryhmittelyyn, lajitteluun, ainutlaatuisuusattribuutteihin ja historiallisten tietokantojen erikoisryhmittelyyn. Indeksiä käytetään yksinkertaisesti ja sitä säädetään automaattisesti lisättäessä elementtejä sarakkeeseen/vektoriin. Indeksejä voidaan yhtä hyvin soveltaa taulukon sarakkeisiin sekä muistissa että levyllä. QSQL-kyselyä suoritettaessa indeksejä käytetään automaattisesti, jos mahdollista. Toiseksi, työ historiallisten tietojen kanssa tapahtuu käyttöjärjestelmätiedostojen näyttömekanismin (muistikartan) kautta. Suuria taulukoita ei koskaan ladata muistiin, vaan tarvittavat sarakkeet kartoitetaan suoraan muistiin ja niistä ladataan vain se osa (tässä auttaa myös hakemistoja), joita tarvitaan. Ohjelmoijalle ei ole väliä, onko data muistissa vai ei; mmap-työskentelymekanismi on täysin piilossa Q:n syvyyksissä.
KDB+ ei ole relaatiotietokanta; taulukot voivat sisältää mielivaltaisia tietoja, kun taas taulukon rivien järjestys ei muutu, kun uusia elementtejä lisätään, ja sitä voidaan ja pitäisi käyttää kyselyitä kirjoitettaessa. Tätä ominaisuutta tarvitaan kiireellisesti aikasarjojen kanssa työskentelyyn (tiedot vaihdoista, telemetriasta, tapahtumalokit), koska jos tiedot lajitellaan ajan mukaan, käyttäjän ei tarvitse käyttää SQL-temppuja ensimmäisen tai viimeisen rivin tai N:n löytämiseen. taulukon rivejä, määritä mikä rivi seuraa N:nnettä riviä jne. Taulukkoliitokset yksinkertaistuvat entisestään, esimerkiksi viimeisimmän tarjouksen löytäminen 16000 500 VOD.L (Vodafone) -tapahtumasta XNUMX miljoonan elementin taulukosta vie noin sekunnin levyllä ja kymmeniä millisekunteja muistista.
Esimerkki aikaliitosta - lainaustaulukko on kartoitettu muistiin, joten VOD.L:tä ei tarvitse määrittää missä, sym-sarakkeen indeksi ja se tosiasia, että tiedot on lajiteltu ajan mukaan, käytetään implisiittisesti. Melkein kaikki liitokset Q:ssa ovat säännöllisiä funktioita, eivät osa valittua lauseketta:
1. aj[`sym`time;select from trade where date=2019.03.26, sym=`VOD.L;select from quote where date=2019.03.26]
Lopuksi on syytä huomata, että KX:n insinöörit, alkaen Arthur Whitneystä itsestään, ovat todella pakkomielle tehokkuudesta ja tekevät paljon vaivaa saadakseen kaiken irti Q:n vakioominaisuuksista ja optimoidakseen yleisimmät käyttötavat.
Koko
KDB+ on suosittu yritysten keskuudessa ensisijaisesti poikkeuksellisen monipuolisuutensa vuoksi - se toimii yhtä hyvin muistitietokantana, tietokantana teratavujen historiatietojen tallentamiseen sekä alustana tietojen analysointiin. Koska tietojen käsittely tapahtuu suoraan tietokannassa, saavutetaan suuri työn nopeus ja resurssien säästö. Tietokantatoimintoihin integroitu täysimittainen ohjelmointikieli mahdollistaa koko pinon tarvittavat prosessit yhdellä alustalla - tietojen vastaanottamisesta käyttäjien pyyntöjen käsittelyyn.
Lisätietoja
Rajoitukset
KDB+/Q:n merkittävä haittapuoli on korkea pääsykynnys. Kielellä on outo syntaksi, jotkut toiminnot ovat voimakkaasti ylikuormitettuja (arvolla on esimerkiksi noin 11 käyttötapausta). Mikä tärkeintä, se vaatii radikaalisti erilaista lähestymistapaa ohjelmien kirjoittamiseen. Vektorikielessä sinun tulee aina ajatella taulukkomuunnoksia, toteuttaa kaikki silmukat useiden kartoitus-/vähennys-funktioiden muunnelmien kautta (jota kutsutaan Q:ssa adverbeiksi) eikä koskaan yritä säästää rahaa korvaamalla vektorioperaatioita atomeilla. Jos haluat esimerkiksi löytää taulukon elementin N:nnen esiintymisen indeksin, sinun tulee kirjoittaa:
1. (where element=vector)[N]
vaikka tämä vaikuttaa hirveän tehottomalta C/Java-standardien mukaan (= luo boolen vektorin, jossa palauttaa siinä olevien elementtien todelliset indeksit). Mutta tämä merkintä tekee lausekkeen merkityksestä selvemmän ja käytät nopeita vektorioperaatioita hitaiden atomien sijasta. Käsitteellinen ero vektorikielen ja muiden välillä on verrattavissa ohjelmoinnin pakollisten ja toiminnallisten lähestymistapojen eroon, ja sinun on oltava valmis tähän.
Jotkut käyttäjät ovat myös tyytymättömiä QSQL:ään. Pointti on, että se näyttää vain oikealta SQL:ltä. Todellisuudessa se on vain SQL:n kaltaisten lausekkeiden tulkki, joka ei tue kyselyn optimointia. Käyttäjän on itse kirjoitettava optimaaliset kyselyt ja Q:ssa, joihin monet eivät ole valmiita. Toisaalta voit tietysti aina kirjoittaa optimaalisen kyselyn itse sen sijaan, että luottaisit mustan laatikon optimoijaan.
Lisäksi Q - Q For Mortals -kirja on saatavilla ilmaiseksi osoitteessa , sinne on kerätty myös paljon muuta hyödyllistä materiaalia.
Toinen suuri haittapuoli on lisenssin hinta. Se on kymmeniä tuhansia dollareita vuodessa prosessoria kohden. Vain suurilla yrityksillä on varaa tällaisiin kuluihin. Viime aikoina KX on tehnyt lisenssipolitiikkaansa joustavammaksi ja tarjoaa mahdollisuuden maksaa vain käyttöajasta tai vuokrata KDB+:n Googlen ja Amazonin pilvissä. KX tarjoaa myös latauksen (32-bittinen versio tai 64-bittinen pyynnöstä).
kilpailijat
On olemassa useita erikoistuneita tietokantoja, jotka on rakennettu samanlaisille periaatteille - sarakepohjaisia, muistissa olevia, erittäin suuriin tietomääriin keskittyviä. Ongelmana on, että nämä ovat erikoistuneita tietokantoja. Silmiinpistävä esimerkki on Clickhouse. Tällä tietokannalla on hyvin samanlainen periaate kuin KDB+ tietojen tallentamiseksi levylle ja indeksin muodostamiseksi; se suorittaa jotkin kyselyt nopeammin kuin KDB+, vaikkakaan ei merkittävästi. Mutta jopa tietokantana Clickhouse on erikoistuneempi kuin KDB+ - verkkoanalytiikka vs mielivaltaiset aikasarjat (tämä ero on erittäin tärkeä - sen takia esim. Clickhousessa ei voi käyttää tietueiden järjestystä). Mutta mikä tärkeintä, Clickhousessa ei ole KDB+:n monipuolisuutta, kielen, joka mahdollistaisi tietojen käsittelyn suoraan tietokannassa sen sijaan, että ne ladattaisiin ensin erilliseen sovellukseen, koottaisiin mielivaltaisia SQL-lausekkeita, käytetän mielivaltaisia funktioita kyselyssä, luodaan prosesseja. ei liity historiallisten tietokantatoimintojen suorittamiseen. Siksi KDB+:aa on vaikea verrata muihin tietokantoihin, ne voivat olla parempia tietyissä käyttötapauksissa tai yksinkertaisesti parempia klassisissa tietokantatehtävissä, mutta en tiedä toista yhtä tehokasta ja monipuolista työkalua tilapäisten tietojen käsittelyyn.
Python integraatio
Tehdäkseen KDB+:n käytön helpommaksi ihmisille, jotka eivät tunne tekniikkaa, KX loi kirjastoja integroitumaan tiiviisti Pythonin kanssa yhdessä prosessissa. Voit joko kutsua mitä tahansa Python-funktiota Q:sta tai päinvastoin - kutsua mitä tahansa Q-funktiota Pythonista (erityisesti QSQL-lausekkeita). Kirjastot muuntavat tarvittaessa (ei aina tehokkuuden vuoksi) tiedot yhden kielen formaatista toisen muotoon. Tämän seurauksena Q ja Python elävät niin läheisessä symbioosissa, että niiden väliset rajat hämärtyvät. Tämän seurauksena ohjelmoijalla on toisaalta täysi pääsy lukuisiin hyödyllisiin Python-kirjastoihin, toisaalta hän saa nopean pohjan Pythoniin integroidun big datan työskentelyyn, mikä on erityisen hyödyllistä koneoppimiseen osallistuville. tai mallinnus.
Työskentely Q:n kanssa Pythonissa:
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')
viittaukset
Yrityksen kotisivu -
Verkkosivusto kehittäjille -
Kirja Q kuolevaisille (englanniksi) -
Artikkelit KDB+/Q-sovelluksista kx:n työntekijöiltä -
Lähde: will.com