Next ’17 Extended - Tokyo #GoogleNext17 #gcpug

mokelab @mokelab

ほんとにすごいのは、ネットワーク #GoogleNext17

そな太 @sonatard

Spannerの論文 Spanner, TrueTime and the CAP Theorem research.google.com/pubs/pub45855.… #GoogleNext17

mokelab @mokelab

Spanner、フルマネージドでグローバルスケールのサービスだよ SQLかけるよ Google Playとかで実績あるよ #GoogleNext17

mokelab @mokelab

SQL 2011に対応してるよ メジャーな言語のライブラリや、JDBCドライバもあるよ #GoogleNext17

_ @apstndb

Spanner の説明、マーケティング上 C と A 両方満たした CA だと言っているけどやはり最終的には CP システムという認識 #GoogleNext17

mokelab @mokelab

Spannerは、Zoneというモノで管理をするんだねー 1つのZoneに更新がはいると、複数のZoneに更新が伝搬するんだねー #GoogleNext17

_ @apstndb

Interleaved Table 周りは実物触る金がないし Cockroach DB とかで学ぶかなーという気持ち #GoogleNext17

mokelab @mokelab

どの製品を使えばいいのかは、フローチャートがあるんだね #GoogleNext17

mokelab @mokelab

MySQL/PostgreSQLにあるデータ型は、対応する型があるよ #GoogleNext17

mokelab @mokelab

テーブルはいろんなところに配置されちゃうので、「似たようなものは同じとこに置こう」 #GoogleNext17

mokelab @mokelab

プライマリーキー タイムスタンプのようなシーケンシャルなキーは避けよう。データの偏りが起きちゃう。 実世界の識別子を使おう #GoogleNext17

_ @apstndb

さっきのデータベース選択周りのチャートはどこにあるんだろう。表はあるんだけど… #GoogleNext17 cloud.google.com/storage-option…

しんめたる @sinmetal

裏側はBigtableみたいなやつがいるので、Keyは分散させたほうがいいね！ #GoogleNext17 #gcpug

そな太 @sonatard

Spanner テーブル間の連携を記述すると同じノードで動く そうしないとjoinで通信が必要になり性能が落ちる #GoogleNext17

そな太 @sonatard

Spannerでキーにタイムスタンプを入れると同じサーバにアクセスが行くので性能が落ちる #GoogleNext17

mokelab @mokelab

1MiB〜5MiBの更新毎にコミットしたほうが、効率よくなるよ セカンダリインデックスを作る前にロードしよう #GoogleNext17

okada @ocadaruma

Spanner、よく分散するキーを選ぶみたいなのはやっぱり考える必要があると #GoogleNext17

mokelab @mokelab

Joinの種類 ひととおりサポートしてるよ #GoogleNext17

s.hiruta @web_se

プライマリキーを利用して、キーはできるだけ散らす、 1M〜5Mでコミットするあたりは、いかに書かれています。cloud.google.com/spanner/docs/b… #GoogleNext17

okada @ocadaruma

STORINGディレクティブで、インデックスと実データを同じノードに置くようにすると。。うーん #GoogleNext17

mokelab @mokelab

クエリのヒントもかけるんだ #GoogleNext17

mokelab @mokelab

デモタイム！ #GoogleNext17

Shoko@育休中 @_okohs

Spanner一通り高機能なのはわかったけど、これを選びたいユースケースはデモで知る感じかな。 #GoogleNext17

Shoko@育休中 @_okohs

おいくらかかるのだろう・・・ #GoogleNext17

mokelab @mokelab

コマンドラインでも作業できるよ #GoogleNext17