Hvad er forskellen mellem Hadoop og KDB?


Svar 1:

UPDATE (Q4 2017): Dette svar blev skrevet for mere end et år siden. Det har for det meste forblevet korrekt, men jeg vil tilføje eventuelle relevante tilføjelser med en opdateringskommentar.

Det afhænger virkelig, hvad du mener med Hadoop. Det er nu slutningen af ​​3. kvartal 2016, og Hadoop betyder ikke længere, hvad det betød, da det kom ud i 2005.

Hadoop plejede at betyde en computermotor baseret på kort / reducere job på masser af hardware og et distribueret filsystem HDFS til brug som en butik til mellemliggende og endelige resultater af beregninger. Oven på denne M / R-motor var der en SQL-motor kaldet Hive. Fra 2012 (måske tidligere) var dette forældet, fordi det simpelthen ikke drage fordel af meget større hukommelsesbanker, som computere havde.

Der er en masse gode foredrag om udviklingen. Mit forslag er dette af Stonebreaker, eller du kan læse hans kommentarer i Læsninger i databasesystemer, 5. udgave, kapitel 5.

Resultatet er, at Hadoop nu betyder et anstændigt pålideligt distribueret filsystem og mange open source-projekter på toppen, hvor den mest fremtrædende er Spark. Spark har gjort noget rigtig godt arbejde. Det er dog ikke en fuldgyldig database, selvom den understøtter SQL. Fra dette skrives grunden til, at det ikke understøtter indekser. Hvilket betyder, at du har brug for et andet værktøj, hvis du vil have hurtige tilfældige læsninger.

Der er flere funktioner, der leveres som standard med en DB som (Mysql, postgresql, Oracle ...)

PermissionsMulti-tenancyTransactions

Der er muligvis flere, men disse var nok til at få mit team til at revurdere Spark, da vores all-end alle skalabaserede db-løsning.

Opdatering (4. kvartal 2017): Der er nu endnu flere Apache-projekter, der hjælper dig med at styre al kompleksiteten. Dette skaber i sig selv mere kompleksitet. Imidlertid synes Druid at være de mest lovende teknologier i flokken. En anden interessant udvikling er, at Kafka nu understøtter materialiserede visninger (i det væsentlige tabeller) og ksql (en version af sql om Kafka-emner). Der er nu også masser af leverandører, der vil håndtere al denne kompleksitet for dig. Selv med en sælger begynder du at opgive nogle af de fordele, som Hadoop tilbyder som open source og hurtige funktionsforbedringer.

I modsætning hertil er KDB en meget stabil og hensigtsmæssig database. Som andre påpegede, bruger den også kort / reducer lignende konstruktioner til at styre meget store datasæt (historisk database).

KDB er slags unik, idet den lover en alt i én løsning. Det har streaming, ipc, websockets, db og et sprog indbygget. Målet med dette er at give et team hurtigt mulighed for at oprette en fuldgyldig løsning. Det er også temmelig udvideligt og giver mulighed for hurtig prototype.

UPDATE (4. kvartal 2017): KX, virksomheden bag KDB, bliver nu meget mere fleksibel i sin interoperabilitet med andre teknologier, herunder et initiativ kaldet fusion, der lover betydelig integration med eksisterende tech og bedre support til Machine Learning.

Den største ulempe er, at den er proprietær og derfor dyr af flere grunde. Produktet er dyrt. Derfor er det ikke bredt vedtaget, og der er få ingeniører, der kender sproget, så de er også sjældne og dyre. Eftersom det er meget magtfuldt, er det nemt at skrive en ikke-vedligeholdelig kode. For mange kan selv idiome i Q (sproget i KDB) se ud som støj fra støj, og mange af dets fans kan lide at spille kodegolf.

Når det er sagt, synes jeg den nylige erhvervelse af KDB fra First Derivatives (FD) har vist en vending i holdning (jeg tør sige elitisme mod popularisme), og det ser ud til, at de prøver at popularisere sproget (ja, det nyligt opdaterede websted og dokumentation har gjort sproget meget mere tilgængeligt). De er endda begyndt at køre konkurrencer for universitetsstuderende og dukke op på konferencer. De har en enorm op ad bakke foran os. Endelig blev KDB designet til økonomiske applikationer. Det betyder ikke, at det ikke kan bruges i andre felter, men at du vil have mindre ressourcer til at håndtere dit rum. En af de bedste grunde til at bruge KDB i finansiering er, at næsten alle dine problemer allerede er løst af en anden, og du skal bare finde løsningen. Hvis du bruger det til gensekventering er der bestemt nye problemer, eller det vil ikke være så indlysende, hvordan man opdeler data.

Endelig har KX skrevet en meget partisk, men værdifuld whitepaper om nøjagtigt dette emne:

https: //kx.com/media/2016/10/Kx -...

TLDR;

Hvis du vil have en størrelse, der passer til alle, med den bedste ydelse og er villig til at sætte nogle alvorlige kontanter sammen med KDB.

Hvis du har et budget og ønsker at håndtere problemer, når de kommer og har ikke noget imod, at du konstant skal få et andet værktøj til at løse nogle hjørnesager. Gå med Hadoop.

Upshot, hverken er perfekt, forvent ikke en sølvkugle i dette rum når som helst snart, problemerne er faktisk hårde.


Svar 2:

Det er værd at tage et kig på openTSDB, der oversættes til timeseries-databasen. Det er

en indpakning omkring hbase, som er den transaktionelle komponent i hadoop.

Punktet er, at det kan bruges til at håndtere hdb-komponenten i kdb, i betragtning af datamængderne hdb-håndtag. Brug derefter sql-lignende sprog, f.eks. Bikub i stedet for q.