컴퓨터로 하는 작업은 대부분이 데이터를 다루는 일임
즉 자료를 받아서 저장하고 처리하고 보내고 삭제하고 하는 작업들이 대다수임
자료구조라는 건 이 자료를 저장할 때 어떻게 저장할까 하는 부분을 다루는 거임
그래서 자료구조의 원리는 당연히 이해해야 하고 컴공 전공생들은 전필로 배우게 됨
예를 들어봄
DB 인덱싱의 원리는 이진탐색임 (해쉬를 사용하는 경우도 있긴 한데 일반적이진 않음)
이진탐색을 통해 원하는 데이터를 빠르게 찾아내자는 게 인덱싱의 핵심 아이디어임
여기서 이진탐색에 가장 적합한 자료구조는 뭘까? 바로 이진트리 구조임
근데 이진트리를 생으로 쓰면 비효율적이니 그걸 개조해서 사용했고 그 결과물이 B+트리임
만약 자료구조를 잘 이해했다면, "N개의 데이터 중 x값이 6 이상인 데이터를 x값 기준으로 정렬해서 가져오고 싶은데, M 번째 자료부터 M+30 번째 자료까지를 끄집어내고 싶다" 같은 쿼리문을 날리면 x값에 인덱싱이 걸려있다고 해도 데이터를 끄집어내는 데 걸리는 시간이 대략 (logN) + M + 30 임을 직관적으로 알 수 있음
왜 그럴까? 왜냐면 B+트리에서는 그 M 번째 데이터가 무슨 데이터인 지 빠르게 알 수 있는 방법이 없거든
이진트리는 기본적으로 비선형 자료구조이니 말 할 필요조차 없고, B+트리는 리프노드에 링크드 리스트 형태로 데이터가 깔려있기는 하지만 결국 링크드 리스트 자체가 M번째 데이터를 가져오려면 O(M)이 걸리는 자료구조이기 때문임
만약 자료구조를 잘 이해하고 있다면 이런 점을 곧바로 파악할 수 있음
하지만 그저 "인덱싱은 데이터를 알아서 잘 끄집어와주는 무언가" 라고만 이해하고 있었다면 이 부분에서 빵꾸가 뚫리는 거임
나중에 M 값에 뭔가 큰 값이 들어갈 일이 있다면 "흠 얘는 M개의 데이터를 스캔하게 될텐데? 이거 괜찮나?" 라는 생각을 할 줄 아는 사람과 그냥 아무것도 모르고 문제의 소지가 될 수 있다는 발상 자체를 못 하는 사람은 결국 응용력에서 차이가 나게 됨
너무 어려운데요
그냥 사용용도만 알아도 거의 충분함 이진 탐색 A* 원리 알지만 그걸 개선할것도 아니고, 대다수 자기 앞에 놓인일 먼저가 우선이지
B+ 트리 나도 알고 이해하지만 막상 그걸 쓰는것도 당장 개선해서 쓰는것보다 상용하는 라이브러리를 쓰니까 결국은 그걸 만드는 행위자체가 굳이 응용을 위한거면 굳이 그걸 재구현해야하는 당위성이 있냐는거지.
진지하게 현업 뛰어보지도 않은 니새끼 말에 가치가 있을 거 같다고 생각하냐? 현장 뛰어보지도 않은 새끼가 자료구조 안중요하네 마네 지랄 염병을 떨고 있네 너처럼 학부생 과제나 대신해주는 병신새끼는 자료구조 필요 없긴 해 ㅋㅋ
이 논리에 가장 큰 맹점은 자기가 어떤 라이브러리 프레임워크를 쓰지 않고, 구현한다는 걸 가정한다는거임 근데 대부분의 백엔드 프레임워크와 라이브러리 가져다 쓰니 당연히 쓰임새 우선으로 하는게 훨씬 당연하거긴함 마치 이걸 알아야만 한다하는데, 자동차 딜러가 자동차 엔진 구조의 윤곽만 알면되는데, 마치 자동차 딜러에게 엔진 구조 자체를 알아야한다고 이야기하는거임
페이지 네이션 M값이 수백만, 수천만 단위까지 간다면 필요하겠지만 이때 배워도 전혀 늦지 않음. 결국 그보다는 당장 라이브러리 프레임워크 사용법 우선 하는게 훨씬 맞고, 막상 기초만 다 배우다보면 결국 프레임워크 응용단까지 못감 이게 맹점임. 결국 어느 계층위에서 뭘 하느냐가 중요하지. 마치 처음부터 배워야한다라는 걸 가정하면 이제 핵심은 '어디까지 기초인가'라는걸 알아서 웹하는놈이 어셈블리판다고 깝치는 맹점에가까워진다는거임
@ㅆㅇㅆ(124.216) 열등감이란게 진짜 무섭구나 ㅋ
하지만 여기서 역인덱싱이 등장한다면?