개발자 99% 커뮤니티에서 수다 떨어요!
[TIL] IT 잡학사전 : Day10 of 14 ( #30 ~ #34 )
오늘 TIL 3줄 요약
후대를 위해 개발자가 가져야 할 자세
SQL과 NoSQL의 특징 및 장단점
버전 관리와 Git 시스템
TIL (Today I Learned) 날짜
2023. 09. 03. 일요일
오늘 읽은 범위
03 마당 코딩별 안내서 ― 컴퓨터 공학 편 ①
에피소드 30 코로나가 준 레거시 시스템의 교훈
04 마당 코딩별 안내서 ― 컴퓨터 공학 편 ②
에피소드 31 데이터와 단짝 친구, SQL
에피소드 32 NoSQL이 뭐죠?
에피소드 33 깃 & 깃허브, 똑같은 거냐고?
에피소드 34 버전을 표기하는 방법도 있어요?
책에서 기억하고 싶은 내용을 써보세요.
[ 코볼 사태 : 코로나가 준 레거시 시스템의 교훈 ]
코볼은 정부와 금융시스템에 많은 기여을 했지만 코로나로 시스템 마비라는 초유 사태가 일어난다. 문제는 이 시스템을 고칠 사람이 없다는 것이다. 과거에 많은 점유율을 차지했던 코볼이지만 현재는 낮은 점유율과 50대라는 높은 평균 연령대를 보여주고 있다. 프로그래밍 기술도 대세가 있다.
이는 곧 우리에게 2가지 교훈을 준다.
프로그램에 책임감을 가지고 만들어라.
소프트웨어는 현대에 모든 것에 영향을 끼치고 있다.
후세대를 위해서 코드는 대충 짜서는 안된다.
프로그램의 관리는 계속되어야 한다.
시스템은 방치되어 서는 안된다.
관리자는 시스템에 관심을 두고 주기적으로 관리를 할 필요가 있다.
코드는 살아있는 생명체와 비슷해서 다양한 문제를 야기 시킬 수 있다.
[개인적 생각] 내가 생각한 관리가 지속되야 하는 이유는 총 3가지 이다.
개발 한 소프트웨어의 스펙은 계속 머물러 있지만 (1)'하드웨어의 발전'과 (2)'소프트웨어의 발전', (3)'대중들의 점유율'이 매우 다방면에서 변하기 때문이다. 결국 소프트웨어는 지속적인 관심이 필요한 것이다. ( 특히, 웹과 모바일이 발전이 심하기 때문에 이런 문제가 일어날 가능성이 크다. )
[ 데이터베이스 ]
데이터베이스
데이터베이스는 엑셀 문서와 유사하게 생겼다. 한 무리의 데이터를 테이블(table)이라 하는데 엑셀의 시트와 같다.
SQL
stucured qurery language
'구조화 된 질의어'
데이터베이스에 어떤 질문 또는 문의를 하기 위해 어떤 구조를 가진 언어이다. ( 프로그래밍 언어는 아니다. )
SQL은 DBMS와 소통하기 위한 언어이지 데이터베이스가 아니다.
SQL은 데이터베이스를 표의 형태로 띠고 있어 매우 정적이다.
만약 열을 늘리고 싶다면 다른 행에는 반드시 그 열에 해당하는 값을 넣어주어야 한다.
만약 그 값이 없다면 그것을 처리할 방법이 필요하다.
예를들어 반팔이라는 데이터를 SQL 데이터베이스에 추가하려면 id, name에 해당하는 값을 마련해야 한다.
[ SQL 문법 ]
SELECT ~ FROM ~ : 어떤 테이블에서 선택하는 것을 의미한다.
(ex) SELECT email FROM users : users 라는 테이블에서 email 열에 해당하는 정보만 가져와.
% : % 이후 나오는 값 만 추리는 기호이다.
ORM
object relational mapping
SQL 번역기 같은 도구로 SQL을 사용을 도와준다.
[주의!] ORM에 의존하지마라.
ORM을 경험한 사람들은 그 편리함 때문에 SQL 공부를 미루게 된다.
심지어 현업에서 풀스택 개발자가 SQL을 모르는 경우도 발생한다.
ORM은 만능이 아니다.
ORM만으로 해결하기 어려운 상황하기 대처하기 어려워 진다.
[ DBMS ]
DBMS
database mangement system
데이터베이스는 데이터를 보관하는 창고일 뿐 직접 정리하거나 처리할 수 있는 능력은 없다. 데이터베이스 대신 DBMS가 관리와 처리를 수행한다.
데이터베이스 관리 시스템(DBMS)는 SQL로 데이터베이스와 상호작용 하려면 DBMS를 거쳐야 한다. DBMS와 데이터베이스가 세트로 다니니 편의상 데이터베이스라고 부르는 것 뿐이다.
[ 종류 ]
MySQL, PostgreSQL, SQLite, Oracle 등
관계형 데이터베이스
데이터 관리의 주요 방법론으로 근 20~30년을 지배하고 있다.
RELATIONAL SQL
MYSQL, Oracle DB, MS SQL, MariaDB 등
세상에 무수히 많은 고나계형 데이터베이스 관리 시스템이 있다. 각 RDBMS 프로그램들은 서로 다른 특징을 가지고 있다.
[참고] 엑셀로도 관계형 데이터베이스를 만들 수 있다.
엑셀의 시트를 데이터베이스에서는 테이블(Table)이라고 표현한다. 그리고 엑셀 파일 자체를 스키다(Schema) 혹은 데이터베이스(Database)라고 표현한다.
[ NoSQL 데이터베이스 ]
NoSQL 데이터베이스
SQL을 사용하지 않다는 의미로 다양한 종류의 NoSQL 데이터베이스가 존재한다. 즉, 특정 용도나 상황에 따라 사용하는 데이터베이스가 다르다.
NON RELATIONAL SQL
(ex) 한국음식, Non한국음식
도큐먼트 데이터베이스
document DB
대표적으로 몽고디비(MongoDB)가 있다. 데이터를 제이슨(JSON) 도큐먼트 형태로 저장한다.
대괄호와 중괄호로만 구성되어 있고, 데이터 마다 구성이 같을 필요가 없다. 그래서 개발자가 원하는 어떠한 모양이나 종류의 데이터라도 저장할 수 있는 장점을 가진다.
키값 데이터베이스
key-value DB
대표적으로 카산드라디비(CassandraDB), 다이나모디비(DynamoDB)가 있다.
도큐먼트 데이터베이스와 비교할 때 어떤 종류의 DB를 얻을 수 있는지가 제한적이다. 저장하기 전에 DB에서 무엇을 얻을 것인지 미리 생각해야 한다.
SQL도 어떤 데이터를 얻을 것인지 고민하지 않는다. 데이터 구조만 걱정할 뿐이다. 하지만 DynamoDB에선 저장하기 전에 미리 어떻게 할지 고민해야 한다.
[ 카산드라 디비 ]
카산드라디비는 열이 넓다는(column wide) 특징을 가지고 있다. 한 행의 열이 엄청 넓은 데이터베이스이다. 또한 읽기 쓰기 속도가 매우 빠르다는 장점을 가지고 있어 수만 개의 데이터를 1초 만에 순식간에 쓸 수 있다.
대용량 데이터를 빠르게 저장해야 하거나 읽어야 한다면 카산드라디비가 좋은 선택지이다.
(ex) 애플은 카산드라디비로 10PetaByte의 데이터를 저장하고 있다. (ex) 넷플릭스, 인스타그램, 우버 같은 회사에서도 사용되고 있다.
[ 다이나모 디비 ]
다이나모 디비는 서버리스, 분산된 key valueDB로써 아마존이 만들었다. 매우 빠른 읽기 쓰기 능력을 자랑한다.
(ex) 듀오링고(Duolingo)라는 언어 학습 애플리케이션에서 사용 중이다.
그래프 데이터베이스
graph DB
노드라는 관계 개념을 사용한다. ( 열이나 도큐먼트가 필요 없다. )
사용자 1이 사진 1에 좋아요를 눌렀다.
사용자 1과 사용자 2는 친구이다.
(ex) SNS를 만든다고 가정하자. 이때의 데이터는 각각 관계망으로 연결되어 있다. 즉, 관계를 이용한 새로운 데이터베이스를 개발하는 것이다.
SQL vs NoSQL
일반적인 프로젝트라면 대부분 SQL 데이터베이스를 사용한다. NoSQL 데이터베이스는 특정한 요건이 아니라면 사용할 필요가 없다.
실제로 인스타그램도 처음에는 PostgreSQL으로 시작했고, 회사 성장과 함께 그래프 데이터베이스(NoSQL 데이터베이스)로 옮겨 갈 필요성이 생겼을 때 옮기는 작업을 진행했다.
기술에는 좋고 나쁨이 없다. 적절한 용도에 맞게 쓰면 된다.
[ 버전 표기 방식 (SemVer) ]
시맨틱 버저닝(semantic versioning specification, SemVer)
숫자 3개를 사용하는 버전 표기 방식을 SemVer이라고 한다. 리액트나 장고 등에서 사용되는 가장 널리 쓰이는 방식이다.
4.1.3.
맨 왼쪽 숫자
4에 해당하는 부분이다.
대규모 업데이트로 프로그램에 엄청난 변화를 의미한다.
하위 버전과 호환이 되지 않는 큰 변화를 의미한다.
집으로 따지면 이사하는 수준이다.
중간 숫자
1에 해당하는 부분이다.
마이너 업데이트를 의미한다.
하위 버전과 호환이 가능하지만 큰 변화를 의미한다.
집으로 따지면 새로 인테리어 하는 수준이다.
맨 오른쪽 숫자
패치나 버그 수정을 의미한다.
기존 프로그램의 오류를 수정하는 것이다.
집으로 따지면 유지 보수 하는 수준이다.
오늘 읽은 소감은? 떠오르는 생각을 가볍게 적어보세요
하나의 프로그램을 만든 다는 것은 후일을 생각해야 하는 고도의 작업이라는 생각이 든다.
내가 단순히 급하다고해서 귀찮다고해서 타협으로 프로그램을 짜서는 안되는 것이다.
그게 내가 되었든, 후임이 되었던 문제가 되어 나타난다.
미래 까지 계산하여 코드를 짤 수 있는 실력이 필요하다.
궁금한 내용이 있거나, 잘 이해되지 않는 내용이 있다면 적어보세요.
이번에는 없습니다.
오늘 읽은 다른사람의 TIL
다수의 영상과 위키백과
