세상의 모든 Software 지식을 정리

직렬화는 네트워크 전송을 위해 구조화된 객체를 바이트 스트림으로 전환하는 과정이다. 역지렬화는 바이트 스트림을 일련의 구조화된 객체로 역전환하는 과정이다. 직렬화는 프로세스간 통신과 영속적인 저장소와 같은 분산 데이터 처리의 독특한 두 영역에서 나타난다. 하둡 시스템에서 노드 사이의 프로세스 간 통신은 원격 프로시저 호출(RPC) 을 사용하여 구현한다. RPC프로토콜은 원격 노드로 보내기 위한 메시지를 하나의 바이너리 스트림으로 구성하기 위해 직렬화를 사용하고, 그 후 원격 노드에서 바이너리 스트림을 원본 메시지로 재구성하기 위해 역직렬화를 사용한다. 일반적으로 RPC직렬화 포맷이 유익한 이유는 다음과 같다. 간결성  간결한 포맷을 사용하면 데이터 센터에서 가장 희소성이 높은 자원인 네트워크 대역폭을 절약할 수 있다. 고속화 프로세스 간 통신은 분산 시스템을 위한 백본을 형성하기 때문에 직렬화와 역직렬화는 가능한 오버헤드가 작아야한다. 확장성 프로토콜은 새로운 요구사항을 만족시키기 위해 점차 변경되므로 클라이언트와 서버 사이의 통제 방식과 관련된 프로토콜의 발전도 직관적이어야한다. 예를들어 새로운 인자를 메소드 호출에 추가할 수 있어야하고, 새로운 서버는 기존 클라이언트에서(새로운 인자없이) 예전 포맷의 메시지도 수용할 수 있어야한다. 상호운용성 일부 시스템을 위해 다양한 언어로 작성된 클라이언트를 지원하는 편이 좋으며, 이를 가능하도록 포맷을 설계할 필요가있다. 하둡은 Writeable이라는 매우 간결하고 빠른 자체 직렬화 포맷을 사용한다. 그러나 확장하거나 자바외에 다른 언어를 사용하는 것은 어렵다.  에이브로는(Writable의 일부 한계를 극복하기 위해 설계된 직렬화시스템) 자바 기본자료형을 위한 Writable래퍼 char(IntWritable로 저장가능)를 제외한 모든 자바 기본 자료형을 위한 Writable 래퍼가 존재한다. 모든 W

각 제네릭 뷰에서 제공하는 속성과 메소드가 많아서 모든 것을 설명하기는 어렵다. 여기서는 오버라이딩에서 자주 사용하는 속성과 메소드를 살펴보겠다. * 속성 오버라이딩 1. model 기본 뷰(View, TemplateView, RedirectView) 3개를 제외하고는 모든 제네릭 뷰에서 사용하는 속성이다. 뷰가 출력할 데이터가 들어 있는 모델을 지정한다. model 대신 queryset속성으로 지정할 수 도 있다. 다음 표현은 동일하다 model = Bookmark queryset = Bookmark.objects.all() 2. queryset 기본 뷰(View, TemplateView, RedirectView) 3개를 제외하고는 모든 제네릭 뷰에서 사용하는 속성이다. 뷰가 출력할 데이터가 들어 있는 모델을 지정한다. 출력대상이 되는 QuerySet객체를 지정한다. queryset속성을 지정하면 model은 무시된다. 3. template_name TemplateView를 포함해 모든 제네릭 뷰에서 사용하는 속성이다. 템플릿 파일 명을 문자열로 지정한다. 4. context_object_name TemplateView를 포함해 모든 제네릭 뷰에서 사용하는 속성이다. 템플릿 파일에서 사용할 컨텍스트 변수명을 지정한다. 5. paginate_by ListView와 날짜 기반 뷰에서 사용한다. 페이징 기능이 활성화된 경우에, 페이지당 몇 개 항목을 출력할 것인지 정수로 지정한다. 6. date_field 날짜 기반 뷰에서 기준이 되는 필드를 지정한다. 이 필드를 기준으로 년/월/일을 검사한다. 이 필드의 타입은 DateField 또는 DateTimeField 이어야 한다. 7. make_object_list 8. form_class FormView, CreateView, UpdateView 에서 사용한

body > div.container > div:nth-child(1) > div.col-md-9.content > ul:nth-child(3) > li:nth-child(15) > a 에서 nth-child는 지원을 하지 않는다. 그래서 다음과 같이 변경한다. body > div.container > div:nth-of-type(1) > div.col-md-9.content > ul:nth-of-type(2) > li:nth-of-type(16) > a 이를 다음과 같이 변경가능하다. div > div.col-md-9.content > ul > li > a

#은 보통 id에 해당 하는 부분으로 html 파일에서 한 개만 존재 . 은 클래스 이름으로 해당 클래스를 여러 군데 사용할 수 있다.

입력 파일이 압축되면 맵 리듀스는 파일 확장명을 통해 사용할 코덱을 결정하고 파일을 읽을 떄 자동으로 압축을 해제할 것입니다. 맵리듀스 잡의 출력을 압축하려면 잡 환경설정에서 mapreduce.output.fileoutputformat.compress 속성을 true로 설정하고, 사용할 압축 코덱의 클래스 이름을 mapreduce.output.fileoutputformat.compress.codec 속성에 지정하라. <맵리듀스 압축 속성> 속성명  타입  기본값 설명 mapreduce.output.fileoutputformat.compress 불린 FALSE 출력압축여부 mapreduce.output.fileoutputformat.compress.codec 클래스명 org.apache.hadoop.io.compress.DefaultCodec 출력 압축에 사용할 코덱 mapreduce.output.fileoutputformat.compress.type 문자열 RECORED 순차 파일 출력에 사용할 압축 유형(NONE, RECORD, BLOCK) * 맵 출력 압축 맵리듀스 애플리케이션이 압축되지 않은 데이터를 읽고 쓰더라도 맵 단계에서 임시 출력을 압축하면 이익이 있다. 맵 출력은 디스크에 기록되고 네트워크를 통해 리듀서 노드로 전송되는데, 이때 단순히 LZO나 LZ4, Snappy와 같은 빠른 압축기를 사용하여 전송할 데이터 양을 줄이면 성능을 향상 시킬 수 있기 때문이다. <맵출력 압축속성> 속성명                                            타입               설명 mapreduce.map.output.compress         불린               맵 출력

하둡 애플리케이션은 거대한 데이터 셋을 처리하기 때문에 압축의 장점을 충분히 활용할 필요가 있다. 어떠한 압축 포맷을 사용할지는 파일크기, 포맷, 처리에 사용되는 도구 같은 고려 사항에 의해 결정된다. 압축과 분할 모두를 지원하는 시퀀스파일, 에이브로, ORCFile, 파케이 같은 컨테이너 파일 포맷을 사용하라. 보통 LZO, LZ4, Snappy 같은 빠른 압축형식이 적당하다. 상당히 느리긴 하지만 bzip2같이 분할을 지원하는 압축 포맷을 사용하라. 또는 분할을 지원하기 위해 색인  애플리케이션에서 파일을 청크로 분할하고, 지원되는 모든 압축 포맷(분할에 관계없이) 을 사용하여 각 청크를 개별적으로 압축하라. 이 경우 압축된 청크가 거의 HDFS 블록 하나의 크기가 되도록 청크 크기를 선택해야한다. 파일을 압축하지말고 그냥 저장하라 파일의 크기가 매우크면 전체 파일에 대한 분할을 지원하지 않는 압축 포맷은 권장하지 않는다. 그 이유는 지역성 을 보장하지 않으면 상당히 비효율적인 맵리듀스 애플리케이션이 되기때문이다.

1. 압축  파일 압축은 저장공간을 줄이고, 네트워크 또는 디스크로부터 데이터 전송을 고속화 할 수 있는 두가지 커다란 이점이 있다. 압축포맷 도구 알고리즘 파일 확장명 분할 가능 DEFLATE N/A DEFLATE .deflate No gzip gzip DEFLATE .gz No bzip2 bzip2 bzip2 .bz2 Yes LZO lzop LZO .lz0 No LZ4 N/A LZ4 .lz4 No Snappy N/A Snappy .snappy No 모든 압축 알고리즘은 압축과 해제가 빨라 질 수록 공간이 늘어나는 희생을 감수해야 하기 때문에 공간과 시간은 트레이드 오프 관계에 있다. 위 표의 도구는 보통 9개의 옵션(-1은 스피드 최적화, -9는 공간 최적화를 의미)를 제공함으로써 어느정도 이러한 트레이드 오프에 대한 제어를 가능하게 한다. 다음 명령은 가장 빠른 압축 메소드를 사용해서 file.gz라는 압축 파일을 생성한다. %gzip -1 file 각 도구는  각기 다른 압축 특성이 있다.  gzip은 일반적인 목적의 압축 도구이고, 공간/시간 트레이드 오프의 중앙에 위치한다. bzip2는 gzip보다 더 효율적으로 압축하지만 대신 더 느리다. bzip2의 압축 해제 속도는 압축속도보다 더 빠르지만 여전히 다른 포맷에 비해 더 느리다. 한편 LZO, LZ4, Snappy 는 모두 속도에 최적화 되었고, gzip보다 어느정도 빠르지만 압축 효율은 떨어진다. Snappy와 LZ4는 압축 해제 속도 측면에서 LZO보다 매우 빠르다 '분할 가능' 열은 압축 포맷이 분할을 지원하는지 여부를 알려준다. 예를들어, 스트림의 특정 지점까지 탐색한

1. 하둡 URL로 데이터 읽기 하둡 파일 시스템에서 파일을 읽는 가장 쉬운 방법은 java.net.URL객체로 데이터를 읽는 스트림을 하나 여는 것이다. 자바가 하둡의 hdfs URL 스킴을 인식하기 위해서는 약간의 작업이 필요 이 작업은 FsUrlStreamHandlerFactory의 인스턴스와 함께 URL클래스의 setURLStreamHandlerFactory()메소드를 호출하여 수행된다. 이 메소드는 JVM하나당 한번씩만 호출할 수 있기 떄문에 일반적으로 정적 블록에서 실행된다. 이러한 한계는 프로그램의 일부 다른 부분 에서 URLStreamHandlerFactory를 설정하면 하둡URL로부터 데이터를 읽을 수 없게 됨을 의미한다. 2. 파일시스템 API로 데이터 읽기 앞에서 설명했듯이 애플리케이션에서 URLStreamHandlerFactory 설정이 불가능한 경우가 있다. 이떄는 파일에 대한 입력 스트림을 열기위해 FileSystem API를 사용해야한다. 하둡시스템의 파일은 하둡 Path객체로 표현된다. 여기서 Path는 hdfs:://localhost/user/tom/quangle.txt같은 하둡 파일 시스템 URL을 의미한다. FileSystem은 일반적인 파일시스템 API로, 첫 단계는 접근할 파일시스템(여기서는HDFS)에 대한 인스턴스를 얻는 것이다. FIleSystem인스턴스를 얻을 수 있는 정적 팩토리 메소드는 다음과같다. public static FileSystem get(Configuration conf) throws IOException public static FIleSystem get(URI uri, Configuration conf) throws IOException public static FIleSystem get(URI uri, Configuration conf, String user) throws IOException Configuration객체는 클라이언트나 서버의 환경

1. settings.py파일에 REST_FRAMEWORK = {    'DEFAULT_PAGINATION_CLASS' : 'study.pagination.TestPagination',    'PAGE_SIZE' : 10 } 2. study디렉토리(settings.py파일 있는 곳) 하위에 from rest_framework.pagination import PageNumberPagination class TestPagination(PageNumberPagination):   page_size_query_param = 'page_size' 적용한다. 그럼 데이터 조회시 자동으로 10개씩 잘라서 조회한다.

urls.py파일에 router 등록시 router = DefaultRouter() router.register(r'testName', views.~~', r'test) urlpatterns = [  url(r'^learning', include(router.urls)), ] 하게되면 testName이 router의 이름이 되고 url경로는 http://127.0.0.1:8000/learining/test 로 잡힌다

* 전통적인 RDBMS                vs                맵리듀스 데이터크기 : 기가바이트        vs               페타바이트 접근방식 :    대화형과 일괄처리 방식        vs      일괄 처리 방식 변경 :          여러번 읽고 쓰기                  vs       한번 쓰고 여러번 읽기 트랜잭션 :        ACID                          vs            없음 구조 :          쓰기 기준 스키마             vs           읽기 기준 스키마 무결성 :       높음                               vs           낮음 확장성  :     비선형                            vs            선형 * 하둡과 RDBMS의 다른 차이점은 데이터 셋 내부에서 처리되는  구조의 양이다. 정형 데이터 는 XML문서나 미리 정의된 특정 스키마를 가진 데이터베이스 테이블과 같이 형식이 정의된 항목으로 구조되어 있다. 이것은 바로 RDBMS의 영역이다. 반정형 데이터 는 정형 데이터에 비해 스키마가 유연하거나 심지어 생략될 수 있다. 따라서 데이터 구조에 대한 최소한의 규칙만 있으면 된다. 예를 들어 그리드 형태의 셀 구조로 된 스프레드 시트는 셀 자체에 어떤 형태의 데이터도 담을 수 있다 비정형 데이터 는 어떠한 내부 구조도 없다. 예를들어 일반 텍스트나 이미지 데이터가 그렇다. 하둡은 데이터 처리 시점에 데이터를 해석하도록 설계되어 있기 떄문에 비정형 데이터나 반정형 데이터도 처리할 수 있다. 읽기 시점 스키마라 불리는 이러한 특성은 유연성을 제공하고 데이터를 불러오는 비용이 많이드는 단계(RDBMS 에서 필요한) 도 피할 수 있다. 하둡은 관계형 데이터베이스보다 많이 사용되지는 않지만 조인을 수행할 수 있다. 맵리듀스와 다양한 하

먼저 1. mongod서버 2. config서버 3. mongos가 필요하다 * mongod는 몽고 데이터를 저장하는 곳 * mongos는 request의 라우터 역할을 한다. * config는 데이터를 저장하지 않고 mongos로 부터 request가 들어왔을 때, 해당 데이터가 어느 샤드에 있는지 알려준다. * mongos는 config서버의 데이터를 캐쉬한다. 1. mongod 구성 * SHARD1 > --shardsvr --port 27017 --dbpath /data/db --replSet reply_replica (Secondary) > --shardsvr --port 27012 --dbpath /data/shard1 --replSet reply_replica  (Primary) > --shardsvr --port 27013 --dbpath /data/shard2 --replSet reply_replica (Secondary) *SHARD2 --shardsvr --port 28017 --dbpath /data/db1 --replSet shard2_replset (Primary) --shardsvr --port 28117 --dbpath /data/db1_replica1 --replSet shard2_replset (Secondary) 2. config 서버 구성 > mongod --configsvr --port 27010 이제 샤드를 등록해야 하는데 config서버에 해당 샤드 들을 등록해야하는데 ver3.4부터는 샤드의 replica만 등록 가능하다 그러므로 replica를 만들어야한다. 일단 Primary에 해당하는 27017포트에 해당하는 녀석에 접속한다 > mongo localhost:27017 그 후 rs.initiate()로 replicaSet을 구성한다. 해당 27017포트는 Primary가 된다 그 후 rs.add

config servers: Config servers store metadata and configuration settings for the cluster. As of MongoDB 3.4, config servers must be deployed as a replica set (CSRS).

* Mongos 프로세스의 주요 특징 빅데이터를 샤드 서버로 분배해 주는 프로세스 하나이상의 프로세스가 활성화 된다. Application Server에서 실행이 가능하다 CONFIG 서버로 부터 Meta-Data를 캐시한다.