동적 요소 순서 보장을 위한 JSON 활용(JSON vs TEXT vs VARCHAR)

프로젝트를 진행하면서 고민한 내용 정리 

 

 

 

[ 프로젝트 설명 ]

공유 페이지 리뉴얼 프로젝트이고, 공유 페이지 내에는 다양한 블록들이 있다. 블록을 추가하고 드래그앤드롭으로 순서를 변경할 수 있다. 공유 페이지 내의 블록들과 블록 내의 데이터들은 저장/수정/조회 시 하나의 API로 전송된다. 공유 페이지 수정 시 블록이 추가되거나 삭제 혹은 순서가 변경될 수 있다. 

블록의 순서는 int값이 아닌, Request, Response 데이터에 순서대로 정렬되어 리스트로 클라이언트와 통신한다. 

 

 

 

 

1. NoSQL vs MySQL

---

프로젝트 플로우상 Update가 많이 발생하고, 데이터 무결성과 정확성 보장을 위해 MySQL을 선택하였다.

 

 

 

 

2. Foreign key를 사용하여 일대다 관계로 DB 설계

---

공유 페이지와 블록 데이터들이 연관관계가 맺어 있다면, 공유 페이지 내에 있는 블록들이 업데이트 될때마다 공유페이지 테이블도 업데이트가 진행이 된다. 업데이트를 최소화하며 블록들의 순서를 보장하기 위한 다른 방법을 생각하게 되었다.    

 

 

 

3. TEXT vs JSON

---

공유 페이지 내 블록들의 순서 보장을 위해 JSON 데이터로 id와 순서 값을 저장하여 문제를 해결하였다. 

 

[MySQL에 JSON 타입도 있는데, TEXT 타입으로 설계한 이유]

JSON 타입은 '데이터의 특정 필드만 접근, 특정 필드만 자주 업데이트, 특정필드로 인덱스 생성' 시 유리하다는 이점이 있으나 성능이 느리다는 단점이 있다. 이 프로젝트에서는 앞서 말한 JSON의 이점이 해당되지 않았기에 빠른 성능 효과를 얻을 수 있는 TEXT 타입으로 설계하였다.

 

공유페이지 테이블

create table space_wall {
    id int auto_increment primary key,
    blocks text, -- position(순서), block_type(ex: listBlock), block_id(PK), block_UUID
    share_url varchar(255),
    space_id int,
    member_id int,
    space_wall_category varchar(255),
    flag varchar(50),
    create_at timestamp default current_timestamp,
    updated_at timestamp default current_timestamp on update current_timestamp,
    deleted_at timestamp null default null,
    foreign key (space_id) references space(id),
    foreign key (member_id) references member(id)
};

blocks 데이터

[
    {
        "position":1,
        "block_type":"WALL_INFO_BLOCK",
        "block_id":33,
        "block_uuid":""
    },
    {
        "position":2,
        "block_type":"SNS_BLOCK",
        "block_id":33,
        "block_uuid":"2222222-0106-4340-b505-280e15626ecc"
        },
    {
        "position":2,
        "block_type":"SNS_BLOCK",
        "block_id":34,
        "block_uuid":"2222222-0106-4340-b505-280e15626ecc"
    },
    {
        "position":3,
        "block_type":"FREE_BLOCK",
        "block_id":33,
        "block_uuid":"1111111-0106-4340-b505-280e15626ecc"
    },
    {
        "position":4,
        "block_type":"LIST_BLOCK",
        "block_id":33,
        "block_uuid":"f108fff1-0106-4340-b505-280e15626ecc"
    },
    {
        "position":4,
        "block_type":"LIST_BLOCK",
        "block_id":34,
        "block_uuid":"f108fff1-0106-4340-b505-280e15626ecc"
    },
    {
        "position":5,
        "block_type":"FILE_BLOCK",
        "block_id":33,
        "block_uuid":"f108fff1-0106-4340-b505-280e15626ecc"
    },
    {
        "position":6,
        "block_type":"LIST_BLOCK",
        "block_id":35,
        "block_uuid":"f108fff1-0106-4340-b505-280e15626ecc"
    },
    {
        "position":6,
        "block_type":"LIST_BLOCK",
        "block_id":36,
        "block_uuid":"f108fff1-0106-4340-b505-280e15626ecc"
    },
    {
        "position":7,
        "block_type":"SNS_BLOCK",
        "block_id":35,
        "block_uuid":"2222222-0106-4340-b505-280e15626ecc"
    },
    {
        "position":7,
        "block_type":"SNS_BLOCK",
        "block_id":36,
        "block_uuid":"2222222-0106-4340-b505-280e15626ecc"
    },
    {
        "position":8,
        "block_type":"TEMPLATE_BLOCK",
        "block_id":33,
        "block_uuid":"f108fff1-0106-4340-b505-280e15626ecc"
    },
    {
        "position":8,
        "block_type":"TEMPLATE_BLOCK",
        "block_id":34,
        "block_uuid":"f108fff1-0106-4340-b505-280e15626ecc"
    },
    {
        "position":9,
        "block_type":"FILE_BLOCK",
        "block_id":34,
        "block_uuid":"f108fff1-0106-4340-b505-280e15626ecc"
    },
    {
        "position":10,
        "block_type":"STYLE_SETTING",
        "block_id":33,
        "block_uuid":""
    }
]

 

 

4. VARCHAR vs TEXT

---

JSON 데이터를 TEXT 컬럼으로 저장하려고 하다 보니 문자열의 경우 VARCHAR로 저장할 수 도 있기 때문에 VACHAR와 TEXT 두 가지를 고려해 보았다.

 

[ TEXT ]

BLOB, TEXT와 같은 대용량 데이터를 저장하는 컬럼 타입을 LOB(LargeObject)라고한다.

RDBMS에서 LOB 데이터는 off-page(Extenrnl off-page storage)라고 하는 외부 공간에 저장된다. 다른 타입의 데이터는 행의 B-Tree에 Inline 저장된다. 그래서 BLOB나 TEXT 컬럼은 레코드 사이즈 한계에 거의 영향을 미치지 않는다.

하지만 MySQL InnoDB엔진의 경우 LOB 데이터의 길이가 767바이트 초과 시에만 off-page에 저장하고, 그 이하일 때는 다른 필드와 함께 행의 B-Tree에 저장(Inline 저장)한다. 이는 공간 효율성과 성능 향상을 위한 것이다. Inline으로 저장되면 데이터에 접근하기 위한 추가적인 디스크 I/O가 필요하지 않아 데이터 액세스가 더 빨라질 수 있다.

 

LOB 데이터는 매번 레코드를 읽고 쓸 때마다 필요한 만큼 메모리가 할당되어야한다. 이때 사용되는 메모리 공간은 Perfomance_Schema에 의해 측정되지 않는다. 그래서 LOB용 메모리 할당 해제가 실행되는지 알 수 없어서 성능 영향도를 파악하기 어렵다는 단점이 있다.

 

[ VARCHAR ]

VARCHAR는 가변길이 문자열 타입이다. 필드에 데이터가 삽입되면 필요한 만큼 버퍼에 메모리가 할당되고, 최대 길이까지 동적으로 확장될 수 있다. (최대길이란 데이터 타입 선언 시 괄호 안에 지정된 숫자)

VARCHAR 타입에 저장된 값이 길어서 off-page로 저장된 경우, MySQL서버는 TABLE 객체의 records[2] 버퍼를 사용하지 못하고 새롭게 메모리 공간을 할당해서 사용한다. 그래서 매우 큰 값이 빈번하게 저장되는 경우에는 주의가 필요하다.

일반적으로는 행의 B-Tree에 저장(Inline 저장)된다.

 

한 행의 최대 크기가 65,535바이트인데, 하나의 varchar 컬럼이 너무 큰 길이를 사용하면 다른 컬럼들이 사용할 수 있는 최대 공간의 크기가 영향을 받게 된다. MySQL 서버에서는 레코드 사이즈 한계로 인해서 varchar 타입의 최대 저장 길이 설정 시에 공간을 아껴서 설정해야 한다. 

 

 

이 프로젝트의 경우 블록 생성에 제한이 없기 때문에 안정적인 서비스 제공을 위하여 TEXT 컬럼을 사용하기로 하였다. 제한되게 설계를 하였다가 어떤 문제로 인하여 DB 커넥션 문제가 발생하게 될 경우, 유저의 데이터가 유실되는 등의 치명적인 문제가 발생할 수 있기 때문이다.

따라서 다른 컬럼에 영향을 미칠 수 있는 값이 들어올 확률이 1%라도 있다면 TEXT 컬럼을 사용하는 게 맞다고 생각하였다.

 

 

 

 

 

 

---

🌈 참고 링크 

JSON vs TEXT

 

VARCHAR vs TEXT