Googleが開発した分散型データベース論文は公開されているが、OSSではないKVSとRDBが合体したような特性を持っている開発当初はKVSだった従来のRDBと互換性があるわけではないので、New SQLとか呼ばれていることもある最初のSpannerの論文が2012年に公開されているので、Googleはそれ以前からSpannerを利用しているGoogle Cloud Spannerとして登場したのは2017年
こんにちは。ymtdzzzです。 Zennの書き味にハマってしまい、個人ブログではなくこちらで書いちゃいます。 今日はSpannerとGoの話。 RepositoryパターンでWebアプリケーションを実装するときは、どこでトランザクション管理を行うかが論点になることが多いですが、恐らくServiceとかUsecase層(infraを意識しないビジネスロジックを扱う層)で行いたいのが通常かと思います。 ただ、Spanner Clientでトランザクション管理を行いたい場合、依存性を排除するのが難しくなってきます。 下記のように、トランザクション境界がライブラリの機能に閉じるため、どうやってそれを抽象化するかというのがポイントになってきそうです。 // この辺の扱いを抽象化したい _, err := client.ReadWriteTransaction(ctx, func(ctx conte
4.2.1 Shardingの手法 先ほどの表1を理解するにはSharding手法の列にあげられた各用語の理解が必要となる。 YugaByteDBのブログ「Four Data Sharding Strategies We Analyzed in Building a Distributed SQL Database」には、非常に詳しくShardingの手法が紹介されている。この記事では、大きく以下4つの分類があるという。 Algorithmic Sharding (例: Memcached/Redis) Linear Hash Sharding (例: 過去のCassandra) Consistent Hash Sharding (例: DynamoDB、Cassandra) Range Sharding (例: Spanner、HBase) 詳細は割愛するが、1つ目のアルゴリズム・シャー
この記事では Cloud Spanner の並行性制御が何であるのか、結果として何を実現しているのかを見てから具体的なロックの実際の挙動について追っていく。 なお分散システムとしての話はあまりないので期待しないように。 この記事では実際の挙動を確認しながら書いているつもりだが、 2021年3月現在の挙動がサイレントに変わることもあることには注意してほしい。 TL;DR Cloud Spanner はロックフリーな Read-Only Transction と、堅実にロックを行う Read-Write Transaction の2つのアクセスパスを持ち、 ROMV と呼ばれる方式に最も近い。 その他技術との組み合わせの結果として分散システムでありながら Serializability と Linearizability を兼ね揃えた理論上最も強い一貫性を実現しており、 Google はそれを
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く