Catalog 가이드

Database

이 페이지의 내용

Database가 기록하는 정보#

필드	내용
`name`·`engine`	이름과 engine. 필수
`handle`	Web 주소 이름. 필수이며 같은 Organization의 Database 사이에서 고유하고 `structures`는 쓸 수 없습니다(주소 이름)
`summary`·`description`	한 줄 요약과 설명
`relational_options`	다섯 RDB의 `database_name`
`redis_options`	Redis의 `mode`(standalone·cluster·sentinel)·`db_index`·`master_name`·`connection_alias`
`cassandra_options`	Cassandra의 `keyspace_name`
`external_references`	코드·외부 문서 출처

engine은 postgresql·mysql·mariadb·oracle·sqlserver·mongodb·redis·cassandra입니다. 접속 주소·자격 증명은 기록하지 않습니다.

Web UI#

Datastores → 새 Database에서 engine과 이름을 입력하고 Database 등록을 누릅니다. Database 상세에서 engine에 맞는 소속 구조(새 Table·새 Collection·새 Key Pattern·새 Cassandra Table)를 추가합니다.

다섯 RDB Database 상세의 ERD 보기는 소속 Table과 기록된 Foreign Key의 참조 구조를 넓은 화면으로 보여줍니다. 같은 Database에서 찾지 못한 대상은 점선의 미등록 Table로, 실제 DB Constraint 없이 기록한 참조는 점 모양 선과 DB Constraint 없음으로 표시하며 카디널리티는 표시하지 않습니다. Table을 고르면 그 Table과 바로 참조하거나 참조되는 Table을 강조하고, 이 상태는 주소에 남아 링크로 공유할 수 있습니다.

소속 구조#

engine	소속 구조	stly 리소스	생성 옵션
PostgreSQL·MySQL·MariaDB·Oracle·Microsoft SQL Server	Table	`tables`	`--database <id>`
MongoDB	Collection	`collections`	`--database <id>`
Redis	Key Pattern	`key-patterns`	`--database <id>`
Cassandra	Table	`cassandra-tables`	`--database <id>`

모든 Database의 소속 구조 요약은 한 번에 조회할 수 있습니다.

stly databases structures

PostgreSQL 예#

{"name": "orders-db", "handle": "orders-db", "engine": "postgresql", "summary": "주문 Service의 운영 DB", "relational_options": {"database_name": "orders"}}

stly databases create --input database.json

Table은 Column·Primary Key·Unique Key·Foreign Key·Index를 definition에 담습니다. 비어 있는 항목도 빈 배열로 보냅니다.

{
  "name": "orders",
  "namespace": "public",
  "summary": "주문 기본 정보",
  "definition": {
    "columns": [
      {"name": "id", "data_type": "uuid", "nullable": false, "default_expression": null, "description": "주문 ID"},
      {"name": "status", "data_type": "text", "nullable": false, "default_expression": "'pending'", "description": "주문 상태"}
    ],
    "primary_key": {"name": "orders_pkey", "columns": ["id"]},
    "unique_keys": [],
    "foreign_keys": [],
    "indexes": []
  }
}

stly tables validate --operation create --database 1Zvw5jZYaAM --input table.json
stly tables create --database 1Zvw5jZYaAM --input table.json
stly tables list --database 1Zvw5jZYaAM --fields id,namespace,name

namespace는 PostgreSQL·Oracle·SQL Server에서는 Schema 이름, MySQL·MariaDB에서는 빈 문자열입니다.

실제 DB Constraint가 없는 참조#

Foreign Key의 constraint_in_database는 실제 DB에 그 Constraint가 있는지 기록합니다. true는 있음, false는 없음, null은 미기록이며 생략하면 null입니다. 실제 DB에 FOREIGN KEY Constraint 없이 애플리케이션 코드·ORM에서만 쓰는 참조는 Column 설명 대신 false로 기록하면 ERD에 표시됩니다. false이면 name·on_delete·on_update를 null로 보내고, 확인한 코드 위치 같은 근거는 description에 적습니다. Structly는 실제 DB에 접속하거나 DDL을 실행하지 않습니다.

{"name": null, "columns": ["user_id"], "target": {"namespace": "public", "table_name": "users", "columns": ["id"]}, "on_delete": null, "on_update": null, "constraint_in_database": false, "description": "출처: order-api/internal/entity/order.go"}

Redis 예#

{"name": "session-cache", "handle": "session-cache", "engine": "redis", "summary": "세션 캐시", "redis_options": {"mode": "standalone", "db_index": 0}}

Key Pattern은 ${변수} 템플릿과 변수 설명, 값 구조, TTL을 기록합니다. 템플릿의 변수마다 variables에 설명이 하나씩 필요합니다.

{
  "template": "session:${session_id}",
  "summary": "로그인 세션",
  "definition": {
    "variables": [{"name": "session_id", "description": "세션 ID"}],
    "value": {"type": "string", "structure": {"encoding": "json", "description": "세션 정보 JSON"}},
    "ttl": {"mode": "fixed", "seconds": 1209600, "description": "14일"}
  }
}

stly key-patterns create --database 8vuXCuVcMBb --input key-pattern.json

값의 type은 string·hash·list·set·sorted_set·stream이며 type마다 structure가 다릅니다. stly schema key-patterns create에서 확인합니다.

Key Pattern은 같은 Organization의 다른 Redis Database로 옮길 수 있습니다. stly가 최신 상세를 조회해 소속만 바꾸며 실제 Redis 키는 옮기지 않습니다.

stly key-patterns move <key-pattern-id> --database <목적지 Database ID> --dry-run
stly key-patterns move <key-pattern-id> --database <목적지 Database ID>

MongoDB Collection과 Cassandra Table의 입력은 stly schema collections create·stly schema cassandra-tables create에서 확인합니다.

Service 연결#

Database와 소속 구조(Key Pattern·Table·Collection·Cassandra Table)에 사용하는 Service를 각각 연결합니다. 공용 Database라면 구조마다 사용하는 Service를 따로 기록할 수 있습니다. Web UI에서는 상세의 연결 Service에서 편집합니다. Database의 연결은 소속 구조에 자동 반영되지 않습니다.

stly databases service-links get <database-id>
stly databases service-links update <database-id> --input links.json --if-match '"연결 조회의 ETag"'
stly key-patterns service-links update <key-pattern-id> --input links.json --if-match '"연결 조회의 ETag"'
stly tables service-links update <table-id> --input links.json --if-match '"연결 조회의 ETag"'

collections·cassandra-tables도 같은 service-links get|update 명령을 사용합니다.

links.json은 {"service_ids": ["Service ID"]} 형식이며 []이면 모두 해제합니다. 소속 구조를 다른 Database로 이동해도 연결은 유지됩니다.

삭제#

소속 구조나 Service 연결이 남아 있는 Database는 삭제할 수 없습니다(HTTP 409 DATABASE_IN_USE). Service 연결이 남아 있는 소속 구조도 삭제할 수 없습니다(HTTP 409 KEY_PATTERN_IN_USE·TABLE_IN_USE·COLLECTION_IN_USE·CASSANDRA_TABLE_IN_USE). 소속 구조를 삭제하고 연결을 해제한 뒤 삭제합니다.