우리는 왜 marvel을 만들었는가

why we built marvel http://www.elasticsearch.org/blog/building-marvel/

문제가 생기면 문제가 언제 생겼는지 어떻게 해서 생겼는지 알 수가 없다.
이것을 알기위해  marvel을 만들었다.

썸네일 가져오는 속도 향상시키기

Improving Dropbox Performance: Retrieving Thumbnails https://tech.dropbox.com/2014/01/retrieving-thumbnails/

많은 썸네일을 여러번 요청하니 느리다.
하나의 요청에 여러 이미지의 URL을 넣어서 요청하는 방식으로 변경(GET사용)
나중에는 SPDY 지원도 추가할 것이다.

Immutability, MVCC, and garbage collection

http://www.xaprb.com/blog/2013/12/28/immutability-mvcc-and-garbage-collection/

Immutability가 이론적으로는 훌륭하지만 실전에서는 문제가 많다. 따라서 이에 관련되어 기존 데이타베이스에서 다른방식의 다양한 해법이 사용되고 있다.

RethinkDB, CouchDB, Datomic

아파치 스파크: 차세대 빅 데이터?

Apache Spark: The Next Big Data Thing? http://blog.mikiobraun.de/2014/01/apache-spark.html

Spark의 basic abstraction은 Resilient Distributed Datasets (RDDs)이다. 

Scalding is a Scala library that makes it easy to specify Hadoop MapReduce jobs.
https://github.com/twitter/scalding

Resilient Distributed Datasets: A Fault-Tolerant Abstraction for
In-Memory Cluster Computing
http://www.cs.berkeley.edu/~matei/papers/2012/nsdi_spark.pdf

Discretized Streams: A Fault-Tolerant Model for
Scalable Stream Processing
http://www.eecs.berkeley.edu/Pubs/TechRpts/2012/EECS-2012-259.pdf

Storm makes it easy to reliably process unbounded streams of data, doing for realtime processing what Hadoop did for batch processing.
http://storm-project.net/

Immutability, MVCC, and garbage collection
http://www.xaprb.com/blog/2013/12/28/immutability-mvcc-and-garbage-collection/

Redis Cluster and limiting divergences

http://antirez.com/news/70

곧 Redis Cluster가 될텐데 여전히 많은 이들의 의문을 가지고 있는 Redis Cluster구현상의 논쟁점 중의 하나인 Redis Cluster가 어떻게 node들 사이에 data set의 불일치를 해결하려고 하는지에 대한 설.
불일치를 완변하게 해결하는 것이 아닌 최대한 제한하는 형태로 해결을 함

Haskell vs. Erlang for bittorent clients

http://jlouisramblings.blogspot.kr/2010/04/haskell-vs-erlang-for-bittorent-clients.html

bittorrent client를 Haskell과 Erlang으로 만들어본 저자의 두 언어 비교 이야기.

* Haskell
static typing
다양한 좋은 라이브러리(attoparsec, PSQueues등)
STM
Haskell 컴파일러인 GHC는 매우 빠르게 동작하는 결과물을 만들어주고 좋은 profiling tool을 가지고 있다.
QuickCheck이나 Test.Framework을 써서 테스트 하기도 좋다.

lazy한것이 문제가 되는 경우가 있다(내용 이해 못했음)
IO도 조금 느리다고 할 수 있다.
GHC가 Erlang VM보다 조금 느리기도 하다.

* Erlang
SASL(system logger)
IO가 무지 빠르다.
OTP(callback framework for processes)
message passing이 빠르다.
shell

dynamic typing -> a type analyzer tool인 the dialyzer를 사용할 수 있다.
불안정 -> OTP로 죽으면 다시  실행시켜버린다.
라이브러리가 많이 않다.

VAGRANT, PUPPET, DOCKER?

http://mattwilcox.net/archives/vagrant-puppet-docker/

Vagrant를 통해 내가 원하는 설정으로 만들어져 있는 virtual server를 만들어 간단하게 start, stop등을 한다.
Puppet을 사용하여 vagrant에 의해 만들어진 서버의 설정을 필요에 맞게 변형하여 사용한다. puppet에 의해 바뀌는 설정은 virtual server의 설정을 기본으로 하여 이루어지므로 원본은 변하지 않는다고 봐도 좋다.
Docker는 puppet과 유사한 새로운 것이다. 관심을 가지고 지켜볼 만한 것이다.

MapReduce and Spark

http://vision.cloudera.com/mapreduce-spark/

하둡이 계속 발전하면서 최근에 하둡2도 나왔지만 Map/Reduce framework이라는 틀에서 나아가는 것은 변하지 않는다. 이것 위에 HBase나 Impala, Solr, Storm같은 것들이 특정한 목적을 위해 만들어지고 있기도 하다.

하둡의 한계를 넘어설 수 있는 뭔가가 필요하고 그것으로 Apache Spark가 있다. Spark와 같이 DAG(directed acyclic graphs)를 엔진으로 썼던 것으로는 Microsoft의 Dryad가 있다. Spark는 UC Berkeley의 AMP lab에서 연구 프로젝트로 시작해서 2010년에 오픈소스화 되었다.

하둡 이후의 다음세대의 것으로 Google의 Dremel과 Pregel이 있고 Facebook의 Presto가 있다.