2009-07-08 2 views
7

Cloud Computing의 미래를 예측하는 컴퓨터 프로그래밍 전도자는 매우 밝습니다. 관계형 데이터베이스가 출현 할 가능성이 있습니까?클라우드 컴퓨팅이 점점 대중화되면서 관계형 DB는 죽음을 맞이할 것입니까?

클라우드 컴퓨팅에 더 적합한 DB는 무엇입니까?

+0

@The close votes : 이것은 나에게 진정한 질문처럼 들립니다. 분명히 오해가 있습니다. 그러나 누군가 오해로 당신을 도우는 것이 큰 부분입니다. 투표를 종료하는 대신 답변을 게시하십시오. –

답변

1

아니요, RDBMS는 기능으로 인해 항상 위치 정보를 갖습니다. 자체적으로뿐만 아니라 OODBMS와 같은 다른 시스템에 대한 백본으로도 사용됩니다.

0

관계형 데이터베이스는 지역화 된 저장소 (예 : 응용 프로그램 별 저장소)와 서버 저장소 모두에서 여전히 관련이 있습니다.

4

관계형 데이터베이스 모델은 관계형 대수학에 확고한 수학적 기초를 가지고 있습니다. 이것은 이론적으로 적절하게 추론하고, 확장하고, 사용하는 것을 쉽게 만듭니다. 이러한 새로운 API 및 사용으로 인해 데이터베이스 액세스 패턴이 크게 변경 되더라도 관계형 데이터베이스가 이러한 이유로 기본 구현을 형성 할 가능성이 큽니다.

+1

하지만 그들은 그렇게하지 않습니다. RDBMS는 아키텍처 때문에 * 고유 한 확장 성 문제가 있습니다. – Bob77

+0

하지만 그들은/무엇 /? 확장성에 대해서는 언급하지 않았습니다. – Kylotan

0

필자가 본 클라우드 컴퓨팅 플랫폼에는 관계형 데이터베이스가 있습니다. 따라서 클라우드 컴퓨팅이 실제로 사용되는 데이터베이스 유형을 참조하여 그림을 변경하는 것을 보지 못합니다.

그러나 결국 우리 모두 익숙한 데이터베이스가 결국 대체 될 것입니다. 문제는 그것이 상위 버전의 RDB 또는 다른 버전인지 여부입니다. 그 질문의 또 다른 측면은 RDB의 현재 작물이 사라질 때까지 얼마나 걸릴 것인가? (나는 답을 하나도 가지고 있지 않다.)

0

구름은 요즘에도 계속 움직이며, 나는 그렇게 빨리 생각하지 않는다.

0

나는 그 클라우드 컴퓨팅의 RDBMS를 죽일 것이라고 생각하지 않습니다 : 그것은 일반적으로 클라우드 스토리지 인프라에 사용되는 RDBMS 시스템과 사람 사이의 좋은 비교를 제공합니다. 뭔가 다른 것이 있습니다.

우선, 주어진 응용 프로그램이 사용하는 저장소 엔진의 유형은 실행중인 위치 (클라우드 또는 특정 서버)에 의존하지 않으며 데이터 저장 방법에 따라 다릅니다.

둘째, 까지 나는 그들이 비 관계형 DBMS와 같은 (예 : CouchDB를 같은 문서 중심의 DBMS로)뿐만 아니라 확장되지 않기 때문에 사람들이 RDBMS에 그들의 탈출구를 생각하는 유일한 이유는을 말할 수있는 클라우드에보다 쉽게 ​​배포 할 수 있습니다. 그러나 RDBMS가 앞으로 더 cloud-friendly 될 수없는 이유는 없습니다. 초기 예를 들어, Drizzle보고 :

드리 즐 프로젝트는 클라우드 및 인터넷 애플리케이션에 최적화 된 데이터베이스를 구축하고있다. 현대 멀티 - 코어/코어 아키텍처에서 대규모 동시성을 위해 설계되었습니다.

그렇다고해서 클라우드 컴퓨팅이 RDBMS를 죽이지 않을 것이라고 생각하지 않습니다. 그들은 단지 적응하도록 강요 될 것입니다. 그러나 기존의 대안이나 새로운 것이 RDBMS만큼 견고하고 사용하기 쉬워 진다면 그것들을 죽일 수 있습니다. 필자가 말하고자하는 것은 완전하게 견고한 소프트웨어 (베타는 허용되지 않음)를 가지고 있으며 프로그래머가 쉽게 전환 할 수있는 솔루션입니다. 그들은 RDBMS를 이해하는 사람들에게 학위를줍니다.ActiveRecord, SQLAlchemy와 같은 ORM과 .NET 지원자가 가정 한 모든 지원 소프트웨어로 인해 RDBMS를 사용하면 첫 번째 정규 형식이 무엇인지 모르는 사람들에게도 쉽게 알 수 있습니다. 그래서 사람들이 (예를 들어) DODBMS를 쉽게 사용할 수있는 방법이있을 때까지 RDBMS가 계속해서 지배적 일 것이라고 생각합니다. 나는 그것이 반드시 나쁜 것임을 말하는 것도 아닙니다. 다시 말하면, 사용하는 DBMS는 데이터에 의존해야하며 사람들이 말하는 것은 차갑지 않고 좋습니다.

0

기사에서 인용 :. 무결성이 가장 낮은 레벨에서 데이터를 확인 관계형 데이터베이스의

"고유 제약 조건 데이터 무결성 제약 조건을 위반하는 물리적 데이터베이스에 입력 할 수 없습니다 이러한 제약은하지 않습니다. 키/값 데이터베이스에 존재하므로 데이터 무결성 보장 책임은 전적으로 애플리케이션에 달려 있지만 애플리케이션 코드에는 종종 버그가 있습니다. 적절히 설계된 관계형 데이터베이스의 버그는 일반적으로 데이터 무결성 문제로 이어지지 않으며 키/그러나 가치 데이터베이스를 사용하면 데이터 무결성 문제가 발생하기 쉽습니다. "

내게있어서 RDBMS는 운명에 처해 있으며 최신 기술은 사용자가 데이터의 정확성에 관심이없는 곳과 똑같은 크고 빛나는 미래에 직면 해 있다는 것입니다.

IMHO.

0

더 많은 구조화 된 데이터를 쿼리해야하는 애플리케이션의 경우 관계형 데이터베이스에는 아무런 문제가 없습니다 (예 :이 날짜에 제품 XYZ를 구입 한 사용자 수는 100 달러가 넘지 만 150 달러 미만). 이러한 시스템의 확장과 확장에 따라 해결해야 할 잠재적 인 중요한 아키텍처 문제가 있습니다. 일단 당신의 DB가 시작된 하나의 머신보다 길어 지거나 트래픽/요청이 사용 가능한 리소스에 과부하를 일으키면 (여전히 관계형 데이터베이스를 유지하고 싶다면) 레이어를 추가해야합니다. 감사하게도 캐싱, 매핑 및 축소 및 기타 기능을 포함하여 지난 몇 년 동안 사용할 수있는 더 많은 옵션이 있지만 이러한 추가 레이어는 복잡성과 유지 관리 오버 헤드를 추가합니다. 한 가지 의미에서 필자는 오늘날 관계형 DB의 확장 성 및 배포 문제를 해결할 가능성이있는 엔지니어링 된 "밴드 - 에이즈"를 고려해 보겠다. 누가 알아. 또한 오늘날이 인기있는 레이어를 볼 수 있습니다.이 모든 것은 기본적으로 이미 객체 DB에서 사용할 수있는 기능을 에뮬레이트하고 개발자가 객체 언어를 사용하여 작업을보다 빠르고 효율적으로 수행 할 수있는 "가상 객체 DB" 성장과 성과의 장애물을 넘었습니다. 그래서 내 생각에 내 생각에, 관계형 DB는 아마도 데이터베이스를 쿼리하고 상대적으로 쉽게 (상대적으로) 데이터베이스를 사용하여 하나의 클라이언트/응용 프로그램으로 결과를 얻었 기 때문에 defacto DB가되었습니다. 볼륨이 커지면서 애플리케이션 복잡성이 급격히 증가함에 따라 더 많은 개발자가 총알을 물리 치기를 결정하고 객체 DB (현재는 관계형 데이터베이스로 표준화되어 있습니다)에 대한 구문을 배우고 모든 미들웨어를 건너 뛰기 만하면됩니다. OODBMS에서 기본적으로 얻을 수있는 기능 만 에뮬레이션하는 레이어 등이 있습니다. 필자는 OODB를 여러 대의 서버에 설치하고 필요에 따라 자동으로 데이터를 배포하며 개발자에게 모든 규모의 데이터베이스 연합에 대한 단일 뷰를 제공하는 것을 보았습니다 ... 시스템 배포가 늘어남에 따라 최상의 솔루션이라고 생각됩니다. 네이티브 분산 아키텍처를 가질 수있는 DB를 얻을 수 있습니다. 어쨌든, 그냥 생각.