Twitterでつらつら考えてたのでブログにもまとめ直してみる。2018理想的なイメージは1会員で1DBを割り当てて全てストアドプロシージャで処理すること。自分でユーザIDとかでシャーディングすればできなくは無い気がする。こんな事が出来ると嬉しいテーブルのレコード単位で細かくロックを制御する必要は不要でテーブルを超えてユーザID単位でロックが掛かって欲しいデータをDBサーバやアプリサーバに取得する処理が無駄なのでストアド的(というかイメージはSpark)にデータがあるストレージで処理して欲しい上記を効率的に実現するためにユーザID単位のデータは全て同じストレージに居て欲しい。あとマスタテーブルは全てのストレージに居て欲しいユーザ単位でロックを掛けると一部の処理は少し長めのとある処理より優先したい時はあるのでトランザクションを割り込ませて既存ロジックは再実行したいそうは言っても集計処理はしたいのでHANAがしてるみたいに分析が得意なDBにリアルタイム連携したいインサートやデリートでインデックスのロックとか他のレコードに影響を与えないで欲しい。もって以下のことは許容できる極端な低レイテンシーは要らない。ビジネスロジック混みで数百ms(もちろんロジック次第では数秒)程度で良い。強い一貫性の保証は同一ユーザIDのものだけで良い分析用DBへの連携は非同期で数秒程度の差分があっても大丈夫。集計だしwhere句は無くても良い。ユーザ自体が瞬時に大量に増えた時にユーザ登録処理速度が低下するのは仕方ない。