Ich habe in den letzten sechs Monaten nach und nach den Datenspeicher von GCP berührt.
Lassen Sie uns die verschiedenen Gefühle beim Berühren des Datenspeichers zur Kenntnis nehmen. Ich würde es gerne mit DynamoDB vergleichen, aber es ist fast ein Merkmal von NoSQL. Es gab nicht viele Artikel, die mich über Designrichtlinien und Änderungen im Denken bei RDB-> KVS unterrichteten, deshalb habe ich sie zusammengefasst.
["NoSQL-Handbuch für RDB-Ingenieure"](http://www.amazon.co.jp/RDB%E6%8A%80%E8%A1%93%E8%80%85%E3%81%AE % E3% 81% 9F% E3% 82% 81% E3% 81% AENoSQL% E3% 82% AC% E3% 82% A4% E3% 83% 89-% E6% B8% A1% E9% 83% A8- % E5% BE% B9% E5% A4% AA% E9% 83% 8E / dp / 479804573X) Ich denke, es ist bis zu einem gewissen Grad in einem Buch wie diesem geschrieben, aber ich glaube nicht, dass Datastore erwähnt wurde. ..
Ich berühre übrigens von GAE / py.
Lassen Sie uns zunächst die Grundbegriffe klären.
Neue Grundkenntnisse der Datenbank Grundlegendes zu Googles riesigem verteilten Datenspeicher Bigtable and Datastore (4/12) Wie in diesem Artikel erwähnt,
| datastore | RDB |
|---|---|
| kind | table |
| entity | record |
| property | field |
Es scheint.
Ich fasste zusammen, woran ich beim Entwerfen des Tisches dachte. Grundsätzlich denke ich, dass es ein allgemeines Konzept in Datastore oder schemaless NoSQL ist.
Der Datenspeicher hat nicht das Konzept einer Tabelle, sondern verwaltet mehrere Arten von Entitäten an einem Ort. Es sieht also so aus, als würde sich Art wie ein Tisch verhalten.
Übrigens hat GCP Namespace genannt? GAE? Es gibt auch ein Konzept, mit dem Sie einen unabhängigen Datenspeicher für dasselbe Projekt erstellen können.
In der Transaktion können mehrere Arten gleichzeitig aktualisiert werden, indem sie in die Entitätsgruppe eingefügt werden. Es scheint jedoch eine Einschränkung zu geben, dass nur etwa 1 / s in eine Entitätsgruppe eingeordnet werden kann.
Die Entität mit Schlüssel zu bekommen ist sehr schnell. Sie können eine Eigenschaft erst abrufen, nachdem Sie eine Entität erhalten haben. Die Abfrage kann also nur die Liste der Schlüssel abrufen. Wenn Sie also eine Abfrage normal ausgeben, scheint der Inhalt intern verzögert zu sein.
Es gibt einen Kompromiss für Integrität.
Wenn es sich um einen normalen Put handelt, der nicht in die Entitätsgruppe aufgenommen werden kann, ist die resultierende Konsistenz garantiert. Dies spiegelt die Ergebnisse nicht sofort wider und einige Abfragen geben für eine Weile alten Inhalt zurück. (Bequemlichkeit des Knotens?) Die Einordnung in eine Entitätsgruppe garantiert eine hohe Konsistenz auf Kosten einer begrenzten Aktualisierungshäufigkeit, und neue Informationen können sofort abgerufen werden.
Aus Sicht der Datenverwaltung erscheint es sehr seltsam, aber beim Entwerfen eines Datenspeichers ist es besser, Objekte mit Ansicht zu entwerfen, dh wie Daten angezeigt und verarbeitet werden.
Mit anderen Worten, es ist notwendig, Anwendungsfälle für die Datenerfassung / -aktualisierung in der Entwurfsphase richtig zu antizipieren. Möchten Sie beispielsweise die Benutzerliste oder Daten abrufen? Eine solche.
Der Grund hängt mit der unten beschriebenen Denormalisierung zusammen, aber die API benötigt immer mehr Zeit, wenn eine Reihe von Abfragen ausgegeben werden. Es ist schlecht für UX, und wenn Sie GAE verwenden, gibt es ein Minutenlimit. Daher ist es besser zu denken, dass Sie etwas zusammenbringen sollten, das zuerst als Daten angezeigt werden soll. Lassen Sie uns die Designrichtlinien in RDB wegwerfen.
Im Gegensatz zu RDB ist es im Datenspeicher fast unmöglich, Aggregate zu verarbeiten. Daher gab es viele Artikel, die eine solche Technik als Summieren empfahlen oder Informationen enthielten, auf die bekanntermaßen in allen Tabellen so weit wie möglich im Voraus Bezug genommen wurde.
Ich persönlich denke, das ist der wichtigste Punkt. Wenn Sie eine Suche oder Abfrage haben, erhalten Sie diese per Abfrage, aber am Ende zeigt KVS (obwohl es im engeren Sinne anders sein kann) seinen wahren Wert bei der schlüsselgetriggerten Erfassung. Die Konsistenz zum Zeitpunkt der Verlängerung ist auch garantiert, wenn der Schlüssel erworben wird. Und wie ich später bemerkte, kann ich es nur mit Schlüssel in der Transaktion w bekommen
Ich habe nicht viel geübt, aber ich schwitze Es ist schneller, die Schlüsselliste und dann eine bestimmte Anzahl von Entitäten abzurufen, anstatt zu versuchen, alle Eigenschaften abzurufen. Wenn Sie nur den Namen benötigen, holen Sie sich den Schlüssel mit der Option get und zeigen Sie ihn an.
Ich habe nach Artikeln gesucht, die beim Entwerfen von Daten hilfreich sein könnten. Alle von ihnen sind alte Artikel, aber sie scheinen bis zu einem gewissen Grad hilfreich zu sein.
Es gibt jedoch auch Umgehungsinformationen, sodass dieser Bereich aufgrund von Aktualisierungen möglicherweise nicht erforderlich ist. Insbesondere wenn Sie einen Teil der Eigenschaftsinformationen in den Schlüssel einfügen und die Schlüsselliste abrufen, müssen Sie sich nicht den Inhalt der Entität ansehen, was etwas Besonderes zu sein scheint.
Es war leicht zu verstehen, wie sich die Entwurfsmethode von RDB unter Verwendung von SQL unter dem Gesichtspunkt der Denormalisierung unterscheidet.
Was geschrieben steht:
Satoshi Nakajimas Blog schrieb auch über Datastore. Hier wird auch eine Denormalisierung empfohlen, aber es war auch leicht zu verstehen, wie die Entitätsgruppe und die Entwurfsrichtlinie verwendet werden. Ich hatte jedoch den Eindruck, dass sich das Problem der Abfragegeschwindigkeit und der hohen Fehlerrate seit der Zeit dieses Blogs erheblich verbessert hat.
Was geschrieben steht:
Es scheint eine Möglichkeit zu geben, die Entität für get und put aufzuteilen. (Ich denke, diese Art ist auch anders) Dies ist möglicherweise nicht sehr praktisch.
Dies ist der offizielle Google-Blog im letzten Jahr, aber er ist sehr hilfreich für den Einstieg.
Recommended Posts