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.









 

Googles superdatabas blir tillgänglig som molntjänst - Computer Sweden

Googles superdatabas blir tillgänglig som molntjänst - Computer Sweden



Google ger sig in i kampen om att hantera riktigt stora
datavolymer med tjänsten Cloud Bigtable. Kompatibilitet med Amazons
Hbase ska ge framgång.




Google Bigtable har
antagit en nästan mytisk ställning vad gäller senare års oortodoxa
hantering av data, jämfört med traditionella relationsdatabaser.
Bigtable har använts länge internt på Google och tekniken har använts i
andra tjänster från Google, men den har kanske framför allt tjänat som
inspirationskälla för andra företags lösningar för att hantera stora
datamängder.


När Google nu gör Bigtable
tillgängligt som en molntjänst i form av Cloud Bigtable så positioneras
tjänsten som en ”molnbaserad nosql-databas”. Vägen till framgång ska,
förutom via teknikens allmänna duglighet för att hantera stora
datavolymer, bli att erbjuda ett programmeringsgränssnitt (api) som är
kompatibelt med Amazons Hadoopbaserade databas Hbase. I teorin ska det
alltså gå att lyfta bort Hbase och stoppa in Cloud Bigtable. Vi får se
hur smidigt det blir i praktiken.


Läs mer: Den sköna nya databasvärlden


Google beskriver Cloud Bigtable som
en lösning för att hantera stora datamängder som kräver mycket, och
komplex, bearbetning. Det låter onekligen ganska likt Hadoop, även om
Google även har siktet inställt på strömmande data med den nya tjänsten.


Rent databastekniskt cirkulerar
begrepp som tabell, rad, kolumn, kolumnfamilj, cell och versioner i
dokumentationen till Hbase, som Googles nya tjänst alltså ska vara
kompatibel med. Det går till exempel att skapa kolumner när som helst,
men däremot måste kolumnfamiljer definieras i ett schema. Hur som helst
borde både de med erfarenhet av relationsdatabaser och de som är mer
inriktade på nosql-databaser kunna använda Cloud Bigtable.


I vanlig ordning för Google så finns
Cloud Bigtable tillgänglig i en betaversion, gratis för de som vill
prova på. Priserna kommer att baseras på flera faktorer, som antalet
noder (”servrar”) som används, mängden data som lagras och mängden
nätverkstrafik.







 

Superlätt att köpa in molntjänster - men hur byter man leverantör? - Computer Sweden

Superlätt att köpa in molntjänster - men hur byter man leverantör? - Computer Sweden



Att byta till molntjänster går snabbt och enkelt. Men nu börjar
företagen upptäcka att det inte alltid är lika lätt att byta leverantör.  




Det är dags
för företagen att greppa konsekvenserna av att köpa molntjänster. Få
har i dag ett riktigt grepp om hur de går till att förflytta sig mellan
olika leverantörer när de väl kommit dit och det saknas alternativa
planer för hur det ska gå till.


– Nu pratar vi mycket om att flytta
in i molnet men vi har inte tränat så mycket på att flytta inom molnet.
Att förstå det bättre är ett jobb som är kvar för it-avdelningarna,
säger Postnords cio Joss Delissen.


Just nu arbetar han för fullt med
två stora upphandlingar och även om Postnords strategi är att först se
om det finns några molnlösningar så gäller det att veta vad man gör.


Läs mer: Googles superdatabas blir tillgänglig som molntjänst


– Vi lever i en kommersiell värld
där alla vill tjäna pengar och behålla kunden på lång sikt – även
it-leverantörerna. Då gäller det som cio att tänka igenom segmentering
och se till att behålla möjligheter att byta och förbättra, säger han.


– Nu är vi på väg in i molnet med
några bra lösningar. Men vi på Postnord är långt ifrån att ha gått över
till molntjänster helt och hållet, delvis av just den anledningen.


Det räcker med att fundera på hur det skulle kännas som privatperson om Google plötsligt deklarerade att Gmail ska kosta fem dollar i månaden.


– Det skulle ju vara jättejobbigt
att byta. Om vi tänker en parallell situation för företag så kan man
tänka sig framtida bekymmer om man inte kan flytta tillräckligt lätt.


Tidigare har det talats om molnmäklare som just ska hjälpa till med sådana här frågor. Är det en del av er upphandling?


– Ja, vi hoppas att  vi kan hitta det i det partnerlandskap som vi bygger. Det är en del av det.


Läs mer: Outsourcing-kontrakt i miljardklassen ska ta Posten in i framtiden


Analytikern Tiny Hayes på Gartner håller med om att det är dags att ta ett helhetsgrepp om sina molntjänster och skapa strategier för det.


– Många har bytt till
molnplattformar väldigt snabbt och flyttat infrastruktur utan att det
gjorts särskilt planerat eller strategiskt, säger han.


Orsaken är helt enkelt det som
kallas skugg-it – att verksamheten rundar it-avdelningen och skaffar
molntjänster på egen hand. Men medan det bara tar några minuter att
skaffa en molntjänst är det långt ifrån lika enkelt att byta den mot en
tjänst hos en annan leverantör.


Tiny Hayes jämför det med att migrera ett datacenter.


– Jag tycker man ska se det så. Det
handlar om att flytta gigabyte, terabyte och pentabyte och då måste
plattformarna konfigureras om. Det är inte så enkelt som att bara stänga
av – ditt data ligger fortfarande kvar därute, säger han.


Många företag inser nu att det krävs mer genomgripande strategier och backupplaner.


– Och då måste den första frågan alltid vara – hur många molntjänster använder vi redan,  säger Tiny Hayes.


Svårigheten är att de
affärsprocesser som finns ute i företagen inte synkar med hur
molntjänsterna är upplagda. Medan det kan ta några minuter att få
tillgång till en server kan det ta två veckor att få fram en inköpsorder
konstaterar han.


– Det ska till ett beslut och en
upphandling och så vidare. Processen är inte byggd för den hastighet som
finns när det gäller molntjänster. Så när man gör sin strategi måste
man också fundera på hur affären ska ändras för att dra nytta av de
olika molnplattformarna.







fredag 24 april 2015

Så undviker du wifi-attacker - Computer Sweden

Så undviker du wifi-attacker - Computer Sweden



Alla företag behöver förbereda sina nätverk för nya typer av
attacker. Här är de vanligaste sårbarheterna och hur man skyddar sig
emot dem.




Hur ska företagen skydda sig från wifi-attacker? här är fem bra tips. Foto:

Phil Whitehouse


I de flesta företag finns en medvetenhet om att cyberkriminella kan
försöka knäcka lösenorden för att få tillgång till olika måltavlor. I
wifi-nätverk är kraftfulla lösenord är en bra medicin. Men det räcker
inte för att säkra wifi-nätverken. Hackare som vill bryta sig in, skapa
kaos eller ställa till skada kan använda sig av olika typer av
sårbarheter. Här är de vanligaste attack- och intrångsförsöken och hur
man skyddar sig mot dem, enligt säkerhetsspecialisten Eric Geier på
Network World.


1. Ha koll på användarapparaterna.

Delad WPA2-säkerhet innefattar ett globalt lösenord för hela nätverket.
Lösenordet finns ofta sparat i alla enheter som regelbundet är anslutna.
Om en enhet tappas bort eller stjäls så bör lösenordet ändras på alla
routrar och åtkomstpunkter och det nya lösenordet behöver kommuniceras
ut till alla användare.


Läs mer: Det är inte kraven utan efterlevnaden som gör att kortsäkerheten brister


2. Stoppa nätverkssnokarna.

Delade nätverk är bra för att hantera många gäster, men för företag
behövs ofta bättre koll. Ofta kan utomstående, som gäster,
bemanningsanställda eller andra söka igenom nätverkstrafik. Om någon har
tillgång till lösenord kan de dekryptera och avlyssna trafik. Ställer
man in WPA2 i företagsläge så stoppar det möjligheten för enskilda
användare att snoka, medan det fortfarande går att dela.


3. Hantera kidnappade sessioner.  

Det finns många verktyg för att identifiera kidnappade sessioner i
bristfälligt säkrade wifi-nätverk, exempelvis Droid Sheep and Face Niff.
Sådana appar funkar med Android och kan användas i kombination med
osäkra sajter. Appen detekterar alla osäkra inloggningar och skapar
tillgång till kapade konton utan behov av ett lösenord.


Läs mer: IBM: ”Skadlig kod infekterar 11 miljoner mobiler i minuten”


4. Checka av åtkomstpunkterna.

Om någon vill få icke-auktoriserad åtkomst till nätverket, kan de
försöka ansluta sig via andra falska åtkomstpunkter eller sätta upp
egna. Alla åtkomstpunkter som inte är klassificerade som säkra bör
betraktas som potentiellt osäkra. Det gäller såväl mjukvaru- som
hårdvarubaserade säkerhetsaspekter.


5. Ha koll på överbelastningsattackerna.

Alla trådlösa nätverk är känsliga för ddos-attacker, både sådana som
sker inifrån och utanför nätverket. Dessa kan sänka prestandan eller
krascha nätverket fullständigt. Nätverkskryptering fungerar inte i alla
sammanhang, vilket gör det möjligt för förövare att skicka falsk trafik.
Inget nätverk kan skyddas helt, men genom att ha koll på vilken typ av
överbelastningsattacker som är vanliga och den allmänna hotbilden, går
det att ha viss beredskap för yttre säkerhetshot mot wifi-nätverket.