我参加了 Coursera 的 “Getting Started With Application Development” 课程，并记录了一些笔记（包括 Datastore，Bigtable，Cloud Spanner 等）

1 年 ago
新, 韵
3 minutes

以下是相关的文章。

    • ?Getting Started With Application Development(Datastore, Bigtable, Cloud Spanner, etc)

Securing and Integrating Components of your Application(IAM, IAP, Pub/Sub, Cloud Endpoint, Cloud Function, etc)
App Deployment, Debugging, and Performance(Cloud Build, App Engine, Cloud Monitoring, etc)

云软件开发工具包，云客户端库和Firebase软件开发工具包

    • Cloud SDK

gcloudコマンド(create/manage GCP resources) e.g. gcloud compute instances list

bqコマンド
gsutilコマンド(for cloud storage)

Client Libraries

Google API Client Libraries should only be used if your programming language of choice isn’t supported by the Google Cloud Client Libraries
Cloud SDKのみ、gRPC通信を採用

Firebase SDK

结算

为了防止意外超支。

    • budgets and alerts

予算を金額で設定する。その50%, 90%, 100%使用時にアラートが飛んでくる

billing exports

Cloud StorageやBQに吐き出せる

reports

GCP上で確認できる。

quotas

Projectレベルでリソースごとにリソースの使用料で指定する。指定量に達するとリソースが使用できなくなるという認識。

rate quotas (その時点から一定期間以内の使用量が一定値をを超えているか)
allocation quotas (その時点までの全使用量が一定値を超えているか)

数据库

云数据存储

    • NoSQLで、スキーマレス

 

    • 保持するデータの大きさによって自動でスケールする

 

    • Data がsemi-structured/hierarchical の時におすすめ

See: https://qiita.com/hogedigo/items/175d5a4afd0fd0fe9de6

shardingとreplicationを自動でやってくれる
ACID transaction, SQL like query, Indexes
元々はBigtableの拡張版として誕生したが、今ではFireStorの中の１モードとなっている。(FireStoreDataStore mode)

ちなみに、FireStoreは、DataStoreモードとNativeモードの二つがある
一度モードを選択すると、そのプロジェクト内ではそのモードしか使えなくなる

クエリ言語はGQL
serializable isolationに対応しているらしい。

关于数据保存方式。

    • data objectはentityと呼ばれている。

entityはuniqueなkeyを持つ。key=namespace + entity kind + identifier + ancestor path(optional)

トランザクションとは、最大で 25 個のエンティティグループ内の 1 つ以上のエンティティに対する一連の Datastore オペレーションです。(= 複数のエンティティーをひとまとめにして、transactionが有効になるという認識、またtransactional commitを有効にする必要があるという認識)
entityは他のentityをparentとしてもてる。親を持たないentityはrootと呼ばれる。自分より親側はancestors, 子側はdescendantsと呼ばれる。entityと他のentityとの間のpathは、entity pathと呼ばれる。
同一のkind(RDBでいうテーブル)内でもentityによって異なるpropertyを持つことが可能

datastoreに、built-in indexと、composite indexesという二種類のindexを持つ。

事前にindexを貼ったpropertyを指定したクエリしか実行できない
built-in indexは、GCP上に表示されない、entityのそれぞれのpropertyにデフォルトではっつけられる
composite indexを新しく作成するするには、index.yamlを編集し、$ gcloud indexes createを実行する
composite indexを削除するためには、index.yamlを編集して不要なものを削除し、$ gcloud datastore indexes cleanupを実行する(put操作)

image.png

关于分片。

（分片=垂直分区）

    • Datastoreでは、一つのentityに対する操作は、マックスで毎秒一回にしたい。

超えると、latencyが大きくなったり、contention errorが発生したりする

Datastoreでは、データサイズによって自動でシャーディング(=スケーリング)してくれる

如果有需要进行分片操作的重型案例的话，我很高兴地将其引用。确实，如果是读操作较为频繁的情况下，复制是一个很好的选择。

image.png

只是为了“防止对特定实体进行过多读写操作导致热点现象发生”，而不是单纯为了加快单个读写操作的目的。

关于DataStore来说，似乎不需要考虑热点问题来进行写入。

image.png

关于查询

image.png
    (クエリのバッチオペレーション)Batch operations allow you to perform multiple operations on multiple objects with the same overhead as a single operation.

500/50/5 规则（逐渐增加流量）

逐渐增加流量到键空间中的新类型或部分。

为了给Datastore模式下的Firestore充足时间准备增加的流量，您应该逐渐增加对新类别的流量。我们建议新类别的最大操作数为每秒500次，然后每5分钟增加50％的流量。按照这种增长计划，理论上您可以在90分钟后达到每秒740K次操作。请确保写操作在键范围内相对均匀分布。我们的SRE称之为”500/50/5″规则。

image.png

云大表

    • high performance, NoSQL database service, 列指向DB

 

    • sparsely populated table (列を使用していない行では、列による空間の消費はありません)

 

    • can scale to billions of rows and 1000s of columns.

 

    • can store terabytes to petabytes of data.

 

    • built for fast key value lookup and scanning over a defined key range. (keyによる検索はできるがカラム指定による条件検索はできない、key-value)

 

    • データの結合(JOIN etc)はできない

 

    • key updates to individual rows are atomic.(行ごとにしかatomicにならない、、)

 

    • offers seamless scaling. Changes to the deployment configuration are immediate so there’s no downtime during reconfiguration.

 

    • 行と列の交差には、タイムスタンプ付きのセルを複数含めることができます。各セルには、その行と列のデータに付けられた、タイムスタンプ付きの一意のバージョンが格納されます。

 

    • HBase(BigTable を元に設計されたOSS)と同じAPIを持つ。 Bigtableの方がHBaseを自前で立てるよりも優れている点は以下。

マシンが簡単に増やせるのでscalabilityに優れている
upgradeやrestartを自分でしなくて良い。
データが暗号化されているのでよりsecureである。
IAMポリシーを利用して誰がどのデータにアクセスできるかをコントロールできる。

Dataの持ち方はCassandraに似てる

image.png
image.png
行キーは、データの取得に使用するクエリに基づいて設計します。
適切に設計された行キーは、Bigtable のパフォーマンスを最大限に高めます。
Bigtable のクエリでは、次のいずれかを使用してデータを取得するのが最も効率的です。

- 行キー
- 行キーの接頭辞
- 開始行キーと終了行キーで定義された行の範囲

その他のクエリでは全テーブル スキャンが行われるため、効率が大幅に低下します。
設計の段階で正しい行キーを選択すれば、後で面倒なデータ移行処理を行わずに済みます。

最佳实践 (zuì jiā shí

请参考：https://cloud.google.com/bigtable/docs/schema-design#best-practices
需要特别注意行键?
以下只提取了一些易于理解的内容。

小さなテーブルを多数作成することは、Bigtable ではアンチパターンになります。

1 つの行に 100 MB を超えるデータを保存しないでください。

この上限を超える行があると、読み取りパフォーマンスが低下する可能性があります。
保存可能な上限は 256MB

1 つの行キーは 4 KB 以下にする必要がある

エンティティのすべての情報を 1 行に保存します。 <- 行をまたいだtransactionは作成できないので

関連するエンティティは隣接する行に保存して、読み取り効率を高めてください。

読み取りと書き込みは（テーブルの行スペース全体に）均等に分散されるのが理想的です。<- 書き込み時にも、行keyを元に挿入場所を探すことに注意

行キーに関して以下は避けるべし

先頭がタイムスタンプである行キー

writeが単一のnodeに集中する

関連データをグループにまとめられない行キー

言わずもがな、行範囲が連続していないと、まとめて読み取ることが非効率になります。)

ハッシュ値

デバッグしづらい
(c.f. [CloudSpannerでは、主キーをハッシュにするのは推奨されている方法の一つ]

シーケンシャル数値 ID

user idとか、新規のユーザーのほうがアクティブなユーザーになる可能性が高いため、このような方法では、大半のトラフィックがごく少数のノードに集中してしまいます
数値を反転させたらOK.(https://cloud.google.com/spanner/docs/schema-and-data-model))

頻繁に更新される識別子

使用頻度の高い行が格納されているテーブルが過負荷状態になります。また、ガベージ コレクションの際にセルが削除されるまで列の以前の値が容量を消費するため、行のサイズが上限を超えてしまう可能性もあります。
代わりに、新しく読み取るごとに新しい行に保存します。

image.png

云数据管理器

image.png

云数据库

image.png

云存储

image.png

在上述存储类别中，数据存储适用于最低存储时长。您可以在达到最低存储时长之前删除文件，但在删除时，会按照文件被存储的最低时长计费。

持恒不变

以下是强一致性

    • Read-after-write

 

    • read-after-metadata-update

 

    • read-after-delete

 

    • bucket listing

 

    • object listing

 

    granting access to resources.

以下是最终一致性。

    • revoking access (1分くらいかかる)

 

    accessing publicly readable cached objects (キャッシュのライフサイクルが期限切れになるまでは変わらない)

终点

image.png

在cname记录中，写有为域名取的别名。

组合对象

最大32のobjectをconcatanateして、一つの新たなobjectを作成することができる

新しくできたobjectは元のobjectを参照しているわけではなくコピーしているので、元のオブジェクトは削除して良い
これにより、大きなobjectをchunkに分けてparallelにアップロードすることができる。

ただし、一回でentire objectをuploadできるのなら、そちらの方が、costはかからないし、overheadも少なくて済む

交通的最佳实践 de

    • retryポリシー

gsutil, client libraryを使ったリソース取得のretryポリシーは、 truncated exponential backoffを採用すべし。

cloud consoleでのリソース取得は、実は内部でbackoffをするように実装されている。

截断指数退避是指当失败次数超过某一固定值时，设置等待时间上限的方法。例如，当失败次数N超过10次时，进行截断处理，无论是第10次失败还是第16次失败，选取的等待时间都限制在[0, 2^10 – 1] = [0, 1023]的范围内。不会因为是第16次失败就从[0, 2^16 – 1]范围内选择。
    • request rate

1000 write per sec, 5000 read per secを超える場合には、20分にリクエスト2倍を上限にリクエストを増やしていく。

保留政策

保留政策是什么？（虽然以下不是来自GCP的说明，但我选择了最容易理解的引用）

通过指定的时间范围，防止内容被完全删除。管理员可以创建保留策略并将其分配给特定文件夹或整个公司。使用保留策略可以在必要的时间段内保留数据，并在法律上不再需要保留数据时自动完全删除内容。

    • objectごとに指定される。

 

    • objectにretention policyが貼っつけられている場合、そのリソースを削除、変更することはできない。このpolicyをlockすることで、保持期間の削除、短縮化ができないようにできる。

 

    bucketは、その中の全てのobjectがretention periodを超えるまで削除できない。

启用GCS资源的终端节点CORS。

你只需要准备一个指定允许跨域请求共享的源的 JSON 文件，并执行 $ gsutil cors set xxx.json 即可。

对于发送到S3端点的请求的响应头中，可以认为会正确指定请求页面的来源主机名作为Access-Control-Allow-Origin。

GCS的访问控制（授予权限）

    • uniform bucket-level accessが理想。

これを使用すると、domain restricted sharingや、IAM conditionsを使用することができるようになる。

数据验证在转移过程中

验证不是必需的。

アップロード時には、クライアントサイドで計算したCRC32c hash か MD5 hashをアップロードのリクエストに含める。Cloud Storageは、このハッシュ値と受け取ったオブジェクトから計算したハッシュ値が一致する場合のみ、そのオブジェクトを作成する。

ダウンロード時には、レスポンスに含まれているrepoted hashと、受け取ったオブジェクトから計算されたハッシュ値を比較してオブジェクトのデータが損失なく受け取れたかを確認できる。

由于MD5哈希函数会根据整个对象计算出一个值，所以在传输复合对象时无法使用。

计算哈希值的方法有以下几种。可以使用`gsutil hash`命令来计算本地文件的哈希值。
使用Boost（C++）、crcmod（Python）、digest-crc（Ruby）等工具可以计算CRC32c哈希。

总结

image.png
image.png

数据保存位置

|云存储|数据存储|大表|云数据库|Spanner|
|—|—|—|—|—|—|
|区域/多区域|区域/多区域|分区|区域|全球|

这一带的数据库比较可以参考https://cloud-ace.jp/column/detail95/ ，看起来很简单易懂。

记事

短暫错误和长期错误的处理设计模式

    • Transient Errors → Exponential Backoffで対応

 

    Service Availability Errors → Circuit Breaker Patternで対応

选择地区的方法
( Xuanze dizhi de fangfa)

数据库位置会影响成本和可用性。如果要降低写入延迟和成本，可以选择区域位置；如果要提高可用性，即使成本增加，也可以选择多区域位置。

✖
广告
将在 10 秒后关闭
bannerAds