Anmerkung der Redaktion: This is a collection of excerpts from KDnuggets articles written by author Alex Williams covering NoSQL topics and concepts for beginners, with links to the full articles for further reading.
Was ist NoSQL?
NoSQL ist im Wesentlichen die Antwort auf die starre Struktur von SQL. NoSQL wurde erstmals in den frühen 1970er Jahren entwickelt und startete erst Ende der 2000er Jahre, als Amazon und Google viel Forschung und Entwicklung betrieben. Seitdem hat es sich zu einem integralen Bestandteil der modernen Welt entwickelt, da viele große Websites auf der ganzen Welt irgendeine Form von NoSQL verwenden.
So what is NoSQL exactly? Essentially it is a philosophy for creating databases that does not require a schema nor does it store data in a relational model. In fact, NoSQL has a variety of NoSQL Databases to pick from, each with their own specialization and use cases. As such, NoSQL is incredibly diverse when it comes to filling niches, and you can almost certainly find a NoSQL data model to fit your needs.
While SQL is a specific database and language, NoSQL isn’t, but that doesn’t mean that we can’t look at the general philosophies and differences between the two.
Weiterlesen NoSQL für Anfänger.
SQL vs. NoSQL
Developers are all too aware of the need for continuing education. Whether there’s a new framework to pick up or a new service to learn, innovation and adaptation are fundamental to development. One of the hottest topics for today is the decision to go with the standard SQL database or to move to a NoSQL database.
Dank der Innovation von Carlo Strozzi gibt es NoSQL-Datenbanken seit Jahrzehnten. Diese Datenbanken waren jedoch bis in die frühen 2000er Jahre nicht viel in den Nachrichten. Zu dieser Zeit begannen Unternehmen wie Google und Amazon, sich stärker in die Entwicklung von NoSQL-Datenbanken zu investieren. Trotz ihrer jüngsten Popularität sind viele Entwickler, Architekten und Designer möglicherweise nicht ganz auf dem neuesten Stand, was NoSQL-Datenbanken bieten.
Um einen Überblick über die Unterschiede zwischen den beiden Datenbanken zu erhalten, sehen Sie sich daher die folgenden 7 wichtigsten Erkenntnisse an, die jeder Entwickler kennen sollte.
Weiterlesen SQL vs NoSQL: 7 wichtige Imbissbuden.
NoSQL erfreut sich als ergänzendes Tool zu herkömmlichen SQL-Ansätzen für Datenbanken und Datenbankverwaltung zunehmender Beliebtheit. Wie wir wissen, folgt NoSQL nicht dem gleichen relationalen Modell wie SQL, was ihm die Möglichkeit bietet, viele leistungsstarke Dinge zu tun. Noch wichtiger ist, dass es sehr flexibel und skalierbar ist, was sich hervorragend für neuere Projekte eignet, die nicht über die Zeit oder das Budget für den Entwurf einer SQL-Datenbank verfügen.
Daher werden wir einen etwas tieferen Blick darauf werfen, wie unterschiedlich es ist Datenmodelle Arbeit.
Column-Oriented Databases
At a very surface level, column-store databases do exactly what is advertised on the tin: namely, that instead of organizing information into rows, it does so in columns. This essentially makes them function the same way that tables work in relational databases. Of course, since this is a NoSQL database, this data model makes them much more flexible.
More specifically, column databases use the concept of keyspace, which is sort of like a schema in relational models. This keyspace contains all the column families, which then contain rows, which then contain columns. It’s a bit tricky to wrap your head around at first but it’s relatively straightforward.
Bei einem kurzen Blick erkennen wir, dass eine Spaltenfamilie mehrere Zeilen hat. Innerhalb jeder Zeile kann es mehrere verschiedene Spalten mit unterschiedlichen Namen, Links und sogar Größen geben (was bedeutet, dass sie keinem Standard entsprechen müssen). Darüber hinaus existieren diese Spalten nur innerhalb einer eigenen Zeile und können ein Wertepaar, einen Namen und einen Zeitstempel enthalten.
Weiterlesen Column-Oriented Databases, Explained.
Graph-Datenbanken
Ironically for a non-relational database, graphs primarily work on the concept of multi-relational data ‘pathways’.
Graph databases are generally straightforward in how they’re structured though. They primarily are composed of two components:
- The Node: This is the actual piece of data itself. It can be the number of viewers of a youtube video, the number of people who have read a tweet, or it could even be basic information such as people’s names, addresses, and so forth.
- The Edge: This explains the actual relationship between two nodes. Interestingly enough, edges can also have their own pieces of information, such as the nature of the relation between two nodes. Similarly, edges might also have directions describing the flow of said data.
Weiterlesen Graph Databases, Explained.
Dokumentendatenbanken
Angeblich besteht die Idee hinter Dokumentendatenbanken darin, dass man beliebige Informationen in einem Dokument speichern kann. Das bedeutet, dass Sie jede beliebige Art von Daten kombinieren und abgleichen können, ohne wirklich befürchten zu müssen, dass die Datenbank sie nicht analysieren kann. Natürlich neigen die meisten Dokumentendatenbanken in der Praxis immer noch dazu, eine Art Schema mit einem Dateiformat und einer vorgegebenen Struktur zu verwenden.
Im Vergleich zu einer SQL-Datenbank, die sowohl tubulär als auch relational ist, weist der Dokumentenspeicher nicht die gleichen Schwächen und Einschränkungen auf wie SQL. Das bedeutet, dass es viel einfacher ist, mit den vorliegenden Informationen zu arbeiten und Abfragen viel einfacher durchzuführen sind. Ironischerweise können Sie die gleichen Aktionen, die Sie in einer SQL-Datenbank ausführen können, auch in einem Dokumentenspeicher ausführen, z. B. Löschen, Hinzufügen und Abfragen.
Wie bereits erwähnt, benötigt jedes Dokument eine Art Schlüssel, der ihm über eine eindeutige ID bereitgestellt wird. Wenn die eindeutige ID in einem Prozess bereitgestellt wird, werden die Informationen im Dokument selbst direkt gelesen und verarbeitet, anstatt sie spaltenweise herauszunehmen.
Weiterlesen Dokumentendatenbanken, erklärt.
Key-Value Databases
Schlüsselwertspeicher sind eigentlich ziemlich einfach. Ein Wert, bei dem es sich im Grunde um beliebige Daten oder Informationen handeln kann, wird mit einem Schlüssel gespeichert, der seinen Standort angibt. Tatsächlich ist dies ein Designkonzept, das in so ziemlich jeder Programmierung als Array- oder Kartenobjekt vorhanden ist. Der Unterschied besteht darin, dass es dauerhaft in einem Datenbankverwaltungssystem gespeichert ist.
Was Schlüsselwertspeicher so beliebt macht, ist, dass die Art und Weise, wie Informationen gespeichert werden, eher eine Art undurchsichtiger Fleck als diskrete Daten ist. Daher ist es wirklich nicht erforderlich, die Datenbank zu indizieren, um eine schnellere Leistung zu erzielen. Stattdessen arbeitet es allein aufgrund seiner Struktur schneller. Ebenso hat es nicht wirklich eine eigene Sprache, sondern setzt auf einfache Befehle zum Abrufen, Einfügen und Löschen.
Dies hat natürlich den Nachteil, dass die Informationen, die Sie aus einer Anfrage erhalten, nicht gefiltert werden. Dieser Mangel an Kontrolle über die Daten kann unter bestimmten Umständen problematisch sein, aber zum größten Teil lohnt sich der Austausch. Da Schlüsselwertspeicher schnell und zuverlässig sind, umgehen die meisten Programmierer alle Filter- / Steuerungsprobleme, auf die sie möglicherweise stoßen.
Weiterlesen Key-Value Databases, Explained.
Bio: Alex Williams ist ein erfahrener Full-Stack-Entwickler und Eigentümer von Hosting-Daten UK. Nach seinem Abschluss an der University of London mit Schwerpunkt IT arbeitete Alex fast 10 Jahre als Entwickler und leitete verschiedene Projekte für Kunden aus aller Welt. Vor kurzem wechselte Alex zu einem unabhängigen IT-Berater und startete seinen eigenen Blog. Dort erforscht er Webentwicklung, Datenmanagement, digitales Marketing und Lösungen für Online-Geschäftsinhaber, die gerade erst anfangen.
Verbunden:
Source: https://www.kdnuggets.com/2021/05/nosql-know-it-all-compendium.html
