뉴스피드 2021

created: 2021-01-29 | updated: 2021-07-04

2020년 7월

승진은 후불제 … 이미 다음 단계 일은 하고 있음 + 그걸 얼마나 잘 당연시하는가

쑤(@sajiiinnn) 님의 트윗

2020년 6월

끝으로 어느 팀이든 좋은 코드를 마스터한 시니어만으로 구성되지 않는다. 프로그래밍팀은 하나의 마을이다. 거기엔 아름답고 웅장하게 세워진 성도 있고 이제 첫 삽을 떠본 주니어가 만든 초가집도 있다. 시니어의 역할은 주니어의 초가집 엉성한 부분을 지적하는것에서 끝나지 않는다. 진짜 마스터는 계속해서 자기 성을 짓는 사람이다. 주니어가 지켜보며 영감 (inspiration)을 얻을만큼 계속해서 조금 더 아름다운 성을 만드는 사람이다. 주니어의 초라한 집에서 훗날 성이 될수 있는 재능을 발견해 용기를 주는 사람이다.

가치투자자 일지

created: 2021-01-22 | updated: 2021-04-11

대한민국

날짜 회사 보고서 주가 시가총액 매출 영업이익 당기순이익 특이사항
2021-04-11 엔씨소프트(KRX: 036570) 사업보고서 (2020.12) 925,000원 20조 3,075억원 5,613억원 1,567억원 803억원
2021-04-11 넷마블네오 사업보고서 (2020.12) 138,000원 1조 7,194억원 881억원 432억원 386억원
2021-04-11 라인게임즈 [한경 CFO Insight] 라인게임즈 텐센트 등에서 1000억원 유치 9,000억원(추정) 투자유치를 위한 유상증자 2회 있었음
2021-03-01 엔씨소프트(KRX: 036570) 분기보고서 (2020.09) 936,000원 20조 5,490억원 5,852억원 2,177억원 1,525억원
2021-03-01 넷마블네오 분기보고서 (2020.09) 92,000원 1조 1,462억원 205억원 100억원 88억원
2021-03-01 라인게임즈 대규모기업집단현황공시[연1회공시및1/4분기용(개별회사)] 4,500억원(추정) 206억원 -431억원 -670억원

미국

날짜 회사 주가 Market Cap(시가총액) Revenue(매출) EPS(주당순이익) 특이사항
2021-03-07 MongoDB(MDB) 308.17$ 18,570,000,000$ 542,900,000$ -4.36
2021-03-07 Oracle(ORCL) 69.97$ 205,990,000,000$ 39,400,000,000$ 3.3
2021-03-07 Cockroach Labs - 2,000,000,000$ - -

MongoDB 스터디 11주차(데이터 모델링)

created: 2021-04-07 | updated: 2021-04-08

고려사항

  • 데이터 모델은 애플리케이션과 함께 변함
  • 데이터 모델에 영향을 미치는 요소
    • 사용자의 요구사항
    • 읽기 및 쓰기 작업의 특성

모델링 순서

  1. 애플리케이션 워크로드 측정
    • 데이터 사이즈
    • 중요도에 따라 작업을 목록화
  2. 데이터와 데이터 간의 관계를 연결(CRD, Collection Relationship Diagram)
    • 레퍼런스할지 임베드 할지 결정
  3. 각 컬렉션의 데이터 모델을 정리(디자인 패턴 적용)

임베딩 vs 레퍼런스

1. 임베딩

User =
{
	"_id": 1,
	"name": "hueypark",
	"items":
	[
		{
			"type": "sword",
			"damage": 10
		},
		{
			"type": "spear",
			"damage": 20
		}
	]
}

2. 레퍼런스(부모가 가진 배열로 연결)

User =
{
	"_id": 1,
	"name": "hueypark",
	"items": [2, 3]
}

Item =
{
	"_id": 2,
	"type": "sword",
	"damage": 10
},
{
	"_id": 3,
	"type": "spear",
	"damage": 20
}

3. 레퍼런스(자식이 가진 스칼라로 연결)

User =
{
	"_id": 1,
	"name": "hueypark"
}

Item =
{
	"_id": 2,
	"user_id": 1,
	"type": "sword",
	"damage": 10
},
{
	"_id": 3,
	"user_id": 1,
	"type": "spear",
	"damage": 20
}

각 방법의 장단점

  1. 임베딩
    • 장점
      • 한 번의 조회로 필요한 데이터를 가져 올 수 있음
      • 트랜잭션 도움 없이 아토믹한 데이터 변경이 가능함
    • 단점
      • 단일 도큐먼트 크기 제한을 고려해야 함
      • 자식을 기준으로 조회하기 어려움(예: 모든 sword 의 수는 몇 개인가?)
  2. 레퍼런스(부모가 가진 배열로 연결)
    • 장점
      • 단일 도큐먼트 크기 제한에서 상대적으로 자유로움
    • 단점
      • 자식으로 부모를 조회할 수 없음
      • 조회를 두 번 해야 함
      • 아토믹한 데이터 변경을 위해 트랜잭션을 사용해야 함
  3. 레퍼런스(자식이 가진 스칼라로 연결)
    • 장점
      • 자식 기반의 조회가 용이함
      • 단일 도큐먼트 크기 제한에서 상대적으로 자유로움
    • 단점
      • 조회를 두 번 해야 함
      • 아토믹한 데이터 변경을 위해 트랜잭션을 사용해야 함

선택 전략

  • 데이터의 특성에 따라 적절한 방법을 적용한다.
  • 기본적으로 임베딩을 사용하고 필요시 레퍼런스로 전환한다.
  • 기본적으로 레퍼런스를 사용하고 필요시 임베딩으로 전환한다.

참고자료

MongoDB 스터디 10주차(트랜잭션)

created: 2021-03-26 | updated: 2021-04-01

트랜잭션

몽고디비는 4.0버전(2018년)부터 여러 도큐먼트에 대한 트랜잭션을, 4.2버전(2019년) 부터는 샤딩된 컬렉션에 대한 분산 트랜잭션을 지원하고 있습니다.

여러 도큐먼트에 대한 ACID 트랜잭션 지원은 다양한 상황에서 개발자가 쉽게 대응할 수 있게 합니다. 스냅샷 격리수준과 아토믹한 실행은 샤딩된 클러스터에서도 트랜잭션이 필요한 워크로드를 제어할 수 있게 합니다.

  • In version 4.0, MongoDB supports multi-document transactions on replica sets.
  • In version 4.2, MongoDB introduces distributed transactions, which adds support for multi-document transactions on sharded clusters and incorporates the existing support for multi-document transactions on replica sets.

IMPORTANT: 대부분의 경우 멀티 도큐먼트 트랜잭션은 큰 부하를 일으키며, 효율적인 스키마를 대체하지 않아야 합니다. 대부분의 시나리오에서 비정규화된 데이터 모델(임베디드 도큐먼트 또는 배열)로 최적화 가능합니다.

MongoDB 스터디 9주차(인덱스)

created: 2021-03-14 | updated: 2021-03-23

인덱스

인덱스는 쿼리가 효율적으로 실행되게 돕습니다. 쿼리에 적절한 인덱스가 있으면 이를 사용해 조회할 도큐먼트 수를 줄일 수 있습니다.

인덱스는 특정 필드 또는 필드들을 값에 따라 정렬해 저장합니다.

정렬된 인덱스는 효율적인 레인지 쿼리를 지원합니다.

몽고디비 인덱스는 B-tree 자료구조를 사용합니다.

_id 인덱스

몽고디비는 _id 유니크 인덱스를 만듭니다. _id 인덱스는 같은 _id 를 가진 도큐먼트가 두 개 생기는 것을 막습니다. _id 인덱스는 제거할 수 없습니다.

NOTE: 샤딩된 클러스터에서 _id 필드를 샤드 키로 사용하지 않으면 오류방지를 위해 애플리케이션이 _id 필드의 유니크성을 보장해야 합니다.

MongoDB 스터디 8주차(aggregation)

created: 2021-03-07 | updated: 2021-03-11

어그리게이션(Aggregation)

어그리게이션 작업은 데이터를 처리하여 계산된 결과를 반환합니다. 어그리게이션은 여러 도큐먼트의 값을 그룹화하고, 데이터에 다양한 작업을 수행한 후 단일 결과를 반환할 수 있습니다. MongoDB는 세 가지 어그리게이션을 제공합니다.

  • Aggregation Pipeline
  • Single Purpose Aggregation Operations
  • Map-reduce

어그리게이션 파이프라인(Aggregation Pipeline)

Aggregation pipeline 은 파이프라인 이용해 데이터의 집계를 처리하는 프레임워크입니다. 여러 스테이지에 걸쳐 도큐먼트들을 집계된 결과로 변경합니다.

아래 예를 살펴봅시다:

db.orders.aggregate([
	{ $match: { status: "A" } },
	{ $group: { _id: "$custmor_id", total: { $sum: "$amount" } } }
])

MongoDB 스터디 8주차(MongoDB CURD 맵 리듀스)

created: 2021-03-06 | updated: 2021-03-07

Map-Reduce

MongoDB 는 맵리듀스 대신 어그리게이션 파이프라인을 사용하길 권장하고 있으며, 상세내용은 아래와 같습니다.

어그리게이션 파이프라이프라인으로 맵 리듀스를 대체할 수 있습니다

어그리게이션 파이프라인은 맵-리듀스보다 좋은 성능과 사용성을 제공하며, $group, $merge와 같은 명령어를 사용해 맵리듀스를 어그리게이션 파이프라인으로 변경할 수 있습니다.

또 사용자 정의 기능이 필요한 경우 4.4 버전부터 $accumulator, $function 명렁어로 해결할 수 있습니다.

맵리듀스를 대체하는 어그리게이션 파이프라인을 알고 싶으면, 맵리듀스에서 어그리게이션 파이프라인으로 변경맵리듀스 예제 문서를 참고하십시오.

참고자료

MongoDB 스터디 7주차(MongoDB CURD 읽기 연산)

created: 2021-02-27 | updated: 2021-03-04

db.collection.find()

쿼리 기준과 일치하는 도큐먼트에 대한 커서를 반환합니다.

파라미터

  • query: 필터에 사용할 쿼리 연산자입니다.
  • projection: 도큐먼트에서 반환할 필드를 지정합니다. 생략하면 모든 필드가 반환됩니다.

db.collection.findOne()

쿼리 기준과 일치하는 하나의 도큐먼트를 반환합니다. 여러 도큐먼트들이 쿼리를 만족하면 디스크에 저장된 순서에 따라 첫 도큐먼트를 반환합니다. 만약 대상이 없으면 null을 반환합니다.

Read Concern

readConcern 옵션을 사용해 읽기 작업의 일관성과 격리수준, 가용성을 제어할 수 있습니다.

4.4 버전부터 기본값의 전역 설정이 가능합니다. 세부정보는 setDefaultRWConcern에서 확인하십시오.

Read Concern Levels

  • local
    • 과반수에 기록되었음을 확인하지 않고 데이터를 반환합니다.(읽어온 데이터가 롤백될 수 있음)
    • 사용가능: causally consistent session 또는 트랜잭션에서 사용할 수 있습니다.
  • available
    • 과반수에 기록되었음을 확인하지 않고 데이터를 반환합니다.(읽어온 데이터가 롤백될 수 있음)
    • 사용가능: causally consistent session 또는 트랜잭션에서 사용할 수 없습니다.
    • 샤딩된 클러스터에서 가장 낮은 레이턴시를 제공합니다. 하지만 샤드된 컬렉션에서 orphaned document를 반환할 수 있음을 유의하십시오.
  • majority
    • 과반수에 기록된 데이터를 반환합니다.
    • 이를 충족하기 위해 각 레플리카 셋 멤버들이 메모리의 majority-commit point 반환해야 합니다. 따라서 위 두 설정에 비해 성능이 떨어집니다.
    • 사용가능:
      • causally consistent session 또는 트랜잭션에서 사용할 수 있습니다.
      • PSA 아키텍처를 사용할 때 이 설정을 쓰지 않게 설정할 수 있습니다. 하지만 이것은 Change Streams, 트랜잭션, 샤디드 클러스터에 영향을 줄 수 있습니다. 자세한 내용은 Disable Read Concern Majority에서 확인하십시오.
  • linearizable
    • 읽기를 시작하기 전에 완료된 쓰기에 대한 데이터만 반환합니다. 쿼리가 결과를 반환하기 전에 레플리카 셋 전체에 결과가 전파되길 기다립니다.
    • 읽기 시작 후 레플리카 셋의 과반이 재시작되어도, 반환된 데이터는 유효합니다.(writeConcernMajorityJournalDefault 을 false 로 변경하면 아닐 수 있음)
    • 사용가능:
      • causally consistent session 또는 트랜잭션에서 사용할 수 없습니다.
      • 프라이머리 노드에만 설정할 수 있습니다.
    • 어그리게이션의 $out, $merge 스테이지에서 사용할 수 없습니다.
    • 요구사항: 유니크하게 식별가능한 단일 도큐먼트에 읽기 작업에서만 보장됩니다.
  • snapshot
    • 트랜잭션이 causally consistent session 이 아니고 Write concern 이 majority 인 경우, 트랜잭션은 과반이 커밋된 데이터의 스냅샷에서 읽습니다.
    • 트랜잭션이 causally consistent session 이고 Write concern 이 majority 인 경우, 트랜잭션 시작 직전에 과반이 커밋된 데이터의 스냅샷에서 읽습니다.
    • 사용가능:
      • 멀티 도큐먼트 트랜잭션에서만 사용가능합니다.
      • 샤딩된 클러스터 중 하나라도 Disable Read Concern Majority 설정을 할 경우 사용할 수 없습니다.

Causal Consistency

뭔가 묘한 일관성 옵션입니다. 잘 찾아보면 활용할 만 한 특수한 사용처가 있을지도 모릅니다.

MongoDB 스터디 6주차(MongoDB CURD 쓰기 연산)

created: 2021-02-23 | updated: 2021-02-25

Create Operations

db.collection.insertOne()

도큐먼트를 하나 추가합니다.

문법

db.collection.insertOne(
	<document>,
	{
		writeConcern: <document>
	}
)
  • writeConcern
    • w: 몇 개의 mongod 에 저장 후 응답할 지 설정
      • <숫자>: 몇 개의 mongod 에 기록될 지 직접 지정
      • “majority”: 과반의 mongod 에 기록되게 설정
      • <커스텀 write concern 이름>: 특정 데이터 센터에 저장되게 설정가능, Custom Multi-Datacenter Write Concerns
    • j: 디스크의 저널에 저장 후 응답할지 설정 여부
    • timeout: 쓰기 제한 시간(밀리세컨드), 반환하기 전에 이미 성공한 쓰기 작업을 롤백하지 않음

db.products.insertOne(
	{ "item": "envelopes", "qty": 100, type: "Self-Sealing" },
	{ writeConcern: { w : "majority", wtimeout : 100 } }
);

db.collection.insertMany()

도큐먼트를 여러 개 추가합니다.