티스토리 뷰
반응형
Web API를 만들때 어떤 Database엔진을 사용해야할지 찾아보는 중에 아래와 같은 내용을 발견했습니다.
SQLite의 적절한 사용(자세한 내용은 여기를 참고합니다) 페이지를 보면 다음과 같은 내용이 있습니다.
SQLite는 다른 문제를 해결하기 위해 MySQL, Oracle, PostgreSQL 또는 SQL Server와 같은 client/server SQL 데이터베이스 엔진과 직접 비교할 수 없습니다.
Client/Server SQL 데이터베이스 엔진은 엔터프라이즈 데이터의 공유 저장소를 구현하기 위해 노력합니다. 확장 성, 동시성, 중앙 집중화 및 제어를 강조합니다. 반면, SQLite는 개별 애플리케이션 및 장치에 로컬 데이터 저장소를 제공하기 위해 사용되며, SQLite는 경제성, 효율성, 신뢰성, 독립성 및 단순성을 강조합니다.
SQLite는 Client/Server 데이터베이스와 경쟁하지 않습니다. SQLite는 fopen ()과 경쟁합니다.
Checklist For Choosing The Right Database Engin
- Is the data separated from the application by a network? → choose client/server
- 관계형 데이터베이스 엔진은 대역폭을 줄이는 데이터 필터 역할을합니다. 따라서 high-bandwidth engine-to-disk 링크가 네트워크를 통과하지 않고 lower-bandwidth application-to-engine 링크 만 통과하도록 데이터베이스 엔진과 데이터를 동일한 물리적 장치에 유지하는 것이 가장 좋습니다.
그러나 SQLite는 애플리케이션에 내장되어 있습니다. 따라서 데이터가 애플리케이션과 별도의 장치에있는 경우 더 높은 대역폭의 engin-to-disk 링크가 네트워크를 통해 있어야합니다. 이 방법은 사용 가능하지만 차선책입니다. 따라서 데이터가 애플리케이션과 별도의 장치에있는 경우 일반적으로 client/server 데이터베이스 엔진을 선택하는 것이 좋습니다.
참고 : 이 규칙에서 "응용 프로그램"은 SQL 문을 실행하는 코드를 의미합니다. "응용 프로그램"이 응용 프로그램 서버이고 내용이 응용 프로그램 서버와 동일한 물리적 시스템에 있는 경우 최종 사용자가 다른 네트워크에 있더라도 SQLite는 여전히 적절할 수 있습니다.
- 관계형 데이터베이스 엔진은 대역폭을 줄이는 데이터 필터 역할을합니다. 따라서 high-bandwidth engine-to-disk 링크가 네트워크를 통과하지 않고 lower-bandwidth application-to-engine 링크 만 통과하도록 데이터베이스 엔진과 데이터를 동일한 물리적 장치에 유지하는 것이 가장 좋습니다.
- Many concurrent writers? → choose client/server
- 많은 스레드 및 프로세스가 동일한 순간에 데이터베이스를 작성해야하는 경우 (그리고 대기열에 추가 할 수없는 경우) 해당 기능을 지원하는 데이터베이스 엔진을 선택하는 것이 가장 좋습니다. 이는 client/server 데이터베이스 엔진을 의미합니다.
SQLite는 데이터베이스 파일 당 한 번에 하나의 작성자 만 지원합니다. 그러나 대부분의 경우 쓰기 트랜잭션은 밀리 초 만 걸리므로 여러 작성자가 번갈아 가며 사용할 수 있습니다. SQLite는 많은 사람들이 의심하는 쓰기 동시성을 더 많이 처리합니다. 그럼에도 불구하고 client/server 데이터베이스 시스템은 접근을 조정하기 위해 오래 실행되는 서버 프로세스가 있기 때문에 일반적으로 SQLite보다 훨씬 더 많은 쓰기 동시성을 처리 할 수 있습니다.
- 많은 스레드 및 프로세스가 동일한 순간에 데이터베이스를 작성해야하는 경우 (그리고 대기열에 추가 할 수없는 경우) 해당 기능을 지원하는 데이터베이스 엔진을 선택하는 것이 가장 좋습니다. 이는 client/server 데이터베이스 엔진을 의미합니다.
- Big data? → choose client/server
- 데이터가 uncomfortable 하거나 단일 디스크 파일에 들어갈 수 없는 크기로 커지면 SQLite 이외의 솔루션을 선택해야합니다. SQLite는 최대 281 테라 바이트 크기의 데이터베이스를 지원하며, 282 테라 바이트 파일을 지원하는 디스크 드라이브와 파일 시스템을 찾을 수 있다고 가정합니다. 그럼에도 불구하고 콘텐츠의 크기가 테라 바이트 범위에 속할 것 같으면 중앙 집중식 client/server 데이터베이스를 고려하는 것이 좋습니다.
- Otherwise → choose SQLite!
- 쓰기 동시성이 낮고 테라 바이트 미만의 콘텐츠를 사용하는 장치 로컬 저장소의 경우 SQLite가 거의 항상 더 나은 솔루션입니다. SQLite는 빠르고 안정적이며 구성이나 유지 관리가 필요하지 않습니다. 그것은 일을 간단하게 유지합니다. SQLite는 "그냥 작동"합니다.
결과적으로 SQLite와 SQL Express는 사용 용도가 다르기 때문에 비교하는 것 자체가 비 현실적이라는 것을 알 수 있습니다. Web API를 서비스로 제공하는 경우에는 SQL Express나 Client/Server 엔진을 사용하도록 합니다.
Editions and supported features of SQL Server 2019
반응형
'Entity Framework Core' 카테고리의 다른 글
Entity Framework Core 시작(4/5) (0) | 2020.12.30 |
---|---|
Entity Framework Core 시작(3/5) (0) | 2020.12.28 |
Entity Framework Core 시작(2/5) (2) | 2020.12.19 |
Entity Framework Core 시작(1/5) (0) | 2020.12.16 |
Entity Framework Core 링크 정리 (0) | 2020.12.14 |
댓글
반응형
공지사항
최근에 올라온 글
최근에 달린 댓글
- Total
- Today
- Yesterday
링크
TAG
- #MVVM
- #prism
- MVVM
- #uwp
- .net
- Always Encrypted
- Cross-platform
- PRISM
- XAML
- #Windows Template Studio
- UWP
- Bot Framework
- C#
- ef core
- kiosk
- IOT
- .net 5.0
- Visual Studio 2022
- LINQ
- dotNETconf
- Behavior
- WPF
- windows 11
- visual studio 2019
- uno platform
- uno-platform
- Microsoft
- Windows 10
- Build 2016
- ComboBox
일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | 4 | 5 | 6 | 7 |
8 | 9 | 10 | 11 | 12 | 13 | 14 |
15 | 16 | 17 | 18 | 19 | 20 | 21 |
22 | 23 | 24 | 25 | 26 | 27 | 28 |
29 | 30 | 31 |
글 보관함