torsdag 11 juni 2015

Glöm Windows 10 - här är framtidens operativsystem - TechWorld

Glöm Windows 10 - här är framtidens operativsystem - TechWorld -> IoT



Inte alla tror att jättar som Microsoft och Apple är inne på
rätt väg vad gäller operativsystem. Vi tittar närmare på ultralätta
Mirage OS och alternativ för mobila enheter och sakernas internet, IoT. 

söndag 10 maj 2015

Multidatabaser blir nästa stora grej - Computer Sweden

Multidatabaser blir nästa stora grej - Computer Sweden:



nyckel-värde-databaser
https://www.google.se/search?q=nyckel-v%C3%A4rde-databaser&ie=utf-8&oe=utf-8&gws_rd=cr&ei=5UlQVYbbI4K7swGYq4CwBg



Moderna applikationer använder ofta flera olika databaser, för
olika typer av data. Det leder till komplexa lösningar och krånglig
drift. Lösningen är att använda en databas som klarar av olika typer av
data.




En modern applikation kan lätt
använda fyra olika databaser, till exempel Redis för cache, MongoDB för
att spara loggar, en relationsdatabas för metadata och till exempel
Elasticsearch för indexering och sökfunktioner. Det ger optimal
funktionalitet för applikationen, men leder till komplex utveckling och
drift, och sårbarhet eftersom samtliga databaser måste fungera för att
applikationen ska fungera. Dessutom finns det inga smidiga lösningar för
att hantera transaktioner som inbegriper flera typer av databaser.


Idealet vore att kunna använda en
enda databas för alla typer av data som en applikation behöver hantera.
Men eftersom ingen vanlig databastyp klarar av att hantera alla olika
typer av data blir lösningen att använda en enkel typ av
databashanterare och mappa de olika typerna av data mot den struktur som
används i den. Den enklaste typen av databas som är populär i dag är
nyckel-värde-databaser (key-value store) som hanterar data i form av par
av nycklar och värden. Värden kan vara tämligen komplexa
datastrukturer, till exempel Jsondokument.


Den här lösningen förordas av
Stephen Pimentel i en krönika på Infoworld. Man ska vara medveten om att
han pratar i egen sak, eftersom han arbetar som utvecklarevangelist på
FoundationDB som är en leverantör av just en nyckel-värde-databas. Men
det finns många intressanta synpunkter i hans resonemang.


Bland fördelarna med att använda en
nyckel-värde-databas för alla data märks att driften blir enklare och
mindre sårbar, samt att det i vissa nyckel-värde-databaser finns
möjligheter att hantera transaktioner. Pimentel hävdar att det går
utmärkt att hantera till exempel Jsondokument, relationsdata och data
som normalt finns i grafdatabaser med en nyckel-värde-databas.


Det som inte framgår av krönikan är
hur enkelt eller svårt det är att beskriva mappningen av till exempel
data i en relationsdatabas till nyckel-värde-formatet. Finns det till
exempel visuella verktyg som underlättar? Hur mycket funktionalitet från
olika datastrukturer går förlorad när de ska överföras till
nyckel-värde-formatet? Och så vidare.


Frågetecknen till trots så har
Pimentel en poäng med behovet av konsolidera databasanvändningen. Frågan
är om dagens databasprodukter är tillräckligt avancerade för att lösa
uppgiften.






Multidatabaser blir nästa stora grej - Computer Sweden

Multidatabaser blir nästa stora grej - Computer Sweden



Moderna applikationer använder ofta flera olika databaser, för
olika typer av data. Det leder till komplexa lösningar och krånglig
drift. Lösningen är att använda en databas som klarar av olika typer av
data.




En modern applikation kan lätt
använda fyra olika databaser, till exempel Redis för cache, MongoDB för
att spara loggar, en relationsdatabas för metadata och till exempel
Elasticsearch för indexering och sökfunktioner. Det ger optimal
funktionalitet för applikationen, men leder till komplex utveckling och
drift, och sårbarhet eftersom samtliga databaser måste fungera för att
applikationen ska fungera. Dessutom finns det inga smidiga lösningar för
att hantera transaktioner som inbegriper flera typer av databaser.


Idealet vore att kunna använda en
enda databas för alla typer av data som en applikation behöver hantera.
Men eftersom ingen vanlig databastyp klarar av att hantera alla olika
typer av data blir lösningen att använda en enkel typ av
databashanterare och mappa de olika typerna av data mot den struktur som
används i den. Den enklaste typen av databas som är populär i dag är
nyckel-värde-databaser (key-value store) som hanterar data i form av par
av nycklar och värden. Värden kan vara tämligen komplexa
datastrukturer, till exempel Jsondokument.


Den här lösningen förordas av
Stephen Pimentel i en krönika på Infoworld. Man ska vara medveten om att
han pratar i egen sak, eftersom han arbetar som utvecklarevangelist på
FoundationDB som är en leverantör av just en nyckel-värde-databas. Men
det finns många intressanta synpunkter i hans resonemang.


Bland fördelarna med att använda en
nyckel-värde-databas för alla data märks att driften blir enklare och
mindre sårbar, samt att det i vissa nyckel-värde-databaser finns
möjligheter att hantera transaktioner. Pimentel hävdar att det går
utmärkt att hantera till exempel Jsondokument, relationsdata och data
som normalt finns i grafdatabaser med en nyckel-värde-databas.


Det som inte framgår av krönikan är
hur enkelt eller svårt det är att beskriva mappningen av till exempel
data i en relationsdatabas till nyckel-värde-formatet. Finns det till
exempel visuella verktyg som underlättar? Hur mycket funktionalitet från
olika datastrukturer går förlorad när de ska överföras till
nyckel-värde-formatet? Och så vidare.


Frågetecknen till trots så har
Pimentel en poäng med behovet av konsolidera databasanvändningen. Frågan
är om dagens databasprodukter är tillräckligt avancerade för att lösa
uppgiften.
 

Den sköna nya databasvärlden - Computer Sweden

Den sköna nya databasvärlden - Computer Sweden



Utan databaser, ingen it. Men vilken databas är rätt? Den frågan
är mycket svårare att besvara i dag än för fem år sedan med ett större
utbud och utmanade normer.




Databaser är bottenplattan i nästan
alla it-lösningar inom näringslivet. Utan data blir det inga
applikationer och för att hantera data krävs databashanterare. Efter att
ha varit ett produktområde som förändrats lite under många år har
utvecklingen tagit ordentlig fart under de senaste fem åren. Från att ha
haft en totalt dominerande roll har relationsdatabasen blivit utmanad
på allvar av flera alternativa typer av databaser.


En genomgång av marknaden visar att valmöjligheterna är många.

 



  • Relationsdatabasen

Relationsdatabaser som Oracle, Microsofts SQL Server, IBM:s DB2 och Mysql är
fortfarande normen. Traditionella administrativa system bygger i stort
sett alltid på sådana. Och det är inom den här dominerande nischen som
det finns mest kompetens bland it-personal. Det finns också en hyfsad
konsensus om hur databaser ska utformas med den här typen av
databashanterare och mycket fokus läggs på att garantera att data är
korrekta.


Det är främst på områden som
beslutsstöd och dataanalys, stora webbtillämpningar och lösningar för
sakernas internet som relationsdatabasen utmanas.

 

  • Varianter av relationsdatabasen

För beslutsstöd och dataanalys blir det ofta problem med den
traditionella relationsdatabasen. Det går för långsamt, helt enkelt. Det
har lett till att olika varianter av relationsdatabasen blivit allt
populärare. En sådan variant är att hantera data kolumnvis i stället för
radvis, en annan att hantera data i minnet i stället för på disk.


Läs mer: Databaser och depprock - likheterna är fler än du tror


Ett enkelt exempel
kolumnhantering är att personnumren för alla personer i ett
personregister lagras i en följd, i stället för att alla uppgifter för
en person lagras i en följd, för att sedan lagra uppgifterna för nästa
person, och så vidare. Det här innebär att det går snabbt att hitta alla
personnummer som uppfyller ett visst kriterium, till exempel alla
kvinnor. Det går också snabbt att summera värden i en kolumn. Den typen
av prestandaförbättringar är viktiga för beslutsstödstillämpningar.


SAP:s Hana är
en relationsdatabas som är både kolumndatabas och minnesdatabas. Den
typen av lösningar blir vanligare, bland annat kan Oracles ledande
traditionella relationsdatabas numera fungera som en kolumnorienterad
minnesdatabas.

 

  • Nosql

Nosql är samlingsnamnet för en mängd olika typer av databaser med den
gemensamma egenskapen att de inte är relationsdatabaser. Upprinnelsen
till dem är att relationsdatabaser i många fall inte fungerar bra för
stora webbtillämpningar. De är inte tillräckligt snabba för webben.


För de flesta nosql-databaserna har
man valt bort konstruktioner för många datastrukturer, speciellt
kopplingar mellan olika data, och även kontroller av att regler för data
uppfylls. Det är funktioner som är vanliga i relationsdatabaser. Det
går snabbt att hantera data, men det går inte att specificera lika
avancerade datastrukturer och att vara lika säker på att data alltid är
korrekta som med relationsdatabaser. I vissa fall har datastrukturerna
från relationsdatabaserna ersatts med andra strukturer som är lämpade
för specifika användningsfall. Ett exempel är att kopplingarnamellan
tabeller i relationsdatabaser ersätts av kopplingarna i grafdatabaser.


Läs mer: Större, bättre, snabbare, starkare – här är nyheterna i kommande versionen av MySQL


Den enklaste typen av nosql-databas
kallas key-value store. I dess allra enklaste form lagras par av nycklar
och värden, till exempel ”1”, ”Lars”. Nästa typ, dokumentdatabasen, kan
beskrivas som en mer avancerad form av key-value-databas, med
skillnaden att värden som lagras kan vara komplexa, till exempel ett
stort dokument innehållande olika typer av data. Men värdet som lagras i
en key-value-databas kan också vara mer komplext än en enkel
textsträng.


Kort sagt, skillnaden mellan en
avancerad key-value-databas och en enkel dokumentdatabas kan vara
hårfin. Att det görs en distinktion mellan de två typerna beror nog på
det grundläggande användningsfallet. I key-value-fallet tänker man sig
enkla datastrukturer, i dokumentfallet mer komplexa, ofta med varierande
struktur för de dokument som finns i en databas.


Populära key value-databaser är till exempel Riak, Dynamo och FoundationDB. Den mest populära dokumentdatabasen är MongoDB. Även IBMs Notes är en dokumentdatabas.


Den tredje viktiga typen av
nosql-databaser är grafdatabasen. Den kan beskrivas som en dopad
relationsdatabas, fokus ligger på kopplingar mellan datavärden.
Grafdatabaser passar utmärkt för tillämpningar av typen ”vänners vänner”
på webbtjänster. Sökningar som får en relationsdatabas att storkna går
ofta blixtsnabbt med en grafdatabas. Svenska Neo4j är en ledande grafdatabas.


Marklogic är ett
bra exempel på hur nosql-databaser utvecklas i dag. Det är en
dokumentdatabas för vilken fokus till en början låg på att hantera
xml-data. I dag hanteras olika typer av dataformat, som Json, och mycket
kraft läggs på att hantera transaktioner, vilket långt i från alltid är
fallet med nosql-databaser.



Hadoop maskot och logga, den gula elefanten.

 



  • Hadoop

Hadoop är egentligen ingen databashanterare, utan ett ramverk för
distribuerad hantering och bearbetning av stora datamängder. Men i
praktiken används Hadoopimplementationer ofta i situationer när
datamängderna är för stora för traditionella relationsdatabaser, typiskt
för analystillämpningar, i princip i satsvisa körningar, så kallade
”batchjobb”.


Läs mer: Ola Bini: "Använd aldrig en databas för mer än en applikation"


Hadoops framgångar kommer sig helt
enkelt av att det ofta är den enda tekniskt och kostnadsmässigt rimliga
lösningen för att hantera stora datamängder. De främsta
Hadoopleverantörerna är Hortonworks, Cloudera och Mapr.

 

  • Fler udda fåglar

Och så uppsamlingsheatet. Här hittar vi alternativ och komplement till Hadoop som Spark och Storm, båda liksom Hadoop från Apache. Det finns också ett antal mindre vanliga nosql-varianter, som objektdatabaser.


Läs mer: Multidatabaser blir nästa stora grej


Splunk är en
bra representant för den här diversekategorin. Produkten startade sitt
liv främst som ett verktyg för logganalys. I dag är ambitionerna mycket
större än så. Företaget Splunk framhäver sin produkt som ett alternativ
till Hadoopimplementationer och det går att se Splunk som ett nav för
datahantering i ett företag.

 



Filemaker Pro undantaget som bekräftar regeln

Filemaker Pro är den enda av de tidigare populära pc-databaserna
som lyckats behålla sin popularitet. På Positionett har man fullt upp
med att skapa system med Filemaker Pro. 




En
typ av databas som minskat i betydelse väsentligt sedan sekelskiftet är
den enkla pc-baserade relationsdatabasen. Produkter som Microsofts
Access och Borlands Paradox användes i stor utsträckning tidigare, inte
bara som databaser, utan även som utvecklings- och driftsmiljöer. I dag
sker det mer sällan.


Läs mer: Google öppnar för fulminnesdatabas


Ett undantag finns i Filemaker Pro,
från leverantören Filemaker. Databasen som började sitt liv på
Macintosh, men även funnits på Windows sedan 1992, används fortfarande
flitigt för att skapa administrativa system.  

I Sverige är konsultföretaget Positionett ett av de ledande på Filemaker Pro.


– Filemaker Pro används för system
med allt från en användare till 20–30 användare. Medeltalet vad gäller
våra färdiga lösningar ligger mellan fem och sex användare, säger Magnus
Wilén som är vd på Positionett i Stockholm.


Läs mer: Kör sql direkt på MongoDB


Han berättar vidare att mellan 70
och 80 procent av företagets kunder kör på Windows, men att bilden av
Filemaker Pro som ett Macprogram ändå lever kvar. En annan bild som
lever kvar är att Filemaker Pro främst är avsett för ensamanvändare, men
bland Positionetts kunder används för det mesta serverversionen av
programmet.


– Användningen av Filemaker Pro har
breddats enormt på senare år. Även affärskritiska system byggs på
Filemaker Pro, och det går att skapa webb- och mobillösningar.