SQLite - die Bananenschnecke der eingebettet Datenbanken
Anfang dieses Monats habe ich eine Blogreihe zum Thema SQLite gestartet. Im ersten Beitrag ging es um die Vorteile, die SQLite gegenüber einfachen Textdateien und den aufwendigeren SQL-Datenbanken für Unternehmen bietet – und tatsächlich bietet es gegenüber beiden deutliche Vorteile. Bis zu einem gewissen Punkt. Und dieser Punkt lag vor fünf Jahren.
Die Sache ist die: Wenn Sie IoT im Bereich Mobile oder IoT tätig sind oder wenn Sie mit verteilten Anwendungen und Daten von der Cloud zum Edge vorstoßen,Datenmanagement lokales, eingebettet Datenmanagement eine entscheidende Fähigkeit – und genau hier hat sich SQLite jahrelang hervorgetan. Doch obwohl lokales und eingebettet Datenmanagement für moderne Datenmanagement notwendig – ja sogar entscheidend –Datenmanagement , reicht es in der Umsetzung durch SQLite nicht aus. Modernes Datenmanagement die Fähigkeit, Daten lokal zu verarbeiten und zu analysieren, sie Peer-to-Peer auszutauschen, Daten zwischen Gateways, anderen intelligenten Maschinen und sogar zurück in die Cloud zu übertragen Cloud und SQLite wurde nie dafür entwickelt, diese Anforderungen zu erfüllen.
Lassen wir die Herausforderungen einmal beiseite, die sich aus den Anforderungen an gemeinsam genutzte und verteilte Daten ergeben – darauf werden wir im nächsten Teil eingehen –, und betrachten wir zunächst die Einschränkungen von SQLite im Bereich der lokalen Datenverarbeitung, beginnend mit einem der wichtigsten Aspekte: der Leistung.
SQLite ist einfach nur langsam.
Vor achtzehn Monaten haben wir Leistungstests mit Actian Zen – unserer eingebettet Zero-DBA-Datenbank eingebettet – im Vergleich zur neuesten SQLite-Distribution durchgeführt und festgestellt, dass Zen je nach ausgeführter Operation um zwei Größenordnungen schneller war. Okay, bei indizierten Löschvorgängen war sie sogar um drei Größenordnungen schneller. Wir haben einen direkten Vergleich durchgeführt und beide auf einem Raspberry Pi 3 getestet, einem kleinen ARM-basierten Einplatinencomputer, den man bei Amazon für unter 50 Dollar kaufen kann. Zen Core und SQLite sind beide kostenlos, und Sie können diesen Test selbst durchführen.
Okay, die Trägheit von SQLite ist also nichts Neues. Jeder in der SQLite-Community weiß, dass SQLite quälend langsam ist. Warum ist es dann trotzdem so beliebt geblieben? Praktisch gesehen war es lange Zeit die einzige Option auf dem Markt. Dafür gibt es drei Gründe. Erstens handelt es sich um ein Open-Source-Produkt, das es schon seit über zwei Jahrzehnten gibt und das daher weithin bekannt ist. Zweitens ist es in vielen Open-Source-Entwickler-Kits enthalten, vor allem in Android. Und schließlich haben viele Datenbankanbieter SQLite irgendwann einmal als ihre „Mobile“-Edition verpackt und umbenannt (siehe MongoDB und Couchbase). Es gibt sogar einige Start-ups, die buchstäblich ihr Label auf SQLite kleben und damit verbundene Dienste als ihr einziges Marktangebot verkaufen.
An dieser Stelle kommen wir wieder auf diese Einschränkungen zurück: Die träge Leistung, die vor fünf Jahren noch ausreichte, wird für die nächsten fünf Jahre (ganz zu schweigen von der Zeit danach) einfach nicht mehr ausreichen. Und die Leistungsprobleme bei SQLite werden sich nur noch verschärfen: Die Datenmanagement am Edge werden mit der Zeit immer anspruchsvoller werden, selbst für eingebettet .
Bedenken Sie den gestiegenen Bedarf an lokaler Datenspeicherung. Es geht nicht mehr nur um einfaches Caching. Datenpersistenz wird nun für rechenintensive lokale Datenverarbeitung und unbeaufsichtigtes Maschinelles Lernen benötigt. In diesen Szenarien sehen wir eine Flut von eingehenden Streaming , für deren Verarbeitung SQLite einfach nicht robust genug ist. Darüber hinaus beobachten wir einen Anstieg der Rechenanforderungen im Zusammenhang mit abfragen, Extraktion und Analyse bestehender Muster aus der lokalen Datenbank und/oder denen externer Peers oder Upstream-Gateways.
Und es geht nicht nur um das Volumen der Streaming oder die Komplexität der durchgeführten Analysen. Hinzu kommt das Problem, dass mehrere Anwendungen gleichzeitig auf denselben Datensatz zugreifen – oder dass sogar ein einzelner Upstream-Abnehmer Daten von mehreren Downstream-Anbietern abonniert und kopiert. Beide Fälle erfordern ein Maß an Zustimmung architektonisch außerhalb des Anwendungsbereichs von SQLite liegt. Man kann bestenfalls sagen, dass SQLite versucht, Zustimmung eine Sperre für die gesamte Datentabelle gegenüber allen anderen Benutzern als demjenigen zu simulieren, der gerade darin liest oder schreibt – selbst wenn dieses Lesen oder Schreiben nur eine einzige Zeile betrifft –, anstatt die granulare Sperre zu verwenden, die eine echte ACID-konforme SQL-Datenbank bieten sollte. Das Endergebnis ist, dass SQLite erhebliche Engpässe verursacht, wenn die Datenanforderungen und -mengen in praktischen IoT mobilen Anwendungsfällen zunehmen.
Eine Steigerung der Rechenleistung der Plattform hinter SQLite wird die Leistung dieses in die Jahre gekommenen Arbeitstiers nur begrenzt verbessern. Was modernes Datenmanagement am Netzwerkrand Datenmanagement , ist ein Gepard, und was wir mit SQLite haben, ist eine Bananenschnecke.
Und keines dieser Szenarien ist eine Vision aus ferner Zukunft. Unternehmen stehen bereits heute vor diesen Herausforderungen – in Umgebungen mit IoT , die Tausende von Sensoren und vorgelagerten Gateways umfassen. Auch einige unserer Mitbewerber sehen sich mit diesen Herausforderungen konfrontiert, da immer mehr von ihnen SQLite als ihre mobile Engine aufgeben wollen.
Falls Sie SQLite im Vergleich zu anderen Datenbanken getestet oder eine Veränderung in der Leistung Ihrer Anwendung dokumentiert haben, als Sie von der Verwendung von Flatfiles auf SQLite umgestiegen sind, lassen Sie es uns wissen. Schreiben Sie mir gerne eine E-Mail an lewis.carr@actian.com.
Wenn Sie bereit sind, SQLite noch einmal in Betracht zu ziehen, informieren Sie sich über Actian Zen. Oder probieren Sie Zen Core einfach kostenlos aus – die Nutzung für Entwicklung und Vertrieb ist lizenzgebührenfrei.