頑張る~。
Bigtableについて
Big tableの特徴
YouTube、GoogleMap、Gmailなどのバックグラウンドとして利用されているのBigtableとのこと。
NoSQLで数百ペタバイトのデータでもさくさく扱えるフルマネージドサービスになっている。
セキュリティについてはKMSと連携しストレージレベルで暗号化されているようなので、内部犯とか変に乗っ取りとかされなければ安心。
Big tableの最適な用途
基本的にはめっちゃデータが流れてくるようなシステムに向いている。
・IoTデバイスで常に大量のデータを取得するようなシステム
・株価のデータ取得など秒単位でデータが来るよう名システム
ちなみにBigQueryは分析用のサービスなので、大量のデータ処理自体は向かないのには注意。
Big tableのパフォーマンス改善施策
Big tableはアクセスの学習をしているようで、稼働してしばらくはパフォーマンスが遅い(といってもそれなりには出るんだろうけど)
ということで、パフォーマンス改善施策としては
・しばらく置いておいてアクセスについての学習時間を設ける
・データ数をそれなりにそろえる
・ディスクをSSDにする
・リージョン、ゾーンをアプリケーションと同じにする
・スケールさせる
あたりがパフォーマンス改善施策として考えられる手法。下3つは大体定番だよね。
DataStoreについて
DataStoreのデータ構造
DataStoreもNoSQLのスキーマレスなデータベース。スキーマレスとはRDBのようにテーブル構造を指定しないデータベースのこと。
なので、基本的に色々なものを格納することが出来る。
データ構造としては、カインド、エンティティ、キー、プロパティという言葉が出てくる。
それぞれの意味は本家から引っ張ってきた以下を参照。
https://cloud.google.com/appengine/docs/legacy/standard/go111/datastore?hl=ja
個人的にはKeyがRDBの主キーと一致する感覚はないんだけど、そういうことなのかしらね・・・?
強整合成と結果整合性
結構ややこしく感じた。Cloud Storageでもこの考え方がある。DataStoreはデータベースなので、アプリにどのような挙動を求めるか、について検討することが重要になる。RDBでいうダーティリードとかファントムリードとかそういうこと。
強整合成 | データを検索したときに常に新しいデータが取得できるようになること |
結果整合性 | データを検索したときにそこまで正確性が求められないようなもの |
その他サービス
Deployment Manager
GCPリソースのデプロイをyaml形式で記述し、このサービスでデプロイをすると、いい感じにデプロイ管理をしてくれる。
IaaC(Infrastracture as a Code)ってやつだね。XaaX系はばずわーどっぽくてあんまり好きじゃない。
DMはデプロイについて管理をしてくれるだけなので、作ったインスタンスのスケールとかそのあたりは自前でやらなくてはいけないことに注意。
同じものを作ってチームで共有したり、同じものを何個も何個も作ったりするときにいちいちコンソールをいじってたら面倒だし、間違う可能性があるよねってシーンで力を発揮するサービスだと思う。
DataFlow
Apache Beam踏襲のパイプラインサービス。ETL処理とかCloud Storage、Big Queryとかにデータを流し込んで処理をしたい、みたいなときに重宝するサービスになっている。概ね色々なサービスと連携可能で、Pub/subやBig tableについても利用できる。
ほかにもDataProcと呼ばれるサービスがあるけど、こっちはHadoopとかSparkとかいうキーワードと一緒に出てくるので試験としてはわかりやすい。
Cloud Function
FaaS(Function as a Service)。処理したい関数をこのサービスに登録しておくと色々なトリガーを検知して関数を実行してくれる。
基本的には短時間で処理できるようなものが望ましく長時間かかる処理については別サービスで処理したほうがよい。
(Calculatorで試算してみたら結構コストが高めだった。)
トリガーはCloud Storageにデータが入ったとかPub/Subのトピックにデータが入ったとか、そういったものをトリガーにして関数を処理することが可能。
DataFlowを使うまでもないようなときはこっちを使うといいかもね。