Sammanfattning
Denna uppsats undersöker hur synkronisering mellan tre valda plattformars databaser (iOS, Android, MySQL) kan utföras på bästa sätt. Utifrån vår primärdata som är vetenskapliga artiklar skrivna i ämnet, samt tidigare forskning och vår sekundärdata som är vårt experiment CrossSync, samt en intervju med Fredrik Ålund på Mimer, har vi med ett kvalitativt synsätt sett på de olika beståndsdelarna som krävs för att kunna utföra synkronisering mellan dessa plattformar. Vårt resultat visar på att en långsam
synkroniseringsmodell måste användas, där hela databasen i den ena enheten jämförs med hela databasen på servern vid varje synkronisering. Det visar också på att synkroniseringen måste anpassas efter mobilernas begränsade resurser.
Abstract
This paper investigates how to best synchronize databases of three chosen platforms (iOS, Android, MySQL). With a qualitative approach where our primary data is peer reviewed journals and prior science in the field and our secondary data is our own experiment CrossSync, and an interview with Fredrik Ålund at Mimer we look at the different parts involved in synchronization of databases. The result of the study indicates that the synchronization needs to be a “Slow Synchronization” where the entire database of the device needs to be compared against the server-‐database. It also indicates that the most crucial part of the process is that the synchronization is adapted for the limited resources of the mobile devices.
Nyckelord/Keywords: Synkronisering, iOS, Android, Mysql, Database replication, Crosssync
Innehållsförteckning
Sammanfattning ... 2
Abstract ... 2
1 Inledning ... 6
1.1 Bakgrund ... 6
1.2 Problemformulering ... 6
1.3 Syfte och forskningsfrågor ... 6
1.4 Avgränsningar ... 7
Plattformar ... 7
Synkroniseringsmodell ... 7
Funktionalitet ... 7
Val av databas ... 7
1.5 Kunskapsintressenter ... 7
Utvecklare ... 7
Användare ... 8
1.6 Disposition ... 8
2 Metod ... 8
2.1 Forskningsansats ... 8
2.1.1 Personliga erfarenheter och motivation ... 8
2.1.2 Litteraturstudie ... 8
2.1.3 Strategi ... 9
2.1.4 Empiriska underlag ... 9
2.2.1 Informationsinsamling ... 10
2.3 Forskningsprocess ... 11
3 Teori ... 12
3.1 Plattformarna ... 12
3.1.1 MySQL ... 12
3.1.2 SQLite ... 12
3.1.3 iOS ... 12
3.1.4 Android ... 13
3.2 Synkronisering ... 14
3.2.2 Synkronisering i en mobil miljö ... 16
3.2.2 Synkroniseringsmodeller ... 19
3.2.3 Snabb synkronisering ... 19
3.2.4Flaggor ... 19
3.2.5 Långsam synkronisering ... 20
3.2.6 Timestamps (Tidsstämplar) ... 21
3.2.7 Synkroniseringsalgoritmen SAMD ... 22
3.2.8 Synkronisering med SyncML ... 25
3.2.9 Synkronisering med CPISync ... 25
4 Empiri ... 26
4.1 Presentation av empiri ... 26
Bakgrund ... 26
Vad är utmärkande för Mimer Mobile? ... 27
Prestanda ... 27
SQLite ... 27
Synkronisering ... 27
4.2 CrossSync ... 28
4.2.1 Val av synkroniseringsmodell ... 28
4.2.2 CrossSync för den mobila enheten ... 28
4.2.2 Flöde/Modell. ... 30
4.2.3 Val av tekniker ... 30
JSON (Datastruktur) ... 30
4.2.4 Experiment: Storlek på JSON-‐ respektive XML-‐paket ... 34
Tillvägagångsätt ... 34
4.2.4 Dynamisk programmering ... 35
4.2.5 Asynkroniska processer ... 38
4.3 Analys av empiri ... 41
4.3.1 Mimer Intervju ... 41
5 Analys ... 41
5.1 Diskussion och generalisering ... 42
5.2 Slutsats ... 42
5.3 Reflektion ... 43
5.4 Förslag på vidare forskning ... 43
6 Källförteckning ... 45
6.1 Litteratur ... 45
6.2 Internetkällor ... 45
6.3 Intervju ... 45
6.4 Vetenskapliga artiklar ... 46
6.5 Uppsatser ... 46
7 Bilagor ... 46
Citat från Intervjun med Fredrik Åhlund (Bilaga 2) ... 50
1 Inledning 1.1 Bakgrund
Under de senaste åren har antalet enheter, med olika plattformar, som används av konsumenter ökat explosionsartat. Allt fler har både en dator och en smart mobiltelefon.
Moderna applikationer finns idag inte enbart till Windows, OS X och Linux, utan har krav på sig att existera även på de nya mobila plattformarna; iOS, Android, Windows Phone för att nämna några. I och med fokuseringen på molntjänster och mobilapplikationer så ökar också kraven på mjukvaruutvecklare att kunna bygga flexibla och anpassade lösningar för hantering och synkronisering av data mellan dessa plattformar.
Synkronisering är själva processen för att få två uppsättningar data att se identiska ut
1. Det finns tre olika modeller; antingen så lyssnar en enhet (target) på en annan (source) efter ny data eller förändringar. I den andra modellen lyssnar flera enheter på en server där all information lagras. Eller så lyssnar ett flertal enheter direkt på varandra, utan server.
I praktiken och för användaren innebär detta att man har uppsättning med enheter, som man vill skall dela samma data. Om användaren exempelvis lägger till en kontakt i sin telefonbok så skall denna kontakt distribueras ut till användarens alla enheter.
Datasynkronisering har blivit de mobila enheternas akilleshäl
2.
1.2 Problemformulering
De nya mobila plattformarna har annorlunda förutsättningar till skillnad från de äldre stationära plattformarna och kräver annan sorts hantering av data för att smidigt kunna fungera. Den mobila enheten är, tillskillnad från den stationära, inte alltid uppkopplad mot nätet
3. Denna kopplar upp och hämtar data som den sedan skapar en lokal kopia av. Detta görs för att spara på de begränsade resurser som en mobil enhet har, exempelvis begränsad datatrafikmängd eller batterikapacitet, till skillnad från de stationära. Detta komplicerar datasynkronisering mellan enheter, eftersom data inte alltid är ajour på alla enheter, utan kan existera i olika versioner. Den kan dessutom existera på olika plattformar som måste kunna kommunicera mot en och samma server.
1.3 Syfte och forskningsfrågor
Syftet och målet med denna uppsats är att få en djupare förståelse för ovan beskrivet problemområde liksom för vad synkronisering innebär, hur det kan förbättras och vilka lösningar som idag finns för att kunna synkronisera data. Framförallt med fokus på mobila plattformar där man inte bara kan fokusera på synkroniseringens funktionalitet, utan den måste även optimeras med hänsyn till begränsade resurser.
1 Building an Industry-Wide Mobile Data Synchronization Protocol, SyncML WhitePaper (2011)
2ibid
3bid, s.3
Vi kommer att skriva en enklare applikation till varje plattform som kan utföra de fyra operationerna i CRUD ”Create”, ”Read”, ”Update” och ”Delete” mot databasen. Och därefter kunna synkronisera sina förändringar så att samma information speglas till applikationerna på de övriga plattformarna.
Forskningsfrågor vi hoppas kunna besvara blir således;
Hur kan man synkronisera data mellan olika plattformar, mobila som stationära, med bästa prestanda men med bibehållen dataintegritet?
1.4 Avgränsningar
Plattformar
Vi kommer att fokusera på tre plattformar som skall hållas synkroniserade. De två stora operativsystemen inom den mobila marknaden är iOS och Android. Dessa skall sedan synkroniseras mot en MySQL-‐databas, som kan köras på alla de stora stationära plattformarna (Windows, OS X och Linux). De mobila plattformarna använder båda interna SQLite-‐databaser.
Synkroniseringsmodell
Vi har valt en modell där flera enheter kommunicerar mot en server. Dock inte enligt synkroniseringsmodellen där alla enheter enbart lyssnar på servern. Utan alla enheter har även rätt att modifiera och lägga in ny data på servern, de både lyssnar och skriver. Mer utförligt hur synkroniseringsmodellen fungerar beskrivs i empiriavsnittet.
Funktionalitet
Vi har valt att implementera synkroniseringen helt utan kompromisser på säkerhet och funktionalitet. Ingen data får ersättas eller tas bort av misstag, utan all data ska i sin senaste version distribueras på ett korrekt sätt till alla enheter. Därefter kommer vi att försöka optimera nätverksanrop och logik för att uppnå så bra prestanda som möjligt utan att funktionaliteten påverkas.
Val av databas
De båda mobila plattformarna har inbyggt stöd för SQLite, och blev därför vårt val av databas på dessa plattformar.
1.5 Kunskapsintressenter
Utvecklare
Vi tror att primärt utvecklare som jobbar med de mobila plattformarna kan vara intresserade
av våra resultat och slutsatser. Många applikationer har någon form av synkronisering och
det finns olika tillvägagångsätt för att implementera det. Vårt arbete beskriver inte syntaxen
för exakt hur detta ska implementeras i kod, men ger bra riktlinjer för vad man ska tänka på
och ta hänsyn till.
Användare
Även användare av smarta mobiler eller någon som ofta kommer i kontakt med serveranrop kan tänkas vara intresserade av vårt arbete. Då det ger en djupare inblick hur ens enhet fungerar.
1.6 Disposition
Uppsatsen börjar med att definiera vilket syfte vi har med arbetet, vår frågeställning klargörs och problembilden presenteras. Vi definierar även vilka avgränsningar vi kommer ha i arbetet i kapitel ett.
Kapitel två presenterar vilken metod och forskningsansats vi har haft i undersökningen. Här presenteras även hur data har samlats in och behandlats. Efter detta följer kapitel tre där vi går igenom vad Synkroniseringsbegreppet innebär i vår kontext och presenterar vilken tidigare forskning som finns på området. Vi undersöker vilka alternativ som finns för synkronisering i en mobil miljö. Vi presenterar även bakgrundsinformation om de tre utvalda plattformar vi i arbetet valt att fokusera på.
I kapitel 4 presenterar vi den empiri vi insamlat från intervjuer, litteratur och experiment.
Här analyseras och diskuteras även dessa data.
I kapitel 5 så sammanfattar vi arbetet och drar avslutande slutsatser om vårt resultat.
I kapitel 6 presenteras våra källor och referenser.
2 Metod
2.1 Forskningsansats
2.1.1 Personliga erfarenheter och motivation
Det är svårt att undgå de mobila enheternas framgångar idag, vi använder oss själva av dem och kommer i kontakt med synkronisering varje dag. Vi är båda intresserade och har utvecklat enklare applikationer till våra enheter, det är dock mer komplext att implementera kommunikation mot andra enheter och plattformar. Lösningarna har ofta blivit väldigt bundna till applikationen och odynamiska. Därför har vi känt en motivation att undersöka detta problem, vad det finns för olika tillvägagångsätt och vilket som är bäst.
2.1.2 Litteraturstudie
Området är relativt nytt och är ständigt i utveckling, därför är det är svårt att hitta nya och
relevanta studier. Men vi har tagit del av några vilket bidragit till att utveckla nya perspektiv
på vår forskningsfråga. Vi kommer främst att använda Internet som medium för vår
litteraturstudie. Just för att det är lättaste sättet att hitta störst omfattning av relevant
litteratur. Dock måste vi vara extra noga med att kontrollera vem som publicerat materialet och bedöma sanningshalten i allt vi hittar.
Litteraturstudien skapar ett konceptuellt ramverk, det vill säga hur vi strukturerar vårt tänkande kring vår uppgift. Vilka olika faktorer som bygger vår fråga, hur vi ser på vår fråga och själva området. Det ger också en bild av hur vi skulle börja designa och utveckla en experimentell lösning, liksom hur vi ska tolka resultatet av den lösningen.
2.1.3 Strategi
Som strategi för att ta ansats till att besvara vår fråga valde vi ”design och skapa”
kombinerat med ”experiment”, vår studie är därav en strategitriangulering (två eller flera strategier). Design och skapa valde vi därför att vi ville själva bygga en synkroniseringslösning, enligt ”Researching Information Systems and Computing”
4kan en IT-‐
lösning agera ett ”fordon” för att besvara sin forskningsfråga. Det vill säga att vi utvecklar vår synkroniseringslösning för att det ger oss god teoretisk förståelse för hur synkronisering är uppbyggt och fungerar samt ett utmärkt sätt att undersöka alternativ och teorier. Vilket ger oss tillräckligt med data för att, slutligen, bidra till en slutsats i denna rapport.
I vissa fall är det svårt att bedöma vilket beslut som är mest fördelaktigt. Där kommer
”experiment” att bli aktuellt. Det är viktigt att empiriskt testa eventuella alternativ för att bedöma vilket som presterar bäst exempelvis.
2.1.4 Empiriska underlag
Vår strategi och angreppsvinkel kommer främst generera kvantitativ data som underlag.
Synkroniseringen kommer att kunna mätas i antal synkroniseringsanrop till server eller hur stor mängd data som skickas exempelvis. De metoder vi kommer att använda för att generera dessa underlag är främst dokumentstudier. Inte bara skrivna dokument som tidigare studier och artiklar, utan hit hör även dokument i form av grafik, diagram, modeller med mera.
Vi kommer även att använda Intervju som metod för att samla in empiriska underlag. Vilket gör vår studie till en metodtriangulering, eftersom den inkluderar två eller fler metoder.
Hur vår data sedan ska tolkas kommer att formas av det konceptuella ramverket som man bildat sig tidigare under litteraturstudien. Dock måste man även hålla analysen av datan öppen för nya tolkningar och perspektiv, som man kanske inte väntat sig.
Vår intervju är en s.k. ostrukturerad intervju.
5Där vi för en öppen dialog och låter den som intervjuas tala fritt om ämnet. Vi planerar dock vilka ämnen vi vill att intervjun skulle kretsa runt och gör därför endast stödfrågor för att sedan låta dessa skapa diskussioner mellan oss
4Sid 109-110, Researching Information Systems and Computing 2006 - Briony J Oates
5Sid 188, Researching Information Systems and Computing 2006 - Briony J Oates
och den vi intervjuar. För att kunna analysera intervjun i efterhand så spelas hela intervjun in.
Uppsatsen har ett deduktivt synsätt där vi utgår från våra egna och redan etablerade teorier i fältet.
6Utifrån dessa teorier använder vi vår data för att komma fram till svaret på vår forskningsfråga. Vi försöker också tolka den data vi samlat från intervjuer och litteratur på ett öppet och kvalitativt sätt. Arbetet kommer genomsyras av en öppen tolkning av den data vi kommer samla. Anledningen till detta öppna angreppssätt är också för att den data vi kommer samla kommer vara väldigt spridd då den kommer från tre olika källor (Litteratur, intervju och programmering.). Rent kvalitativt kommer denna data vara kontextuell och svåranalyserad om den skulle analyseras kvantitativt. Kvalitativ data behöver kvalitativ dataanalys.
7Vi har valt att använda en blandning mellan ett kvalitativt och ett kvantitativt synsätt där vi med hjälp av litteraturen, intervju och experiment ville identifiera de viktigaste delarna i en väl fungerande synkroniseringsmodell för mobila databaser. Denna tolkning kommer mestadels ta sin grund i kvalitativa reflektioner av vår data, medan teknikerna inblandade i synkroniseringen kommer mätas med ett mer kvalitativt synsätt där vi mäter effektivitet på och funktion på ett mer positivistiskt sätt. Anledningen till denna delning av synsätt är att vår forskningsfråga är svårdefinierad, med mening, och frågar öppet vilken synkroniseringsmodell som fungerar ”bäst”. Denna definition syftar på att inte endast fokusera på tekniska aspekter utan även ta en grund utifrån mjukare faktorer så som användningen av tekniken för den som implementerar den och användarens upplevelse av tekniken.
2.2.1 Informationsinsamling
Vi har i vårt arbete valt tre olika källor för insamling av data. Den största delen har varit att läsa den litteratur som finns skriven om ämnet och lärt oss vilka modeller som idag finns för synkronisering mellan databaser. För att sedan sätta in denna data i vår kontext har vi valt ett av dessa synkroniseringssätt som förespråkats och byggt en prototyp av denna synkronisering på de plattformar vi valt att jobba med. Denna prototyp har i sin tur genererat nya problemområden, som vi sedan sökt ytterligare information om i litteraturen.
Utöver detta har vi även valt att genomföra en intervju med Fredrik Ålund på Mimer för att samla in relevant information från en person som är väl insatt i ämnet.
En annan informationskälla är själva programmeringen. Under programmeringens gång tvingas man ständigt ta beslut och välja olika strategier. Alla har sina för och nackdelar och
6Sid 269, ibid
7Sid 275, ibid
påverkan på prestandan. Det är också här den logiska uppbyggnaden av synkroniseringsmodellen måste fastställas (se gärna bilaga 1 ”Flödesschema”).
2.3 Forskningsprocess
Vår forskningsprocess kretsar kring en iterativ process där vi med hjälp av litteraturen och intervjuer kan undersöka ett steg i taget av synkroniseringsprocessen och identifiera vilka olika angreppsätt som är möjliga samt vilka som resulterar i bästa prestanda och tillförlitlighet.
Fas 1.
• Datainsamling i form av litteraturstudie.
• Programmering.
• Möte med handledare.
Fas 2.
• Intervju med Fredrik Åhlund, Mimer.
• Programmering forts.
• Möte med handledare.
Fas 3.
• Kritisk granskning av det insamlade materialet. Analys och kategorisering.
• Programmering forts.
• Möte med handledare.
Fas 4.
• Utvärdering datainsamling från programmering.
• Fortsatt litteraturstudie.
• Fortsatt Programmering.
Fas 5.
• Sammanställning av rapport samt inlämning.
De olika faserna överlappar givetvis varandra i viss mån, men denna process har utformats
för att vara iterativ och fortgående utan avbrott.
3 Teori
3.1 Plattformarna
3.1.1 MySQL
MySQL är en relationell databasserver som släpptes 1996, det var ett open source-‐projekt som utvecklades på en konsultfirma i Sverige. 2001 bildade man ett helt eget bolag kring produkten, som då hunnit blivit väldigt populär världen över.
8Idag är det världens mest använda databasserver. Relationella databaser överhuvudtaget är överlägset det vanligaste alternativet för att lagra data idag. En relationell databas lagrar data i tabeller med kolumner och rader, tabellerna kan i sin tur innehålla länkar (”foreign keys”), eller ha förhållande till (”relationships”), andra tabeller i databasen.
9MySQL finns till i princip alla de vanligaste plattformarna och har API med stöd för en rad vanliga programmeringsspråk som till exempel C, C++, Java och PHP för att nämna några.
1I vårt projekt har vi använt PHP för att hantera databasen.
Det främsta målet med MySQL har alltid varit nå så hög prestanda som möjligt. Några metoder som MySQL använder är bland annat indexering av textsträngar och ”cachning”
(Stored procedures) av databasfrågor, vilket har gjort det avsevärt snabbare att hämta data ur databasen.
83.1.2 SQLite
SQLite är en enklare databas koncentrerad till en enda fil. All data behandlas och lagras direkt på denna fil, istället för en server. Behörigheter för åtkomst kan därmed även kontrolleras genom att konfigurera läs-‐ respektive skrivrättigheter för den databasfilen.
Förutsatt att operativsystemet har dessa funktioner.
9Fokus ligger på att göra databasen så kompakt, resursbesparande och enkel att administrera som möjligt. Men ändå erbjuda samma huvudsakliga funktionalitet som en de större konkurrenterna som till exempel, ovan beskrivet, MySQL.
10SQLite är gratis, open source och stödjs både i Android och iOS.
3.1.3 iOS
Apple utvecklade iOS som plattform till deras smartphone iPhone, som debuterade på smartphone-‐marknaden i sin första version 2007. Till skillnad från konkurrenterna hade iOS utelämnat en del funktioner, till fördel för ett nytänkande, attraktivt och responsivt gränssnitt som tilltalade en ny målgrupp som inte tidigare intresserat sig för smartphones.
8 Sid 573, Beginning PHP and MySQL 5, W. Gilmore
9 Sid 6, Beginning MySQL, Sheldon, Robert Moes, Geoff
10 Sid 535, Beginning PHP and MySQL 5, W. Gilmore
Därefter har iOS utvecklats med fler funktioner och till att stödja flera av Apples produkter som exempelvis, iPad och iPod.
11Applikationer för iOS skrivs i programmeringsspråket Objective-‐C i Apples egna IDE Xcode.
För att testa egenutvecklade applikationer på en fysisk enhet krävs dock ett utvecklarmedlemskap hos Apple. Applikationer distribueras via Apples ”App Store”, där samtliga applikationer är publicerade av utvecklare med medlemskap hos Apple. Dessutom genomgår alla applikationer en kvalitetskontroll innan de publiceras i ”App Store” för att säkerställa användarupplevelse, designriktlinjer och att enhetens resurser används på ett korrekt sätt.
12Enligt statistik från Gartner hade iOS i kvartal tre 2011 en marknadsandel på 15%. Vilket är något sämre än samma period i fjol. Nedgången beror dock inte på sämre försäljningssiffror utan snarare på Androids framgångar (beskrivet nedan).
113.1.4 Android
Android Inc. grundades av Andy Rubin och är ett mobilt operativsystem med öppen källkod som blev uppköpt av Google 2005. Det lanserades officiellt av Google i november i 2007.
13Det är skrivet i Java, således är även alla applikationer för plattformen skrivna i java, men är i botten baserat på en Linuxkärna. Google tillhandahåller ett SDK-‐plugin för Eclipse, som är den IDE som Google rekommenderar vid utveckling för Android. Applikationer publiceras av registrerade utvecklade i Googles egna Android Market, men applikationer kan även installeras från andra källor om användaren tillåter det.
HTC blev den första tillverkaren att sälja telefoner med Android när de lanserade telefonen
”Dream” i oktober 2008. Idag säljer även tillverkare som Samsung, Motorola, LG och Sony Ericsson telefoner med Android för att nämna några.
Plattformens popularitet har vuxit avsevärt sedan dess lansering; I december 2010 annonserade Andy Rubin på sin Twitter att 300 000 stycken Android-‐telefoner aktiveras varje dag. I december 2011 hade den siffran växt till 700 000 per dag
14. Enligt en rapport från statistikföretaget Gartner som publicerades i tredje kvartalet 2011 så stod Android för 52,5%
av smartphone marknaden.
15Android har inbyggt stöd för SQLite.
11 http://www.apple.com
12 Sid 8-‐9. Porting an iOS Application to the Android OS Platform, Björn Olsson
13 Sid 5, Android : A Programmer's Guide, DiMarzio, Jerome
14 http://twitter.com/#!/Arubin
15 http://www.gartner.com/it/page.jsp?id=1848514
3.2 Synkronisering
Synkronisering är processen att upprätthålla datakonsistens mellan olika målenheter.
Synkronisering av databaser är alltså processen att få databaser som existerar på olika plattformar att spegla samma data. I denna uppsats kommer vi fokusera på synkronisering mellan databaser vilket innebär en icke-‐realtids-‐synkronisering där en eller flera enheter kan frikopplade från nätverket, bearbeta data och sedan koppla upp för att synkronisera denna data med övriga enheter.
16I Synkroniseringsprotokollet SyncML’s white paper definierar man denna process på detta sätt:
“This reconciliation operation – where updates are exchanged and conflicts are resolved – is known as data synchronization.”
17Denna process kan utformas på flertalet olika sätt. En av de viktigaste delarna i synkroniseringsprocessen är att identifiera hur många enheter data skall synkroniseras mellan. Förhållandet ett-‐till-‐ett är ett vanligt sätt at synkronisera databaser. Mobiltelefoner eller PDA’s kopplas in till datorn för att synkronisera dess kontakter, email etc.
Synkronisering kan dock innehålla flera enheter som skall synkroniseras mot en server, användaren kan t.ex. ha en mobiltelefon och en läsplatta som båda skall synkroniseras mot en laptop för att spegla samma data. Det finns även fall där man vill synkronisera flera enheter mot flera enheter. Detta är ett mer komplicerat fall av synkronisering och faller ofta under en ”Peer-‐To-‐Peer”-‐modell.
Synkronisering kan delas in i två kategorier. Realtidssynkronisering och icke realtidsynkronisering. Realtidssynkroniseringen kräver en ständig uppkoppling mellan enheterna och erbjuder därmed också bästa möjliga dataintegritet mellan enheterna. Den icke realtidsbaserade synkroniseringen synkroniserar data när användaren själv vill eller enligt ett förbestämt schema. Eftersom vårt fokus i denna uppsats dock ligger på synkronisering mellan mobila databaser så kommer detta att implementera effektivast med en icke realtidsbaserad synkronisering då man inte kan garantera mobilernas uppkoppling mot internet. En icke-‐realtidsbaserad synkronisering resulterar även i många andra fördelar i en mobil miljö då man med denna implementation kan skapa effektiva synkroniseringsscheman baserat på mobilens begränsade resurser.
I artikeln ”Synchronizing a database to Improve Freshness” skriver man att synkronisering av databaser i många fall är något som är nödvändigt för att kunna förbättra prestanda och tillgänglighet i applikationen. I detta fall talar man om sökmotorer och hur dessa måste hålla sig synkroniserade med de websidor som existerar på internet för att reflektera korrekta och
16 Sid 1517, Fast PDA Synchronization Using Characteristic Polynomial Interpolation, Ari Trachtenberg, David Starobinski, Sachin Agarwal, IEEE INFOCOM (2002)
17 Building an Industry-‐Wide Mobile Data Synchronization Protocol, SyncML WhitePaper (2011), sid 3
uppdaterade länkar till sidorna. Idag tar det upp till sex månader för en ny hemsida att registreras på de populära sökmotorerna och cirka 14 % av alla länkar i sökmotorerna är felaktiga, vilket visar på vikten vid en fungerande synkronisering i dessa sammanhang.
18Att mäta hur pass ”ny” data är blir i dessa sammanhang ofta ett problem. Hur skall man identifiera när en hemsida exempelvis har uppdaterats?
När synkronisering skall ske mellan två datakällor måste följande punkter hanteras
19:
• Synkroniseringsfrekvens
Vi bestämmer först hur ofta vi skall synkronisera den lokala databasen. Skall detta ske varje gång applikationen startas? Varje gång någon rad i den lokala databasen förändras? Eller vid regelbundna tidpunkter? Givetvis vill vi ha så uppdaterad data som möjligt i vår databas, men detta måste vägas mot tidsåtgång och resurshantering när vi talar om en mobil miljö.
• Resursallokering
Skall alla element i databasen synkroniseras vid samma intervall? Om vi vet att vissa tabeller uppdateras oftare så skall synkroniseringen av dessa tabeller förslagsvis ske oftare? I detta fall kan avancerade algoritmer implementeras som räknar ut hur ofta denna rad/information uppdateras och bestämma synkroniseringsintervallen av detta element beroende på hur ofta informationen förändras.
• Synkroniseringsordning
Vi måste också identifiera i vilken ordning vi skall synkronisera elementen.
Vissa element är möjligtvis beroende av att andra element är uppdaterade för att informationen inte skall bli korrupt. Ett exempel på detta är i relationella databaser.
Vi måste se till att alla separata element inblandade i en relation är synkroniserade före vi kan synkronisera förändringar i själva relationen.
Exempel:
Vi har en tabell som heter böcker. Denna har följande kolumner:
• Titel
• Utgivningsår
• Författare (Ett många-‐till-‐många förhållande mot Författare-‐tabellen.)
18 Synchronizing a database to Improve Freshness (Stanford)(1999)
19
ibid
Om det har lagts till en författare i denna relation som ännu inte existerar i den lokala databasen så måste denna författare synkroniseras och läggas till i den lokala databasen före relationen kan läggas till i boktabellen (Eller den länkade många-‐till-‐många tabellen) databasen. Det är också viktigt att se till att CRUD (Create, Read, Update, Delete) utförs i rätt ordning då dessa operationer måste ske i rätt ordning för att garantera integriteten i synkroniseringen. Allt detta gör ordningsföljden till en viktig komponent för en fungerande synkronisering.
• Synkroniseringstidpunkt
Denna punkt skall bestämmas i korrelation med bestämmelse av synkroniseringsfrekvensen. Vinner vi något på att endast utföra synkroniseringen vid utvalda tidpunkter? Om vår synkronisering t.ex. indexerar hemsidor till en sökmotor så kan det vara en prestandavinst att synkroniseringen av hemsidorna sker på natten, då belastningen på dessa sidor antagligen är mindre.
Dessa punkter kan alla användas för att räkna ut hur ”uppdaterad” vår lokala databas är i förhållande till vår källa. Från detta kan vi ställa in vår synkronisering för att kunna
”garantera” en viss nivå av ”freshness”.
203.2.2 Synkronisering i en mobil miljö
Att synkronisera databaser i en mobil miljö gör processen än mer avancerad. Mobiler har inte samma förutsättningar som stationära datorer, vilket innebär att man måste planera de steg som beskrevs i stycket innan med detta i åtanke. Här tänkte vi lista några av de mobilspecifika begränsningar som påverkar synkroniseringsprocessen.
• Beräkningskapacitet
I litteraturen påpekas ofta att mobiler/PDA inte har samma beräkningskapacitet som stationära datorer.
21Även om detta ofta är sant, så har de senaste årens utveckling inom det mobila fältet medfört att vi idag har mobiler som ofta är lika kraftfulla som datorerna var för endast några år sedan.
22Beräkningen av synkroniseringsprocessen skulle därmed kunna spridas över alla enheter inblandade för att få en mer balanserad belastning. Det viktiga i denna punkt är dock att vara medveten om vilken beräkningskapacitet som kommer finnas på de olika enheterna som är inblandade i synkroniseringen och göra beslut om vart beräkningen skall äga rum baserat på
20 Synchronizing a database to Improve Freshness (Stanford)(1999)
21 A Database Synchronization Algorithm for Mobile Devices (IEEE Transactions on Consumer Electronics, Vol.
56, No. 2, May 2010)
22 Intervju Mimer
detta. Den långsamma synkroniseringsmodellen (Se nedan) är nästan alltid bäst på denna punkt då den nästan inte kräver någon sort beräkning.
23• Trådlös nätverksanslutning.
De flesta mobiler ansluter idag med hjälp av GSM eller 3G till internet. Även då 3G-‐
nätverket idag har hastigheter för nedladdning som motsvarar ett vanligt hemmabredband (5 – 10mbit/s) så är Accesstiderna/Latency på 3G-‐nätet ännu väldigt höga.
24Detta innebär att synkroniseringen hellre bör överföra en större mängd data vid enstaka tillfällen än att överföra samma mängd data i ett flertal nätverksanrop. I artikeln ”Latency in Broad-‐band Mobile Networks” sammanfattar man detta på följande vis:
”How can sensitivity to latency be quantified? For example: if a large amount of data is sent over a period of 2 seconds, with a typical latency of 100ms, then quite
probably the latency here isn't very noticeable, but if instead it were a smaller amount of data sent and it were to takes 0,01ms, then the latency is more than the transmission time.”
25Figur 1
Det kan dock också vara ett problem att upprätthålla en uppkoppling under lång tid över det mobila nätverket, så även här måste alltså synkroniseringen byggas för att inte göra för många anrop till servern och samtidigt inte för få/stora anrop och därmed tappa sin uppkoppling. En synkronisering bör även stäva efter att använda så lite metadata som
23 On the Scalability of Data Synchronization Protocols for PDAs and Mobile Devices, S. Agarwal, D. Starobinski, A. Trachtenberg, Department of Electrical and Computer Engineering Boston University, IEEE (2002).
24 Latency in Broad-‐band Mobile Networks, lara Serrano, Beatriz Garriga, Julia Velasco, Julio Urbano, Santiago Tenorio and Manuel Sierra 3G Radio Product Vodafone Group Networks, Madrid, Spain.
25 ibid
möjligt för självaste synkroniseringen för att hålla nere storleken för anropen, baslinjen för denna mätning bör vara den teoretiskt minsta möjliga storlek som krävs. Nedan beskrivna CPISync är en algoritm som är inriktad på detta och ligger nära den teoretiskt lägsta gränsen.
26• Strömförbrukning
Mobiltelefoner drivs idag av batteri och detta är förmodligen enhetens mest värdefulla resurs. Synkroniseringsfrekvensen och Synkroniseringstidpunkten måste därför anpassas med energiåtgång i åtanke. Att koppla upp mot Internet är väldigt kostsamt i strömförbrukning och bör därför göras endast i de intervaller detta krävs.
• Specifika Plattformsbegränsningar
I förhållande till de tidigare punkterna bör också påpekas att en av de plattformar vi i denna uppsats valt att koncentrera oss på, iOS, inte tillåter implementeringen av synkroniseringen att utföras på samma sätt som på de andra plattformarna. Med just de punkter vi just nämnt i åtanke har Apple begränsat användningen av exempelvis bakgrundsprocesser. En viktig försäljningspunkt på de moderna mobilerna är exempelvis batteritid. Det ligger därför i tillverkarnas intresse att begränsa utvecklares förmåga att använda hårdvaran när enheten exempelvis är i vila. Ett flertal pressartiklar om detta har hittats, dock ej några vetenskapliga sådana.
27iOS har även den begränsningen att inte kan byta ut den underliggande databasen i själva telefonen utan man har som utvecklare endast tillgång till sin egen applikation (s.k sandboxing).
2829
30
• Nätverksstorlek
Nätverksstorlek syftar på hur väl synkroniseringsmetoden kan skala till fler enheter.
Den mobila miljöns begränsningar ställer hårdare krav på synkroniseringsprocessen och det är därför viktigt att veta hur väl modellen skalar när ett flertal enheter används i synkroniseringen. I detta hänseende fungerar inte den snabba synkroniseringsmetoden överhuvudtaget (Se nedan) då den endast kan rymma två enheter.
26 On the Scalability of Data Synchronization Protocols for PDAs and Mobile Devices, S. Agarwal, D. Starobinski, A. Trachtenberg, Department of Electrical and Computer Engineering Boston University, IEEE (2002).
27 http://www.pcworld.com/article/199528/multitasking_with_ios_4_is_horrible_apple_blew_it.html
28http://developer.apple.com/library/ios/#documentation/Security/Conceptual/Security_Overview/Conc epts/Concepts.html#//apple_ref/doc/uid/TP30000976-CH203-SW1
29 The Apple Sandbox
30 Mimer intervju
3.2.2 Synkroniseringsmodeller
De flesta stora aktörer inom databas-‐branschen erbjuder idag egna lösningar på synkronisering mellan databaser, dessa är dock byggda för att fungera endast mot den egna plattformen.
31Fokusen i denna uppsats är på lösningar som fungerar över multipla plattformar, så dessa tekniker kommer inte vara aktuella för uppsatsen. Nedan redovisar vi istället de alternativ till synkronisering mellan multipla plattformar som presenterats i litteraturen. Man kan säga att alla dessa bygger på antingen en långsam eller snabb synkroniseringsmodell (Båda beskrivna nedan.). Vi vill presentera denna teori då valet av tekniken bakom vår egen implementering finner sin grund i dessa tekniker.
3.2.3 Snabb synkronisering
Snabb synkronisering kan användas när förhållandet för databassynkroniseringen är ett-‐till-‐
ett. En mobiltelefon som alltid synkas mot samma dator exempelvis. Om användaren i detta fall lägger till något i databasen på mobiltelefonen så kan denna rad markeras med en flagga för att visa att raden behövs synkroniseras. Denna modell är ofta använd när synkronisering mellan två enheter implementeras då den är effektiv och enkel att implementera. Den har dock stora begräsningar och kan inte skalas till större nätverk av enheter.
323.2.4Flaggor
Snabb synkronisering kan implementeras med hjälp av flaggor. Med flaggor kan man
”flagga” att en rad i databasen har blivit uppdaterad men inte än synkroniserats. Detta kan utföras med en enkelt boolesk etta eller nolla på liknande sätt.
31 http://www.red-‐gate.com/products/sql-‐development/sql-‐comparison-‐sdk/learn-‐more/synchronizing-‐
databases
32
Database synchronization between devices, A new synchronization protocol for SQLite databases, Shitian Long, KTH Stockholm Sweden (2011)
Figur 2. Synkronisering med hjälp av flaggor.
När en rad i databasen redigeras ändras denna flagga till en etta, som i detta fall indikerar på att databasen behövs synkroniseras, efter synkroniseringen genomförts sätts denna flagga tillbaka till noll. Denna lösning fungerar på mindre databaser, men blir problematisk när exempelvis samma rad har uppdaterats på både målenheten och i källan. Flaggorna blir inte heller möjliga att använda i annat än ett-‐till-‐ett synkroniseringsscenario. En fördel med att använda flaggor är att dessa kan ta mindre minnesplats än en lösning som är baserad på exempelvis tidsstämplar.
När synkroniseringen genomförs så skickas alla de markerade raderna till datorn för att antingen läggas till, tas bort eller uppdateras i datorns databas. Denna synkroniseringsmodell skickar alltså endast de rader som markerats som uppdaterade till servern. Modellen går dock inte att använda när man har fler enheter som skall synkroniseras då flaggorna efter en synkronisering blir nollställda. I dessa fall måste man istället använda sig av en långsam synkroniseringsprocess.
3.2.5 Långsam synkronisering
Om antalet målenheter eller källenheter är fler än en och mer än en ändring i taget är tillåtet
så måste man använda sig av den långsamma synkroniseringsmodellen. Denna
synkroniseringsmodell jämför hela databasen på målenheten med hela databasen på källan
för att identifiera vad som behövs uppdateras. Detta gör att både bandbreddsåtgång och
beräkningsresurser ökar avsevärt med den långsamma synkroniseringsmodellen. Till skillnad
från den snabba synkroniseringsmodellen så ökar tidsåtgången linjärt med mängden data.
För långsam synkronisering används ofta tidstämplar, hashsummor eller algebraiska algoritmer.
3.2.6 Timestamps (Tidsstämplar)
En synkroniseringstidsstämpel är en vanlig lösning för att markera att en databas har blivit
uppdaterad. Detta utförs genom att lägga till en extra kolumn i databasen som uppdateras
till tidpunkten då data redigerades. Raderna i en tabell kan således jämföras mot servern
genom att jämföra dessa tidsstämplar. Om målenhetens rad har en nyare tidstämpel än
källan så vet man att källan behöver hämta hela denna rad från målenheten. Denna lösning
har många fördelar. För det första så brukar tid finnas som datatyp i de flesta databaser och
kan därför enkelt implementeras som en extra kolumn. Lösningen möjliggör även
identifiering av flera uppdateringar av samma data. Om man exempelvis har tre enheter som
är uppkopplade mot samma server och alla redigerat samma rad i databasen, så kan servern
enkelt identifiera i vilken följd dessa uppdateringar gjordes för att således kunna uppdatera
dess egen data i samma ordning och sedan sätta ännu en nyare tidstämpel i den bearbetade
raden för att signalera enheterna om att denna rads uppdateringar nu sammanfogats till en
ny version av raden som behövs uppdateras på målenheterna. Se nedan.
Figur 3. Synkronisering med hjälp av tidsstämplar
Denna typ av synkronisering är enkel att implementera, men kan vara svår att skala upp till större nätverk med ett flertal enheter.
333.2.7 Synkroniseringsalgoritmen SAMD
SAMD är en synkroniseringsalgoritm för synkronisera en mobils databas med en servers databas. Den presenteras i artikeln ”A Database Synchronization Algorithm for Mobile Devices”. SAMD står för “Synchronization Algorithms based on Message Digest” och bygger på att ”ta en bild” på serverns databas och en bild på mobilens databas för att sedan jämföra de båda och välja ut de rader som behöver synkroniseras. Om synkronisering är nödvändig så utförs den enligt SAMDS synkroniseringspolicy. Styrkan med SAMD är att den
33 On the Scalability of Data Synchronization Protocols for PDAs and Mobile Devices, S. Agarwal, D.
Starobinski, A. Trachtenberg, Department of Electrical and Computer Engineering Boston University, IEEE (2002), pp. 7.
