Y-Wakuta commented 5 years ago

頂いたコメント

NoSEですが column family を複数使ってクエリに応答するケースの join コストが，objective function に含まれてないように思います．本来，複数のcolumn family をジョインするコストは極端に大きいので，1つの column family で表現するようにするか，secondary index を使うかしないといけないと思います．1) 1つのCFを使うケース，2) SI + CF のケース，3) CF+CFのケース，これらのコストモデルを少し精緻にする必要がありそう．

いや，Cijは get operation 数を考慮して決定されるため，ジョイン結果の cardinality を予測して Cij を決定してるので，問題なさそう．

NoSE’s plans involve only a single get from the first column family in each plan. Thus, n = 1 for the first column family. The number of get operations for the next column family depends on the number of results returned from the get on the first column family.

一方で，secondary index を利用する際には，secondary index を利用する際の get の呼び出し数 n ＋ the next column family を使った結果の返却数 w だけを計上するべき(secondary index の返却数と next column family の getの呼び出し数は，共に通信コストを生まないため)．

Y-Wakuta commented 5 years ago

cassandra上のテーブルではpartition keyは一意なので、NoSEの条件である等号条件を使用したgetでは一行しか帰ってこない。これをNoSEの論文ではn=1に言っている。そして１つのrowの中にn個のcolumnが合った場合に次のcolumn familyに対してn回のgetが発行されることを言っている。

そして、上記の処理をCF+CFで行うと、１つ目のCFの結果を全てのnodeに対して行う必要があるため、非常に効率が悪い。一方、SI+CFの場合はSIの結果は１つのnodeの中で完了するため、効率が良い。

Y-Wakuta commented 5 years ago

[ ] 分散環境において、単独のCFを使用する場合に対してSI+CFを使用する時のcostは単純に2倍では無いと思われるので、具体的な確認を行う。

Y-Wakuta commented 5 years ago

各 Query Planについて考察

diskIOに関しては別のIssueで対応するためここでは無視

CF単体

アクセス時にネットワーク通信コスト
現状のNoSEのcost関数のままとする
結果の再送にネットワーク通信コスト

CF + CF

アクセス時の通信コスト
現状のNoSEのcost関数
結果の再送にネットワーク通信コスト
一件目の結果件数 * (ネットワークアクセスコスト + 現状のNoSEのcost関数 + 再送時の通信コスト)

SI + CF

アクセス時の通信コスト
SIだが現状のNoSEの通信コスト？
ノード内のアクセスなので次のCFへのアクセスコストは無視するか
再送時の通信コスト？

Y-Wakuta commented 5 years ago

CF,CF+CF,SI+CFにおけるクエリの手順について.pdf

Y-Wakuta commented 5 years ago

NoSEは以下の式でcostを評価している

step.cost = get_num × get_cost + width × width_cost

ここで、この式の$get_cost, width_cost$の値をSIを使用する場合にそれぞれ低く設定したい。そこで、２つの変数、$client_db_network_cost,si2cf_cost$を設定する。そして、それぞれの変数の値を低く設定する時は

(変数) * (si2cf_cost / (client_db_network_cost * width))

として低く設定するのはどうか。次にどのようにこの２つの変数の値を取得するかについて以下の方法が考えられる。まず、実験設定としてCassandraのノードは１つに設定する。そしてその１つのノードに対して単純にCFにQueryを行う場合と、SIを使用してCFを行う場合の差をsi2cf_cost と考えられる。ただし、ここで、primary key とSIを貼る対象の属性は同じ特徴を持つ属性でないと公平ではなくなる。

Y-Wakuta commented 5 years ago

Y-Wakuta commented 5 years ago

si2cfCostにも1の結果のレコード数の積が掛かるはずだが、DBのノード内の話なので、クエリをその件数分発行することと比べたら無視できるということで上記の方法で進める。

Y-Wakuta commented 5 years ago

SASIのクエリ実行時間がなかなか安定しないので、別Issueに切り出して計測する。

Y-Wakuta commented 5 years ago

変数類は #71 で計測することにしてこのIssueを閉じる

Y-Wakuta / nose_index

CF+CFに対するCF+SIのcost計算について #39

頂いたコメント

各 Query Planについて考察

CF単体

CF + CF

SI + CF