Push-Nachrichten von MacTechNews.de
Würden Sie gerne aktuelle Nachrichten aus der Apple-Welt direkt über Push-Nachrichten erhalten?

Apples Hochleistungsdatenbank: FoundationDB als Open Source veröffentlicht

Im Jahr 2009 wurde FoundationDB mit dem Ziel gegründet, eine schnelle, einfache und verteilte NoSQL-Datenbank zu entwickeln, die selbst bei Fehlern und Ausfällen die Datenintegrität nicht gefährdet ("ACID-Compliant").

Fast alle Apple-Dienste, wie zum Beispiel die iCloud-Photo-Bibliothek, iCloud Drive, Notizen, Erinnerung sowie Pages, Numbers und Keynote basieren intern auf Apples CloudKit. CloudKit bietet Apple und Drittherstellern den Zugriff auf eine NoSQL-Datenbank, aufgeteilt in private Datenbanken zur Synchronisation von Informationen über die eigenen Geräte hinweg wie auch über öffentliche Datenbank zur Erstellung von Apps wie Apple News oder Twitter-artigen Programmen.

Apple kaufte Anfang 2015 die Firma FoundationDB - damals wurde spekuliert, dass Apple FoundationDB besonders bei CloudKit einsetzen könnte. Ein kürzlich erschienenes Paper über die Innereien von CloudKit widerspricht dem allerdings - hier erwähnt Apple, dass man intern Apache Cassandra als NoSQL-Datenbank für CloudKit einsetzt.


Apple hat nun den Quellcode von FoundationDB über GitHub unter der "Apache License 2.0" veröffentlicht - diese Lizenz erlaubt selbst die kommerzielle Nutzung uneingeschränkt. Beschrieben ist in der Dokumentation, wie man FoundationDB auf macOS wie auch unter Linux mittels Docker zum Laufen bekommt.

Es ist unklar, warum Apple vor drei Jahren FoundationDB gekauft hat. Entweder ist das Ziel, das 2014 erstmals erschienene CloudKit langfristig von Apache Cassandra auf FoundationDB zu migrieren oder man war nicht an der Technologie von FoundationDB, sondern viel mehr an den Entwicklern interessiert.
iPhone 16 Pro
iPhone 16 Pro
Eskalationskurs: ARM kündigt Qualcomm die Design-Lizenz
Eskalationskurs: ARM kündigt Qualcomm die Desig...
Das iPhone 16 lässt sich ab sofort vorbestellen (Aktualisierung)
Das iPhone 16 lässt sich ab sofort vorbestellen...
iPhone 16: Welche Netzteile schnelles Laden versprechen
iPhone 16: Welche Netzteile schnelles Laden ver...
Kurz: 5G-Netze noch mit sehr wenigen Nutzern +++ Apple Pencil als TV-Antenne (Patent)
Kurz: 5G-Netze noch mit sehr wenigen Nutzern ++...
Release Candidate ist da! iOS 18, iPadOS 18, macOS 15 und watchOS 11 sind fertig
Release Candidate ist da! iOS 18, iPadOS 18, ma...
iMac M4 angekündigt
iMac M4 angekündigt
Vor 10 Jahren: 3 Milliarden für Beats
Vor 10 Jahren: 3 Milliarden für Beats

Kommentare

NikNik20.04.18 09:44
Wenn man ein Software-Projekt nicht selbst kommerziell anbietet, sondern nur intern nutzt, dann bietet es sich an es Open Source zu machen. So bekommt man eine breitere Tester-Gemeinschaft und vielleicht sogar noch kostenlose Entwickler mit dazu.

Die Apache License 2 erlaubt es ja auch jederzeit, dass Apple eigene Beiträge zur Datenbank zurückhält. Es besteht hier kein Zwang der Code-Öffnung.
+1
dsTny20.04.18 09:51
Die neue DB wird in macOS und iOS nativ integriert und löst Sqlite / CoreData ab. Offizielle Ankündigung auf der WWDC mitsamt Versprechen auf bessere Performance bei Datenbank Queries
-1
Mendel Kucharzeck
Mendel Kucharzeck20.04.18 09:55
dsTny
Ähm ne FoundationDB ist einfach für einen anderen Use-Case gedacht als SQLite. SQLite ist optimal als lokale Datenbank mit einem Client. FoundationDB ist genau das Gegenteil.
+2
ssb
ssb20.04.18 10:13
Der Tipp mit WWDC mag nicht so falsch sein - aber es wird eher um neue Frameworks gehen. HealthKit und ResearchKit wären da Kandidaten, aber auch MachineLearning etc. kann von solchen Datensammlungen profitieren. Apps dann auch, wenn man solche Daten von innerhalb eigener Apps abfragen könnte.
0
aMacUser
aMacUser20.04.18 10:13
Mendel Kucharzeck
dsTny
Ähm ne FoundationDB ist einfach für einen anderen Use-Case gedacht als SQLite. SQLite ist optimal als lokale Datenbank mit einem Client. FoundationDB ist genau das Gegenteil.
Der Unterschied ist noch viel gravierender. SQLite ist eine relationale Datenbank und FoundationDB ist eine NoSQL-Datenbank vom Typ Key-Value-Store. Das sind zwei von Grund auf unterschiedliche Konzepte der Datenhaltung.
+6
dsTny20.04.18 10:31
Das war auch eher mit einem Augenzwinkern geschrieben. Mir ist wohl bewusst, dass Sqlite relational und FoundationDB NoSql ist.
Dennoch denke ich, dass man sehr wohl auch diese Art der Datenbank integrieren und (lokal) durchsetzen könnte. Vielleicht mit einigen Abwandlungen, aber grundsätzlich empfinde ich SQL(ite) sehr behäbig. Mit CoreData habe ich noch nicht gearbeitet, aber zumindest gelesen, dass die bei vielen Daten ebenfalls recht behäbig werden soll (stimmt das?). Deswegen fände ich es gut, wenn Apple eine neue DB einbaut, welches leichtgewichtig und schnell ist.
0
aMacUser
aMacUser20.04.18 10:33
dsTny
Deswegen fände ich es gut, wenn Apple eine neue DB einbaut, welches leichtgewichtig und schnell ist.
FoundationDB wäre dafür allerdings vermutlich um weiten oversized.
+2
LoCal
LoCal20.04.18 10:58
dsTny
Das war auch eher mit einem Augenzwinkern geschrieben. Mir ist wohl bewusst, dass Sqlite relational und FoundationDB NoSql ist.
Dennoch denke ich, dass man sehr wohl auch diese Art der Datenbank integrieren und (lokal) durchsetzen könnte. Vielleicht mit einigen Abwandlungen, aber grundsätzlich empfinde ich SQL(ite) sehr behäbig. Mit CoreData habe ich noch nicht gearbeitet, aber zumindest gelesen, dass die bei vielen Daten ebenfalls recht behäbig werden soll (stimmt das?). Deswegen fände ich es gut, wenn Apple eine neue DB einbaut, welches leichtgewichtig und schnell ist.

Unter macOS kannst Du das jetzt schon, denn da kann man eigene Persistent Store Types anlegen.
Ich hab zwar keine Lösung, doch ich bewundere dein Problem
+1
Mendel Kucharzeck
Mendel Kucharzeck20.04.18 11:02
dsTny
Grundsätzlich ist SQLite und auch Core Data mit SQLite-Store extrem performant - aber wie bei fast allem nur, wenn du es richtig benutzt. Viele Entwickler sind versucht, Core Data genau so wie ein normales Objektmodell im Speicher zu nutzen und erhalten daher miese Performance. Wenn man sich darüber bewusst ist, wie Core Data intern funktioniert, kann man damit klasse arbeiten und sich eine Menge Arbeit ersparen.

Trivial-Beispiel für schlechte Core-Data-Nutzung: Du willst alle Einträge haben, die über Etikett A und B verfügen. Was machen viele Entwickler? Holen sich alle Einträge in den Speicher, gehen dann in einer Schleife alle Einträge durch und merken sich diese mit Etikett A und B. Was passiert? Die ganze Core-Data-Datenbank "hängt" im RAM. Richtig wäre, mittels eines Predicates gleich nur die Einträge zu holen, auf die die Kriterien zutreffen - nicht alles gammelt im Speicher rum und die eigentliche Arbeit wurde in SQLite (über einen Index!) erledigt.
+6
LoCal
LoCal20.04.18 11:16
Mendel Kucharzeck
dsTny
Grundsätzlich ist SQLite und auch Core Data mit SQLite-Store extrem performant - aber wie bei fast allem nur, wenn du es richtig benutzt. Viele Entwickler sind versucht, Core Data genau so wie ein normales Objektmodell im Speicher zu nutzen und erhalten daher miese Performance. Wenn man sich darüber bewusst ist, wie Core Data intern funktioniert, kann man damit klasse arbeiten und sich eine Menge Arbeit ersparen.

Ich glaube der grösste Nachteil an CoreData ist, dass viele es falsch Nutzen.
Es geht ja schon beim anlegen des Objektgraphen los. Dort wird oft normalisiert als würde man sich in einer rationalen Datenbank bewegen.
Dazu kommt, dass viele, auch alteingesessene Entwickler, der festen Überzeugung sind, dass CoreData gleich SQLite ist.
Ich weiss nicht, wie oft ich schon unfreiwillige Vorträge gehalten habe um, im besten fall zu beginn, meistens aber mitten im Projekt, zu erklären was CD ist und wie es "richtig" funktioniert.
Ich hab zwar keine Lösung, doch ich bewundere dein Problem
+2
Mendel Kucharzeck
Mendel Kucharzeck20.04.18 11:32
LoCal
Die Verlockung ist für viele aber auch groß, Core Data wie ein In-Memory-Object-Graph zu benutzen...mit verheerenden Folgen.
0
DSkywalker20.04.18 11:36
Schaut man in Source des servers https://github.com/apple/foundationdb/tree/master/fdbserver , dann finden man.....
TUSCH
SQLite

Ist also im Endefekt "nur" ein heftigst aufgebohrtes SQLLite
+2
DSkywalker20.04.18 11:39
Interessant ist auch, wie sie das alles zusammengerührt haben...
  • Boost
  • Mono
  • Java

Was für eine wilde Mischung und vor allem KEIN Swift
+2
dsTny20.04.18 16:34
Danke für die Erläuterung Ineffiziente Nutzung ist natürlich suboptimal.
0

Kommentieren

Sie müssen sich einloggen, um die News kommentieren zu können.