데이터베이스 설계 기초 - PostgreSQL, Cassandra 및 MongoDB 비교

안녕하세요 친구. XNUMX월 두 번째 연휴를 떠나기 전에, 코스에 새로운 스트림이 시작될 것을 예상하여 번역한 자료를 여러분과 공유합니다. "관계형 DBMS".

애플리케이션 개발자는 의도한 워크로드에 가장 적합한 데이터베이스를 선택하기 위해 여러 운영 데이터베이스를 비교하는 데 많은 시간을 소비합니다. 요구 사항에는 단순화된 데이터 모델링, 트랜잭션 보장, 읽기/쓰기 성능, 수평 확장 및 내결함성이 포함될 수 있습니다. 전통적으로 선택은 SQL 또는 NoSQL이라는 데이터베이스 범주에서 시작됩니다. 각 범주는 명확한 장단점을 제시하기 때문입니다. 낮은 대기 시간과 높은 처리량 측면에서 고성능은 일반적으로 절충 불가능한 요구 사항으로 간주되므로 모든 샘플 데이터베이스에 필수적입니다.

이 기사의 목적은 애플리케이션 개발자가 애플리케이션 데이터 모델링의 맥락에서 SQL과 NoSQL 중에서 올바른 선택을 하도록 돕는 것입니다. 하나의 SQL 데이터베이스인 PostgreSQL과 두 개의 NoSQL 데이터베이스인 Cassandra 및 MongoDB를 살펴보고 테이블 생성, 채우기, 테이블에서 데이터 읽기 및 삭제와 같은 데이터베이스 설계의 기본 사항을 다룹니다. 다음 기사에서는 인덱스, 트랜잭션, JOIN, TTL 지시문 및 JSON 기반 데이터베이스 디자인을 살펴보겠습니다.

SQL과 NoSQL의 차이점은 무엇입니까?

SQL 데이터베이스는 기존 정규화된 관계형 데이터베이스 모델 위에 예상치 못한 방식으로 JOIN을 사용하여 데이터를 쿼리하는 기능뿐만 아니라 ACID 트랜잭션 보장을 통해 애플리케이션 유연성을 높입니다.

모놀리식/단일 노드 아키텍처와 중복성을 위한 마스터-슬레이브 복제 모델 사용을 고려할 때 기존 SQL 데이터베이스에는 선형 쓰기 확장성(예: 여러 노드에 걸친 자동 분할) 및 자동/제로 데이터 손실이라는 두 가지 중요한 기능이 부족합니다. 이는 수신된 데이터의 양이 단일 노드의 최대 쓰기 처리량을 초과할 수 없음을 의미합니다. 또한 내결함성(비공유 아키텍처)에서는 일부 일시적인 데이터 손실을 고려해야 합니다. 여기서 최근 커밋이 아직 슬레이브 복사본에 반영되지 않았다는 점을 명심해야 합니다. 가동 중지 시간이 없는 업데이트도 SQL 데이터베이스에서 달성하기 어렵습니다.

NoSQL 데이터베이스는 일반적으로 본질적으로 분산됩니다. 그 안에서 데이터는 여러 섹션으로 나누어져 여러 노드에 분산됩니다. 비정규화가 필요합니다. 이는 사용자가 보내는 특정 요청에 응답하기 위해 입력한 데이터도 여러 번 복사해야 함을 의미합니다. 전반적인 목표는 읽기 중에 사용 가능한 샤드 수를 줄여 고성능을 얻는 것입니다. 이는 NoSQL에서는 쿼리를 모델링해야 하고 SQL에서는 데이터를 모델링해야 함을 의미합니다.

NoSQL은 분산 클러스터에서 높은 성능을 달성하는 데 중점을 두고 있으며 이는 ACID 트랜잭션 손실, JOIN 및 일관된 글로벌 보조 인덱스를 포함하는 많은 데이터베이스 설계 절충안의 기본 근거입니다.

NoSQL 데이터베이스는 선형 쓰기 확장성과 높은 내결함성을 제공하지만 트랜잭션 보장이 상실되어 미션 크리티컬 데이터에 적합하지 않다는 주장이 있습니다.

다음 표에서는 NoSQL의 데이터 모델링이 SQL과 어떻게 다른지 보여줍니다.

SQL과 NoSQL: 둘 다 필요한 이유는 무엇입니까?

Amazon.com, Netflix, Uber, Airbnb와 같이 사용자 수가 많은 실제 애플리케이션은 복잡하고 다면적인 작업을 수행해야 합니다. 예를 들어 Amazon.com과 같은 전자 상거래 애플리케이션은 사용자 정보, 제품, 주문, 송장과 같은 가볍고 중요도가 높은 데이터와 제품 리뷰, 지원 메시지, 사용자 활동 등 무겁고 덜 민감한 데이터를 저장해야 합니다. 사용자 리뷰 및 추천. 당연히 이러한 애플리케이션은 하나 이상의 NoSQL 데이터베이스와 함께 하나 이상의 SQL 데이터베이스를 사용합니다. 지역 간 및 글로벌 시스템에서 NoSQL 데이터베이스는 특정 지역에서 실행되는 신뢰할 수 있는 원본 SQL 데이터베이스에 저장된 데이터에 대한 지리적 분산 캐시로 작동합니다.

YugaByte DB는 SQL과 NoSQL을 어떻게 결합합니까?

로그 중심 혼합 스토리지 엔진, 자동 샤딩, 샤딩된 분산 합의 복제 및 ACID 분산 트랜잭션(Google Spanner에서 영감을 얻음)을 기반으로 구축된 YugaByte DB는 NoSQL(Cassandra & Redis)과 동시에 호환되는 세계 최초의 오픈 소스 데이터베이스입니다. SQL(포스트그레SQL). 아래 표에서 볼 수 있듯이 Cassandra와 호환되는 YugaByte DB API인 YCQL은 NoSQL API에 단일 및 다중 키 ACID 트랜잭션과 글로벌 보조 인덱스 개념을 추가하여 트랜잭션 NoSQL 데이터베이스 시대를 엽니다. 또한 PostgreSQL과 호환되는 YugaByte DB API인 YCQL은 SQL API에 선형 쓰기 확장 및 자동 내결함성 개념을 추가하여 분산 SQL 데이터베이스를 세상에 선보입니다. YugaByte DB는 본질적으로 트랜잭션이므로 이제 NoSQL API를 미션 크리티컬 데이터의 맥락에서 사용할 수 있습니다.

앞서 기사에서 밝혔듯이 "YSQL 소개: YugaByte DB용 PostgreSQL 호환 분산 SQL API", YugaByte DB에서 SQL 또는 NoSQL 중 선택은 전적으로 기본 워크로드의 특성에 따라 달라집니다.

• 기본 워크로드가 다중 키 JOIN 작업인 경우 YSQL을 선택할 때 키가 여러 노드에 분산되어 NoSQL보다 지연 시간이 길어지거나 처리량이 낮아질 수 있다는 점을 이해하세요.
• 그렇지 않은 경우 두 가지 NoSQL API 중 하나를 선택하세요. 한 번에 한 노드에서 쿼리가 제공되면 더 나은 성능을 얻을 수 있다는 점을 염두에 두세요. YugaByte DB는 여러 워크로드를 동시에 관리해야 하는 실제 복잡한 애플리케이션을 위한 단일 운영 데이터베이스 역할을 할 수 있습니다.

다음 섹션의 데이터 모델링 랩은 기본 데이터베이스가 아닌 PostgreSQL 및 Cassandra API 호환 YugaByte DB 데이터베이스를 기반으로 합니다. 이 접근 방식은 서로 다른 두 데이터베이스의 완전히 독립적인 클러스터를 사용하는 것과 달리 동일한 데이터베이스 클러스터의 서로 다른 두 API(두 개의 서로 다른 포트에 있음)와 쉽게 상호 작용할 수 있다는 점을 강조합니다.
다음 섹션에서는 데이터 모델링 랩을 살펴보고 다루는 데이터베이스의 차이점과 일부 공통점을 설명합니다.

데이터 모델링 연구실

데이터베이스 설치

복잡한 배포 아키텍처가 아닌 데이터 모델 설계에 중점을 두고 로컬 시스템의 Docker 컨테이너에 데이터베이스를 설치한 다음 해당 명령줄 셸을 사용하여 상호 작용합니다.

PostgreSQL 및 Cassandra 호환 YugaByte DB 데이터베이스

mkdir ~/yugabyte && cd ~/yugabyte
wget https://downloads.yugabyte.com/yb-docker-ctl && chmod +x yb-docker-ctl
docker pull yugabytedb/yugabyte
./yb-docker-ctl create --enable_postgres

MongoDB의

docker run --name my-mongo -d mongo:latest

명령줄 액세스

해당 API에 대한 명령줄 셸을 사용하여 데이터베이스에 연결해 보겠습니다.

PostgreSQL

psql PostgreSQL과 상호작용하기 위한 명령줄 셸입니다. 사용 편의성을 위해 YugaByte DB에는 bin 폴더에 바로 psql이 포함되어 있습니다.

docker exec -it yb-postgres-n1 /home/yugabyte/postgres/bin/psql -p 5433 -U postgres

카산드 라

cqlsh CQL(Cassandra Query Language)을 통해 Cassandra 및 호환 데이터베이스와 상호 작용하기 위한 명령줄 셸입니다. 사용 편의성을 위해 YugaByte DB에는 cqlsh 카탈로그에 bin.
CQL은 SQL에서 영감을 얻었으며 테이블, 행, 열 및 인덱스와 유사한 개념을 가지고 있습니다. 그러나 NoSQL 언어로서 특정 제한 사항이 추가되며, 대부분은 다른 기사에서도 다룰 것입니다.

docker exec -it yb-tserver-n1 /home/yugabyte/bin/cqlsh

MongoDB의

몽고 MongoDB와 상호작용하기 위한 명령줄 셸입니다. MongoDB 설치의 bin 디렉토리에서 찾을 수 있습니다.

docker exec -it my-mongo bash 
cd bin
mongo

테이블 만들기

이제 명령줄을 사용하여 데이터베이스와 상호 작용하여 다양한 작업을 수행할 수 있습니다. 다양한 아티스트가 작곡한 노래에 대한 정보를 저장하는 테이블을 만드는 것부터 시작해 보겠습니다. 이 노래는 앨범의 일부일 수 있습니다. 또한 노래의 선택적 속성에는 출시 연도, 가격, 장르 및 등급이 있습니다. "태그" 필드를 통해 향후 필요할 수 있는 추가 속성을 고려해야 합니다. 키-값 쌍의 형태로 반구조화된 데이터를 저장할 수 있습니다.

PostgreSQL

CREATE TABLE Music (
    Artist VARCHAR(20) NOT NULL, 
    SongTitle VARCHAR(30) NOT NULL,
    AlbumTitle VARCHAR(25),
    Year INT,
    Price FLOAT,
    Genre VARCHAR(10),
    CriticRating FLOAT,
    Tags TEXT,
    PRIMARY KEY(Artist, SongTitle)
);	

카산드 라

Cassandra에서 테이블을 생성하는 것은 PostgreSQL과 매우 유사합니다. 주요 차이점 중 하나는 무결성 제약 조건(예: NOT NULL)이 없다는 점이지만 이는 NoSQL 데이터베이스가 아닌 애플리케이션의 책임입니다.. 기본 키는 파티션 키(아래 예의 Artist 열)와 클러스터링 열 집합(아래 예의 SongTitle 열)으로 구성됩니다. 파티션 키는 행을 어느 파티션/샤드에 배치해야 하는지 결정하고, 클러스터링 열은 현재 샤드 내에서 데이터를 구성하는 방법을 나타냅니다.

CREATE KEYSPACE myapp;
USE myapp;
CREATE TABLE Music (
    Artist TEXT, 
    SongTitle TEXT,
    AlbumTitle TEXT,
    Year INT,
    Price FLOAT,
    Genre TEXT,
    CriticRating FLOAT,
    Tags TEXT,
    PRIMARY KEY(Artist, SongTitle)
);

MongoDB의

MongoDB는 데이터를 데이터베이스(카산드라의 Keyspace와 유사)로 구성합니다. 여기에는 문서(테이블의 행과 유사)를 포함하는 컬렉션(테이블과 유사)이 있습니다. MongoDB에서는 기본적으로 초기 스키마를 정의할 필요가 없습니다. 팀 "데이터베이스 사용"아래 표시된 는 첫 번째 호출에서 데이터베이스를 인스턴스화하고 새로 생성된 데이터베이스의 컨텍스트를 변경합니다. 컬렉션도 명시적으로 생성할 필요가 없으며 새 컬렉션에 첫 번째 문서를 추가하면 자동으로 생성됩니다. MongoDB는 기본적으로 테스트 데이터베이스를 사용하므로 특정 데이터베이스를 지정하지 않은 모든 컬렉션 수준 작업은 기본적으로 해당 데이터베이스에서 실행됩니다.

use myNewDatabase;

테이블에 대한 정보 가져오기
PostgreSQL

d Music
Table "public.music"
    Column    |         Type          | Collation | Nullable | Default 
--------------+-----------------------+-----------+----------+--------
 artist       | character varying(20) |           | not null | 
 songtitle    | character varying(30) |           | not null | 
 albumtitle   | character varying(25) |           |          | 
 year         | integer               |           |          | 
 price        | double precision      |           |          | 
 genre        | character varying(10) |           |          | 
 criticrating | double precision      |           |          | 
 tags         | text                  |           |          | 
Indexes:
    "music_pkey" PRIMARY KEY, btree (artist, songtitle)

카산드 라

DESCRIBE TABLE MUSIC;
CREATE TABLE myapp.music (
    artist text,
    songtitle text,
    albumtitle text,
    year int,
    price float,
    genre text,
    tags text,
    PRIMARY KEY (artist, songtitle)
) WITH CLUSTERING ORDER BY (songtitle ASC)
    AND default_time_to_live = 0
    AND transactions = {'enabled': 'false'};

MongoDB의

use myNewDatabase;
show collections;

테이블에 데이터 입력
PostgreSQL

INSERT INTO Music 
    (Artist, SongTitle, AlbumTitle, 
    Year, Price, Genre, CriticRating, 
    Tags)
VALUES(
    'No One You Know', 'Call Me Today', 'Somewhat Famous',
    2015, 2.14, 'Country', 7.8,
    '{"Composers": ["Smith", "Jones", "Davis"],"LengthInSeconds": 214}'
);
INSERT INTO Music 
    (Artist, SongTitle, AlbumTitle, 
    Price, Genre, CriticRating)
VALUES(
    'No One You Know', 'My Dog Spot', 'Hey Now',
    1.98, 'Country', 8.4
);
INSERT INTO Music 
    (Artist, SongTitle, AlbumTitle, 
    Price, Genre)
VALUES(
    'The Acme Band', 'Look Out, World', 'The Buck Starts Here',
    0.99, 'Rock'
);
INSERT INTO Music 
    (Artist, SongTitle, AlbumTitle, 
    Price, Genre, 
    Tags)
VALUES(
    'The Acme Band', 'Still In Love', 'The Buck Starts Here',
    2.47, 'Rock', 
    '{"radioStationsPlaying": ["KHCR", "KBQX", "WTNR", "WJJH"], "tourDates": { "Seattle": "20150625", "Cleveland": "20150630"}, "rotation": Heavy}'
);

카산드 라

전체적인 표현 INSERT Cassandra의 경우 PostgreSQL의 경우와 매우 유사해 보입니다. 그러나 의미론에는 한 가지 큰 차이점이 있습니다. 카산드라에서 INSERT 실제로는 조작이다 UPSERT, 행이 이미 존재하는 경우 마지막 값이 행에 추가됩니다.

데이터 입력은 PostgreSQL과 유사합니다. INSERT 이상

.

MongoDB의

MongoDB는 Cassandra와 같은 NoSQL 데이터베이스이지만 삽입 작업은 Cassandra의 의미적 동작과 공통점이 없습니다. 몽고DB에서 끼워 넣다() 기회가 없다 UPSERT, 이는 PostgreSQL과 유사합니다. 없이 기본 데이터 추가 _idspecified 새 문서가 컬렉션에 추가됩니다.

db.music.insert( {
artist: "No One You Know",
songTitle: "Call Me Today",
albumTitle: "Somewhat Famous",
year: 2015,
price: 2.14,
genre: "Country",
tags: {
Composers: ["Smith", "Jones", "Davis"],
LengthInSeconds: 214
}
}
);
db.music.insert( {
artist: "No One You Know",
songTitle: "My Dog Spot",
albumTitle: "Hey Now",
price: 1.98,
genre: "Country",
criticRating: 8.4
}
);
db.music.insert( {
artist: "The Acme Band",
songTitle: "Look Out, World",
albumTitle:"The Buck Starts Here",
price: 0.99,
genre: "Rock"
}
);
db.music.insert( {
artist: "The Acme Band",
songTitle: "Still In Love",
albumTitle:"The Buck Starts Here",
price: 2.47,
genre: "Rock",
tags: {
radioStationsPlaying:["KHCR", "KBQX", "WTNR", "WJJH"],
tourDates: {
Seattle: "20150625",
Cleveland: "20150630"
},
rotation: "Heavy"
}
}
);

테이블 쿼리

아마도 쿼리 구성 측면에서 SQL과 NoSQL의 가장 중요한 차이점은 사용되는 언어일 것입니다. FROM и WHERE. SQL에서는 표현식 이후에 허용됩니다. FROM 여러 테이블을 선택하고 WHERE 어떤 복잡성이라도 있을 수 있습니다(운영 포함). JOIN 테이블 사이). 그러나 NoSQL은 다음 사항에 심각한 제한을 가하는 경향이 있습니다. FROM, 지정된 하나의 테이블에서만 작동합니다. WHERE, 기본 키는 항상 지정되어야 합니다. 이는 앞서 이야기한 NoSQL 성능 향상과 관련이 있습니다. 이러한 요구로 인해 표 간 및 키 간 상호 작용이 가능한 한 모두 감소됩니다. 요청에 응답할 때 노드 간 통신에 큰 지연이 발생할 수 있으므로 일반적으로 피하는 것이 가장 좋습니다. 예를 들어 Cassandra에서는 쿼리가 특정 연산자로 제한되도록 요구합니다( =, IN, <, >, =>, <=)를 파티션 키에 적용합니다. 단, 보조 인덱스를 요청할 때를 제외합니다(여기서는 = 연산자만 허용됩니다).

PostgreSQL

다음은 SQL 데이터베이스에서 쉽게 실행할 수 있는 쿼리의 세 가지 예입니다.

• 아티스트의 모든 노래를 표시합니다.
• 제목의 첫 번째 부분과 일치하는 아티스트의 모든 노래를 표시합니다.
• 제목에 특정 단어가 있고 가격이 1.00 미만인 아티스트의 모든 노래를 표시합니다.

SELECT * FROM Music
WHERE Artist='No One You Know';
SELECT * FROM Music
WHERE Artist='No One You Know' AND SongTitle LIKE 'Call%';
SELECT * FROM Music
WHERE Artist='No One You Know' AND SongTitle LIKE '%Today%'
AND Price > 1.00;

카산드 라

위에 나열된 PostgreSQL 쿼리 중 첫 번째 쿼리만 Cassandra에서 변경 없이 작동합니다. LIKE 다음과 같은 클러스터링 열에는 적용할 수 없습니다. SongTitle. 이 경우 운영자만 허용됩니다. = и IN.

SELECT * FROM Music
WHERE Artist='No One You Know';
SELECT * FROM Music
WHERE Artist='No One You Know' AND SongTitle IN ('Call Me Today', 'My Dog Spot')
AND Price > 1.00;

MongoDB의

이전 예제에서 볼 수 있듯이 MongoDB에서 쿼리를 생성하는 주요 방법은 다음과 같습니다. db.collection.find(). 이 메서드에는 컬렉션 이름(music 아래 예에서는), 따라서 여러 컬렉션을 쿼리하는 것은 금지됩니다.

db.music.find( {
  artist: "No One You Know"
 } 
);
db.music.find( {
  artist: "No One You Know",
  songTitle: /Call/
 } 
);

테이블의 모든 행 읽기

모든 행을 읽는 것은 앞서 살펴본 쿼리 패턴의 특별한 경우일 뿐입니다.

PostgreSQL

SELECT * 
FROM Music;

카산드 라

위의 PostgreSQL 예제와 유사합니다.

MongoDB의

db.music.find( {} );

테이블의 데이터 편집

PostgreSQL

PostgreSQL은 지침을 제공합니다. UPDATE 데이터를 변경합니다. 그녀에게는 기회가 없습니다 UPSERT이므로 해당 행이 더 이상 데이터베이스에 없으면 이 문은 실패합니다.

UPDATE Music
SET Genre = 'Disco'
WHERE Artist = 'The Acme Band' AND SongTitle = 'Still In Love';

카산드 라

카산드라는 UPDATE PostgreSQL과 유사합니다. UPDATE 동일한 의미를 가지고 있습니다 UPSERT, 좋다 INSERT.

위의 PostgreSQL 예제와 유사합니다.

MongoDB의
운전 최신 정보() MongoDB에서는 기존 문서를 완전히 업데이트하거나 특정 필드만 업데이트할 수 있습니다. 기본적으로 의미 체계가 비활성화된 하나의 문서만 업데이트합니다. UPSERT. 여러 문서 업데이트 및 유사한 동작 UPSERT 해당 작업에 대한 추가 플래그를 설정하여 적용할 수 있습니다. 예를 들어 아래 예에서는 특정 아티스트의 장르가 그의 노래를 기반으로 업데이트됩니다.

db.music.update(
  {"artist": "The Acme Band"},
  { 
    $set: {
      "genre": "Disco"
    }
  },
  {"multi": true, "upsert": true}
);

테이블에서 데이터 제거

PostgreSQL

DELETE FROM Music
WHERE Artist = 'The Acme Band' AND SongTitle = 'Look Out, World';

카산드 라

위의 PostgreSQL 예제와 유사합니다.

MongoDB의

MongoDB에는 문서를 삭제하는 두 가지 유형의 작업이 있습니다. 삭제원() /삭제많은() и 없애다(). 두 가지 유형 모두 문서를 삭제하지만 다른 결과를 반환합니다.

db.music.deleteMany( {
        artist: "The Acme Band"
    }
);

테이블 삭제

PostgreSQL

DROP TABLE Music;

카산드 라

위의 PostgreSQL 예제와 유사합니다.

MongoDB의

db.music.drop();

결론

SQL과 NoSQL 중 하나를 선택하는 것에 대한 논쟁은 10년 넘게 격렬해졌습니다. 이 논쟁에는 데이터베이스 엔진 아키텍처(모놀리식, 트랜잭션 SQL 대 분산, 비트랜잭션 NoSQL)와 데이터베이스 설계 접근 방식(SQL에서 데이터 모델링 대 NoSQL에서 쿼리 모델링)이라는 두 가지 주요 측면이 있습니다.

YugaByte DB와 같은 분산 트랜잭션 데이터베이스를 사용하면 데이터베이스 아키텍처에 대한 논쟁을 쉽게 잠재울 수 있습니다. 데이터 볼륨이 단일 노드에 쓸 수 있는 것보다 커지면서 자동 샤딩/리밸런싱을 통해 선형 쓰기 확장성을 지원하는 완전 분산형 아키텍처가 필요해졌습니다.

게다가 어느 기사에서도 밝혔듯이 Google 클라우드,트랜잭션적이고 강력한 일관성을 갖춘 아키텍처는 이제 비트랜잭션적이고 최종적으로 일관된 아키텍처보다 더 나은 개발 민첩성을 제공하는 데 더 많이 사용됩니다.

데이터베이스 설계 논의로 돌아가서, 복잡한 실제 애플리케이션에는 두 가지 설계 접근 방식(SQL 및 NoSQL)이 모두 필요하다고 말하는 것이 타당합니다. SQL "데이터 모델링" 접근 방식을 사용하면 개발자는 변화하는 비즈니스 요구 사항을 보다 쉽게 ​​충족할 수 있으며, NoSQL "쿼리 모델링" 접근 방식을 사용하면 동일한 개발자가 짧은 대기 시간과 높은 처리량으로 대용량 데이터를 작업할 수 있습니다. 이러한 이유로 YugaByte DB는 접근 방식 중 하나를 홍보하는 대신 공통 코어에서 SQL 및 NoSQL API를 제공합니다. 또한 YugaByte DB는 PostgreSQL 및 Cassandra를 비롯한 널리 사용되는 데이터베이스 언어와의 호환성을 제공함으로써 개발자가 일관성이 뛰어난 분산 데이터베이스 엔진을 사용하기 위해 다른 언어를 배울 필요가 없도록 보장합니다.

이 기사에서는 PostgreSQL, Cassandra 및 MongoDB 간의 데이터베이스 설계 기본 사항이 어떻게 다른지 살펴보았습니다. 향후 기사에서는 인덱스, 트랜잭션, JOIN, TTL 지시문 및 JSON 문서와 같은 고급 디자인 개념을 자세히 살펴보겠습니다.

남은 주말 잘 보내시기 바라며, 초대합니다. 무료 웹 세미나, 14월 XNUMX일에 진행됩니다.

출처 : habr.com