Skip to content

Instantly share code, notes, and snippets.

View kumagi's full-sized avatar
:octocat:
Fine.

Hiroki KUMAZAKI kumagi

:octocat:
Fine.
View GitHub Profile
@kumagi
kumagi / code_reading.md
Created March 12, 2019 17:30 — forked from taichi/code_reading.md
太一のコードの読み方メモ

太一のコードの読み方メモ

全体として太一が感覚的に実践している事を論理的に説明しようと試みている為、
説明の粒度が適切でなかったり一貫性が無いように見える部分があるかもしれない。
普段やっているけども書ききれていない事も多分きっとある。

コードを読むとは何か

  • コードを嗜む
  • コードを学ぶ
  • 武器を手に入れる

Jubatusのpficommon移植作業

作業時期

  • 0.5.0リリース前
  • 新機能のPull Requestのマージが完了していること
  • リリース予定のissueがない状態
  • 11/11(月)コードフリーズ予定であり、その日か

作業の方針

Latency numbers every programmer should know

L1 cache reference ......................... 0.5 ns
Branch mispredict ............................ 5 ns
L2 cache reference ........................... 7 ns
Mutex lock/unlock ........................... 25 ns
Main memory reference ...................... 100 ns             
Compress 1K bytes with Zippy ............. 3,000 ns  =   3 µs
Send 2K bytes over 1 Gbps network ....... 20,000 ns  =  20 µs
SSD random read ........................ 150,000 ns  = 150 µs

Read 1 MB sequentially from memory ..... 250,000 ns = 250 µs

#NoSQLデータモデリング技法

原文:NoSQL Data Modeling Techniques « Highly Scalable Blog

I translated this article for study. contact matope[dot]ono[gmail] if any problem.

NoSQLデータベースはスケーラビリティ、パフォーマンス、一貫性といった様々な非機能要件から比較される。NoSQLのこの側面は実践と理論の両面からよく研究されている。ある種の非機能特性はNoSQLを利用する主な動機であり、NoSQLシステムによく適用されるCAP定理がそうであるように分散システムの基本的原則だからだ。一方で、NoSQLデータモデリングはあまり研究されておらず、リレーショナルデータベースに見られるようなシステマティックな理論に欠けている。本稿で、私はデータモデリングの視点からのNoSQLシステムファミリーの短い比較といくつかの共通するモデリングテクニックの要約を解説したい。

本稿をレビューして文法を清書してくれたDaniel Kirkdorfferに感謝したいと思う

@kumagi
kumagi / gist:1868747
Created February 20, 2012 10:48 — forked from uneco/gist:1333025
文字数が同じで意味が反対の英単語
slow 遅い
fast 速い
above より上に
below より下に
absolute 絶対的な
relative 相対的な
abstract 抽象的な

Latency numbers every programmer should know

L1 cache reference ......................... 0.5 ns
Branch mispredict ............................ 5 ns
L2 cache reference ........................... 7 ns
Mutex lock/unlock ........................... 25 ns
Main memory reference ...................... 100 ns             
Compress 1K bytes with Zippy ............. 3,000 ns  =   3 µs
Send 2K bytes over 1 Gbps network ....... 20,000 ns  =  20 µs
SSD random read ........................ 150,000 ns  = 150 µs

Read 1 MB sequentially from memory ..... 250,000 ns = 250 µs

Resilient Distributed Datasets(RDD)

この章ではRDDの概要について説明します。 最初はRDD($2-1)Sparkで利用するプログラムインタフェース($2-2)について説明します。それからメモリの詳細について説明し($2-3)、最後にSparkのモデルの限界($2-4)について議論します。

2-1. RDD概要

RDDは読み込み専用のレコードを分割した集まりです。RDDはオペレーションを通して安定したストレージか他のRDDが作成されます。私たちはこのオペレーションについて他のRDDオペレーションと差別化するためにtransformationsとよびます。例えばmap,filter,joinなどがそれにあたります。

RDDは常に実データを持つ必要はありません。その代わりRDDはストレージのデータからたどれるための情報を持つようにします。これはパワフルな特徴で失敗したあと、再構成できないRDDはプログラムから参照できません。