たれぱんのびぼーろく

わたしの備忘録、生物学とプログラミングが多いかも

AWS DynamoDB

f:id:tarepan5884:20180212220823p:plain

DynamoDB では、テーブル、項目、および属性が、操作するコアコンポーネントです。テーブルは項目の集合であり、各項目は属性の集合です。
DynamoDB コアコンポーネント - Amazon DynamoDB

Read

大きく分けて2つのRead方法がある。

  • パーティションキーに基づいて取得
    • ソートキーで絞り込みが可能
    • 代替キーによる場合もこれと同じ
    • queryはこれにあたる
  • 全件取得
    • 取得後、フィルターをして返り値とすることも可能
    • scan はこれにあたる

キーはitemのあるattributeとして設定する.
DynamoDB API - Amazon DynamoDB

DynamoDB は 2 種類の異なるプライマリキーをサポートします。
パーティションキー – パーティションキーという 1 つの属性で構成されたシンプルなプライマリキー。
...
パーティションとソートキー – 複合プライマリキーと呼ばれるこのキーのタイプは、2 つの属性で構成されます。最初の属性はパーティションキーであり、2 番目の属性はソートキーです。 DynamoDB コアコンポーネント - Amazon DynamoDB

パーティション

内部の仕組み
パーティションとデータ分散 - Amazon DynamoDB

クエリの柔軟性: セカンダリインデックス

DynamoDB はプライマリキーを使用してテーブルの各項目を一意に識別し、セカンダリインデックスを使用してクエリの柔軟性を高めます。
DynamoDB コアコンポーネント - Amazon DynamoDB

インデックスは高速化をもたらしてくれる
ただし更新コストが高くつきうるのでお気をつけて.

インデックスは代替のクエリパターンへのアクセスを付与し、クエリを高速化できます。
...
インデックスの作成は慎重に判断する必要があります。 テーブルに書き込みが発生するたびに、テーブルのインデックスはすべて、更新する必要があります。 大きなテーブルでの書き込み量が多い環境では、大量のシステムリソースを消費する可能性があります。
インデックス管理 - Amazon DynamoDB

スループットと費用

DynamoDBは割り当てスループット (処理速度) で料金がおおよそ決定する.
その計算方法がやや独特
docs.aws.amazon.com
docs.aws.amazon.com

キャパシティーユニットをいくつ割り当てるかで最大スループットが決まり、消費量はitemサイズで決まる.

Read

  • GetItem: itemサイズ (4KB単位で切り上げ)
  • Query: 取得itemサイズ合計 (4KB単位で切り上げ)
  • Scan: テーブル内itemサイズ合計 (4KB単位で切り上げ)

Scanはヤバい、でかいテーブルだとキャパシティを大量に消費してしまう.
1読み取りキャパシティーユニットは4KB/sなので、1キャパシティユニット == 小さい1操作 という感覚. scanはヤバい

GetItem – テーブルから単一の項目を読み取ります。GetItem が消費するキャパシティーユニットの数を決定するには、項目のサイズを次の 4 KB 境界まで切り上げます。...
たとえば、3.5 KB の項目を読み取ると、DynamoDB は項目サイズを 4 KB まで切り上げます。

Query - 同じパーティションキー値を持つ複数の項目を読み取ります。返されるすべての項目は単一の読み取りオペレーションとして扱われ、DynamoDB はすべての項目の合計サイズを計算し、次の 4 KB 境界に切り上げます。たとえば、クエリの結果、合計サイズが 40.8 KB になる 10 項目が返されるとします。DynamoDB はオペレーションの項目サイズを 44 KB まで切り上げます。クエリの結果、64 バイトの項目が 1,500 項目返されると、累積サイズは 96 KB になります。

Scan - テーブルのすべての項目を読み取ります。DynamoDB は、スキャンにより返される項目のサイズではなく、評価される項目のサイズを考慮します。
項目サイズおよびキャパシティーユニットの消費 - Amazon DynamoDB

良い資料

www.slideshare.net

docs.aws.amazon.com

Amazon DynamoDBをwebから使う

  1. AWS-sdkから使う
  2. API Gatewayを経由する

1. AWS-sdkから使う

Javascript aws-sdkを用いて認証・アクセスをおこなう.
docs.aws.amazon.com

不労所得スペクトラム

純粋な不労所得なんてほぼ存在しない
メンテの手間をかけないと続かない
だから収入/労働のスペクトラムが、勤労所得と不労所得の正確な理解なのでは

SVG (とD3.js) で線を描く

基本はSVG path.
d3-shapeはpathの作成を簡単にしてくれる

SVG path要素

とても自由度の高いpath.
d属性にコマンドを設定すればかなり自由な線が引ける

developer.mozilla.org

d3-shape

SVG path要素のd属性コンストラクタになる
d3でpath要素のselectionにデータを付け、このデータに基づいてpathを作成できる

This line generator can then be used to compute the d attribute of an SVG path element:
path.datum(data).attr("d", line);

github.com

例:

Connected Dots - bl.ocks.org

d3.js scaleの更新

scaleのdomainやrangeを更新したい、どうすべきか

codes

index.js
Showing the top match Last indexed 5 days ago
7     default as scaleIdentity
8   } from "./src/identity";
9   
10  export {
11    default as scaleLinear
12  } from "./src/linear";  

Search · scaleLinear · GitHub

d3-scale/src/linear.js
export default function linear() {
  var scale = continuous(deinterpolate, reinterpolate);

  scale.copy = function() {
    return copy(scale, linear());
  };

  return linearish(scale);
}

d3-scale/linear.js at 396d1c95fef85241bc3b4b75d747174251ae8e89 · d3/d3-scale · GitHub

linear()は、continuous Scaleをlinearish()でlinear化して返す。要はlinear Scaleを返す.

export default function continuous(deinterpolate, reinterpolate) {
......
  function rescale() {
    piecewise = Math.min(domain.length, range.length) > 2 ? polymap : bimap;
    output = input = null;
    return scale;
  }
  function scale(x) {
    return (output || (output = piecewise(domain, range, clamp ? deinterpolateClamp(deinterpolate) : deinterpolate, interpolate)))(+x);
  }
......
  scale.domain = function(_) {
    return arguments.length ? (domain = map.call(_, number), rescale()) : domain.slice();
  };
......
  return rescale();
}

continuousはscale関数を返す. だからscale(x)でスケーリングできるんだね
d3-scale/continuous.js at 396d1c95fef85241bc3b4b75d747174251ae8e89 · d3/d3-scale · GitHub

社会保険

日本の制度では、医療保険、年金保険、介護保険雇用保険労災保険の5種類の社会保険制度がある。
社会保険 - Wikipedia

医療保険

いわゆる健康保険 (けんぽ)

医療保険 - Wikipedia

技術開発の新規性と生存者バイアス

技術革新 (新しい技術の創出) がなぜ既存プレーヤーから生まれずらいか。
アカデミアを念頭に考えたけど、もっとgeneralな気もする

結論: 技術の未発展さと生存者バイアスが組み合わさっているからおこる
技術の進展は
現時点では不可能 -> 可能だが誰もやっていない ->誰かがやって技術革新
を理論上たどる
なぜ「既存プレーヤーから生まれずらい」という議論は、真ん中の技術レベルの段で議論になるはず
そして誰もやっていないものを作るには「情熱」か「必要性」がいる
「まだ存在しない技術が生き残りに必要」な人間は、第1段階の技術レベルな時代には死んでしまう (退場してしまう)。
ゆえに、第2段階に入ったとき生きているプレーヤーは技術革新をする動機が薄い
なので、この段階で新規参入して「技術がないと死ぬ」状況にあるやつらが技術革新をすることがおおい

のだとおもう