Windows / Linux가 관계형 데이터베이스 (RDBMS)를 사용하지 않는 이유는 무엇입니까?

Windows / Linux가 관계형 데이터베이스 ( RDBMS )를 사용하지 않는 이유는 무엇 입니까?

파일 시스템을 사용하여 모든 데이터를 저장하지만 웹 사이트 / 웹 앱에서 사용하는 데이터베이스를 사용하는 것이 더 효율적이라고 생각하지 않습니까?

스토리지를 위해 데이터베이스를 통한 파일 시스템 사용에 대해 자세히 설명하십시오.

이것은 텍스트 파일의 데이터를 구문 분석하는 것보다 데이터베이스를 사용해야하는 경우와 중복되지 않습니다 . 나는 운영 체제 컨텍스트에 대해서만 이야기하고 있으며 그 질문은 일반화되었습니다.

오늘날 대부분의 데이터베이스 관리 시스템 (예 : PostGreSQL , MongoDB 등)은 내부적으로 데이터를 OS 파일 내부에 보관합니다 (과거에는 일부 DBMS는 원시 디스크 파티션을 직접 사용했습니다).

^{아직도 회전하는 하드 디스크를 사용하는 최근 컴퓨터 에서 디스크는 CPU 또는 RAM에 비해 너무 느려서 소프트웨어 계층을 추가하는 것은 관련이 없습니다. SSD 기술이 약간 변경 될 수 있으며 일부 파일 시스템은 SSD에 최적화되어 있습니다.}

파일 은 역사적 및 사회적 이유로 (일반적으로 C 컴파일러 및 대부분의 도구-편집자, 링커-파일을 원하므로 닭고기 및 계란 문제가 있음) 대부분의 OS에서 일반적으로 존재하며 매우 좋은 파일 이 많기 때문에 시스템 구현.

BTW, 일부 필수 시스템 기능은 데이터베이스를 사용할 수 있습니다. 예를 들어 Linux 에서 데이터베이스의 정보를 사용하도록 PAM 을 구성 할 수 있지만 실제로는 거의 수행되지 않습니다. 또한 일부 메일 서버는 일부 또는 대부분의 데이터를 데이터베이스 (예 : Exim )에 저장할 수 있습니다 .

파일은 데이터베이스보다 추상화가 약간 낮으므로 구현하기 쉽고 ( 리눅스 커널 의 파일 시스템 및 VFS 계층으로) 사용하기가 더 빠릅니다. 특히 파일 작업은 데이터베이스 작업보다 훨씬 제한적입니다. 실제로 파일이나 파일 시스템을 매우 제한된 데이터베이스로 볼 수 있습니다!

당신이 디자인 할 수있는 운영 체제를 모든 파일없이 , 그러나 다른 직교과 지속성 기계 (예를 들어, 모든 필요 과정이 지속 될, 당신은 많은 상관 없어 명시 적으로 OS가 지속적으로 자원을 관리하기 때문에, 스토리지에 대한). 이는 여러 학술 운영 체제 ⁽¹⁾ ( 1980 년대 의 Smalltalk 및 Lisp 시스템 , IBM System i , 일명 AS / 400 및 osdev 와 연결된 일부 장난감 프로젝트)에서 수행 되었습니다.), 그러나 이런 방식으로 OS를 디자인 할 때 기존의 많은 도구를 활용할 수 없습니다 (예 : 컴파일러와 사용자 인터페이스를 처음부터 새로 만들어야하므로 많은 작업이 필요합니다).

파일 시스템은 응용 프로그램 서버 (예 : 사용자 영역에서 실행되는 Hurd 변환기) 이므로 마이크로 커널 운영 체제는 커널 계층에서 제공하는 파일이 필요하지 않을 수 있습니다 . 오늘날 MirageOS 의 유니 커널 접근 방식 도 살펴보십시오

리눅스 (그리고 아마도 VMS & Unix 에서 영감을 얻은 Windows )는 파일이 필요합니다. 최소한 init 프로그램 (커널에 의해 시작된 첫 번째 프로그램)은 파일에 저장된 실행 파일이어야합니다 (종종 요즘 시스템화/sbin/init 될 수 있음 ). (거의) 다른 모든 프로그램은 execve (2 ) syscall은 파일에 저장해야합니다. 그러나 FUSE를 사용하면 파일과 유사한 의미를 파일이 아닌 것들에 제공 할 수 있습니다.

또한 Linux (그리고 아마도 모르고 사용하지 않은 Windows)에서도 sqlite 는 파일에서 일부 SQL 데이터베이스를 관리하고이를위한 API를 제공하는 라이브러리입니다. 안드로이드 (리눅스 변형)가 많은 sqlite 파일을 사용하는 것으로 널리 알려져 있지만 POSIX와 유사한 파일 시스템을 가지고 있습니다.

응용 프로그램 검사 점에 대해서도 읽어보십시오 (현재 많은 OS에서 프로세스 상태를 파일로 작성하도록 구현 됨). 이 접근법은 응용 프로그램 파일을 수동으로 작성할 필요가 없지만 체크 포인트 장치를 사용하여 전체 프로세스 상태를 유지하기 만하면됩니다.

실제로 흥미로운 질문은 현재 운영 체제가 여전히 파일을 사용하는 이유이며 그 대답은 기존의 경제적, 문화적 이유 (슬프게도 오늘날 대부분의 프로그래밍 언어 및 라이브러리는 여전히 파일을 원합니다)입니다.

참고 1 : 지속적인 학술 운영 체제 에는 Lisaac & Grasshopper가 포함 되지만 이러한 학술 프로젝트는 비활성화 된 것으로 보입니다. http://tunes.org/ 도 살펴보십시오 . 비활성 상태이지만 이러한 주제에 대해 많은 토론을 받았습니다.

참고 2 : 파일 개념은 시간 이 지남에 따라 크게 바뀌 었습니다 ( 최초의 프로그래밍 경험에 대한 이 답변을보십시오) : 1980 년대 IBM PC (디렉토리 없음 )의 첫 번째 MSDOS , 1978 Vaxen의 VMS- (모두 고정 레코드가 있음) 1970 년대 메인 프레임 ( OS / VS2 MVS를 사용하는 IBM / 370 )은 파일 및 파일 시스템의 개념이 매우 다릅니다 (특히 해당 시간에 하드 디스크 액세스 시간의 비율 때문에 코어 메모리 액세스 시간은 수천에 달했습니다. 따라서 현재 디스크가 절대적으로 사용 되더라도 디스크는 오늘보다 비교적 빠르게 실행 됩니다.이전 세기보다 더 빠른 오늘날의 CPU / 디스크 속도 비율은 약 백만입니다. 그러나 이제 SSD가 있습니다). 또한 파일이 메모리가 지속적 일 때 유용하지 않거나 유용하지 않습니다 ( CAB500 마그네틱 드럼, 1960 년대 또는 MRAM을 사용하는 향후 컴퓨터 )

이것은 의견에 근거한 것이지만, 그것은 또 다른 역사적 유물이라고 생각합니다. 초기 OS는 당시 사용 가능한 하드웨어의 특성과 상당히 밀접한 관련이있는 성능을 위해 간단한 파일 시스템 설계를 사용했으며 그 이후에도 마찬가지였습니다. 더 많은 트랜잭션 쿼리 / 삽입 API가 설정되면 이전 파일 읽기 / 쓰기 API를 변경하기가 어렵습니다.

모든 현재 파일 시스템은 이러한 이전 API와 역 호환되어야합니다.

Microsoft는 Longhorn 개발 에서 파일 시스템을 RDBMS 기반 시스템으로 대체하는 것에 대해 생각했습니다 . 이는 너무 많은 변화를 가져 왔지만 RDBMS를 사용하여 메타 데이터 복사본을 저장하는 Windows Search 및 SQL Server의 Filestream 시스템 (예 : 파일 데이터의 데이터베이스 테이블은 Windows 탐색기 가 데이터에 액세스하고 동일한 데이터의 SQL 쿼리를 허용하는 일반 디렉토리로 OS에 노출됩니다 .

다른 OS에는 RDBMS 파일 시스템이 있습니다. AS / 400 은 이것들을 가지고 있었지만 나는 그것에 대해 충분히 배우지 못했습니다. 나는 그것이 당시에 얼마나 이상하게 나타 났는지 기억합니다). 다른 메인 프레임 시스템에도 같은 방식이 있다고 생각합니다.

진정한 이유는 필요가 없기 때문입니다. 데이터베이스를 병합하지 않고 데이터베이스 위에 계층화하면 최소한의 복잡성을 대폭 줄인 병합 된 솔루션뿐만 아니라 대부분의 상황을 처리합니다. 다른 상황에서 언급 한 일부 상황에서는 권한 구조와 같은 데이터베이스 상단에 파일의 일부를 계층화했습니다. 이 경우 이러한 권한을 관리하는 데이터베이스는 상용 RDBMS보다 훨씬 간단합니다.

그것들을 병합하는 데에는 이점이 있지만, 지금까지는 움직임이 느리게 성장할 정도로 충분히 적었습니다. 사람들이 "2010 년 이후에받은 모든 송장의 세 번째 열을주고 함께 합친다"라고 말하거나 "이 파일을 Excel에서 제거 할 때까지 삭제하지 마십시오" 스프레드 시트도 있습니다. "

파일 시스템은 관계형 데이터베이스에 비해 몇 가지 장점이 있습니다.

• 그들은 훨씬 간단합니다. 이것은 컴퓨터를 부트 스트랩 할 때 큰 문제입니다. 안드로이드 에서도스토리지 용 RDBMS가있는 초기 부트 로딩 프로세스를 관리하기위한 오래된 이미지가 있습니다.
  • 한계를 정의하는 것이 더 쉽습니다. 무제한 머신에서 RDBM은 상당히 많은 기능을 제공합니다. 그러나 파일 시스템 세계에서는 회전 디스크 위에 직접 계층화 할 때 빠른 시도로 인해 많은 제한이 있습니다. RDBMS 조회가 파일 시스템에 대해 동일한 보증을 제공하는 것보다 이러한 한계를 초과하지 않는다는 것을 증명하기가 어렵습니다.
• 계층 구조를 더 잘 처리합니다. 많은 경우 사람들이 파일을 계층 적 형태로 저장하는 것이 여전히 당연합니다. RDBMS에서는 특별한 경우입니다. 파일 시스템은 이러한 특수한 경우에 최적화되지만 RDBMS는 그렇지 않습니다.
• 신뢰할 수 있음. 하나의 거대한 시스템이 완벽하게 작동한다는 것을 증명하는 것보다 두 개의 레이어가 독립적으로 작동한다는 것을 증명하는 것이 훨씬 쉽습니다. ACID 또는 외래 키 제약 조건을 처리하는 계층 아래의 계층에서는 RAID 어레이, 정전시 오류 방지 저널 및 기타 고급 기능을 쉽게 구현할 수 있습니다.

다른 답변은 운영 체제가 관계형 데이터베이스를 내부 / 배타적으로 의존하지 않는 이유에 대한 광범위한 이유를 제공한다고 생각합니다.

분명히 관계형 데이터베이스를 파일 시스템으로 마운트 할 수있는 기술이 있습니다. Oracle DBFS (데이터베이스 파일 시스템) 가 그 예입니다. 이 문서의 스 니펫은 그 배후의 근거를 잘 설명합니다.

데이터베이스 파일 시스템 (DBFS)은 데이터베이스의 기능을 활용하여 파일을 저장하고 관계형 데이터를 효율적으로 관리 할 때 데이터베이스의 장점을 활용하여 데이터베이스에 저장된 파일에 대한 표준 파일 시스템 인터페이스를 구현합니다. 이 인터페이스를 사용하면 데이터베이스에 파일을 저장하는 것이 더 이상 사용하도록 특별히 작성된 프로그램 BLOB및 CLOB프로그래밍 방식의 인터페이스 로 제한되지 않습니다 . 이제 파일의 역할을하는 운영 체제 (OS) 프로그램을 사용하여 데이터베이스의 파일에 투명하게 액세스 할 수 있습니다.

솔루션은 데이터베이스 테이블에 저장된 LOB 데이터에 대한 인터페이스 세트 (명령 행 클라이언트, 코드 라이브러리)를 제공합니다. 이것은 Windows 및 Linux 운영 체제에서 사용할 수 있습니다 (알 수있는 한 통합 수준은 운영 체제마다 다릅니다)

출처 : docs.oracle.com

문서에 따르면 파일 시스템은 Linux에서 투명하게 사용할 수 있어야합니다.

Linux에는 dbfs_client또한 사용자 공간의 파일 시스템 ( FUSE) 커널 모듈을 사용하여 데이터베이스에 저장된 파일에 대한 투명한 액세스를 제공하고 Linux 커널을 변경할 필요가없는 파일 시스템 마운트 지점을 구현 하는 마운트 인터페이스가 있습니다. FUSE커널 모듈 에서 표준 파일 시스템 호출을 수신 하여 DBFS Content Store 의 PL / SQL 프로 시저에 대한 OCI 호출 로 변환합니다 .

따라서 귀하의 질문에 대한 답변은 일반적으로 운영 체제가 관계형 데이터베이스를 파일 시스템으로 사용할 이유가 없다는 것입니다 (OS의 핵심 구성 요소의 경우 실제로 문제가 될 수 있습니다). 동시에 어떤 문제가 그것을 요구할 때 그것을 할 수 있습니다.

모든 OS의 주요 기능은 응용 프로그램, 하드웨어 및 사용자 간의 상호 작용을 용이하게하는 것입니다.

그렇다면 Windows / Linux OS가 관계형 데이터베이스 (RDBMS)를 사용하지 않는 이유는 무엇입니까? 이것은 성경적 비율의 문제이지만 짧은 대답은 다음과 같습니다. rdbms와 같은 복잡한 구조를 파일 시스템으로 사용하면 얻을 수있는 실질적인 이점은 없습니다.

"관계형"은 "관계형 데이터베이스"에서 작동하는 단어이며 파일 시스템에 저장된 대부분의 데이터는 다른 데이터와 관련이 없습니다. 파일 시스템은 일반적으로 관계형 데이터베이스가 아닌 제한된 데이터베이스로 구현됩니다.