따봉 구걸남's 블로그

OTT 구독은 안해도 따릉이는 구독을 하고 있습니다. 

가격도 저렴하고 활용도도 높아서 만족하고 있는데요, 한정거장만 가면 되는데 환승을 해야하거나 축구나 야구경기가 있어 지하철이 매우 혼잡할때 활용하면 매우 좋습니다. 

여러 달 사용하고 느낀 점과 개선하면 좋겠다 싶은 것들을 끄적여 봅니다.

- 요금

 일회용 요금은 1시간 1000 원입니다.  

 1시간 6개월은 15000 원, 1년은 30000 원이라 할인이 없어 굳이 1년을 할 필요는 없습니다. 

 여기서 주의점은 6개월 동안 하루에 1시간만 사용하는 것은 아니라는 것인데요.  

 1시간내에 반납하면 하루에 몇번이라도 계속 이용할수 있다.

그래서 반납만 가능하다면 굳이 2시간 권을 살 필요도 없습니다.

아무데나 반납가능 한것은 아니고 반드시 지정된 대여소에 반납해야 반납이 가능합니다. 

가끔 민간이 운영하는 공유 vehicle 중에 아무데나 반납하는 것들도 있는데요. 

사용자는 편하겠지만 다른 시민이나 거주민에게는 매우 보기도 않좋고 민폐인데 따릉이는 그렇지 않아 좋습니다.

- 주의점 

 오랜동안 사용하면서 몸소 겪은 꿀체험기

 자전거의 정비상태가 제 각각 이라 대여하기 전에 몇가지 체크하고 대여하면 좋습니다. 

 제일 기본적으로는 벨, 브레이크 입니다. 브레이크는 매우 중요해서 보통 정비상태는 좋습니다.

 벨은 가끔 이상한 위치에 달려있거나 해서 불편한 경우도 있으니 잘 확인이 필요합니다. 

 두번째는 잠금장치 인데요. 

  앱으로 잠금해제를 하면 블루투스로 신호가 전달되서 자전거 잠금장치가 열려야 되는데 

 가끔 안되는 경우가 있습니다. 시간내에 반납해야 되고 고장시 바로 도움을 받을 직원이 있는 것도 아니라 

 굉장히 난처한 상황에 처할수도 있어요. 그럴때는 차분히 앱이나 핸드폰을 재부팅 해 봅니다. 

 또는 수동으로 열리는지 시도해봅니다. 처음부터 잠금해제가 시원찮게 동작하면 바로 반납하게 다른 기기를 선택하는게 젤 좋아요.  

- 개선점 및 느낀점

따릉이는 민간사업자가 영리 목적으로 운영하는 것은 아닙니다. (겨울에는 위험하니 사용을 자제해 달라고 권고까지 합니다. )그래서 상대적으로 저렴한 비용으로 운영을 하고 있는데요.. 아무래도 정비에 들어가는 비용이 발생할텐데 사용자들로부터 피드백을 받을수 있는 시스템이 있다면 그 노력을 조금은 줄일수 있지 않을까 하는 생각을 해봤습니다. 직접 타지 않고서는 잘 모르는 상태들이 있으니까요.

많이 탈수록 탄소배출량이 절감되서 더 좋은 환경을 만들고자 하는 취지로 다들 많이 이용했으면 좋겠네요. 

mysql 의 innodb 엔진에서는 테이블 생성시 참조제약조건만 걸고 해당 컬럼에 인덱스를 생성하지 않아도 자동으로 인덱스가 생성이 된다. 

constraint 만 걸고 테이블을 생성하는 것과 명시적으로 키를 생성하는 것의 차이를 알아보자. 

drop table parent;
drop table child_no_idx;
drop table child_idx;


-- parent 테이블 생성 (일반 컬럼 추가)
CREATE TABLE parent (
    id INT NOT NULL PRIMARY KEY,
    name VARCHAR(50),
    email VARCHAR(100),
    created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP
) ENGINE=InnoDB;

-- child 테이블 생성 (제약조건만 명시)
CREATE TABLE child_no_idx (
    id INT NOT NULL PRIMARY KEY,
    parent_id INT,
    name VARCHAR(50),
    email VARCHAR(100),
    description TEXT,
    CONSTRAINT `fk_no_idx_parent_id` FOREIGN KEY (`parent_id`) REFERENCES parent(id)
) ENGINE=InnoDB;

-- child 테이블 생성 (제약조건 + key를 명시)
CREATE TABLE child_idx (
    id INT NOT NULL PRIMARY KEY,
    parent_id INT,
    name VARCHAR(50),
    email VARCHAR(100),
    description TEXT,
    KEY `ix04_child` (`parent_id`),
    CONSTRAINT `fk_idx_parent_id` FOREIGN KEY (`parent_id`) REFERENCES parent(id)
) ENGINE=InnoDB;


-- 인덱스 확인을 위한 쿼리
SHOW INDEX FROM child_no_idx;

SHOW INDEX FROM child_idx;

참조제약조건이 걸려있으면 인덱스를 생성하지 않아도 자동으로 인덱스가 (제약조건 이름으로) 생성이 되었다. 

이제 세컨더리 인덱스를 아래와 같이 추가해보자. 

create index ix01_child on child_no_idx(name, parent_id);
create index ix02_child on child_no_idx(parent_id, name);

제약조건 이름으로 자동 생성되었던 인덱스가 사라졌다. 

참조 제약조건 컬럼(parent_id) 을 선두로 하는 인덱스가 명시적으로 생기면 자동 생성된 인덱스가 사라진다.  

두번째 명시적으로 key 를 만들었던 경우를 비교해보자. 

세컨더리 인덱스를 동일하게 추가해보자. 

create index ix01_child on child_idx(name, parent_id);
create index ix02_child on child_idx(parent_id, name);

사라지지 않고 남아있다.  

물론 ix02_child 인덱스가 parent_id 컬럼을 포함하므로 ix04_parent_id 인덱스는 삭제가 되어도 상관이 없다. 

다만 (제약조건으로 인해) 자동 생성된 인덱스는 자동 삭제가 될수도 있다는 것을 유의해야하고, 이를 인지 하지 않은 상태에서 인덱스를 추가할 경우 의도치 않게 삭제될수 있으니 무조건 명시적으로 key 를 만드는 것이 좋다. 

IOPS와 throughput은 데이터베이스 및 스토리지 시스템의 성능을 측정하는 중요한 지표이다.

IOPS (Input/Output Operations Per Second)

초당 처리할 수 있는 읽기/쓰기 작업의 수를 나타냄
작은 파일들에 대한 빈번한 접근이 필요한 경우에 중요한 지표
데이터에 대한 빠른 접근 및 처리가 필요한 환경에서 중요

Throughput (처리량)

초당 처리할 수 있는 데이터의 크기를 측정. 주로 메가바이트 단위로 표현
큰 파일들을 주로 다루고 데이터 처리 작업이 많지 않은 경우에 중요한 지표
한 번에 큰 용량의 파일을 읽어야 할 때 중요

계산식

IOPS x I/O size = Throughput
예: 16,000 IOPS × 64 KiB = 1,024 MiB/s (Throughput)