[Ger­man] Daten­banken - Big Data

Der fol­gende Text ist das Re­sul­tat meiner Fachar­beit, welche ich in der 11. Klasse auf dem Gym­na­sium Ger­resheim in Düs­sel­dorf unter der Leitung von Dr. Fred­er­ick Ma­g­ata geschrieben habe. Für diese Fachar­beit habe ich 15 von 15 möglichen Punk­ten er­hal­ten.


1. Ein Überblick über die Welt der großen Datenmengen

Big Data ist ein seit 2010 in der In­for­matik sehr häu­fig ver­wen­de­ter Be­griff, speziell in Verbindung mit dem World Wide Web, welcher als Hype ange­se­hen wer­den kann. Viele Un­ternehmen wie Google, Face­book und IBM wer­ben mit “Big Data”, je­doch wird auf den er­sten Blick nicht di­rekt klar, was damit genau gemeint ist, außer dass es sich bei diesem Be­griff wohl um große Daten­men­gen han­deln muss, da – wie bei den meis­ten Hype-The­men – oft nicht mehr ob­jek­tiv über das Thema berichtet wird. In dieser Fachar­beit möchte ich ve­r­an­schaulichen, was Big Data be­deutet, welche Vorteile durch die Ver­wen­dung von Big Data-Tech­nolo­gien in neuen Pro­jek­ten entste­hen, aber auch, welche Her­aus­forderun­gen in diesem Zusam­men­hang be­wältigt wer­den müssen. Nach der De­f­i­n­i­tion des Be­griffes “Big Data” werde ich An­wen­dungs­fälle an­hand zweier Pro­jekt-Beispiele aus der Ver­gan­gen­heit und der Gegen­wart zeigen und er­läutern, in­wiefern diese als Big Data-Pro­jekte ange­se­hen wer­den kön­nen. Ich werde den Fokus dieser Fachar­beit auf die Daten­banksys­teme legen, welche zur Spe­icherung der großen Daten­men­gen ver­wen­det wer­den kön­nen. Im Hin­blick auf die Menge der frei ver­füg­baren Daten­banksys­teme möchte ich zeigen, wie sich diese am besten un­terteilen lassen und welches Sys­tem für welches Big Data-Pro­jekte am besten geeignet ist. Dafür werde ich ein Pro­gramm schreiben, welches die bei­den be­liebtesten Daten­banksys­teme MySQL und Mon­goDB au­toma­tisiert hin­sichtlich der Ef­fizienz bei den bei­den wichtig­sten Op­er­a­tio­nen – das Ein­fü­gen und Ausle­sen von vie­len Daten – testet und die Ergeb­nisse auswertet. Zur Verdeut­lichung der diesem neuen Be­griff zu­grun­deliegen­den Daten­bank­tech­nolo­gien werde ich einen Web-Crawler schreiben, in welchem ich alle grundle­gen­den As­pekte von Big Data mit ein­beziehen werde und welcher die Daten­struk­turen der neueren Daten­banksys­teme ver­wen­den wird. Beide Ex­per­i­mente werde ich dieser Fachar­beit in einer virtuellen Mas­chine bei­le­gen, so­dass der Leser sie selbst erneut aus­führen und auswerten kann. Den Quell­text dieser Ex­per­i­mente werde ich unter der GPL-Lizenz on­line bere­it­stellen (siehe An­hang 2).

2. Definition des Begriffes „Big Data“

„Big Data“ – Der Be­griff selbst ist nur un­ge­nau definiert. Es gibt drei rel­a­tive Kri­te­rien, von de­nen min­destens ein Kri­terium er­füllt wer­den muss, damit Daten als „Big Data“ ange­se­hen wer­den kön­nen: Die Daten­menge (Vol­ume), die Geschwindigkeit der Daten (Ve­loc­ity) und die Vielfalt der Daten (Va­ri­ety). Diese drei Kri­te­rien wer­den auch als die drei „V“ beze­ich­net.

2.1. Die Datenmenge (Volume)

Unter dem Be­griff „Vol­ume“ ver­steht man, welche Menge an Daten in einer Daten­bank gespe­ichert wird. Wer­den in einer Daten­bank viele Daten gespe­ichert – genauer ist dies nicht definiert –, so ist dieses Kri­terium er­füllt. Wer­den z.B. in einer Daten­bank 1.000.000 Daten­sätze gespe­ichert, so kön­nte man bere­its sagen, dass das Kri­terium er­füllt ist. Ver­gle­icht man die Menge der Daten­sätze je­doch beispiel­sweise mit den knapp 845 Mio. ak­tiven Be­nutzern, die bei Face­book reg­istri­ert sind, sprich den min­destens 845 Mio. Daten­sätzen die da­her bei Face­book gespe­ichert wer­den müssen, so scheinen un­sere eine Mil­lio­nen Daten­sätze nicht mehr al­lzu viel zu sein. Was unter „viel“ ver­standen wer­den kann sei also der In­ter­pre­ta­tion des Lesers über­lassen, Menge ist in diesem Fall rel­a­tiv und hängt von der Aus­gangssi­t­u­a­tion ab.[3]

2.2. Die Geschwindigkeit der Daten (Velocity)

Der Be­griff „Ve­loc­ity“ beschreibt die Geschwindigkeit in welcher Daten im Server ein­tr­e­f­fen und ve­r­ar­beitet wer­den müssen. Tr­e­f­fen Daten im Server so schnell ein, dass er mit der Ve­r­ar­beitung dieser in Echtzeit an seine Gren­zen kommt, ist dieses Kri­terium er­füllt. Je­doch ex­istiert auch hier keine genaue De­f­i­n­i­tion, ab welcher Datengeschwindigkeit dieses Kri­terium er­füllt ist. Ein han­del­süblicher Com­puter wäre natür­lich nicht dazu in der Lage, Daten in der sel­ben Geschwindigkeit zu ve­r­ar­beiten wie beispiel­sweise ein Su­per­com­puter oder ein Com­puter-Clus­ter. Um auf das Beispiel Face­book zurück­zu­greifen, lassen sich hier die abgegebe­nen Likes als Beispiel nehmen. Täglich wer­den von den reg­istri­erten Be­nutzern ca. 1,2 Mrd. Likes abgegeben. Das sind durch­schnit­tlich ca. 13.889 Likes pro Sekunde, die in den Da­ten­cen­tern abge­spe­ichert und ve­r­ar­beitet wer­den müssen. Mit dieser An­zahl von An­fra­gen pro Sekunde wäre ein han­del­süblicher Com­puter maß­los über­lastet. Für die Com­puter, die bei Face­book, Inc. die An­fra­gen übernehmen ist diese An­zahl je­doch nicht beson­ders groß. Auch hier kommt es wieder auf den An­wen­dungs­fall an, ab wann das Kri­terium er­füllt ist.

2.3. Die Vielfalt der Daten (Variety)

Bei Big Data kommt es nicht unbe­d­ingt nur auf die Größe oder Geschwindigkeit der Daten an. Die Vielfalt der Quellen aus de­nen Daten gesam­melt und ve­r­ar­beitet wer­den und die Vielfalt der Daten­for­mate selbst, spielt eben­falls eine wichtige Rolle und be­d­ingt das Kri­terium „Va­ri­ety“. Nehmen wir als Beispiel wieder Face­book. Be­nutzer kön­nen hier Daten in Form von Text (Posts) spe­ich­ern, je­doch auch Fo­tos und Videos von ihrem Smart­phone aus hochladen, Links zu Web­sites teilen und ihren ak­tuellen Stan­dort veröf­fentlichen. Zusät­zlich dazu kön­nen sie sich mit an­deren Nutzern über den in­te­gri­erten Chat aus­tauschen. Alle diese Daten müssen von den Servern ve­r­ar­beitet und gespe­ichert wer­den, haben je­doch un­ter­schiedliche For­mate. Die Schwierigkeit besteht nun darin, die Daten so anzu­passen, dass sie struk­turi­ert und für die spätere Ve­r­ar­beitung und Analyse geeignet auf den Servern gespe­ichert wer­den kön­nen.

3. Anwendungsbeispiele für Big Data

Big Data Pro­jekte gibt es viele – sowohl on­line als auch of­fline. Im Fol­gen­den möchte ich zwei dieser Pro­jekte vorstellen.

3.1. Anwendungsbeispiel aus der Vergangenheit: Die amerikanische Volkszählung im Jahr 1890

Eines der er­sten Pro­jekte, die man bere­its als Big Data Pro­jekt beze­ich­nen kann, wurde im Jahr 1890 ge­plant und aus­ge­führt: Die amerikanis­che Volk­szäh­lung sollte das er­ste Mal durch Maschi­nen un­ter­stützt und beschle­u­nigt wer­den. Die Volk­szäh­lung aus dem Jahr 1880 sollte knapp 8 Jahre lang dauern, so­dass Her­man Hol­lerith, ein amerikanis­cher In­ge­nieur, ver­suchte, einen Weg zu finden, mit dem sich die Daten der Volk­szäh­lung ein­facher ve­r­ar­beiten lassen wür­den. Seine Idee be­stand darin, die Daten in Form von Lochkarten zu er­fassen, die sich durch seine Mas­chine später ausle­sen lassen wür­den. Der Auf­bau dieser Mas­chine ist sowohl ein­fach als auch ge­nial. Die Lochkarten wer­den durch kleine Met­al­lköpfe aus­ge­le­sen. Passt ein Met­al­lkopf durch ein Loch, so kommt er mit dem unter der Lochkarte liegen­den Gegen­stück in Kon­takt, so­dass der Strom an dieser Stelle fließen kann. Dadurch wird ein Zählmech­a­nis­mus ak­tiviert und die entsprechende Zahl um 1 er­höht. Mith­ilfe dieser Mas­chine kon­nte die Auswer­tung der Frage­bö­gen von ca. 63 Mil­lio­nen Bürg­ern, die jew­eils Daten zu 55 un­ter­schiedlichen Fra­gen bein­hal­teten, in knapp zwei Jahren fer­tiggestellt wer­den. Auch wenn die Kri­te­rien „Ve­loc­ity“ und „Va­ri­ety“ nicht er­füllt sind, kann dieses Pro­jekt alleine durch das riesige Daten­vol­u­men als Big Data Pro­jekt ange­se­hen wer­den.

3.2. Anwendungsbeispiel aus der Gegenwart: Google

Google ist die weltweit mit Ab­stand am meis­ten genutzte Such­mas­chine. Ange­fan­gen als ein Stu­den­ten­pro­jekt na­mens Back­Rub im Jahr 1996 en­thält die von Google ver­wen­dete und selbst en­twick­elte Daten­bank BigTable mit­tler­weile über eine Bil­lio­nen Links zu un­ter­schiedlichen Web­seiten. Da Googles Daten­bank durchgängig durch Googles eige­nen Crawler Google­bot ak­tu­al­isiert wird, welcher mith­ilfe „eine[r] gewaltige[n] An­zahl von Com­put­ern“ täglich mehrere Mil­liar­den Web­sites in­diziert, ist das Kri­terium „Ve­loc­ity“ er­füllt. Neben der ur­sprünglichen Such­mas­chine bi­etet Google heute zusät­zlich viele weit­ere Ser­vices, wie z.B. das Video­por­tal YouTube, das soziale Net­zw­erk Google+, den E-Mail Ser­vice Google Mail, den Stream­ing-Di­enst Google Mu­sic und das Wer­benet­zw­erk Ad­Words an, welche ähn­lich große Daten­men­gen wie die Such­mas­chine selbst erzeu­gen. So wer­den auf YouTube beispiel­sweise jede Minute ca. 100 Stun­den an neuem Video­ma­te­r­ial hochge­laden, die ve­r­ar­beitet und dem In­dex hinzuge­fügt wer­den müssen. Zusät­zlich dazu en­twick­elt Google ak­tiv das auf vie­len Smart­phones ver­wen­dete Be­trieb­ssys­tem An­droid, welches über den Google Ac­count eines Users alle wichti­gen Daten mit den Google Ser­vices syn­chro­nisieren kann. Die Kri­te­rien „Vol­ume“ und „Va­ri­ety“ sind bei bei diesem Un­ternehmen durch die hohe An­zahl an un­ter­schiedlichen Ser­vices, welche jew­eils un­ter­schiedliche Daten erzeu­gen und die Größe der Daten­banken, eben­falls er­füllt. Durch die riesi­gen Men­gen an Daten, die Google durch ihre eige­nen Ser­vices zur Ver­fü­gung ste­hen, wäre es für das Un­ternehmen the­o­retisch möglich, von den meis­ten Be­nutzern ein voll­ständi­ges Pro­fil zu er­stellen. Hier stößt Google teil­weise auf laute Kri­tik. Auch wenn Googles Motto „Don’t be evil“ lautet, kön­nen diese Daten, ger­aten sie in falsche Hände, sehr wohl zu „bösen“ Zwecken einge­setzt wer­den. Durch die veröf­fentlichten Doku­mente über die NSA und deren Ko­op­er­a­tionspro­gramm Prism, durch das unter An­derem Google sehr viel Geld er­hal­ten hat, um den Daten­verkehr seiner Be­nutzer der NSA zugänglich zu machen, bestätigte sich diese Kri­tik in den let­zten Monaten bere­its.

4. Nutzen und Herausforderungen von Big Data

Angenom­men, ein Un­ternehmen hat sich dazu entsch­ieden, ein Big Data-Pro­jekt zu starten. Worin liegt der Nutzen dieser erzeugten Daten­men­gen? Nutzt man die Vorteile der großen Daten­men­gen als Un­ternehmen ziel­gerichtet, so kön­nen durch Auswer­tun­gen und Verknüp­fun­gen dieser Daten die Risiken bei Entschei­dun­gen min­imiert und Prozesse op­ti­miert wer­den. So kann ein Un­ternehmen, das Soft­ware en­twick­elt, beispiel­sweise gesam­melte Nutzungssta­tis­tiken dazu ver­wen­den, um her­auszufinden, mit welchen Bere­ichen der Soft­ware die Be­nutzer noch Schwierigkeiten haben, und diese gezielt op­ti­mieren. Ein Un­ternehmen, das in Win­dräder in­vestiert, hat z.B. durch gesam­melte Wet­ter­daten die Möglichkeit, diese so zu platzieren, dass Sie den Wind so ef­fizient wie möglich in Strom umwan­deln. Zu­dem kann mith­ilfe dieser Daten auch im Vo­raus berech­net wer­den, wie viel En­ergie ein gegebenes Win­drad in einem Zeitraum liefern wird, so­dass einge­se­hen wer­den kann, ob Ge­bi­ete in Zukunft aus­re­ichend mit Strom ver­sorgt wer­den kön­nen. Ein Un­ternehmen, das Pro­dukte verkauft, hat die Möglichkeit, an­hand der gesam­melten und analysierten Test­berichte von Käufern, sowie von Daten aus So­cial Me­dia Net­zw­erken seine Mar­ket­ingstrate­gie anzu­passen. Hier kön­nen beispiel­sweise auch gezielt einzelne Käufer ange­sprochen wer­den. An­hand des Kon­sumver­hal­tens der Kun­den ist es – vo­raus­ge­setzt, das Un­ternehmen hat genü­gend Daten in diesem Bere­ich gesam­melt – möglich, vo­rauszu­berech­nen, welche Pro­dukte dieser Kunde als näch­stes Kaufen wollen kön­nte und ihm de­mentsprechend Wer­bung zu schicken. Dies kann, wenn das Sys­tem gut en­twick­elt ist, kom­plett au­toma­tisiert geschehen. Laut einer Analyse des Har­vard Busi­ness Re­view ar­beiten Un­ternehmen, welche Big Data ein­set­zen, um Entschei­dun­gen zu tr­e­f­fen, ca. 5 Prozent pro­duk­tiver und ca. 6 Prozent prof­itabler. Auch wenn der Nutzen von Big Data-Pro­jek­ten klar sicht­bar ist, stellt die Ver­wen­dung der neuen Tech­nolo­gien für die Un­ternehmen eine neue Her­aus­forderung dar. Wie in der De­f­i­n­i­tion des Be­griffes „Big Data“ bere­its er­wähnt, muss die Soft­ware und Hard­ware zur Ver­wen­dung in Big Data-Pro­jek­ten dazu in der Lage sein, eine große Menge an Daten in einer möglichst gerin­gen Zeit zu spe­ich­ern und zu ve­r­ar­beiten. Frühere Sys­teme basierten meist auf weni­gen, sehr leis­tungsstarken Servern, die diese An­fra­gen ve­r­ar­beiten mussten. Mit der steigen­den Daten­menge wurde diese Meth­ode je­doch zu kosten­in­ten­siv. Die Ve­r­ar­beitung und Spe­icherung der Daten sollte da­her eher auf viele Server verteilt wer­den. Mit einem geeigneten Sys­tem ließen sich sowohl die Kosten min­imieren, als auch die Skalier­barkeit der Pro­jekte sich­er­stellen. Bei großen An­bi­etern wie z.B. Ama­zon lassen sich Server – bezahlt pro Stunde – mi­eten, so­dass sie je nach Be­darf zu dem Sys­tem hinzuge­fügt wer­den kön­nen. Eine be­liebte Lö­sung für diesen Ansatz ist das open-source Pro­jekt Hadoop, welches von der Apache Foun­da­tion en­twick­elt wird. Mith­ilfe dieser Soft­warelö­sung lassen sich Aufträge, wie beispiel­sweise die Ve­r­ar­beitung von Daten­sätzen in einer Daten­bank ef­fizient auf be­liebig viele Server verteilen. Zu­dem ist es wichtig, nur die Daten zu sam­meln, welche auch wirk­lich später benötigt wer­den. Diese müssen in den Daten­banken so ef­fizient struk­turi­ert wie möglich gespe­ichert wer­den, so­dass sie später gut weit­er­ver­ar­beitet wer­den kön­nen. Nun ist es nötig, den Nutzen dem Aufwand, welcher durch die Her­aus­forderun­gen bei Big Data Pro­jek­ten entsteht, ent­ge­gen­zustellen um zu entschei­den, ob es sich lohnt, ein Big Data-Pro­jekt zu starten.

5. Geeignete Datenbanksysteme

Um für Big Data Pro­jekte geeignet zu sein, sollte ein Daten­banksys­tem dazu in der Lage sein, mit den drei bere­its er­wäh­n­ten Kri­te­rien umge­hen zu kön­nen. Es soll­ten also dazu in der Lage sein, eine große Menge an Daten so zu spe­ich­ern, dass sie schnell wieder abgerufen und ve­r­ar­beitet wer­den kann. Zu­dem soll­ten die Sys­teme dazu in der Lage sein, auf mehrere Server verteilt wer­den zu kön­nen. Daten­banksys­teme lassen sich grob in zwei Kat­e­gorien un­terteilen: Re­la­tional und nicht-re­la­tional.

5.1. Relationale Datenbanksysteme (MySQL)

In re­la­tionalen Daten­banken wer­den die Daten in zwei­di­men­sion­alen Daten­struk­turen, sprich in Tabellen gespe­ichert. Die Spal­ten, oder auch At­tribute, der Tabelle geben feste Eigen­schaften des Daten­satzes an, eine Zeile, auch Tu­pel genannt, repräsen­tiert einen Daten­satz. Die er­ste Spalte in jeder Tabelle spe­ichert in den meis­ten Pro­jek­ten einen ein­deuti­gen In­dex, wie z.B. eine fort­laufende Zahl. Diese Spalte wird meis­tens als „ID“ oder „id“ beschriftet. Eine Tabelle für reg­istri­erte Kun­den kön­nte also die Spal­ten ID, Name, Vor­name, Mail und Pass­wort bein­hal­ten (siehe An­hang 3.1). Jedes At­tribut be­sitzt einen fes­ten Da­ten­typ, wie beispiel­weise einen In­te­ger oder einen String und bei den meis­ten Da­ten­typen auch eine obere Grenze für die Größe. Das At­tribut Name der oben gezeigten Beispielta­belle kön­nte z.B. als String mit einer max­i­malen Größe von 50 Ze­ichen definiert wer­den. Die re­la­tionale Daten­struk­tur hat mehrere Vorteile. Durch die feste Struk­tur der Tu­pel kann ein Pro­gramm wis­sen, mit welchen Daten es ar­beiten wird. Die Daten­sätze kön­nen zu­dem le­icht nach einem bes­timmten At­tribut sortiert und gefiltert wer­den. Viele re­la­tionale Daten­banken un­ter­stützen das Er­stellen von In­dizes über eine oder mehrere Spal­ten. Angenom­men, ein Pro­gramm muss häu­fig Be­nutzer-Tu­pel an­hand des Nach­na­mens abfra­gen, so kann auf das At­tribut „Name“ ein In­dex gesetzt wer­den. Ohne den In­dex würde das Daten­banksys­tem je­den Ein­trag in der Tabelle durch­suchen und die Ein­träge, die mit der Abfrage übere­in­stim­men, zurück­geben. Die Kom­plex­ität der Abfrage läge im schlimm­sten Falle hier bei (Siehe An­hang 3.3, Vi­o­lett). Bei kleinen Pro­jek­ten ist das kein Prob­lem, bein­hal­tet die Tabelle je­doch eine sehr große An­zahl an Daten­sätzen, wird diese Abfrage unter Um­stän­den zu lange dauern. Durch den In­dex auf dem At­tribut legt die Daten­bank in­tern einen binären Such­baum, auch Bi­na­ry­SearchTree oder BTREE genannt, über die Daten an. Die Kom­plex­ität der Abfra­gen, die nur auf dieses At­tribut zu­greifen, liegt damit auf (An­hang 3.3, Blau). Zwei häu­fig genutzte re­la­tionale Daten­banksys­teme sind MySQL von Or­cale und Poste­greSQL von der Post­greSQL Global De­vel­op­ment Group. Sie ver­wen­den zur Abfrage der Daten die Sprache SQL. Um beispiel­sweise alle Be­nutzer, deren Nach­name mit B an­fängt, nach Nach­name sortiert abzu­rufen, lässt sich der fol­gende Code ver­wen­den:

SELECT * FROM Kunden WHERE Nachname LIKE ’B%’ ORDER BY Nachname ASC
Die Nachteile der relationalen Datenbanksysteme liegen wieder in der festen Struktur der Tabellen. Ein Beispiel, warum dies ein Nachteil sein kann, sind Zuordnungen. Angenommen, einem Kunden sind mehrere Bestellungen zugeordnet, welche wieder eigene Attribute besitzen, so muss für diese Bestellungen eine weitere Tabelle angelegt werden, die ein Attribut enthält, in dem die ID des Kunden gespeichert wird. So kann eine 1-zu-n Beziehung hergestellt werden. Soll diese Bestellung nun aus mehreren Produkten bestehen, welche ebenfalls jeweils eigene Attribute besitzen, so müssen zwei weitere Tabellen angelegt werden: Eine Tabelle, die alle Produkte mit ihren Attributen enthält und eine Tabelle, welche die Zuordnung der Produkte zu den Bestellungen enthält. So kann eine n-zu-n Beziehung hergestellt werden, sprich beliebig viele Produkte können beliebig vielen Bestellungen zugeordnet werden. Die fertigen Tabellen mit ihren Zuordnungen könnten so aussehen, wie die Abbildung in Anhang 3.2. Ein weiteres Problem an den festen, tabellenartigen Strukturen besteht darin, dass sich hierarchische Strukturen nicht ohne weiteres speichern lassen. Sollen Beispielsweise Produktkategorien mit jeweils beliebig vielen Unterkategorien gespeichert werden, so müsste eine Tabelle für die Produktkategorien angelegt werden, die ein Attribut enthält, welches jeweils die ID der übergeordneten Kategorie enthält. Nun weiß die Datenbank zwar, welche Kategorie einer anderen Kategorie übergeordnet ist, um aus diesen Daten jedoch eine echte hierarchische Struktur zu erstellen, müssen sie außerhalb der Datenbank noch einmal traversiert und dadurch in eine entsprechende Struktur umgewandelt werden. Je nachdem wie viele Kategorien es gibt, kann dies lange dauern. Probleme können zusätzlich auftreten, wenn z.B. die Wurzel der hierarchischen Struktur nicht mehr existiert.

5.2. Nicht-Relationale Datenbanksysteme (MongoDB)

Bei nicht-re­la­tionalen Daten­banksys­te­men ist die Struk­tur der zu spe­ich­ern­den Daten nicht fest­gelegt. Beispiele von nicht-re­la­tionalen Daten­banksys­te­men sind Sys­teme, in de­nen Daten in Form von Graphen oder JSON- bzw. BSON-Doku­menten, gespe­ichert wer­den, auf welche ich später weiter einge­hen werde. Beispiele dafür sind GraphDB und Mon­goDB. Eine Un­terkat­e­gorie von nicht-re­la­tionalen Daten­banksys­te­men sind so­ge­nan­nte NoSQL-Daten­banken. Diese Beze­ich­nung stammt ur­sprünglich von einer Be­we­gung gegen äl­tere Daten­banksys­teme, welche auf die An­frage­sprache SQL set­zen. Ein großes Merk­mal vieler NoSQL-Sys­teme ist der Ver­such, die Verteilung der Daten auf viele Server so ef­fizient und sta­bil wie möglich zu gestal­ten, wie in dem Kapi­tel „Her­aus­forderun­gen von Big Data“ bere­its er­wähnt. Es gibt je­doch auch noch NoSQL-Daten­banksys­teme, in de­nen die Daten, fast wie bei re­la­tionalen Daten­banken, in Form von Tabellen gespe­ichert wer­den. Ein Beispiel dafür ist das Sys­tem Hy­per­table, welches auf Googles BigTable Daten­struk­tur basiert. Der Un­ter­schied zu re­la­tionalen Daten­struk­turen besteht hier darin, dass jede Zeile zusät­zlich zu den im Vorhinein fest­gelegten At­tributen be­liebig viele zusät­zliche At­tribute be­sitzen kann. Da das Spek­trum der nicht-re­la­tionalen Daten­banksys­teme die Ka­paz­itäten der Fachar­beit über­schre­iten würde, werde mich hier mit einem der be­liebtesten Sys­teme, Mon­goDB, au­seinan­der­set­zen. Mon­goDB ist ein doku­menten-ori­en­tiertes open-source Daten­banksys­tem welches Daten in Form von BSON-Doku­menten spe­ichert. JSON ist ein Daten­for­mat, welches dazu en­twick­elt wurde, Daten in einem für Men­schen gut les­baren und für Pro­gramme schnell zu ve­r­ar­bei­t­en­den For­mat abzus­pe­ich­ern. Das For­mat basiert in seinen Grundzü­gen auf der Sprache JavaScript, nutzt je­doch nur einen Teil der ver­füg­baren Syn­tax. Die Daten wer­den in Form von Key-Value Paaren gespe­ichert, davon kön­nen in einem JSON Doku­ment be­liebig viele ex­istieren. Der Key wird durch einen String, wie z.B. ”name“ dargestellt, der Wert kann ein In­te­ger, String, Dou­ble, Boolean, aber auch ein Ar­ray oder wiederum ein an­deres JSON-Doku­ment sein. Die Da­ten­typen müssen im Gegen­satz zu de­nen in re­la­tionalen Daten­banken nicht im Vorhinein fest­gelegt wer­den. Ar­rays wer­den in eck­i­gen Klam­mern gespe­ichert, Ob­jekte, bzw. Doku­mente, wer­den mit geschweiften Klam­mern um­fasst. Ein­träge, sowie At­tribute wer­den durch Kom­mata voneinan­der ge­trennt. BSON, oder auch Bi­nary JSON, ist ein von Mon­goDB en­twick­eltes Daten­for­mat, welches auf JSON auf­baut, je­doch weit­ere Da­ten­typen in­te­gri­ert und die Daten in einem von Men­schen nicht mehr les­baren, binären For­mat spe­ichert, welches von Pro­gram­men schneller ve­r­ar­beitet wer­den kann als das JSON-For­mat. Neue Da­ten­typen sind beispiel­sweise ver­schiedene Da­tums­for­mate, binäre Daten, reg­uläre Aus­drücke und JavaScript Pro­gramm­code. Keys in BSON kön­nen im Zusam­men­hang mit Mon­goDB auch als At­tribute der Doku­mente beze­ich­net wer­den. Jedes Doku­ment in Mon­goDB er­hält beim Spe­ich­ern au­toma­tisch das At­tribut „_id“, welches einen au­toma­tisch gener­ierten Wert en­thält, mit dem sich das jew­eilige Doku­ment ein­deutig iden­ti­fizieren lässt. Dieser Wert wird bere­its vor dem Spe­ich­ern des Doku­mentes vom Client gener­iert und en­thält einen String, welcher sich aus dem ak­tuellen Zeit­stem­pel, der ID des Com­put­ers, der ID des Prozesses und einem Zäh­ler zusam­mensetzt, so­dass die Einzi­gar­tigkeit sichergestellt wird, auch wenn mehrere Clients gle­ichzeitig Doku­mente in die Daten­bank ein­fü­gen. Die BSON-Doku­mente wer­den in Mon­goDB in so­ge­nan­nten Col­lec­tions gespe­ichert, eine Daten­bank kann be­liebig viele Col­lec­tions en­thal­ten. Col­lec­tions in Mon­goDB sind also ver­gle­ich­bar mit Tabellen in re­la­tionalen Daten­banken. So kön­nte die Daten­bank für einen on­line Shop die Col­lec­tions „Pro­dukte“, „Kat­e­gorien“ und „Kun­den“ en­thal­ten. Ein BSON-Doku­ment für einen Kun­den kön­nte beispiel­sweise, wie in dem Beispiel für re­la­tionale Daten­banken, die At­tribute „Name“, „Vor­na­men“, „Mails“ und „Pass­wort“ bein­hal­ten. Die Felder „Vor­na­men“ und „Mails“ kön­nen jew­eils ein Ar­ray en­thal­ten. So kann ein Kunde be­liebig viele Vor­na­men und E-Mail Adressen ein­tra­gen. Eine E-Mail Adresse kann auch ein Ob­jekt mit mehreren At­tributen sein. So kann jede E-Mail Adresse eine Pri­or­ität en­thal­ten, oder das At­tribut, ob Newslet­ter an diese Adresse ver­schickt wer­den soll (siehe An­hang 3.4). Durch den Auf­bau der Doku­mente lassen sich auch sehr ein­fach hi­er­ar­chis­che Struk­turen spe­ich­ern. So kön­nte beispiel­sweise eine Liste der Kat­e­gorien als eine Col­lec­tion von Haup­tkat­e­gorien aufge­baut wer­den, wobei jede Kat­e­gorie das At­tribut „Un­terkat­e­gorien“ be­sitzt, welches ein Ar­ray mit den Un­terkat­e­gorien darstellt. Löscht man nun eine Haup­tkat­e­gorie, wer­den alle Un­terkat­e­gorien entsprechend mit­gelöscht. Auch die Au­flis­tung der Kat­e­gorien ist auf diese Art ein­facher, da es möglich ist, alle Kat­e­gorien inklu­sive Un­terkat­e­gorien mith­ilfe von nur einem Be­fehl abzu­rufen, was bei re­la­tionalen Daten­banksys­te­men auf­grund der Struk­tur nicht ohne Weit­eres möglich ist. Auch bei Doku­menten ist es möglich, Ref­eren­zen auf ein an­deres Doku­ment zu er­stellen. Angenom­men, je­dem Kun­den sollen, wie in dem Beispiel für re­la­tionale Daten­banken, Bestel­lun­gen zugewiesen wer­den, so kann jeder Kunde ein At­tribut „Bestel­lun­gen“ er­hal­ten, welches die ID der Bestel­lun­gen en­thält. Mon­goDB wird in diesem Fall au­toma­tisch erken­nen, dass es sich hi­er­bei um eine Ref­erenz han­delt, und die ID durch das entsprechende Ob­jekt er­set­zen. So lässt sich eine 1-zu-n, aber auch eine n-zu-n Verbindung schnell und ein­fach re­al­isieren. Es ist – wie z.B. bei MySQL – möglich, in Mon­goDB In­dizes über bes­timmte At­tribute anzule­gen, welche man oft in Abfra­gen benötigt, um die Geschwindigkeit zu op­ti­mieren. Auch hier wird in­tern ein binärer Such­baum er­stellt, was bere­its für die re­la­tionalen Daten­banken genauer er­läutert wurde. Stan­dard­mäßig liegt ein In­dex auf dem At­tribut „_id“. Mon­goDB wird mit einer an JavaScript an­gelehn­ten Sprache ges­teuert. Will man, wie bei MySQL, also alle Kun­den, sortiert nach dem Nach­na­men, abrufen, deren Nach­name mit „B“ an­fängt, so lässt sich der fol­gende Aufruf ver­wen­den:

db.kunden.find({"name": /B.*/}).sort({"name": 1})
Ein großer Vorteil von MongoDB im Hinblick auf Big Data ist die Möglichkeit, die Datenbank auf mehrere Server zu replizieren. Dafür wird ein Server als „Primary“ deklariert. Dieser Server nimmt alle Anfragen an und verarbeitet diese. Wenn sich an der Datenbank nach der Anfrage etwas geändert hat, so werden diese Änderungen auf die Datenbanken der anderen Server übertragen. Dadurch, dass nur der primäre Server Anfragen verarbeitet, wird sichergestellt, dass es keine Konflikte zwischen den Datensätzen gibt. Fällt der primäre Server nun aus – dies ist für MongoDB der Fall, wenn er länger als 10 Sekunden nicht mit den anderen Servern kommuniziert – so wird einer der sekundären Server als neuer primärer Server ausgewählt, der nun die Anfragen verarbeitet. Die Zeitspanne, für die ein solches System nicht erreichbar ist, liegt also bei maximal 10 Sekunden. Das Risiko eines Datenverlustes wird durch dieses System extrem minimiert, vor allem, wenn sich die unterschiedlichen Server an verschiedenen Orten auf der Welt befinden. Diese Replikation ist bei wenigen relationalen Datenbanken verfügbar. Bei MySQL ist so ein System beispielsweise nur mithilfe einer alternativen Version, MySQL Cluster, möglich.

5.3. Leistungsvergleich zwischen MySQL und MongoDB

Um die Leis­tung der bei­den be­liebten Daten­banken MySQL und Mon­goDB miteinan­der zu ver­gle­ichen, habe ich ein abgeschirmtes Test­szenario aufge­baut. Die bei­den Daten­banksys­teme laufen in einer virtuellen Mas­chine (Vir­tu­al­Box) und wer­den über ein selb­st­geschriebenes Python-Script au­toma­tisiert abge­fragt. Zuerst wer­den beide Sys­teme kom­plett geleert. Dadurch bleiben keine Über­reste von vorheri­gen Tests übrig, die das Ergeb­nis ver­fälschen kön­nten. Dann wird eine Liste mit einer gegebe­nen An­zahl von zufäl­li­gen Strings mit einer Länge von jew­eils 100 Ze­ichen gener­iert. Diese Liste wird nun sowohl in MySQL, als auch in Mon­goDB einge­fügt, wobei für je­den Ein­trag eine neue An­frage an die Daten­bank gestellt wird. Dies soll die Leis­tung unter einer ho­hen An­frage­fre­quenz testen. An­schließend wer­den alle hinzuge­fügten Ein­träge nacheinan­der, an­hand des zufäl­li­gen Strings, in bei­den Daten­banken gesucht – bei dem er­sten Durch­lauf, ohne dass ein In­dex auf dem String-At­tribut liegt, bei dem zweiten Durch­lauf mit einem In­dex auf diesem At­tribut. Damit kann fest­gestellt wer­den, wie gut beide Daten­banksys­teme dazu fähig sind, Ein­träge zurück­zuliefern, auch wenn die Fre­quenz der An­fra­gen sehr hoch ist. Zusät­zlich wer­den in diesem Test An­fra­gen, bei de­nen auf dem abge­fragten At­tribut schon ein In­dex liegt den An­fra­gen gegenübergestellt, bei de­nen dieser In­dex noch nicht ex­istiert. Alle Tests wer­den danach zusät­zlich mit einer neuen Verbindung pro Abfrage, also mith­ilfe von Threads, durchge­führt, so­dass die Geschwindigkeit der Daten­banken unter ho­her Aus­las­tung noch besser getestet wer­den kann. Diese Tests habe ich mit 1000, 5000, 10000 und 100000 Test-Daten­sätzen durchge­führt, alle Zeiten wur­den in Mikrosekun­den gemessen, um kle­in­ste Un­ter­schiede besser fest­stellen zu kön­nen. Bere­its bei 1000 Test-Daten­sätzen ließen sich deut­liche Un­ter­schiede zwis­chen MySQL und Mon­goDB fest­stellen. Während das Ein­fü­gen der Daten­sätze in MySQL ca. 1362 µs pro Daten­satz gedauert hat, benötigte Mon­goDB nur ca. 606 µs pro Daten­satz. Dies kann gut daran liegen, dass Mon­goDB die Daten­sätze un­ab­hängig von der An­frage in der Daten­bank spe­ichert, der Client also nicht mehr auf eine Antwort warten muss. Dies ist bei MySQL nicht der Fall – hier muss der Client warten, bis die Daten voll­ständig gespe­ichert wur­den. Dies dauert zwar länger, hat aber den Vorteil, dass Fehler beim Ein­fü­gen der Daten so­fort erkannt und be­han­delt wer­den kön­nen. Bei den Abfra­gen der einge­fügten Ein­träge aus der Daten­bank werde ich mich auf die Ergeb­nisse bei 100000 Test-Daten­sätzen beziehen, denn hier waren die Un­ter­schiede – zum einen zwis­chen der Leis­tung der bei­den Daten­banken, aber auch zwis­chen Abfra­gen, bei de­nen auf der abge­fragten Spalte bere­its ein In­dex lag und de­nen ohne In­dex auf der abge­fragten Spalte – deut­lich sicht­bar. So dauerte die Abfrage aller Ein­träge aus MySQL ohne In­dex ca. 1626 Sekun­den, sprich ca. 27 Minuten, während sie bei den Ein­trä­gen aus Mon­goDB ohne In­dex ca. 2249 Sekun­den, bzw. ca. 37 Minuten dauerte.[38] Hier ist MySQL also ef­fek­tiver als Mon­goDB. Sieht man sich die Graphen der Abfragedauer pro Ein­trag an, so erkennt man, abge­se­hen von den kleinen Schwankun­gen, einen lin­earen Anstieg der Abfragedauer. Dies lässt sich dadurch erk­lären, dass beide Daten­banken je­den Ein­trag auf die in der Abfrage gegebene Be­din­gung über­prüfen müssen, je­doch ex­plizit nur einen Ein­trag zurück­geben sollen. So wird also, wenn der er­ste Daten­satz bere­its mit den Be­din­gun­gen übere­in­stimmt, die Abfragedauer min­i­mal sein, während sie max­i­mal sein wird, wenn erst der let­zte Daten­satz auf die Be­din­gun­gen zutrifft. Die selbe Abfrage, dieses Mal je­doch mit einem In­dex auf der jew­eils abge­fragten Spalte, dauerte bei MySQL in­s­ge­samt ca. 20 Sekun­den, was knapp 80 Mal so schnell ist, wie bei der Abfrage ohne In­dex. Auch bei Mon­goDB dauerte die Abfrage in­s­ge­samt nur ca. 32 Sekun­den, was unge­fähr 71 Mal so schnell ist wie die Abfrage ohne In­dex. Hier wird bere­its der Vorteil der In­dizes deut­lich. Sieht man sich hier die Graphen der Abfragedauer pro Ein­trag an, so fällt auf, dass sich die Dauer bei den er­sten abge­fragten Ein­trä­gen nicht son­der­lich von der Dauer bei den let­zten abge­fragten Ein­trä­gen un­ter­schei­det. Dies liegt daran, dass die Daten­sätze durch das An­le­gen eines In­dexes in einem binären Such­baum gespe­ichert wer­den, was ich in dem Beispiel zu MySQL bere­its genauer er­läutert habe. Zusam­menge­fasst lässt sich sagen, dass sich MySQL in diesem Leis­tung­stest als leis­tungsstärker her­aus­gestellt hat. Da dieser Test je­doch nur die grundle­gen­den Op­er­a­tio­nen, Schreiben und Lesen von Daten­sätzen, ver­glichen hat, lässt sich mith­ilfe dieses Ergeb­nisses nicht ab­so­lut be­haupten, dass MySQL für jedes Pro­jekt die bessere Wahl ist. Hier kommt es auf viele un­ter­schiedliche Fak­toren an. Diese Vor- und Nachteile habe ich bere­its in den Beschrei­bun­gen der bei­den Daten­banken näher erörtert.

6. Fazit

Big Data-Pro­jekte eröff­nen Un­ternehmen viele neue Möglichkeiten im Bere­ich der Kostenop­ti­mierung, sei es durch die gezielte An­pas­sung von Wer­bung an Kun­den, durch die Op­ti­mierung von Stan­dorten für die beste Er­re­ich­barkeit oder durch die Min­imierung des Risikos bei In­vesti­tio­nen durch Vorher­sagen der Be­din­gun­gen. Durch das stetig wach­sende Bedürf­nis, große Daten­men­gen so spe­ich­ern zu kön­nen, dass sie schnell abgerufen und ef­fizient weit­er­ver­ar­beitet wer­den kön­nen, entste­hen viele neue Daten­banksys­teme, wie beispiel­sweise Mon­goDB und MySQL Clus­ter. Auch die Meth­o­den zur Er­höhung der Leis­tung von Servern haben sich in den let­zten Jahren von dem Prinzip, eher wenige, leis­tungsstarke Server einzuset­zen, zu dem Prinzip, die Last auf viele, schwächere Server zu verteilen, geän­dert. Dadurch ent­standen neue Sys­teme, wie z.B. Apache Hadoop. Welches der vie­len Daten­banksys­teme für ein spez­i­fis­ches Pro­jekt am besten einge­setzt wer­den soll, hängt von sehr vie­len un­ter­schiedlichen Fak­toren ab, so­dass es hier kein ab­solutes Op­ti­mum gibt. Zusam­menge­fasst lässt sich sagen, dass der Big Data Hype für die In­for­matik viele Vorteile bringt. Die Daten­spe­icherung wird stetig ef­fizien­ter, die Möglichkeiten der Analyse dieser Daten wach­sen zusam­men mit der Möglichkeit, sehr viele Daten zu spe­ich­ern und neue Daten­banksys­teme brin­gen stets neue Konzepte mit sich. Je­doch brin­gen diese neuen Tech­nolo­gien viele neue Fra­gen, wie beispiel­sweise die Frage nach der Pri­vat­sphäre der Be­nutzer, mit sich, die noch beant­wortet wer­den müssen. Diese Fra­gen re­ichen teil­weise in den ethis­chen Bere­ich hinein, eine klare Antwort da­rauf gibt es hier noch nicht.

Literaturverzeichnis

YouTube. (kein Da­tum). Sta­tis­tics. Von YouTube Press: https://​www.youtube.com/​yt/​press/​sta­tis­tics.html

An­ches­try. (07. 1890). Abgerufen am 05. 02. 2013 von 1890 United States Fed­eral Cen­sus: http://​c.an­ces­try.com/​pdf/​trees/​charts/​1890Us­Cen­sus.pdf

Ama­zon. (kein Da­tum). Ama­zon EC2 Pric­ing. Abgerufen am 08. 02. 2014 von Ama­zon Web Ser­vices: http://​aws.ama­zon.com/​ec2/​pric­ing/

Amer­i­can Mem­ory Home. (19. 04. 1895). Abgerufen am 05. 02. 2014 von Hol­lerith's elec­tronic tab­u­lat­ing ma­chine (from Rail­road Gazette): http://​mem­ory.loc.gov/​mss/​mcc/​023/​0001.jpg

Apache Hadoop. (04. 03. 2014). Wel­come to Apache Hadoop! Abgerufen am 06. 03. 2014 von Apache Hadoop: http://​hadoop.apache.org/

Blake, K. (1996). Na­tional Archives. Abgerufen am 30. 01. 2014 von "First in the Path of the Fire­men" - The Fate of the 1890 Pop­u­la­tion Cen­sus, Part 1: http://​www.archives.gov/​pub­li­ca­tions/​pro­logue/​1996/​spring/​1890-cen­sus-1.html

Brücher, C. (2013). Re­think Big Data. mitp.

Bruno, L. C. (kein Da­tum). Plate, punch card, and in­struc­tions for Her­man Hol­lerith's Elec­tric Sort­ing and Tab­u­lat­ing Ma­chine, ca. 1895. (Her­man Hol­lerith Pa­pers). Abgerufen am 30. 01. 2014 von Words and Deeds in Amer­i­can His­tory: Se­lected Doc­u­ments Cel­e­brat­ing the Man­u­script Di­vi­sion's First 100 Years: http://​mem­ory.loc.gov/​cgi-bin/​query/​r?am­mem/​mcc:@field(DO­CID+@lit(mcc/​023))))

Branck­aute, F. (15. 02. 2012). Face­book 2012 [In­fo­graphic]. Abgerufen am 24. 01. 2014 von The Blog Her­ald: http://​www.blogher­ald.com/​2012/​02/​15/​face­book-2012-in­fo­graphic/

Chaney, P. (1. 08. 2012). Un­der­stand­ing the 6 Face­book Post Types. Abgerufen am 25. 01 2014 von Prac­ti­cal Ecom­merce: http://​www.prac­ti­calecom­merce.com/​ar­ti­cles/​3680-Un­der­stand­ing-the-6-Face­book-Post-Types

Chang, F., Dean, J., Ghe­mawat, S., & Hsieh, W. C. (11. 2006). Google Re­search Pub­li­ca­tions. Abgerufen am 05. 02 2013 von Bigtable: A Dis­trib­uted Stor­age Sys­tem for Struc­tured Data: http://​re­search.google.com/​archive/​bigtable.html

Ecma In­ter­na­tional. (01. 10. 2013). The JSON Data In­ter­change For­mat. Abgerufen am 22. 02 2014 von Ecma In­ter­na­tional: http://​www.ecma-in­ter­na­tional.org/​pub­li­ca­tions/​files/​ECMA-ST/​ECMA-404.pdf

Ernst, N., Greis, F., & Thoma, J. (25. 07 2013). Glos­sar zur NSA-Af­färe. Abgerufen am 05. 02 2014 von Golem: http://​www.golem.de/​news/​glos­sar-zur-nsa-af­faere-ma­rina-prism-no­forn-scis­sors-pin­wale-sigad-us-984xn-1307-100428.html#Prism

Dum­b­ill, E. (31. 12. 2013). Big Data Va­ri­ety Means That Meta­data Mat­ters. Abgerufen am 25. 01. 2014 von Forbes: http://​www.forbes.com/​sites/​ed­ddum­bill/​2013/​12/​31/​big-data-va­ri­ety-means-that-meta­data-mat­ters/

Face­book, Inc. (01. 01. 2014). Key Facts. Von Face­book News­room: http://​news­room.fb.com/​Key-Facts

Google, Inc. (25. 07. 2008). We knew the web was big... Abgerufen am 05. 02. 2014 von Google Of­fi­cial Blog: http://​google­blog.blogspot.de/​2008/​07/​we-knew-web-was-big.html

Google, Inc. (kein Da­tum). Google Un­ternehmen. Abgerufen am 05. 02. 2014 von Un­ternehmensgeschichte im De­tail: http://​www.google.com/​about/​com­pany/​his­tory/

Google, Inc. (kein Da­tum). Google­bot. Abgerufen am 05. 02. 2014 von Google Web­mas­ter-Tools-Hilfe: https://​sup­port.google.com/​web­mas­ters/​an­swer/​182072

Hy­per­table, Inc. (kein Da­tum). Ar­chi­tec­ture | Hy­per­table - Big Data. Big Per­for­mance. Abgerufen am 18. 02. 2015 von Hy­per­table - Big Data. Big Per­for­mance: http://​hy­per­table.com/​doc­u­men­ta­tion/​ar­chi­tec­ture/

Hillyer, M. (04. 2012). Man­ag­ing hi­er­ar­chi­cal data in MySQL. Abgerufen am 22. 02. 2014 von Mike Hilly­er's Per­sonal Web­space: http://​mike­hillyer.com/​ar­ti­cles/​man­ag­ing-hi­er­ar­chi­cal-data-in-mysql/

Hor­vath, S. (2013). Ak­tueller Be­griff - Big Data. Abgerufen am 21. 01. 2014 von Deutscher Bun­destag: http://​www.bun­destag.de/​doku­mente/​analy­sen/​2013/​Big_­Data.pdf

Kersken, S. (06. 2007). Prak­tis­cher Ein­stieg in MySQL mit PHP. Abgerufen am 06. 03 2014 von O'Reilly: http://​ex­am­ples.or­eilly.de/​open­books/​pdf_ein­mysql2ger.pdf

Lemke, J. (14. 08. 2013). Google we­gen Gmail und Pri­vat­sphäre in der Kri­tik. Abgerufen am 05. 02 2014 von Win­Fu­ture: http://​win­fu­ture.de/​news,77441.html

Mad Skills GmbH. (kein Da­tum). Google-Ac­count: Der Schlüs­sel zu den Google-Di­en­sten. Abgerufen am 05. 02. 2014 von An­droid­next: http://​www.an­droid­next.de/​google-ac­count/

Mon­goDB, Inc. (2013). Data Mod­el­ing In­tro­duc­tion. Abgerufen am 22. 02. 2014 von Mon­goDB: http://​docs.mon­godb.org/​man­ual/​core/​data-mod­el­ing-in­tro­duc­tion/

Mon­goDB, Inc. (2013). Data­base Ref­er­ences. Abgerufen am 22. 02. 2014 von Mon­goDB: http://​docs.mon­godb.org/​man­ual/​ref­er­ence/​data­base-ref­er­ences/

Mon­goDB, Inc. (2013). Glos­sary. Abgerufen am 22. 02. 2014 von Mon­goDB: http://​docs.mon­godb.org/​man­ual/​ref­er­ence/​glos­sary/#​term-col­lec­tion

Mon­goDB, Inc. (2013). Sin­gle In­dexes. Abgerufen am 22. 02. 2014 von Mon­goDB: http://​docs.mon­godb.org/​man­ual/​core/​in­dex-sin­gle/

Mon­goDB, Inc. (kein Da­tum). Spec­i­fi­ca­tion - BSON. Abgerufen am 22. 02. 2014 von BSON - Bi­nary JSON: http://​bson­spec.org/#/​spec­i­fi­ca­tion

Mon­goDB, Inc. (2013). Repli­ca­tion - In­te­gra­tion. Abgerufen am 22. 02. 2014 von Mon­goDB: http://​docs.mon­godb.org/​man­ual/​core/​repli­ca­tion-in­tro­duc­tion/

Or­a­cle. (kein Da­tum). MySQL Clus­ter CGE. Abgerufen am 22. 02 2014 von MySQL: http://​www.mysql.com/​prod­ucts/​clus­ter/

Pakalski, I. (24. 08. 2013). Prism Skan­dal: NSA zahlte Face­book, Google und Mi­crosoft Mil­lio­nen­be­träge. Abgerufen am 05. 02. 2014 von Golem: http://​www.golem.de/​news/​prism-skan­dal-nsa-zahlte-face­book-google-und-mi­crosoft-mil­lio­nen­be­traege-1308-101177.html

Saake, G., Sat­tler, K.-U., & Heuer, A. (2013). Daten­banken - Konzepte und Sprachen (5. Au­flage Ausg.). mitp.

Spichale, K., & Wolff, E. (01. 2013). Big Data und zeit­gemäße Daten­ver­ar­beitung. iX De­vel­oper , S. 67-98.

Sta­tista. (2013). Mark­tan­teile der Such­maschi­nen weltweit im Sep­tem­ber 2013. Abgerufen am 05. 02. 2014 von Sta­tista: http://​de.sta­tista.com/​sta­tis­tik/​daten/​studie/​222849/​um­frage/​mark­tan­teile-der-such­maschi­nen-weltweit/

Rod­den, T. (11. 02 2014). Big Data and T's & C's. Com­put­er­phile. (S. Ri­ley, In­ter­viewer)