'분류 전체보기'에 해당되는 글 93건

shallow copy란 object는 새로 생성하되 그안에 있는 값들은 참조 한다는 소리고, 

deep copy란 안에있는 값을 참조하지 않고 복사해온다는 소리.

참조.

1. https://docs.python.org/2/library/copy.html

2. http://kkoseul.tistory.com/m/post/53

프로젝트 간단 설명: 테이블에 있는 NFC에 휴대폰을 테깅하여 웹브라우져 메뉴를 띄워 원격 주문.

*목차

1. 주문화면 스크린샷

2. 주문 시연 동영상

(아래 나오는 꾼노리 및 꾼노리 안산점 지점과는 무관한 데모 프로젝트 입니다.)

1. 주문화면 스크린샷

2. 주문 시연 동영상

s3 upload 하다가 발생한 에런데 문제는 파일이름에 특문이 들어가 있어서 였다.

Official Tutorial

기본적으로 이걸 따르는데, 하나가 빠졌다.

일단, OpenCV Tutorial 1 - Camera Preview를 가지고 테스트 했는데,

onResume에서 onManagerConnected를 호출해 줘야 한다.

Check list

1. Project Properties에 C/C++ 메뉴가 없다

프로젝트 폴더에 마우스 오른쪽 버튼을 클릭 -> Android Tools -> Add Native Support.. -> 공백 없는 마음에 드는 이름으로 쓰고 finish.

끝.

2. Project마다 맨처음에 ndk-build를 못찾아서 에러가 날수 있는데, NDKROOT variable설정을 해줘야 ${NDKROOT}를 인식할 수 있다. 

(환경설정(Preference)에서 Android->NDK에 NDK Location은 설정 해놨다고 가정)

환경설정(Preference) -> C/C++ -> Build -> Build Variables -> Add

Name: NDKROOT

Type: Directory

Value: ndk folder를 browse 해서 넣어줌.

만약, 에러가 사라지지 않는다면 -> 프로젝트 오른쪽버튼 클릭 -> Android Tools -> Fix Project Properties 클릭 -> clean build -> Build project.

끝.

3. 위 튜토리얼의 두가지 방법중 llibs 폴더 추가하고 복사하면 끝나는 간단한 과정이 있는 반면, 두번째 꺼는 약간 복잡해 보인다. 하지만 c++코드를 쓴다면 반드시 해줘야 하는것. 그리고 복잡하지도 않다.
일단, 1번을 따라해서 프로젝트 폴더에 jni폴더가 생기게 한뒤 튜토리얼에 나와있는데로 하면되고, 만약에 안된다면, 여기를 참고해서 Application.mk를 추가로 만든다.

끝.

MongoDB Management Service)

* 이점

- Serviced by MongoDB Guys

- Super easy setup and Fancy features (Monitoring + Backup)

- Clear and Clean Dashboard

- Group Alerts (Pager, Email, Hipchat..)

- API Supported

일단, Backup을 셋팅하기 위해서는 Backup을 저장할 instance가 하나 필요하고 이곳에는 mongod가 실행되어있어야 한다. type은 sharded 또는 replica-set으로 되어있어야 하며 standalone으로 되어있으면 mms에서 Backup용으로 감지가 안된다. 또한 MMS에서 Backup용으로 감지되기위해서는 monitoring agent와 backup agent가 설치되어있어야 한다.

정리하자면 Backup용 instance에 아래 1,2,3번이 설치되어있고 4번이 설정되어있으면됨.

1. mongod

2. monitoring agent

3. backup agent

4. db sharding or replica set 설정

(sharded 된 벡업 db를 쓴다면 각 디비 instance에 2,3번을 설치할 필요는 없고 config서버에만 설치하면된다. sharding이 안되어있고, replica set하나인 경우는 primary에만 설치되면 된다)

요 설정이 끝나면, MMS에서 Backup 탭을 눌렀을때 자동으로 감지가 된다. 이후 부터는 설정된 주기에 따라 자동으로 Backup된다.

1. Download the 32-bit or 64-bit deb package.

$ curl -OL https://mms.mongodb.com/download/agent/monitoring/mongodb-mms-monitoring-agent_2.1.0.35-1_amd64.deb

2. Install the package
$ sudo dpkg -i mongodb-mms-monitoring-agent_2.1.0.35-1_amd64.deb

3. Edit /etc/mongodb-mms/monitoring-agent.config and enter your API key, as shown below
$ mmsApiKey=6d2f19515939c45d6905ef9f0d584e1c

4. Start the agent
$ sudo start mongodb-mms-monitoring-agent

5. Continue to setup @ mms console

* 호스트 추가시 팁

에이전트는 기본적으로 모든 정보를 알아서 MMS에 전송하는데(Outbound only) MMS 콘솔에서 호스트에 대한 자세한 정보를 맵핑시켜놓기 위해 호스트를 추가하는 메뉴가 있다. 그런데 이때 묻는 정보들에 당황하지 않고, 다음의 팁들을 염두하고 입력하면 수월할지어다.

- 호스트 타입은 Standalone / Shard Cluster / Replica Set / Master Slave 가 있다.

- Standalone 은 Config 서버 입력할때 쓰면 좋다.

- Shard Cluster 는 Mongos 서버 입력할떄 쓰면 좋다. (보통 이거 하면 알아서 Replica Set 다 찾아줌)

- Replica Set / Master Slave 로 구성했다면 요걸로 고르면 됨.

- 그리고 호스트네임은 수집된 정보에서 호스트 식별해내기 위한 것으로 Public IP / Private IP 구분 없다. (울 서버에 Inbound 요청하려고 하는것이 아님)

The Backup Agent requires network access. To avoid contention for network and CPU resources, we recommend running the Backup Agent on a separate host from your mongod instances. Performance impact on the cluster is similar to adding an additional secondary node. The Backup agent has the same performance profile impact as a secondary. For the initial backup, the load scales with the size of your data set. Once an initial backup exists, the load scales with oplog gigabytes used per hour. Within the US, MMS Backup sends snapshots at 50-100Mbps. Assuming a compression factor of 4x and transmission speeds of 50Mbps, a 250 GB snapshot will take 2.5 hours.  

1. Download the 32-bit or 64-bit deb package.

$ curl -OL https://mms.mongodb.com/download/agent/backup/mongodb-mms-backup-agent_1.4.6.43-1_amd64.deb

2. Install the package

$ sudo dpkg -i mongodb-mms-backup-agent_1.4.6.43-1_amd64.deb

3. Edit /etc/mongodb-mms/backup-agent.config and enter your API key, as shown below

apiKey=6d2f19515939c45d6905ef9f0d584e1c

4. Start the agent 

$ sudo start mongodb-mms-backup-agent

* References

https://jira.mongodb.org/secure/attachment/34148/backup-manual.txt 

Problematic Code

Code with no problem

mongoDB에서 샤딩을 해주기 위해서는 shard key를 정해주어야 한다.

샤딩을 하는 이유는 읽기와 쓰기를 분산시켜 디비의 부하를 줄이기 위함인 것처럼

이 목적을 가장 잘 달성할  수 있는 컬럼을 shard key로 잡아야 한다.

거의 대부분은 _id를 샤드키로 잡고 쓴다고 하고, mongodb도 기본적으로 _id에 맞추어 샤드를 테스트하고 최적화 했을 것이다.

샤딩 key로 데이터쓰기를 할때 range 방법과 hash방법이 있는데, range는 데이터가 얼마나 들어올지 fix된 상황에 적합할 것이고, 대부분의 경우는 hash방법이 좋지 않을까 생각한다.

그리고 샤드는 컬렉션 단위로 이루어지는데, 디비에 저장된 전체 데이터를 읽어서 처리해야 하는 데이터같은 경우는 샤드에 포함시키지 않아야 한다. 샤드된다면 각 샤드를 모두 뒤져서 가져와햐 하기 때문이다. 이때 샤드에 포함되지 않은 컬렉션은 따로 디비를 만들어 사용할 수도 있지만 그렇지 않은경우는 샤드들중 primary shard에 저장된다. 따라서 request에 따라서 primary shard에 부하가 집중될 수도 있으니 디자인을 잘 설계해야 할 것이다.

그리고 샤드들중 db하나가 lock이 걸리면 다른 샤드들은 정상동작하고 하나의 샤드만 lock이 걸린다. (collection이 1,2,3,4로 나눠졌을때 3번샤드의 collection때문에 락이 걸리면 그 collection이 속한 db가 락이 걸릴텐데 이때 3번샤드의 db만 락이 걸린다는 소리)  

물론 안써도 되게 만드는 방법이야 있겠지만 mysql을 쉽게 버릴수 없는 이유를 살펴보자.

mongoDB과 다르게 mysql의 장점은 트랜젝션이다.

트랜젝션은 atomic이 보장되고 중간에 실패하더라도 실질적인 영향을 미치지 않도록 할 수 있다. 하지만 mongodb같은 경우 각각의 쿼리들이 나눠있고 따로 불러야 하기 때문에 중간에 디비가 뻣거나 문제가 생길경우 대처하기가 어렵다.

그리고 atomic을 보장해야하는 상황을 예로들면 select하고 이 결과가 없다면 insert하는 하나의 트랜젝션은 중간에 다른 놈이 insert를 안했다는 보장을 받아야 한다. 하지만 nosql은 select와 insert가 나눠있기 때문에 select를 해왔을때는 없었지만 insert를 할때 없을거라는 보장을 할 수 없다. 

간단히 naver.com 홈페이지를 fetch해오는 로직이 있다고 하자.

그리고 post request를 날려 이로직이 끝난뒤에 response를 받고 싶다면?

잘못된 사용 예)

이렇게 하면 result는 이렇다

self.test()함수를 기다리지 않고 바로 done하고 response를 날리고 나중에 res가 도착하자 print가 되었다.

여기서 문제는 post() 함수는 기다리는 로직이 없고, 또한 asynchronous 데코도 없기때문에 로직이 끝나자 auto finish를 한것이다.

그럼 제대로 기다리려면 어떻게 해야할까? 방법은 2가지다.

1. @gen.coroutine 이용

yield를 써서 post함수 역시 test함수를 기다린다. 결과적으로 fetch를 기다리는것과 같다.

결과는

test

HTTPResponse

done

[web:1728] 200 POST /test (::1) 2.23ms (connection 종료, response 보냄)

이 된다.

2. @web.asynchronous 이용

이 경우에는 로직이 약간 변경된다. 기본적으로 post에서는 커넥션을 끊지 않을 뿐 post함수는 끝나고 단지 커넥션은 self.finish()를 요청하는곳에서 종료된다는것을 명시하는 것이다.

결과는 1번과 같다.