Redis vs Cassandra
- Trådstarter kongen
- Startdato
adeneo
Medlem
Det kommer litt an på, det er to vidt forskjellige databasesystemer.
Som oftest vil Redis være raskere ettersom data lagres i minnet, som selvfølgelig er mye raskere enn disk, men det lagres selvfølgelig også på disk som en backup.
Redis er mer passende for begrensede mengder data, og enkle key/value sett, altså for eksempel et begrenset antall ID'er, som henviser til et lite datasett.
Cassandra er derimot mer egnet når man trenger skalerbare løsninger med liten feilmargin, ettersom Cassandra enkelt kan utvides nærmest uendelig, også på tvers av servere osv. og derfor kan brukes til store mengder data.
Med CQL er det også mulig å gjøre noe mer avanserte spørringer, samt at map reduce er tilgjengelig gjennom tillegg som Hadoop.
Det er ikke uvanlig at både Redis og Cassandra benyttes samtidig, til forskjellige oppgaver, ettersom man normalt velger database etter behov og hvilke data som skal lagres.
Som oftest vil Redis være raskere ettersom data lagres i minnet, som selvfølgelig er mye raskere enn disk, men det lagres selvfølgelig også på disk som en backup.
Redis er mer passende for begrensede mengder data, og enkle key/value sett, altså for eksempel et begrenset antall ID'er, som henviser til et lite datasett.
Cassandra er derimot mer egnet når man trenger skalerbare løsninger med liten feilmargin, ettersom Cassandra enkelt kan utvides nærmest uendelig, også på tvers av servere osv. og derfor kan brukes til store mengder data.
Med CQL er det også mulig å gjøre noe mer avanserte spørringer, samt at map reduce er tilgjengelig gjennom tillegg som Hadoop.
Det er ikke uvanlig at både Redis og Cassandra benyttes samtidig, til forskjellige oppgaver, ettersom man normalt velger database etter behov og hvilke data som skal lagres.
Altså, det du spør om her, å "lagre id av folks pc/mobil i en database istedet for å bruke cookies for å gjenkjenne "anonyme" brukere", er ikke mulig, uavhengig av databasevalg. Hvor har du tenkt å få den IDen fra?
Hvis du vil gjenkjenne brukere uten å bruke cookies, så er local storage et alternativ.
Hvis du vil gjenkjenne brukere uten å bruke cookies, så er local storage et alternativ.
kongen
kongemedlem
Takk for svar
Datastax har laget noe in-memory for Cassandra, kanskje Cassandra blir like kjapp som Redis da?
http://www.datastax.com/2014/02/why-we-added-in-memory-to-cassandra
Jeg lager en id basert på ip, os, browser, plugins etc som puttes i database
Det er en dårlig idè og vil ikke fungere like bra som cookies. Vær klar over at hvis du håndterer sessions på denne måten så åpner du deg selv for en myriade av sikkerthetshull og sårbarheter. Aldri bruk noe slikt for å styre sessions. Skal du kun spore brukerne dine, så bruk local storage hvis du på død og liv ikke vil bruke cookies.
adeneo
Medlem
Her kommer det vel an på hva dataene skal brukes til, i mange tilfeller holder det å lagre IP adresse i en database ?
Browser fingerprinting blir også stadig bedre, for eksempel Panopticlick og lignende, og kan i de fleste tilfeller gjenkjenne brukere helt fint, og sikkerhetsmessig er det faktisk tryggere enn cookies.
https://panopticlick.eff.org/
En session er jo egentlig ikke noe annet enn en cookie med en ID som brukes som nøkkel til data som er lagret på serversiden.
Alle typer teknologier som klarer å gjenkjenne brukere kan derfor brukes til å lage sessions, men local storage er jo svært dårlig egnet ettersom det ikke er tilgjengelig på serversiden, kun på klientsiden, og man må da altså laste inn siden, hente ID'en på klientsiden, og sende den til serveren, sannsynligvis med ajax, noe som i praksis er en helt håpløs løsning.
Jeg er forøvrig enig i at cookies generelt sett er veien å gå for sessions, innlogging osv. men man bør vite hva man driver med dersom det dreier seg om innlogging hvor sensitive eller private data er tilgjengelig, ettersom cookies også er svært sårbare for diverse angrep.
Browser fingerprinting blir også stadig bedre, for eksempel Panopticlick og lignende, og kan i de fleste tilfeller gjenkjenne brukere helt fint, og sikkerhetsmessig er det faktisk tryggere enn cookies.
https://panopticlick.eff.org/
En session er jo egentlig ikke noe annet enn en cookie med en ID som brukes som nøkkel til data som er lagret på serversiden.
Alle typer teknologier som klarer å gjenkjenne brukere kan derfor brukes til å lage sessions, men local storage er jo svært dårlig egnet ettersom det ikke er tilgjengelig på serversiden, kun på klientsiden, og man må da altså laste inn siden, hente ID'en på klientsiden, og sende den til serveren, sannsynligvis med ajax, noe som i praksis er en helt håpløs løsning.
Jeg er forøvrig enig i at cookies generelt sett er veien å gå for sessions, innlogging osv. men man bør vite hva man driver med dersom det dreier seg om innlogging hvor sensitive eller private data er tilgjengelig, ettersom cookies også er svært sårbare for diverse angrep.
Det spørs hva formålet er, ja.
Ønsker man å spore brukere, men kan av en eller annen grunn ikke bruke cookies ( eneste grunnen jeg kan se er å unngå generell skepsis til cookies ), så er local storage den beste løsningen. Det er riktig som du nevner at denne kun er tilgjengelig på klientsiden, så da må man sende denne dataen til en server med javascript.
For brukersporing så er dette helt kurant. Tracking kan gjøres helt uavhengig av applikasjonsbackenden, akkurat som GA gjør. Gjør man det på klientsiden, så kan man bruke en page cache også, noe man ikke kan om gjør det i backenden.
Grunnen til at man aldri skal bygge en hash til å identifisere en session av request headere utenom cookies er at cookies blir beskytta av nettleseren. Cookies blir kun sendt til domenet som satt de, mens resten av request headerne blir sent til alle domener.
Så la oss si du bygger en ID basert på de andre request headerne, md5(serialize($_REQUEST)), og bruker denne som session id. Hvis du har en innlogget bruker hos deg, så trenger jeg bare at den brukeren besøker min nettside for å ta kontroll over den kontoen. Det vil være triviellt enkelt å knekke en slik autentisering.
Vil det funke? Ja, på sett og vis, men er det noe poeng i å finne opp hjulet på nytt, når det nye hjulet er langt mindre sikkert?
Ønsker man å spore brukere, men kan av en eller annen grunn ikke bruke cookies ( eneste grunnen jeg kan se er å unngå generell skepsis til cookies ), så er local storage den beste løsningen. Det er riktig som du nevner at denne kun er tilgjengelig på klientsiden, så da må man sende denne dataen til en server med javascript.
For brukersporing så er dette helt kurant. Tracking kan gjøres helt uavhengig av applikasjonsbackenden, akkurat som GA gjør. Gjør man det på klientsiden, så kan man bruke en page cache også, noe man ikke kan om gjør det i backenden.
Grunnen til at man aldri skal bygge en hash til å identifisere en session av request headere utenom cookies er at cookies blir beskytta av nettleseren. Cookies blir kun sendt til domenet som satt de, mens resten av request headerne blir sent til alle domener.
Så la oss si du bygger en ID basert på de andre request headerne, md5(serialize($_REQUEST)), og bruker denne som session id. Hvis du har en innlogget bruker hos deg, så trenger jeg bare at den brukeren besøker min nettside for å ta kontroll over den kontoen. Det vil være triviellt enkelt å knekke en slik autentisering.
Vil det funke? Ja, på sett og vis, men er det noe poeng i å finne opp hjulet på nytt, når det nye hjulet er langt mindre sikkert?
kongen
kongemedlem
Det skal ikke brukes til noe innlogging, det skal brukes til å gjenkjenne ikke-innloggede brukere, slik at en spesialtilpasset side kan genereres.
F.eks hvis du er singel mann på 25 år som kjører Audi og bor i en 2 roms leiliget i tredje etasje i en blokk i Oslo, og når du besøker vg.no så får du artikler og annonser tilpasset deg. Da slipper du å bli møtt med annonser for OB tamponger og artikler om hvordan vokse bikinilinjen.
F.eks hvis du er singel mann på 25 år som kjører Audi og bor i en 2 roms leiliget i tredje etasje i en blokk i Oslo, og når du besøker vg.no så får du artikler og annonser tilpasset deg. Da slipper du å bli møtt med annonser for OB tamponger og artikler om hvordan vokse bikinilinjen.
adeneo
Medlem
Det er helt kurant å samle inn data på den måten, men som regel ønsker man jo å bruke session data til å tilpasse innholdet som sendes fra serveren, og da fungerer det dårlig å vente til siden er lastet inn, og ID'en blir hentet fra local storage og sendt med ajax.
Det er derfor cookies nesten alltid benyttes, fordi de er en del av header'n og er tilgjengelige overalt, men sikkert er det på ingen måte, selv om man setter secure og HttpOnly flaggene så kan cookies i verste fall snappes opp, og uten SSL er det forholdsvis enkelt det også, det er derfor løsninger som krever en viss sikkerhet regenerer og ikke bruker løsninger som holder deg innlogget over tid, ettersom det også krever cookies som kan bli kompromittert.
Legg merke til at Local Storage faktisk er mindre sikkert enn cookies : https://www.owasp.org/index.php/HTML5_Security_Cheat_Sheet#Local_Storage
Alle typer identifiseringer som kun er kryptert med en enkel MD5 hash er enkle å knekke, legg til litt salting og en treg hashing, slik som PBKDF2, så blir det uendelig mye vanskeligere, ettersom angriperen først må vite AT du bruker data samlet inn fra brukeren som en nøkkel, hvilke data, hvordan og med hva de er saltet, og hvordan og med hva de er hashet, det er med andre så godt som helt umulig å finne ut av, med mindre man har tilgang til serveren, og da er man allerede inne.
Jeg ser poenget ditt, med at de samme dataene er tilgjengelige for alle nettsider og kan like enkelt hentes fra nettside A som nettside B, men sikkerhet har ikke alltid så mye med de beste løsningene å gjøre, men hvor kreativ man er.
Selv dårlige løsninger som er uvanlige, er mye vanskeligere å knekke enn vanlige løsninger som er gode, til en viss grad selvfølgelig !
Så er spørsmålet, hvor interessante er de dataene Kongen skal samle inn ?
Dersom det kun er brukere som skal identifiseres, så er jo IP adresse normalt det enkleste dersom man ikke ønsker å bruke cookies (som helt utvilsomt er det beste).
Må det være mer spesifikt for å fange opp forskjellige brukere på samme IP eller lignende, så er jo browser fingerprinting sammen med IP adressen ganske sikkert, ettersom antall brukere på samme IP sannsynligvis er svært begrenset.
Det kan godt være det er slik, jeg surfer anonymt, og er ikke så veldig plaget med tilpasset reklame, men det du beskriver høres mer ut som en beacon, også kalt web bug, som er noe blant annet Google benytter for å følge med på hva du surfer etter, og hva du driver med på nett, slik at de bedre kan tilpasse innholdet du ser, og det er ikke noe som er enkelt å lage for de fleste av oss som ikke har en eller annen finger med i nesten alle nettsider på nett, slik Google har.
Normalt sett må du jo få brukerne til å taste inn slike data på nettsiden din, for så å lagre de sammen med en ID som gjenkjenner brukeren, og da er du nesten inne på akkurat det samme som et innloggingssystem.
Sist redigert:
kongen
kongemedlem
Tror ikke vg.no gjør slik idag, men jeg skal gjøre det på mine sider. Jeg tror det er større sjansje for at noen klikker annonser og linker hvis de er super-relevante til brukeren.
Det med data kan kjøpes. Hvis man f.eks. har epostadresse så kan man kjøpe data fra 3. part, slik som alder, kjønn, inntekt etc, ved å match epostadresser i hverandres databaser. Hvis man matcher pc/mobil id'er mot hverandre så slipper man å innhente epostadresser også.
For å gjøre dette real-time så brukes api, men ting må gå kjapt. Superkjapt. Folk har liten tålmodighet til å vente på at ting skal lastes, spesielt på mobil som har liten prosessorkraft.
Det med data kan kjøpes. Hvis man f.eks. har epostadresse så kan man kjøpe data fra 3. part, slik som alder, kjønn, inntekt etc, ved å match epostadresser i hverandres databaser. Hvis man matcher pc/mobil id'er mot hverandre så slipper man å innhente epostadresser også.
For å gjøre dette real-time så brukes api, men ting må gå kjapt. Superkjapt. Folk har liten tålmodighet til å vente på at ting skal lastes, spesielt på mobil som har liten prosessorkraft.