mercari/datastore実戦投入
DatastoreについてみなさまGCPをお使いになっているでしょうか。 GCPにはバックエンドのDBとしてCloudSQLというRDBと、NoSQLであるDatastoreというのがあります。 周囲の事例を聞く限りは、マスターデータなど変化が少なかったり、seedデータ的なものを用意しなければならないものをのぞいて、基本的にDatastoreを利用している印象です。 また、GAEで開発する場合はinternalなAPIからDatastoreを利用できる一方、GKEなどからは、GCPの外部向けAPIを呼び出すことでデータを送受信します。 さて、自分はいつもGoでAPIを書くのがいいよ！と触れ回ってるわけですが、GCP上で開発を進める際には前述の通りDBにはDatastoreを使っています。 このDatastoreですが、そのまま使うと自前でキーを発行する必要があったり、値をキャッシュしたり
ぼくが かんがえた さいきょうの でーたすとあ らっぱー - Qiita
ソウゾウ社の社内勉強会Go Friday 第60回用の資料です。 本来Go Fridayでは資料作ったりとかの事前準備はせんでええわいということになってるんですが素手で「ええやんこれ〜〜」という感想を引き出せる気がしなかったので作りました。 go.mercari.io/datastoreの話です。 今日話すこと なぜ最強なのか。いかにして最強なのか。これからの最強。 ほしい理由 解決方法 実装方法(めんどいのでGo Friday中で口頭で説明) 設計上の判断と移行の注意点 これから実装する機能 Datastoreって何？ Googleのやつ。 appengineユーザなら誰しもお世話になってるはず。 ラッパがほしい理由 つらいこととかめんどくさいこととかが色々ありそれを解消したい。 →よろしい！ならば自分でラッパーを作るしかない！ つらポイント1 type PropertyLoadSave
DatastoreとFirestoreとApp Engineの関連 - Qiita
注意書き この記事は2017年12月の記事です。 現在、Google Cloud FirestoreはUPDATEされて、以下の内容とは異なります。 新しい記事はお待ち下さい！ 記事 Cloud Firestore がBetaで公開されました。 Cloud Firestoreは、Firebase Realtime Databaseの後継に当たるサービスです。 Firebase Realtime DBに存在していたリアルタイム更新やデータベースルール, オフライン機能や、Firebase Authとの連携などを受け継いでいます。 大きく変わったのはバックエンドです。 Firebase Realtime DBは、もともとGoogleが作ったものではなく、Googleが買収したサービスでした。 買収後、FirebaseはAuth, Push通知, Analytics, Remote Config
GAE/Go＋Datastoreで楽にお安く総件数を取得する - Qiita
Google Cloud Datastoreは一般的なRDBMSに比べると使えるクエリの柔軟性がありません。特にGAE初心者が困惑する点の一つが、SQLのCOUNT関数相当の機能が用意されていないことです。 「正確な件数なんて大抵の場合不要な情報だろう」というのがGoogleの中の人の考えなのかもしれません。実際、GoogleのプロダクトはGoogle検索にせよGmailにせよ件数表示が適当なものが多い気がします。その方針を貫き通せるならそれが一番いいような気もしますよね。 とはいえ、Datastoreを使っていてCOUNT関数が欲しくなるときもあるでしょう。できるだけ労力をかけず、かつできるだけGoogleさんにお金を払わずにDatastoreクエリの件数を取る方法について調べてみました。 統計用のkindを利用する 特定のkindのおおよその総件数を知りたい場合、Datastoreの統
Datastoreにpythonで触ってみたメモ - Qiita
ここ半年くらい前から少しずつ、GCPのDatastoreを触っています。 今更ながらDatastoreを触ってみた雑感をメモしてみます。 DynamoDBとの比較とかしたいですが、ほとんどNoSQLの特徴的な感じです。 あまり、RDB->KVSの時の設計指針や思想の転換について教えてくれる記事とかなかったのでまとめてみました。 「RDB技術者のためのNoSQLガイド」 こういう本にある程度書かれているのかな、と思いますが、Datastoreのことは載ってなかったような気がします。。 ちなみにGAE/pyから触っています。 RDBの概念との対応 まずは基本の用語の整理から。 データベース新基礎知識 Googleの巨大分散データストアBigtableとDatastoreを理解する （4/12） この記事に書いてありましたが、 datastore RDB らしいです。 Datastoreの特徴
（2018/2/26 追記）Datastore/Go のデータ設計のコツ - pospomeのプログラミング日記
僕の Datastore の記事は Cloud Datastore/AppEngine Datastore 時代のものなので、現在の Firestore の Datastore mode だと一部の内容が正しくないと思うので注意してください。(´・ω・`)— pospome (@pospome) March 24, 2021 Datastoreを使っていて、 ある程度コツとか注意点みたいなものが分かってきたので、 まとめてみました。 継続的に追記していく予定です。 間違っているところがあれば コメント or twitter で教えてください。 Datastoreの entity, kind などの用語は理解している前提です。 ParentKeyに気をつける Go では Filter による OR, IN 検索ができない 文字列に対する LIKE 検索がない 結局どんなクエリが発行できるのか
スケーラブル GCP アーキテクチャ
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
GAE Datastore の Single-property Index と Composite Index は全く違うものと理解する - addsict's blog
Datastore の Single-property Index と Composite Index はどちらも似たようなものだと思っていたのですが、実際のところはかなり違う性質をそれぞれ持っていることが段々とわかってきたので、現時点の自分の理解をメモしておきます。 恐らく Cloud Datastore にも該当する話だと思います。 Datastore のインデックスの種類 Datastore には2種類のインデックスが存在します。 Single-property Index (Built-in Index とも呼ばれる) Composite Index (Custom Index とも呼ばれる) このうち Single-property Index はデフォルトで全てのプロパティに有効になっているインデックスであり、Entity を保存した段階でそれぞれのプロパティに対応するインデッ
Google Cloud Datastore Masakari Talk - Qiita
Datastore Masakari Talks で Google Cloud Datastore について話をしてきました。 その時のスライドの内容に多少の補足をいれつつ、ここにまとめておきます。 なお、Masakari Talk ということで弱点や注意点だけを取り上げてていますが、Google Cloud Datastore はスケーラブルな分散データストアでありつつ、単純な KVS にとどまらずクエリで検索できるし、 ACID トランザクションもあるしで、とても優秀なデータストアです。 SQLっぽいけど、SQLではない JOIN, GROUP BY, OR, 集計関数(MAX, MIN) などが無い。 基本的にインデックスを使って最小限にスキャンして、必要なエンティティを取ってくるデータベース。BigQueryと違ってフルスキャンではないので、集計やORなど出来ない。 クエリにはイン
GAEでハマったこと(´･ω･`) - Qiita
はじめに 2年前のAdvent Calendarで、GAE/Goのハマったところ(´･ω･`)という記事を書きました。 当時betaだったGAE/Goもその後めでたく正式リリースされ、最近では徐々に大きな会社や案件での採用事例も聞こえるようになってきました。数年前の状況を考えると涙がちょちょぎれる程感慨深いです(ToT) 2年前の記事ではGAEのGo SDKに特化したハマりポイントを紹介しましたが、今回はGAE(Google App Engine)自体のハマりポイントを書こうと思います。最近GAEを使い始めた人も多いかと思いますので参考になれば幸いです。 注：GAE runtime共通の話題を取り上げますが、コード例はGAE/Goで書きます Datastore Index爆発でハマった(´･ω･`) GAE Datastoreではカスタムインデックスを作ることで、通常では行えない条件の検索
GAE Datastore について - Sojiro's Blog
同一 kind の entity でも違う property を持ちうる それぞれの entity は同名の property でも型の違うデータを持ちうる Other storages 複数の table の join や 複数のカラムに対する不等号比較など、すべての SQL 操作が必要なら Google Cloud SQL ACID transaction を必要としないスキーマレスなデータを扱うなら Google Bigtable オンラインで分析されるデータを扱うなら Google BigQuery 画像や動画などの変更がない大きなデータを扱うなら Google Cloud Storage Entities ひとつの entity は1つ以上の property をもつ property は1つ以上の値を取りうる Keys key は entity を特定する key は以下を含む
GAE/Goのdatastoreの挙動について - Qiita
GAE/J+Slim3の語彙・知識を元にここに解説を書く。 GAE/Goの知識とGo言語の知識が混ぜこぜで書かれているかあまり気にしてはいけない。 以下の調査結果を得るためのテストコードはここに置いた。 EntityにKeyは付属してこない structを定義する時に、そのstructに自分自身のKeyを持たせる方法はない。 EntityにIdまたはNameを自分で定義して、Putする時、Getした後にそこに忘れずにId, Nameを取り出したり移し替えたりして頑張る。 これを自動でやってくれるライブラリがgoonである。 IncompleteKeyはPutした後でも値は変わらない key := datastore.NewIncompleteKey(c, "Test", nil) newKey, err := datastore.Put(c, key, foo) // keyはIncomp
想定の50倍ものトラフィックが発生したPokémon Go。基盤となったのはGoogle CloudのCloud DatastoreとGoogle Container Engine
想定の50倍ものトラフィックが発生したPokémon Go。基盤となったのはGoogle CloudのCloud DatastoreとGoogle Container Engine Googleは9月29日付のブログ「Bringing Pokémon GO to life on Google Cloud」で、Pokémon GoのインフラとしてGoogle Cloudが使われており、サービス開始後に想定の50倍ものトラフィックが押し寄せてきたことを紹介しています。 下記のグラフのオレンジ色の線が当初の想定（Original Launch Target）、赤い線が想定していた最悪のケース（Estimated Worst Case）です。しかし現実にやってきたトラフィックは緑路の線（Actual Traffic）でした。 当初の想定よりも5倍余裕を持って最悪のケースを想定していたところに、実際
(2016年7月)GAE Datastore writeのコストが下がってるか試してみた - Qiita
2016/7/1からCloud Datastore(GAEのDatastore)の課金体系が変わりました。 従来はオペレーション単位で課金されていて、例えば1エンティティ書き込んだとしてもsingle property indexやcustom indexの書き込みも同時に課金されていましたが、新体系ではエンティティ単位での課金になると言います。 これが本当ならばセコセコとプロパティにnoindexつけて課金を節約する、というバッドノウハウは不要になる！素晴らしい！1 ＼(^o^)／ 詳細は下記URLを参照。 英語版のみ「New Cloud Datastore Pricing Starting July 1st, 2016」というところに書かれています。日本語版は未だ古い情報のみ。GCPはドキュメント翻訳がいつも遅いですよね・・・ (´･ω･`) 引用: 従来writeオペレーションは$0
Google App Engine上のベスト・プラクティス、その１: Datastore
Google App Engine上でアプリを作りはじめて約二ヶ月。いろいろと分かって来たこともあるので、自分へのメモも含めてまとめてみる。まずは、Datastoreの話から。 なによりも大切なのはデータベースの設計 あたりまえと言えばあたりまえの話だが、App Engine上でアプリを作る上でもっとも大切なこと（＝頭を使うべきところ）は、データベースの設計である。特にリレーショナル・データベース（RDB）上でのアプリ作りに慣れた人には、大きな「発想の転換」が必要なので、ここは注意が必要。 特に絶対にやっては行けないのは、 将来RDB上へ移行できるようにレイヤーを作って、その上にアプリを作る RDB上に作ったアプリをデータモデルを大幅に変更せずにApp Engine上に移植する RDBを前提に設計されたフレームワークをApp Engine上に載せて、その上にアプリを作る など。App En
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
