Die Vorteile einer nicht-relationalen Datenbank (z. B. eines Schlüssel-Wert-Paarspeichers) sind offensichtlich, wenn sie in großen Datensätzen (google, facebook, linkedin) verwendet werden. Wie können Ihrer Meinung nach kleine bis mittelgroße Anwendungen von der Verwendung nicht relationaler Datenbanken profitieren?
IBM Mainframes haben seit den 60er Jahren "nicht relationale" Datenbanken (hierarchische Datenbanken wie IMS + Varianten). Diese Datenbanken werden immer noch verwendet, weil sie extrem schnell sind und eine große Skalierung ermöglichen.
Der Zweck von relationalen Datenbanken bestand darin, eine regelmäßige, relativ abstrakte Methode zum Speichern und Abrufen von Daten bereitzustellen, bei der das Tuning relativ unabhängig vom Datenmodell durchgeführt werden kann (gilt nicht für IMS). Sie wurden eher als Reaktion auf die Unfähigkeit entworfen, hierarchische Datenbanken leicht zu reorganisieren. Die Oberseite ist nette Organisation; der Nachteil ist mittel, keine hohe Leistung.
Google bietet skalierbaren Speicher und MapReduce für die Skalierung. Es ist nicht relational.
Anfang des letzten Jahrzehnts gab es einen großen Schub, Daten in XML zu speichern, im Wesentlichen in hierarchischer Form, weil XML implizit hierarchisch ist. Das war ein großer Fehler IMHO, weil es die Unannehmlichkeiten der hierarchischen Datenbanken wiederholte, aber nichts von der Leistung hatte. Ich bin nicht sehr überrascht, dass diese Bewegung so ziemlich gestorben zu sein scheint.
Der größte Teil des praktischen Push-to-Non-Relational scheint mir in Bezug auf Leistung und Umfang zu liegen. Ich sehe nicht, wie das "kleinen" Anwendungen viel hilft.
Die Leute haben eine praktische Datenverwaltung mit wissensbasierten Systemen vorgeschlagen, aber nicht getan. Doug Lenats CYC fällt mir hier ein. Die Fähigkeit der Datenbank um einer Anwendung zu helfen, nicht naheliegende Schlussfolgerungen zu zeichnen, fällt mir ein sehr interessantes für "kleine" Anwendungen auf, die versuchen "schlau" zu sein. Aber davon gibt es noch nicht viele.
Der Vorteil einer NoSQL-Datenbank in diesem Maßstab liegt darin, dass das Datenbankmodell (Schlüsselwert, Dokument usw.) den Anforderungen der Anwendung gut entspricht und die erweiterte relationale Funktionalität nicht benötigt wird.
Am kleinen Ende des Spektrums ist Leistung kein Thema, denn fast alles ist schnell. Speicher-Engines sind kein Problem, wenn Sie keine hochentwickelte Abfrage-Engine benötigen, ist das Fehlen von SQL-Unterstützung kein Problem.
Sie wissen, wie gut es passt und wie einfach es zu benutzen ist. Ehrlich gesagt, Werkzeuge werden zu einem Problem. Die Werkzeuge für relationale Datenbanken sind ausgereift, NoSQL-Tools sind weniger funktionsreich und weniger kampfsicher. Zu oft handelt es sich um Selbstbauwerkzeuge. Überlegen Sie sich genau, welche Tools Sie aufgeben und wie viel Sie benötigen.
Wenn Sie einen NoSQL-Dienst (z. B. Amazon SimpleDB und Microsoft Azure) im Vergleich zu einem Produkt in Erwägung ziehen, ergeben sich weitere Vorteile für kleinere Projekte. Wenn Sie nur für das bezahlen müssen, was Sie verwenden, und Sie nicht viel verwenden, kann es günstiger sein, als einen dedizierten Server laufen zu lassen, um die kostenlose Nutzungsebene für SimpleDB freizugeben.
Sie vermeiden auch einen Teil der Wartungskosten für Server und Datenbanken. Dies kann ein großer Gewinn sein, wenn Sie keinen DBA haben oder wenn Ihre DBAs bereits überlastet sind. Natürlich haben Sie immer noch Administratorarbeit zu erledigen, aber es ist deutlich reduziert und in der Regel einfacher.
Wenn es um Graphendatenbanken geht (wie Neo4j - ein Projekt, in das ich involviert bin), dann sind sie unter Skalierung zur Komplexität . Das heißt, sie bieten "bessere Substrate für die Modellierung von Geschäftsdomänen" (siehe Der Staat von NoSQL , auch von Ben Scofield , auch). Für mich ist das in kleinen bis mittleren Apps sehr wichtig.
Dies wird vielleicht besser anhand von Beispielen erklärt, daher hier einige Links zu Beispielanwendungen / Domänenmodellierung:
Die Frage erfordert vielleicht ein bisschen mehr Kontext ... unter der Annahme einer Python-Umgebung, betrachte das Tutorial im y_serial-Projekt: Ссылка
NoSQL wird nicht nur aus Gründen der Skalierbarkeit übernommen. Die Serialisierung (jedes beliebigen Python-Objekts) und die Persistenz sind in jedem Maßstab sehr praktisch. Betrachten Sie das Schlüssel-Wert-System als einen Ansatz.
Eines der Probleme mit einem RDBMS besteht darin, dass Sie Ihre Domänenmodelle für die Programmiersprachen dem relationalen Schema Ihres RDBMS zuordnen müssen. Dieser Aufwand wird normalerweise für die Konfiguration Ihrer ORM-Schicht aufgewendet.
Mit NoSQL-Datenbanken sind Sie nicht gezwungen, Ihre Objekte einem relationalen Modell zuzuordnen, und in den meisten Fällen werden Ihre Objekte so wie sie sind serialisiert. Mangels eines Vermittlungsschemas werden Datenmigrationen und Versionierungen einfacher .
Ein weiterer Vorteil ist die Skalierbarkeit und Leistung. Da die meiste Zeit Ihre Daten von "Schlüsseln" effektiv empfangen werden, wird alles verwendet und indexiert. Trivial Sharding ist möglich, indem Sie einen% (MOD) für den Schlüssel gegen die Anzahl Ihrer verfügbaren NoSQL-Instanzen ausführen und eine natürliche Datenpartitionierung bereitstellen, die für das Sharding entscheidend ist.
Wenn Sie daran interessiert sind, zu sehen, wie sich die Entwicklung mit einem NoSQL von einem RDBMS unterscheidet, habe ich ein Tutorial, in dem ich Ihnen zeige, wie Sie vorgehen müssen Entwerfen einer einfachen Bloganwendung mit Redis .
Wenn Sie einige gängige PaaS-Cloud-Dienste wie einen Schlüssel-Wert-Speicher, einen BLOB-Speicher und einen Message Queue-Speicher zusammenführen, können Sie kleine Anwendungsentwickler von der Tyrannei des DBA und der Infrastruktur-Mitarbeiter befreien .
Heute greifen kleine Entwickler oft auf Jet-MDBs zurück. Warum? Einfacher, gemeinsamer Zugriff ist so einfach wie das Speichern der MDB-Datei in einer Dateifreigabe, die für die gesamte Anwendungsgemeinschaft sichtbar ist. Wenn sie damit davonkommen können (d. H. Die notwendige Unterstützung von den Gatekeepern erhalten), können sie SQL Server Express, MySQL usw. verwenden.
Leider können diese Torwächter in einer großen Organisation ziemlich feindselig sein. Erwähnen Sie eine "Datenbank" und plötzlich stehen Sie vor der DBA-Bande und den damit verbundenen Verzögerungen, Anwendungsüberprüfungen, Prioritätensetzung usw. Erwähnen Sie, dass Sie einen Server benötigen und dass Sie diesem anderen Erschießungskommando gegenüberstehen.
Wenn Sie eine NoSQL-Lösung und zugehörige Cloud-Dienste verwenden, können Sie eine Menge davon eliminieren, wenn Sie kein RDBMS benötigen.
Zum einen ist nur ein Konto bei einem öffentlichen Cloud-Anbieter erforderlich. Dies ist etwas, das ziemlich einfach wird, sobald das Konzept genehmigt wurde. Und einfacher für Sie als Entwickler, sobald Sie genehmigt und ein Konto zugewiesen bekommen haben, obwohl es natürlich die üblichen Buchhaltungsprobleme gibt.
Aber lassen Sie uns das beiseite stellen. Was ist, wenn Ihre Organisation eine private Cloud für solche Zwecke implementiert? Viele Probleme mit der externen Rechnungsstellung gehen weg, Datensicherheitsprobleme gehen weg usw.
Solch eine Sache könnte auf eine halbanonyme Art und Weise implementiert und bereitgestellt werden, fast so einfach wie die Verwaltung von Dateifreigaben. Die Anonymität kommt zustande, denn sobald Sie für die Entwicklung in der hausinternen Cloud freigegeben wurden, muss niemand mehr die Details Ihrer Aktivitäten verwenden, um eine Anfrage zu prüfen, bevor Sie eine Datei auf einer vorhandenen Dateifreigabe erstellen können .
Offensichtlich wären Speicher- und CPU-Kontingente zu verwalten. Niemand kann es sich leisten, einfach weiter zu skalieren. Rogue-Anwendungen verbrauchen möglicherweise große Mengen an Ressourcen. Was Sie also brauchen, ist eine Art Quotensystem, um die Nutzung zu begrenzen. Ob dies von Infrastrukturmitarbeitern überwacht wird, ist eine Implementierungsentscheidung, oder es könnte genauso behandelt werden wie die gemeinsame Nutzung von Dateien: läuft aus und jemand schreit den Programmierer an, der wiederum in ihn hineinschaut und mehr verlangt (oder seine Fehler behebt) / p>
Aber Sie enden mit "Utility Computing" und durch "ohne SQL" entstehen Ihnen keine Kosten (und Probleme) beim Umgang mit DBAs. Sie können immer noch still sitzen im Internet surfen in ihren großen Büros, während Sie etwas Arbeit erledigen.
Amazon SimpleDB kann für diejenigen nützlich sein, die eine nicht-relationale Datenbank für die Speicherung von kleineren, nicht-strukturellen Daten benötigen. Amazon SimpleDB hat eine Speichergröße von 10 GB pro Domäne. Amazon SimpleDB bietet Einfachheit und Flexibilität. SimpleDB indiziert automatisch alle Daten. Die Amazon SimpleDB-Preisgestaltung basiert auf Ihrer tatsächlichen Box-Nutzung. Sie können alle UTF-8-String-Daten in Amazon SimpleDB speichern.
Tags und Links nosql amazon-simpledb non-relational-database