Ist MongoDB gut?
Programmiere aktuell eine App mit .net Maui und will ein paar daten online Speichern. Ist MongoDB dafür eine gute Wahl?
Was für Daten? Wie sind die Daten strukturiert?
Integer, strings und auch Bilder. Die Daten sind aktuell in einer Klasse mit sqlite gespeichert und des will ich halt ändern, dass dann alles in der Datenbank gespeichert wird.
3 Antworten
Zunächst wohl das Wichtigste: Für .NET gibt es einen MongoDB-Treiber. Das heißt, du kannst eine MongoDB auch für dein Projekt nutzen.
Ob es allerdings Sinn macht, eine MongoDB statt einem relationalen Datenbanksystem (wie MySQL) zu verwenden, hängt davon ab, wie deine Daten strukturiert sein sollen und in welcher Form du mit ihnen operierst.
Ein relationales Schema eignet sich am besten, um Daten relational zueinander zu verknüpfen und um Datenkonsistenz zu gewährleisten. Letzteres heißt, du kannst Daten beispielsweise vor dem Schreiben besser prüfen (siehe Constraints) und bei Bedarf Operationen auch zu einer reversiblen Transaktion bündeln. DBMS wie MySQL, MSSQL oder PostgreSQL bringen von sich aus schon zahlreiche Funktionalitäten mit, die eine sichere, stabile Datenspeicherung/-verwaltung ermöglichen. Eine Überführung deiner Daten aus der SQLite-Datenbank in ein anderes RDBMS sollte des Weiteren nicht schwerfallen.
Eine MongoDB hingegen gibt keine Struktur/kein Schema vor, in dem die Daten gespeichert werden. Das erlaubt schnellere Schreibvorgänge und fixe Anpassungen, allerdings bist du dann auch selbst für die Datenkonsistenz verantwortlich (du kannst bspw. schnell und problemlos ein neues Property XY zu einem Datensatz hinzufügen, musst beim Lesen allerdings berücksichtigen, dass es dieses Property nicht zwingend in jedem Datensatz geben muss). Außerdem werden die Daten erst in einen dateibasierten Zwischenspeicher aufgenommen, bevor sie tatsächlich in die Datenbank geschrieben werden.
Generell lohnt sich eine MongoDB am ehesten für Anwendungen, bei denen viele Daten innerhalb kürzester Zeit (immer wieder) geschrieben oder aktualisiert werden sollen (z.B. Analysedaten/generell Big Data). Bei Bedarf kann man das System sowohl horizontal als auch vertikal skalieren.
Bezüglich der Speicherung von Bildern wäre es ebenso günstig, sich vorab mehr Gedanken zu machen, was man tatsächlich braucht.
Man kann sie natürlich als Base64-Strings einlagern (< ~5 MB) oder in irgendwelchen BLOB-Typen speichern. Für MongoDB gibt es (für Bilder > 16MB) GridFS, was die Dateien in einzelne Teile aufsplittet und dann in separate Dokumente der Datenbank legt.
Vorteilhaft dabei ist, dass es leichter ist, Bilder zu versionieren, den Zugriff auf sie zu verwalten oder Backups anzufertigen. Allerdings stopfst du damit auch schnell die Datenbank voll (nicht, dass sie eine Maximalkapazität hätte - die wird vom Host bestimmt), was sich auf die Performance auswirkt.
Die Alternative dazu wäre, die Bilder stattdessen im Dateisystem abzulegen und somit Ballast von dem Datenbankserver zu nehmen. Von dort ist auch der Lesezugriff viel schneller. Die Datenbank selbst bräuchte sich lediglich einen Verweis (Dateipfad) merken.
Haha, soll ich jetzt in die tiefe Materie einsteigen? ^^
Kurz gesagt kann ich dir folgendes empfehlen: Willst du eine SQL Datenbank wähle Postges, willst du eine Non-SQL Datenbank wähle MongoDB. Sind sind i.d.R. die besten Datenbanken für beide Lösungen.
Alles weitere geht tiefer in die Materie, allerdings nehme ich mal aufgrund deiner Frage an, dass es sich um einen kleineren Service/Website handeln wird.
I.d.R. ist Postgres schneller als MongoDB, dafür weniger Flexibel. Aber nun mal Hand aufs Herz: Bei deinem Setup bewegen wir uns bei der Frage der Geschwindigkeit im Nanosekunden Bereich, also ist das komplett zu vernachlässigen.
Nimm das worauf du mehr Bock hast weil es ehrlich gesagt egal ist.
Das kommt darauf an, wie diese Daten strukturiert sind (oder eben nicht).
Mir persönlich ist SQL geläufiger, aber das soll für Dich nichts heißen :-)