각각 하나의 스키마로 여러 개의 데이터베이스를 사용하는 것이 좋습니까, 아니면 여러 개의 스키마로 하나의 데이터베이스를 사용하는 것이 좋습니까?

각각 하나의 스키마로 여러 개의 데이터베이스를 사용하는 것이 좋습니까, 아니면 여러 개의 스키마로 하나의 데이터베이스를 사용하는 것이 좋습니까?

닫혔습니다. 이 질문은.여론에 입각한현재 답변을 수락하고 있지 않습니다.

---

이 질문을 개선하고 싶으십니까?이 게시물을 편집하여 사실과 인용문으로 답변할 수 있도록 질문을 업데이트합니다.

9개월 전에 문을 닫았습니다.

커뮤니티는 9개월 전에 이 질문을 다시 시작할지 여부를 검토한 후 이 질문을 닫았습니다.

원래 종료 이유가 해결되지 않았습니다.

이 질문을 개선합니다.

제 질문 중 하나에 대해 이 의견을 낸 후, X 스키마와 함께 하나의 데이터베이스를 사용하는 것이 더 나은지, 아니면 그 반대인지 생각하고 있습니다.

저는 사람들이 등록할 때 (실제로) 데이터베이스를 만드는 웹 애플리케이션을 개발하고 있습니다. (아니요, 소셜 네트워크가 아닙니다. 모든 사용자가 자신의 데이터에 액세스할 수 있어야 하고 다른 사용자의 데이터는 절대로 볼 수 없어야 합니다.)이전 버전의 애플리케이션(MySQL에서 여전히 실행 중)에서 사용한 방법입니다. Plesk API를 통해 모든 등록에 대해 다음 작업을 수행합니다.

1. 제한된 권한으로 데이터베이스 사용자를 만듭니다.
2. 이전에 생성한 사용자와 수퍼유저(유지관리용)만 액세스할 수 있는 데이터베이스 만들기
3. 데이터베이스 채우기

이제 포스트그레SQL에서도 동일한 작업을 수행해야 합니다(프로젝트가 성숙해지고 MySQL이 모든 요구 사항을 충족하지 못함).독립적으로 . 모든스데이/스합마백독수니다행야해로으립적업을이.pg_dump에서는 두 가지 방식으로 모두 완벽하게 작동하며, 스키마 하나 또는 데이터베이스 하나에만 액세스하도록 구성할 수 있는 사용자도 마찬가지입니다.

그래서, 당신이 더 경험이 있다고 가정하면, Postgre.저보다 SQL 사용자, 제 상황에 가장 적합한 솔루션은 무엇이라고 생각하십니까? 그리고 그 이유는 무엇입니까?$x 스키마 대신 $x 데이터베이스를 사용하면 성능 차이가 있습니까?향후 유지관리(신뢰성)에 더 적합한 솔루션은 무엇입니까?모든 데이터베이스/스키마의 구조는 항상 동일합니다!

백업 문제(pg_dump 사용)의 경우 한 데이터베이스와 여러 스키마를 사용하여 모든 스키마를 한 번에 덤프하는 것이 더 나을 수 있습니다. 복구는 개발 시스템에 메인 덤프를 로드한 다음 필요한 스키마만 덤프하고 복원하는 것이 매우 간단합니다. 한 가지 추가 단계가 있습니다.하지만 스키마를 하나씩 버리는 것보다 모든 스키마를 버리는 것이 더 빨라 보입니다.

업데이트 2012

지난 2년 동안 애플리케이션 구조와 디자인이 많이 바뀌었습니다.저는 여전히 "여러 스키마가 있는 one db" 접근 방식을 사용하고 있지만, 여전히 응용프로그램의 각 버전에 대해 하나의 데이터베이스가 있습니다.

Db myapp_01
    \_ my_customer_foo_schema
    \_ my_customer_bar_schema
Db myapp_02
    \_ my_customer_foo_schema
    \_ my_customer_bar_schema

백업을 위해 각 데이터베이스를 정기적으로 덤프한 다음 개발 서버에서 백업을 이동합니다.PITR/WAL 백업도 사용하고 있지만, 앞서 말했듯이 모든 데이터베이스를 한 번에 복원해야 하는 것은 아닙니다.따라서 올해는 아마 기각될 것입니다(제 상황에서는 최선의 접근법이 아닙니다).

애플리케이션 구조가 완전히 바뀌어도 지금부터 1-db-many-schema 접근 방식은 저에게 매우 잘 작동했습니다.거의 잊어버릴 뻔했습니다. 모든 데이터베이스/스키마가 항상 동일한 구조를 가집니다.이제 모든 스키마에는 사용자 데이터 흐름에 동적으로 반응하여 변경되는 고유한 구조가 있습니다.

A 포스트그SQL "schema"는 MySQL "데이터베이스"와 거의 같습니다.Postgre에 많은 데이터베이스 보유SQL 설치에 문제가 생길 수 있습니다. 스키마가 많으면 문제 없이 작동합니다.따라서 해당 데이터베이스 내에서 하나의 데이터베이스와 여러 스키마를 사용해야 합니다.

물론, 저는 1-db-many-schema 접근법을 사용할 것입니다.이를 통해 모든 데이터베이스를 덤프할 수 있지만 다음과 같은 여러 가지 방법으로 하나만 매우 쉽게 복원할 수 있습니다.

1. db(모든 스키마)를 덤프하고 새 db에 덤프를 로드한 후 필요한 스키마만 덤프한 후 기본 db에 복원합니다.
2. 스키마를 하나씩 개별적으로 덤프합니다. (하지만 기계는 이런 식으로 더 많은 고통을 겪을 것이라고 생각합니다. 그리고 저는 약 500개의 스키마를 기대합니다!)

그렇지 않으면 검색을 통해 스키마를 복제하는 자동 프로시저가 없다는 것을 알게 되었지만, 많은 사람들이 다음과 같이 제안합니다.

1. 템플릿 스키마 생성
2. 복제가 필요한 경우 새 이름으로 이름 변경
3. 덤벼!
4. 이름을 다시 변경합니다.
5. 덤프 복원
6. 마법이 끝났습니다.

나는 그것을 위해 파이썬으로 두 줄을 썼습니다. 나는 그들이 누군가를 도울 수 있기를 바랍니다(2초 이내에 작성된 코드, 운영에 사용하지 마십시오).

import os
import sys
import pg

# Take the new schema name from the second cmd arguments (the first is the filename)
newSchema = sys.argv[1]

# Temperary folder for the dumps
dumpFile = '/test/dumps/' + str(newSchema) + '.sql'

# Settings
db_name = 'db_name'
db_user = 'db_user'
db_pass = 'db_pass'
schema_as_template = 'schema_name'

# Connection
pgConnect = pg.connect(dbname= db_name, host='localhost', user= db_user, passwd= db_pass)

# Rename schema with the new name
pgConnect.query("ALTER SCHEMA " + schema_as_template + " RENAME TO " + str(newSchema))

# Dump it
command = 'export PGPASSWORD="' + db_pass + '" && pg_dump -U ' + db_user + ' -n ' + str(newSchema) + ' ' + db_name + ' > ' + dumpFile
os.system(command)

# Rename back with its default name
pgConnect.query("ALTER SCHEMA " + str(newSchema) + " RENAME TO " + schema_as_template)

# Restore the previous dump to create the new schema
restore = 'export PGPASSWORD="' + db_pass + '" && psql -U ' + db_user + ' -d ' + db_name + ' < ' + dumpFile
os.system(restore)

# Want to delete the dump file?
os.remove(dumpFile)

# Close connection
pgConnect.close()

다음과 같은 이유로 여러 스키마 대신 여러 데이터베이스가 허용된 답변에 대해 권장합니다.

1. 마이크로 서비스를 실행하는 경우 "스키마" 간에 결합할 수 없도록 강제해야 하므로 데이터가 얽히지 않고 개발자가 다른 마이크로 서비스의 스키마에 참여하지 않고 다른 팀이 변경을 할 때 더 이상 작동하지 않는 이유를 궁금해할 수 있습니다.
2. 나중에 로드가 쉽게 필요할 경우 별도의 데이터베이스 시스템으로 마이그레이션할 수 있습니다.
3. 고가용성 및/또는 복제를 설정해야 하는 경우, 서로 완전히 독립적으로 별도의 데이터베이스를 두는 것이 좋습니다.전체 데이터베이스와 비교하여 하나의 스키마만 복제할 수 없습니다.

여러 데이터베이스와 여러 스키마를 사용합니다. :)

포스트그레의 스키마SQL은 Oracle의 패키지와 매우 유사합니다.데이터베이스는 전체 데이터 집합을 구별하기 위한 것인 반면 스키마는 데이터 엔티티에 더 가깝습니다.

예를 들어 "사용자 관리", "LongTermStorage" 등의 스키마를 사용하여 전체 애플리케이션에 대해 하나의 데이터베이스를 가질 수 있습니다.그러면 "사용자 관리"에는 "사용자" 표와 사용자 관리에 필요한 모든 저장 프로시저, 트리거, 시퀀스 등이 포함됩니다.

데이터베이스는 전체 프로그램이고 스키마는 구성요소입니다.

인 어 포스트그레SQL 컨텍스트 데이터베이스가 아닌 스키마 간에 모두 유니온할 수 있으므로 하나의 데이터베이스를 여러 스키마와 함께 사용하는 것이 좋습니다.이러한 이유로 데이터베이스는 다른 데이터베이스와 완전히 격리되는 반면 스키마는 동일한 데이터베이스 내의 다른 스키마와 격리되지 않습니다.

앞으로 어떤 이유로 인해 스키마 간에 데이터를 통합해야 하는 경우 여러 스키마에서 이 작업을 수행하는 것이 쉽습니다.여러 데이터베이스를 사용하는 경우 여러 개의 데이터베이스 연결이 필요하고 각 데이터베이스에서 응용프로그램 논리에 따라 "수동으로" 데이터를 수집하고 병합합니다.

후자는 경우에 따라 이점이 있지만, 대부분의 경우 단일 데이터베이스-다중 스키마 접근 방식이 더 유용하다고 생각합니다.

여러 스키마는 여러 데이터베이스보다 더 가벼워야 하지만 이를 확인할 수 있는 참조를 찾을 수 없습니다.

그러나 "고객" 열이 테이블에 추가되도록 웹 응용프로그램을 리팩터링하는 대신 별도의 데이터베이스를 사용하는 것이 좋습니다.이러한 방식으로 특정 고객의 데이터베이스를 더 쉽게 복원할 수 있습니다. 다른 고객에게 방해가 되지 않습니다.

이는 시스템의 가용성과 연결이 어떻게 설계되는지에 따라 달라집니다.이러한 데이터베이스에 저장되는 데이터는 무엇입니까?연결된 데이터인 경우에는 단일 DB 인스턴스에 유지할 수 있지만, 부분적으로 연결되어 있고 한 시스템이 다운된 경우 부분적으로 실행될 수 있는 경우에는 서로 다른 인스턴스에 있어야 합니다.

상세설명 :-

하나의 DB 인스턴스를 사용할 때 여러 데이터베이스를 사용할 때 시스템 충돌 또는 mysql 서버의 다운으로 인해 연결이 중단되면 동일한 인스턴스에 있는 모든 데이터베이스도 다운되므로 모든 응용프로그램이 영향을 받게 됩니다.

각 데이터베이스에 대해 DB 인스턴스를 분리할 때 하나의 데이터베이스 시스템이 중단되어도 다른 응용프로그램은 영향을 받지 않습니다.따라서 다른 애플리케이션은 다운 DB에 의존하는 애플리케이션만 실행할 수 있습니다.

또한 두 경우 모두 슬레이브 데이터베이스에서 로드 밸런싱을 수행할 수 있도록 복제 메커니즘을 사용해야 합니다.

여러 스키마가 있는 단일 데이터베이스로 작업하는 것은 다음과 같은 이유로 postgres 데이터베이스에서 연습하는 좋은 방법입니다.

1. postgres의 데이터베이스 간에 공유되는 데이터가 없습니다.
2. 서버에 대한 지정된 연결은 연결 요청에 지정된 단일 데이터베이스의 데이터에만 액세스할 수 있습니다.

여러 스키마를 사용하는 경우:

1. 많은 사용자가 서로 간섭하지 않고 하나의 데이터베이스를 사용할 수 있습니다.
2. 데이터베이스 개체를 논리적 그룹으로 구성하여 보다 쉽게 관리할 수 있도록 합니다.
3. 타사 응용프로그램은 다른 개체의 이름과 충돌하지 않도록 별도의 스키마로 배치할 수 있습니다.

언급URL : https://stackoverflow.com/questions/1152405/is-it-better-to-use-multiple-databases-with-one-schema-each-or-one-database-wit