JSON String in Datenbank speichern - BigData ? - was ist beste Variante ?

verwendetes Datenbanksystem: MS SQL 2016

Hallo zusammen,

aktuell habe ich ein Projekt bei dem ich gerne JSON Daten aus einer API Abfrage sammeln möchte und nach mehreren Wochen schauen möchte ob sich etwas geändert hat. Nun stellt sich die Frage in welcher Form das Speichern am besten passieren kann. Meine aktuelle Idee ist in einer SQL Datenbank in einem Textfeld den kompletten String zu speichern. Da ich noch nicht weiss wie ich die Daten später brauche halte ich es nicht für sinnvoll diese jetzt schon auf mehrere Tabellen aufzuteilen, sondern erst die Auswertung zu machen wenn die Daten wieder gebraucht werden.

Nun kommen die Daten als GZIP an, da stellt sich mir die Frage ob es nicht besser ist die gleich gepackt in der DB zu speichern und wie das funktionieren würde ?

Als letzte Alternative noch NOSQL, da fehlen mir aber die Erfahrungswerte.

Was meint Ihr dazu ?

Michael

@micha0827
Wie werden die Daten auf deiner Seite verarbeitet/verwendet?
Ansonsten ist JSON speichern eigentlich immer ein Fall für eine NoSql Dokumenten DB.
Aber hier wäre noch zu klären wie du die Daten verwendest/speicherst und auch abfragen willst.

Dateien, wie deine GZIP Archive, sollte man möglichst aus der DB raushalten.
Diese blähen nur die Sicherungen enorm auf, was bei Replikationen dann noch zusätzlich ins Gewicht fällt.

T-Virus

Ein String in einer SQL Datenbank ist de facto nicht abfragbar; das kann also nie eine Lösung sein.
Der SQL Server (SQL Server 2016 und Azure SQL) unterstützt aber in gewisser Weise eine hybride Welt von SQL und NoSQL mit einem eigenen DataType.

Hier eignet sich jedoch tatsächlich eine NoSQL Datenbank - bei diesen Informationen und Ausgangslage - absolut am Besten.

Das GZIP kannste direkt ignorieren; das musste raus halten.
Wenn man in irgendeiner Weise Dateien hat, die man als Dateien halten muss dann gibt es dafür Lösungen wie MongoDB's GridFS.

Hier ist aber der NoSQL Weg offensichtlich der Weg der Wahl.

Da Du auf Azure bist kannst Du Dir direkt CosmosDB (hieß früher DocumentDB) anschauen, das NoSQL unterstützt und als einzige NoSQL Engine auch SQL-Befehle versteht.
Gleichzeitig versteht aber CosmosDB auch die MongoDB-Befehle (außer GridFS).
MongoDB geht den üblichen Weg einer NoSQL Datenbank und nutzt dafür eine auf MapReduce-Engine basierenden Abfrage.

PS: Du willst hier offensichtlich eine Rohdaten-Datenbank aufbauen.
Dazu solltest Du Dir dann evtl. das Prinzip eines Data Lakes sowie die Grundlagen des ETL-Prozess anschauen.
Azure bietet Dir zu ETL auch direkt ein Tool an: Data Factory.

Was Du vor hast ist erfahrungsgemäß "etwas mehr" als mal kurz Daten zu speichern.
Soviel noch als Hinweis.

@T-Virus

Es geht um Produktdetailseiten von Shops. Ich möchte einen Optimierungsratgeber anbieten. Die Produktseiten bekomme ich als JSON. Die möchte ich speichern und nach gewisser Zeit diesen JSON erneut abrufen um zu schauen ob und wenn ja wie der Kunde meine Optimierungsempfehlungen umgesetzt hat. Also im Endeffekt geht es darum 2 JSON Strings (Kategoriedaten, Artikelmerkmale etc.) zu vergleichen und eine Auswertung zu machen was geändert wurde.

Michael

Artikeleigenschaften -> NoSQL.

PS: Big Data ist das aber noch nicht, da gehört dann ein wenig Mehr dazu 😉

Ist ein fall für NoSQL.
Gibt hier einige gute Dokumenten DBs.

T-Virus

Kommt der JSON Response wirklich als GZIP an oder ist das nur die Kompression während des Transports? IdR erfolgt die Kompression transparent und man bekommt es nicht wirklich mit.

Was ist Gleichheit?

{"foo":1,"bar":2}

ist als string anders als

{"bar":2,"foo":1}

inhaltlich aber gleich.

Text auf Gleichheit zu prüfen kann bei großen Texten sehr lange dauern. Da kann eine gestaffelte Prüfung auf (in dieser Reihenfolge) Länge, Hash, Komplett effizienter sein.

Große Datenmengen pro Feld in einer SQL Datenbank können die Performance beeinträchtigen, wenn man das nicht passend vorbereitet. Der MSSQL bietet dafür etwas an FILESTREAM (SQL Server).

Alternativ (wie von T-Virus schon vorgeschlagen) bietet sich auch die getrennte Speicherung rohen Daten im Filesystem und nur die Metadaten (Id, Länge, Hash, ...) im SQL Server.

PS:

Ob ich hier wirklich NoSql als Lösung sehe ... da bin ich im Moment noch ohne Meinung

@Abt
Was ist mit Azure Table Storage ? Ist deutlich kostengünstiger als Cosmos DB ?

@Sir Rufo
Ist nur die Transportkomprimierung.

Michael

Sind zwar beides NoSQL Technologien aber mit einem völlig anderen Fokus.

Table Storage ist nur ein Key-Value Speicher wie zB. Redis.
Bietet aber keinerlei komplexe Abfragemöglichkeit. Quasi alle Abfragen auf eine Table Storage erfordert einen Table Scan.
Total ineffizient und ungeeignet für diesen Fall.

Den Preis sollte man bei so einem Thema nie ganz vorne anstellen.
Du solltest in erster Linie Produkte in Erwägung ziehen, weil sie geeignet sind - nicht weil sie günstig(er) sind.
Ansonsten passiert relativ schnell das hier: https://www.smashingmagazine.com/wp-content/uploads/images/developers-designers/work.gif

MySQL bietet einen gesonderten Datentypen für JSON mit entsprechenden Funktionen (z. B. zum Extrahieren einzelner Werte aus dem JSON) an. Vielleicht wäre das eine Variante zum Speichern der Daten.

https://dev.mysql.com/doc/refman/5.7/en/json.html

@hypersurf
PostgreSQL hat auch JSON Support.
Da es hier aber nur um die reine Speicherung von JSON geht, würde ich auch eine entsprechende NoSQL DB bevorzugen.

Wenn es hier aber um die Speicherung von Anwendungsdaten und den JSON Daten gehen würde, wäre dies eine mögliche Lösung.

T-Virus

JSON Datentypen für den hybriden Zweck haben alle Datenbanken heute: sie müssen es auch.
Es gibt fast keine größeren Anwendungen mehr, die wirklich nur relationale Daten haben.

NoSQL steht ja auch für Not Only SQL und nicht für "Kein SQL".
Es ist einfach "etwas mehr".

Aber trotzdem bleiben relationale Datenbanken eben relationale Datenbanken.
Sie können auch mit einem extra Datentyp nicht das leisten, was eine NoSQL Datenbank in diesem Sinne leisten kann.

So, Daten werden jetzt in die Cosmos DB geschrieben, danke an Alle für die Unterstützung.

Michael