Servo: Inside Mozilla's mission to reinvent the web browser for the nulti-core age
http://www.zdnet.com/servo-inside-mozillas-mission-to-reinvent-the-web-browser-for-the-multi-core-age-7000026606/
=> 위 내용에 대한 요약
Servo는 기존의 브라우저들의 단점을 극복하기 위해 완전히 밑바닥부터 개발되고 있는 차세대 브라우저이다. 모질라와 삼성에 의해 개발되고 있다.
현재 주 브라우저들은 쓰레드나 멀티프로세싱을 하긴 하지만 많은 작업을 sequential하게 진행한다. 주로 layout -> rendering -> javascript 의 순이라고 보면 된다. Servo는 이 세작업을 각각의 task로 분리하여 동시에 동작시킨다.
물론 serialisation을 피할 수 없는 것도 있기 때문에 이러한 것들은 sequential하게 동작할 수 밖에 없다. 하지만, 독립적으로 할 수 있는 많은 것들(윈도우를 resize한다던지 또는 iframe의 경우라던지)이 있다. layout의 경우도 tree형태로 동작함으로서 순차적으로 진행해야 하지만 이것을 벗어나 독립적으로 동작시킬 수 있는 것도 있다. Servo는 이것을 기존의 브라우저들보더 더 강하게 parallel layout을 시도한다.
Servo는 Rust를 개발언어로 사용하기 때문에 C/C++에서와 같은 메모리 문제를 발생시키지 않는다. 이것은 보안에 매우 큰 이점을 가진다. Rust는 task 사이에 메모리를 공유하지 않고 서로간에 메시지로 통신하기 때문에 data 공유의 문제가 발생하지 않는다.
2014년 2월 28일 금요일
2014년 2월 20일 목요일
드랍 박스에서의 비디오 변환
Video Processing at Dropbox
https://tech.dropbox.com/2014/02/video-processing-at-dropbox/
* 비디오 관련 문제점
1. 다양한 종류의 코덱이 있다.
2. 네트워크 상태가 사용자에 따라 다르다.
3. 사용자가 사용는 장비의 성능이 제각각이다.
=> 위 문제 해결을 위해 소스 비디오를 사용자의 장비에 맞는 형태로 변경(transcode)한다.
초기에는 사용자가 비디오를 올리면 올리자마자 바로 모든 장비에서 볼 수 있도록 변경을 해주었는데 이것은 적합하지 않았다. 그래서 사용자의 요청이 있을 때 변경해서 보여주는 형태로 바꾸었다.
* 구현
HTTP Live Streaming 사용: 사용자의 환경에 맞는 다른 bit rate의 비디오를 선택하여 재생할 수 있도록 해주는 장점이 있다.
한번 transcoding되고 나면 cache를 사용 한다.-> 물론 사용자의 패턴에 따른 적당한 retention 정책으로 유지한다.
transcoding중에는 사용자가 transcoding worker에서 비디오를 받아올 수 있도록 한다.
transcoding에 ffmpeg를 사용: fast start도 사용
비디오를 쪼개는 데(segment)에는 애플에서 제공하는 것과 ffmpeg에 있는 것이 있는데 모두 우리에게 맞지 않아서 직접 개발했다.
segment의 크기는 latency(round trip과 transmission time을 고려)를 줄이기 위해 작은 사이즈로부터 5초까지 증가시킨다. 실제로 segment는 처음에 2s, 2s, 3s, 3s, 4s, 4s, 5s ... 의 형태로 증가한다.
그래도 latency가 불만족스러워 이를 더 줄이기 위해 비디오의 처음 몇초는 아예 미리 transcoding하였다.
https://tech.dropbox.com/2014/02/video-processing-at-dropbox/
* 비디오 관련 문제점
1. 다양한 종류의 코덱이 있다.
2. 네트워크 상태가 사용자에 따라 다르다.
3. 사용자가 사용는 장비의 성능이 제각각이다.
=> 위 문제 해결을 위해 소스 비디오를 사용자의 장비에 맞는 형태로 변경(transcode)한다.
초기에는 사용자가 비디오를 올리면 올리자마자 바로 모든 장비에서 볼 수 있도록 변경을 해주었는데 이것은 적합하지 않았다. 그래서 사용자의 요청이 있을 때 변경해서 보여주는 형태로 바꾸었다.
* 구현
HTTP Live Streaming 사용: 사용자의 환경에 맞는 다른 bit rate의 비디오를 선택하여 재생할 수 있도록 해주는 장점이 있다.
한번 transcoding되고 나면 cache를 사용 한다.-> 물론 사용자의 패턴에 따른 적당한 retention 정책으로 유지한다.
transcoding중에는 사용자가 transcoding worker에서 비디오를 받아올 수 있도록 한다.
transcoding에 ffmpeg를 사용: fast start도 사용
비디오를 쪼개는 데(segment)에는 애플에서 제공하는 것과 ffmpeg에 있는 것이 있는데 모두 우리에게 맞지 않아서 직접 개발했다.
segment의 크기는 latency(round trip과 transmission time을 고려)를 줄이기 위해 작은 사이즈로부터 5초까지 증가시킨다. 실제로 segment는 처음에 2s, 2s, 3s, 3s, 4s, 4s, 5s ... 의 형태로 증가한다.
그래도 latency가 불만족스러워 이를 더 줄이기 위해 비디오의 처음 몇초는 아예 미리 transcoding하였다.
2014년 2월 18일 화요일
페이스북 로그인 연동하기 - web
여기서는 웹 서비스 개발시 로그인을 할 때 페이스북 로그인과의 연동을 어떻게 할 수 있는지를 알아보자.
(참조: https://developers.facebook.com/docs/facebook-login/manually-build-a-login-flow/)
1. 페이스북에서 app을 만들어서 App ID(=Client ID)와 App secret(=Client Secret)을 발급받는다.
2. Authorization을 위해 "https://graph.facebook.com/oauth/authorize" 로 redirect한다.
이 때 get을 사용하며 parameter로 아래의 값을 넣어준다.
client_id: 페이스북에 app을 만들면 생성되는 값
redirect_uri: 페이스북으부터 되돌아오기 위한 url 이자 두번째 단계를 실행하기 위한 url
scope: 사용자에게 요청할 퍼미션 리스트
response_type: response data를 어디에 넣을 것인지 선택
state: CSRF를 방지하기 위해 생성한 unique string. 다음번 access token 단계에서 여기에서 넣어준 state값과 같은 state가 넘어왔는지를 보고 제대로 된 단계를 진행하고 있는 것인지 확인한다.
예를 들면 아래와 같은 URL이 될 것이다.
https://graph.facebook.com/oauth/authorize?client_id=1234567890&redirect_uri=http://yoursite.com/authenticate/&scope=email&response_type=code&state=djkfgj3kfjg-23jfjgjg-32jfjgj4--djfjgkf
위의 예 URL에 한 내용은 아래와 같다.
client_id는 페이스북에서 app을 만들면 생성되는 값을 넣어주고 redirect_uri는 페이스북에서 authorize가 처리되고 나면 redirect줄 url을 넣어준 것이다. scope는 간단하게 email로 설정해 주었고 response_type은 url에 parameter로 넘어오도록 code로 해준 것이고 state는 UUID.randomUUID() 을 사용해서 random number를 만들어낸 것이다.
로컬에서의 테스트를 위해 redirect_uri에 localhost를 넣어주면 redirect관련 에러가 발생한다. 이 경우는 페이스북 앱의 설정(Settings)에서 App Domains에 localhost 를 넣어주고 Site URL에 사용할 주소를 넣어준다(내 경우는 다음과 같이 넣어주었다: http://localhost:9000).
3. 2에서 사용자가 정상적으로 access를 허락하면 페이스북에서는 내가 넣어준 redirect uri로 redirect시켜준다. 여기서 access token을 가져오기 위한 작업을 한다.(서버에서 바로 http로 페이스북 access token url에 접속한다.)
정상적이라면 redirect시 파라메터에 state와 code 값이 넘어온다. state값이 정상적인 값(2에서 넣어준 값)인지 확인한다.
이제 access token을 얻어오기 위해 "https://graph.facebook.com/oauth/access_token" 에 요청을 한다. 이때 넘겨주는 parameter는 다음과 같다.
client_id: 페이스북 앱 생성시 생성되는 값
redirect_uri: OAuth 프로세스를 시작한 request_uri
client_secret: 페이스북 앱 생성시 생성되는 값
code: redirect시 받은 값
위의 요청을 하면 accesss_token 과 expires를 response로 준다. 여기까지 에러 없이 진행되었으면 인증 완료된 것이다.
에러의 경우 error 파라메터로 에러를 넘겨주므로 이 파라메터가 있는지 항상 확인해야 한다.
"access_denied"와 "redirect_uri_mismatch"등의 에러 내용이 있다.
4. 이제 사용자 정보를 요청한다. url은 "https://graph.facebook.com/me" 이다.
요청할 때 parameter로 access_token과 fields를 넣어준다.
fields는 요청할 사용자 정보이다:(예: id,name,last_name,username,,email,)
페이스북 api를 참조하여 다른 url로 다른 정보를 추가로 요청할 수도 있다.
(참조: https://developers.facebook.com/docs/facebook-login/manually-build-a-login-flow/)
1. 페이스북에서 app을 만들어서 App ID(=Client ID)와 App secret(=Client Secret)을 발급받는다.
2. Authorization을 위해 "https://graph.facebook.com/oauth/authorize" 로 redirect한다.
이 때 get을 사용하며 parameter로 아래의 값을 넣어준다.
client_id: 페이스북에 app을 만들면 생성되는 값
redirect_uri: 페이스북으부터 되돌아오기 위한 url 이자 두번째 단계를 실행하기 위한 url
scope: 사용자에게 요청할 퍼미션 리스트
response_type: response data를 어디에 넣을 것인지 선택
state: CSRF를 방지하기 위해 생성한 unique string. 다음번 access token 단계에서 여기에서 넣어준 state값과 같은 state가 넘어왔는지를 보고 제대로 된 단계를 진행하고 있는 것인지 확인한다.
예를 들면 아래와 같은 URL이 될 것이다.
https://graph.facebook.com/oauth/authorize?client_id=1234567890&redirect_uri=http://yoursite.com/authenticate/&scope=email&response_type=code&state=djkfgj3kfjg-23jfjgjg-32jfjgj4--djfjgkf
위의 예 URL에 한 내용은 아래와 같다.
client_id는 페이스북에서 app을 만들면 생성되는 값을 넣어주고 redirect_uri는 페이스북에서 authorize가 처리되고 나면 redirect줄 url을 넣어준 것이다. scope는 간단하게 email로 설정해 주었고 response_type은 url에 parameter로 넘어오도록 code로 해준 것이고 state는 UUID.randomUUID() 을 사용해서 random number를 만들어낸 것이다.
로컬에서의 테스트를 위해 redirect_uri에 localhost를 넣어주면 redirect관련 에러가 발생한다. 이 경우는 페이스북 앱의 설정(Settings)에서 App Domains에 localhost 를 넣어주고 Site URL에 사용할 주소를 넣어준다(내 경우는 다음과 같이 넣어주었다: http://localhost:9000).
3. 2에서 사용자가 정상적으로 access를 허락하면 페이스북에서는 내가 넣어준 redirect uri로 redirect시켜준다. 여기서 access token을 가져오기 위한 작업을 한다.(서버에서 바로 http로 페이스북 access token url에 접속한다.)
정상적이라면 redirect시 파라메터에 state와 code 값이 넘어온다. state값이 정상적인 값(2에서 넣어준 값)인지 확인한다.
이제 access token을 얻어오기 위해 "https://graph.facebook.com/oauth/access_token" 에 요청을 한다. 이때 넘겨주는 parameter는 다음과 같다.
client_id: 페이스북 앱 생성시 생성되는 값
redirect_uri: OAuth 프로세스를 시작한 request_uri
client_secret: 페이스북 앱 생성시 생성되는 값
code: redirect시 받은 값
위의 요청을 하면 accesss_token 과 expires를 response로 준다. 여기까지 에러 없이 진행되었으면 인증 완료된 것이다.
에러의 경우 error 파라메터로 에러를 넘겨주므로 이 파라메터가 있는지 항상 확인해야 한다.
"access_denied"와 "redirect_uri_mismatch"등의 에러 내용이 있다.
4. 이제 사용자 정보를 요청한다. url은 "https://graph.facebook.com/me" 이다.
요청할 때 parameter로 access_token과 fields를 넣어준다.
fields는 요청할 사용자 정보이다:(예: id,name,last_name,username,,email,)
페이스북 api를 참조하여 다른 url로 다른 정보를 추가로 요청할 수도 있다.
2014년 2월 17일 월요일
Custom Class Loading in Dalvik
Custom Class Loading in Dalvik
http://android-developers.blogspot.kr/2011/07/custom-class-loading-in-dalvik.html
=> 위 내용에의 요약
1. Dalvik은 custom class를 로딩하는 것을 지원한다.
보통은 이렇게 클래스를 로딩하는 것이 필요없지만 필요한 경우가 있다.
- 크기가 큰 앱은 dex가 최대로 지원하는 64k method reference이상을 포함할 수 있다. 이 경우는 프로그램을 두개의 dex로 나누어서 피해갈 수 있다.
- 프레임워크의 형태가 런타임에 동적으로 로딩하는 형태일 수 있다.
http://android-developers.blogspot.kr/2011/07/custom-class-loading-in-dalvik.html
=> 위 내용에의 요약
1. Dalvik은 custom class를 로딩하는 것을 지원한다.
보통은 이렇게 클래스를 로딩하는 것이 필요없지만 필요한 경우가 있다.
- 크기가 큰 앱은 dex가 최대로 지원하는 64k method reference이상을 포함할 수 있다. 이 경우는 프로그램을 두개의 dex로 나누어서 피해갈 수 있다.
- 프레임워크의 형태가 런타임에 동적으로 로딩하는 형태일 수 있다.
자바 메모리 모델에 대하여
Java Memory Model Under The Hood
http://gvsmirnov.ru/blog/tech/2014/02/10/jmm-under-the-hood.html
-> 위의 내용에 대한 간단 요약
1. 하드웨어 레벨에서의 자바 메모리 모델에 대한 설명
메인 메모리를 직접 사용하는 것은 매우 느리므로 캐시를 사용한다. 캐시는 하나의 프로세서에서는 문제없이 잘 동작하지만 프로세서가 여러개(실행이 동시에 여러군데서 되는 경우)인 경우 문제가 매우 복잡해진다(한쪽에서 캐시한 것을 다른 쪽에서 값을 바꾸어 버린다던지 하는 경우가 있을 수 있다.).
cach에 대한 설명: http://arstechnica.com/gadgets/2002/07/caching/2/
- Cache Coherency Protocols
MESI에서 모든 캐시는 아래의 상태를 가진다.
Invalid: 캐시가 메모리의 값을 가지고 있지 않다.
Exclusive: 값이 캐시에 있지만 변경되지 않았다.
Modified: 값이 변경되었지만 메인 메모리에 다시 쓰여지지 않았다.
Shared: 하나 이상의 프로세서가 같은 메모리의 값을 캐시에 가지고 있다.
Shared 상태에 있는 값을 바꾸고 싶으면 Invalidate 메시지를 다른 프로세서에 보내고 ack를 받으면 값을 변경한다. 이것은 시간이 매우 많이 걸리는 문제가 있다. -> Store Buffer를 사용해서 시간 낭비문제를 해결한다: 값을 버퍼에 넣어두고 모든 invalidate 메시지가 오면 값을 commit한다.
- Store Buffer의 두가지 문제점
1. store buffer에 있는 값이 완전히 commit 되지 않았는데 이를 읽어가는 문제가 있을 수 있다: Store Forwarding
2. 값이 버퍼를 떠나는 순서가 보장되지 않는다.
Invalidate Queues: invalidation을 처리하기 위해 도입
- Invalidate 요청이 들어오면 Invalidate Acknowledge 메시지는 바로 보내진다.
- Invalidate는 바로 적용되는 것이 아니라 special queue에 있다가 편리한 때 실행된다.
- 프로세서는 Invalidate를 모두 처리하고 나서야 캐시에 있는 메시지를 처리한다.
* Store Memory Barrier
store buffer에 있는 모든 것들을 다 적용한 후 이후에 오는 것들을 적용한다.
* Load Memory Barrier
invalidate queue에 있는 모든 invalidate들을 적용한 후
2. OpenJDK 소스 레벨에서의 자바 메모리 모델에 대한 설명
http://gvsmirnov.ru/blog/tech/2014/02/10/jmm-under-the-hood.html
-> 위의 내용에 대한 간단 요약
1. 하드웨어 레벨에서의 자바 메모리 모델에 대한 설명
메인 메모리를 직접 사용하는 것은 매우 느리므로 캐시를 사용한다. 캐시는 하나의 프로세서에서는 문제없이 잘 동작하지만 프로세서가 여러개(실행이 동시에 여러군데서 되는 경우)인 경우 문제가 매우 복잡해진다(한쪽에서 캐시한 것을 다른 쪽에서 값을 바꾸어 버린다던지 하는 경우가 있을 수 있다.).
cach에 대한 설명: http://arstechnica.com/gadgets/2002/07/caching/2/
- Cache Coherency Protocols
MESI에서 모든 캐시는 아래의 상태를 가진다.
Invalid: 캐시가 메모리의 값을 가지고 있지 않다.
Exclusive: 값이 캐시에 있지만 변경되지 않았다.
Modified: 값이 변경되었지만 메인 메모리에 다시 쓰여지지 않았다.
Shared: 하나 이상의 프로세서가 같은 메모리의 값을 캐시에 가지고 있다.
Shared 상태에 있는 값을 바꾸고 싶으면 Invalidate 메시지를 다른 프로세서에 보내고 ack를 받으면 값을 변경한다. 이것은 시간이 매우 많이 걸리는 문제가 있다. -> Store Buffer를 사용해서 시간 낭비문제를 해결한다: 값을 버퍼에 넣어두고 모든 invalidate 메시지가 오면 값을 commit한다.
- Store Buffer의 두가지 문제점
1. store buffer에 있는 값이 완전히 commit 되지 않았는데 이를 읽어가는 문제가 있을 수 있다: Store Forwarding
2. 값이 버퍼를 떠나는 순서가 보장되지 않는다.
Invalidate Queues: invalidation을 처리하기 위해 도입
- Invalidate 요청이 들어오면 Invalidate Acknowledge 메시지는 바로 보내진다.
- Invalidate는 바로 적용되는 것이 아니라 special queue에 있다가 편리한 때 실행된다.
- 프로세서는 Invalidate를 모두 처리하고 나서야 캐시에 있는 메시지를 처리한다.
* Store Memory Barrier
store buffer에 있는 모든 것들을 다 적용한 후 이후에 오는 것들을 적용한다.
* Load Memory Barrier
invalidate queue에 있는 모든 invalidate들을 적용한 후
2. OpenJDK 소스 레벨에서의 자바 메모리 모델에 대한 설명
디자이너들이 많이 가는 사이트 모음
Where designers go to find photos and graphics
http://www.sitebuilderreport.com/blog/where-the-best-designers-go-to-find-photos-and-graphics
저같은 디자인에 문외한인 사람들이 가져다 쓰면 좋을 것들이 많이 있네요. 저작권에 문제 없는 이런 것들 좋아요~
http://www.sitebuilderreport.com/blog/where-the-best-designers-go-to-find-photos-and-graphics
저같은 디자인에 문외한인 사람들이 가져다 쓰면 좋을 것들이 많이 있네요. 저작권에 문제 없는 이런 것들 좋아요~
2014년 2월 13일 목요일
비트코인 프로토콜을 통한 비트코인 설명
Bitcoins the hard way: Using the raw Bitcoin protocol
http://www.righto.com/2014/02/bitcoins-hard-way-using-raw-bitcoin.html
-> 위의 내용에 대한 요약
* 비트코인 address
1. random 256-bit private key를 생성한다. 나중에 transaction을 sign하는데 사용된다.
2. private key를 가지고 Elliptic Curve DSA 알고리즘을 사용해서 512-bit public key를 생성한다. 나중에 transaction에의 signature를 확인하는데 사용된다. public key의 앞에 04를 붙인다.(bitcoinj에서 bouncy castle을 사용해서 public key를 만드는데 코드를 보면 private key로부터 public key 생성시 04가 붙어서 나온다. bouncy castle는 왜 04를 붙인 public key를 주는걸까? 자세한 내용 확인 필요)
3. public key를 SHA-256과 RIPEM hash 알고리즘을 사용해서 160bit로 만든다.
4. 160bit로 만든 hash 값을 Base58Check로 인코딩한다. 이것이 사용자들이 서로 교환하는 비트코인 address이다.
5. private key를 로컬에 저장하는데 Wallet Interchange Format으로 저장한다. WIF는 단순히 Base58Check 인코딩이다.
* Transaction
1.비트코인을 이 주소에서 저 주소로 옮기는 것
2. input과 output으로 이루어진다.
3. 이전 transaction의 output으로 부터 비트코인을 가져와서 input으로 하고 보내고자 하는 쪽을 output으로 한다.
4. 모든 input은 다 사용되어야 한다. 따라서, 일부분만 쓰고자 하면 남는 부분은 자기 자신에게 다시 보내는 형태로 사용한다.
5. 사용료(fee)가 있다. 사용하고 남는 값이 모두 fee가 된다. 보통 값이 그리 크지는 않다.
* Transaction을 sign하기
1. transaction의 내용을 private key로 hash한 다음에 sign한다.
2. public key가 transaction에 포함되는데 이 key가 맞는 지는 이전의 transaction에서의 address를 봄으로서 파악할 수 있다.
3. signing한 것을 public key로 verify할 수 있다.
* peer 찾기
1. 하나의 peer와 연결되면 이 peer와 서로 알고 있는 다른 peer들의 주소를 교환한다.
2. 그렇다면 가장 처음의 peer는 어떻게? - 몇개의 신뢰할만한 peer가 이미 네트워크 상에 존재하도록 만든다: DNS에 등록해 놓거나 프로그램에 미리 입력해 놓기.
http://www.righto.com/2014/02/bitcoins-hard-way-using-raw-bitcoin.html
-> 위의 내용에 대한 요약
* 비트코인 address
1. random 256-bit private key를 생성한다. 나중에 transaction을 sign하는데 사용된다.
2. private key를 가지고 Elliptic Curve DSA 알고리즘을 사용해서 512-bit public key를 생성한다. 나중에 transaction에의 signature를 확인하는데 사용된다. public key의 앞에 04를 붙인다.(bitcoinj에서 bouncy castle을 사용해서 public key를 만드는데 코드를 보면 private key로부터 public key 생성시 04가 붙어서 나온다. bouncy castle는 왜 04를 붙인 public key를 주는걸까? 자세한 내용 확인 필요)
3. public key를 SHA-256과 RIPEM hash 알고리즘을 사용해서 160bit로 만든다.
4. 160bit로 만든 hash 값을 Base58Check로 인코딩한다. 이것이 사용자들이 서로 교환하는 비트코인 address이다.
5. private key를 로컬에 저장하는데 Wallet Interchange Format으로 저장한다. WIF는 단순히 Base58Check 인코딩이다.
* Transaction
1.비트코인을 이 주소에서 저 주소로 옮기는 것
2. input과 output으로 이루어진다.
3. 이전 transaction의 output으로 부터 비트코인을 가져와서 input으로 하고 보내고자 하는 쪽을 output으로 한다.
4. 모든 input은 다 사용되어야 한다. 따라서, 일부분만 쓰고자 하면 남는 부분은 자기 자신에게 다시 보내는 형태로 사용한다.
5. 사용료(fee)가 있다. 사용하고 남는 값이 모두 fee가 된다. 보통 값이 그리 크지는 않다.
* Transaction을 sign하기
1. transaction의 내용을 private key로 hash한 다음에 sign한다.
2. public key가 transaction에 포함되는데 이 key가 맞는 지는 이전의 transaction에서의 address를 봄으로서 파악할 수 있다.
3. signing한 것을 public key로 verify할 수 있다.
* peer 찾기
1. 하나의 peer와 연결되면 이 peer와 서로 알고 있는 다른 peer들의 주소를 교환한다.
2. 그렇다면 가장 처음의 peer는 어떻게? - 몇개의 신뢰할만한 peer가 이미 네트워크 상에 존재하도록 만든다: DNS에 등록해 놓거나 프로그램에 미리 입력해 놓기.
2014년 2월 11일 화요일
MySql에서 많은 양의 데이터 다루기
Handling large data in MySql
http://tagide.com/blog/2012/08/how-to-handle-large-data-in-mysql/
-> 위의 내용에 대한 간단한 요약입니다.
1. MySql의 설정 조정
아래의 설정을 조정해 볼 수 있는데 아래의 값은 하나의 예이다.
key_buffer_size = 1G
sort_buffer_size = 16M
tmp_table_size = 4G
max_heap_table_size = 8G
read_buffer_size = 512K
read_rnd_buffer_size = 512K
myisam_sort_buffer_size = 4G
2. 하나의 테이블에 인덱스가 있는 것을 가져오는 것은 잘 가져온다. -> 여러 테이블을 건드리는 경우 느리게 동작할 가능성이 많다.
3. explain 명령어로 MySql 명령어의 상태를 살펴 볼 수 있다.
4. 현재 느리게 동작하는 명령일지라도 인덱스를 잘 사용하면 빠르게 동작하도록 바꾸어 줄 수 있다.
5. 필요에 따라 벌크 데이터를 가져온 다음에 자바나 파이썬으로 직접 필터링이나 프로세싱을 할 수도 있다.
http://tagide.com/blog/2012/08/how-to-handle-large-data-in-mysql/
-> 위의 내용에 대한 간단한 요약입니다.
1. MySql의 설정 조정
아래의 설정을 조정해 볼 수 있는데 아래의 값은 하나의 예이다.
key_buffer_size = 1G
sort_buffer_size = 16M
tmp_table_size = 4G
max_heap_table_size = 8G
read_buffer_size = 512K
read_rnd_buffer_size = 512K
myisam_sort_buffer_size = 4G
2. 하나의 테이블에 인덱스가 있는 것을 가져오는 것은 잘 가져온다. -> 여러 테이블을 건드리는 경우 느리게 동작할 가능성이 많다.
3. explain 명령어로 MySql 명령어의 상태를 살펴 볼 수 있다.
4. 현재 느리게 동작하는 명령일지라도 인덱스를 잘 사용하면 빠르게 동작하도록 바꾸어 줄 수 있다.
5. 필요에 따라 벌크 데이터를 가져온 다음에 자바나 파이썬으로 직접 필터링이나 프로세싱을 할 수도 있다.
2014년 2월 1일 토요일
Why I Dropped Dropbox and got OwnCloud
http://dorktech.com/why-i-dropped-dropbox-and-got-owncloud/
dropbox와 같은 기능을 하는 OwnCloud라는 것이 있다. 자체 서버가 있는 경우 ownCloud를 설치함으로서 dropbox에서 제공하는 기능을 자체적으로 사용할 수 있다.
dropbox와 같은 기능을 하는 OwnCloud라는 것이 있다. 자체 서버가 있는 경우 ownCloud를 설치함으로서 dropbox에서 제공하는 기능을 자체적으로 사용할 수 있다.
피드 구독하기:
글 (Atom)