Wenn Sie nicht beabsichtigen, Daten für eine Granularität pro Spalte abzurufen oder zu aktualisieren, ist Ihr Plan zum Speichern von JSON-Dokumenten als einzelner Wert in Ordnung, insbesondere, wenn Sie Spaltenspalten-Daten speichern (und das Qualifikationsmerkmal) müssen auch in jeder Zeile gespeichert werden, wodurch ein Speicher-Overhead hinzugefügt wird, der proportional zur Anzahl der Werte ist und daher in Ihrem Maßstab aussagekräftig sein kann. In Ihrem Modell verwenden Sie Bigtable einfach als Schlüsselwertspeicher.
Wenn Sie JSON in Zukunft in mehrere Spalten aufteilen möchten, können Sie einer laufenden Bigtable-Instanz zusätzliche Spaltenfamilien hinzufügen (oder einfach zusätzliche Spaltenqualifizierer innerhalb Ihrer vorhandenen Spaltenfamilie verwenden) und Ihre Daten über a paralleler Prozess wie Hadoop MapReduce oder Google Cloud Dataflow.
In einem separaten Hinweis benötigen Sie abhängig von Ihrer Lese-/Schreibrate möglicherweise mehr als das Standardkontingent von 30 Bigtable-Knoten. Bitte beachten Sie die Bigtable performance page für ein Ballpark-Maß der Leistung, die Sie pro Bigtable-Serverknoten erwarten sollten, aber Sie sollten Ihre spezifischen Lese-/Schreibmuster benchmarken, um die Grundliniennorm festzulegen, und entsprechend skalieren.
Wenn Sie ein zusätzliches Kontingent benötigen und bereits Kunde der Google Cloud Platform mit einem Support-Plan sind, öffnen Sie ein Support-Ticket. Wenn nicht, bitte get in touch with us, um Ihren Anwendungsfall detaillierter zu besprechen. Ich bin der Produktmanager für Google Cloud Bigtable. Wenn Sie das Kontaktformular verwenden, erwähnen Sie meinen Namen in Ihrer Nachricht, um sicherzustellen, dass er an mich weitergeleitet wird. Sie können mich auch über LinkedIn erreichen.
Viel Glück mit Ihrem Projekt!