-
Notifications
You must be signed in to change notification settings - Fork 3
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Paged File, I/O System] 초코칩(권기호) 미션 제출합니다. #3
[Paged File, I/O System] 초코칩(권기호) 미션 제출합니다. #3
Conversation
import java.util.ArrayList; | ||
import java.util.List; | ||
|
||
public class Page implements Serializable { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Serializable을 이용해서 페이지를 구현해주셨군요.
추후에 페이지 구조가 변경되면 이미 저장된 데이터를 역직렬화 할 수 있을까요?
우리가 만든 DBMS가 완성되어 사용자가 테이블을 만들어 데이터를 추가한 상황에서 페이지 클래스의 필드가 추가되거나 삭제, 수정되면 기존 데이터를 역직렬화 할 수 있나요?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
복잡한 데이터 구조의 객체라도 직렬화 기본 조건만 지키면 큰 작업 없이 바로 직렬화가 가능하기 때문에 큰 신경을 쓰지 않아도 된다는 측면에서 사용했습니다.
추후에 페이지 구조가 변경되면 이미 저장된 데이터를 역직렬화 할 수 있을까요?
해당 부분은 직렬화를 사용하지 않아도 어떠한 방식이든(JSON, CSV, ...) 문제가 될 수 있는 부분이라 생각합니다.
@@ -0,0 +1,16 @@ | |||
package database.storageEngine.page; | |||
|
|||
public class PageFactory { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
이부분은 Page 클래스에 정적 팩토리 메서드로 만들 수 있는데 따로 팩토리 클래스를 만든 이유가 궁금합니다. 초코칩이 생각하는 분리의 기준이 있나요? 궁금해요!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Page 클래스에서 여러 가지 생성자로 생성 로직을 만들 수 있지만, 생성자가 많아지면 Page 클래스 내부가 길어진다는 단점이 있습니다! 생성하는 로직만 분리할 수 있다고 생각하여 팩토리 클래스를 생성했습니다!
this.pageHeader = new PageHeader(pageType); | ||
this.userStorageRecords = new ArrayList<>(); | ||
this.pageDirectory = new PageDirectory(); | ||
this.freeSpace = PAGE_SIZE - (this.fileHeader.getHeaderSize() + this.pageHeader.getHeaderSize()); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
freeSpace를 계산할때 pageDirectory의 크기는 고려되지 않고 있는데요. freeSpace가 레코드로 가득 찬경우 pageDirectory의 크기 때문에 PAGE_SIZE가 초과되는 문제는 없을까요?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Page 생성 시점에서 검증하게끔 변경했습니다!
|
||
private static final int PAGE_SIZE = 16 * 1024; | ||
private static final String DIRECTORY_PATH = "disk"; | ||
private static final String FILE_EXTENSION = ".ibd"; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
추후에 테이블의 스키마를 저장한다면 .ibd 외에 다른 확장자 파일을 만들 수도 있을것 같아요. 그때 이 클래스를 재활용 할 수 있을것 같은데 파일확장자는 상수가 아닌 인자로 받는건 어떤가요?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
FileExtension Enum 클래스를 만들고, 이를 FileManager로부터 분리했습니다!
return Optional.of(page); | ||
} | ||
} catch (IOException | ClassNotFoundException e) { | ||
return Optional.empty(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
IOException에 대해서 Optional.empty()을 리턴해도 문제가 없을까요? 파일을 읽는 과정에서 문제가 발생했을때 페이지가 없다고 하면 추후에 버그가 발생했을때 잡기 어려운 코드가 될 수 있을것 같아요.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
예외를 확인할 수 있도록 커스텀 Excpetion을 만들었습니다!
src/main/java/database/storageEngine/bufferpool/pageReplacementStrategies/LFUStrategy.java
Show resolved
Hide resolved
private static final int HEADER_SIZE = 38; | ||
|
||
private final long pageNumber; | ||
private final long checksum; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
checksum은 어떤역할인가요!?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
의도는 File의 손상 여부를 체크하는것이였으나, 현재는 사용하고 있지 않아 제거했습니다!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
안녕하세요 초코칩~ 코드 재미있게 봤어요 😀
저랑 구현하시는 방향이 전체적으로 비슷한 것 같아서 재미있었습니다 😊
궁금한 부분과 간단한 코멘트 남겨놨습니다. 😎
|
||
private static final int HEADER_SIZE = 38; | ||
|
||
private final long pageNumber; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
저는 페이지 번호 자료형을 int로 사용했는데 long 타입을 사용할만큼 파일 크기가 커질지..?
적절한 자료형을 잘 모르겠습니다 어떻게 생각하시나요
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
int와 long은 메모리 측면에서 두 배 차이가 나기 때문에 불필요하게 남용하면 메모리 낭비로 이어질 수 있어서 커지지 않는 다는 보장이 있다면 int를 쓰는게 맞다고 봐요!
개발하는 과정에서 페이지에 어느정도의 데이터가 저장되어 몇개의 페이지가 번호가 생성될 수 있을지 파악하기 힘들어 int로 설정했습니다!
코드 잘 봤습니다! 앞으로도 화이팅입니다! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
꼼꼼하게 봐주셔서 감사합니다 :)
|
||
private static final int HEADER_SIZE = 38; | ||
|
||
private final long pageNumber; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
int와 long은 메모리 측면에서 두 배 차이가 나기 때문에 불필요하게 남용하면 메모리 낭비로 이어질 수 있어서 커지지 않는 다는 보장이 있다면 int를 쓰는게 맞다고 봐요!
개발하는 과정에서 페이지에 어느정도의 데이터가 저장되어 몇개의 페이지가 번호가 생성될 수 있을지 파악하기 힘들어 int로 설정했습니다!
private static final int HEADER_SIZE = 38; | ||
|
||
private final long pageNumber; | ||
private final long checksum; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
의도는 File의 손상 여부를 체크하는것이였으나, 현재는 사용하고 있지 않아 제거했습니다!
|
||
private static final int PAGE_SIZE = 16 * 1024; | ||
private static final String DIRECTORY_PATH = "disk"; | ||
private static final String FILE_EXTENSION = ".ibd"; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
FileExtension Enum 클래스를 만들고, 이를 FileManager로부터 분리했습니다!
return Optional.of(page); | ||
} | ||
} catch (IOException | ClassNotFoundException e) { | ||
return Optional.empty(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
예외를 확인할 수 있도록 커스텀 Excpetion을 만들었습니다!
@@ -0,0 +1,16 @@ | |||
package database.storageEngine.page; | |||
|
|||
public class PageFactory { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Page 클래스에서 여러 가지 생성자로 생성 로직을 만들 수 있지만, 생성자가 많아지면 Page 클래스 내부가 길어진다는 단점이 있습니다! 생성하는 로직만 분리할 수 있다고 생각하여 팩토리 클래스를 생성했습니다!
this.pageHeader = new PageHeader(pageType); | ||
this.userStorageRecords = new ArrayList<>(); | ||
this.pageDirectory = new PageDirectory(); | ||
this.freeSpace = PAGE_SIZE - (this.fileHeader.getHeaderSize() + this.pageHeader.getHeaderSize()); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Page 생성 시점에서 검증하게끔 변경했습니다!
import java.util.ArrayList; | ||
import java.util.List; | ||
|
||
public class Page implements Serializable { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
복잡한 데이터 구조의 객체라도 직렬화 기본 조건만 지키면 큰 작업 없이 바로 직렬화가 가능하기 때문에 큰 신경을 쓰지 않아도 된다는 측면에서 사용했습니다.
추후에 페이지 구조가 변경되면 이미 저장된 데이터를 역직렬화 할 수 있을까요?
해당 부분은 직렬화를 사용하지 않아도 어떠한 방식이든(JSON, CSV, ...) 문제가 될 수 있는 부분이라 생각합니다.
페이지는 어떻게 구성되나요?
아래 그림의 페이지의 구조를 참고하여 구현했습니다.
FileTrailer는 Page의 유효성을 검사하는 역할인데, 현재 단계에서는 굳이 필요성을 못느껴 구현하지 않았습니다.
페이지 교체 알고리즘은 어떤 것으로 결정하고, 왜 결정했나요?
FIFO는 성능이 안좋다고 알려져 있어, 당장 구현하기 좋았던 LRU 알고리즘을 적용했습니다. 어떤 알고리즘이 좋은지 몰라서, 알고리즘이 변경될 가능성이 있다고 판단했습니다. 따라서 전략 패턴을 적용해서 알고리즘을 교체할수 있게 구현했습니다.