SQLite를 사용해야만 하는 이유

원문 : Why you should probably be using SQLite | Epic Web Dev by Kent C. Dodds

Why you should probably be using SQLite

 

하지만 백엔드 개발에는 절대 사용하면 안된다.

 

응용 프로그램 데이터를 저장하는 위치는 전체 응용 프로그램에 막대한 영향을 미칩니다. 여기서 사용하기로 결정한 항목에 따라 전체 스택에 영향을 미칩니다.

많은 사람들에게 기본값이 된 MySQL 및 Postgres와 같은 훌륭한 솔루션이 있습니다. 이것들은 훌륭한 해결책입니다. 그러나 대부분의 웹앱 사용 사례에서는 SQLite를 사용하여 삶을 크게 단순화할 수 있습니다.

SQLite는 전체 데이터베이스가 단일 파일에 있다는 독특한 기능을 가진 SQL 기반 데이터베이스입니다. 이러한 이유로 많은 사람들이 역사적으로 간단한 사용 사례를 위한 간단한 데이터베이스로 간주했습니다.

그러나 최근 몇 년 동안 SQLite는 훨씬 더 고급 사용 사례를 위한 간단한 데이터베이스로 많은 개발과 관심을 받았습니다. 이러한 발전 중 일부와 우리 대부분에게 SQLite가 최고의 절충안인 이유에 대해 이야기해 보겠습니다.

제로 레이턴시(Zero Latency)

SQLite가 디스크의 단일 파일이라는 사실은 "n+0 문제"를 크게 줄이는 1 대기 시간의 주요 이점과 함께 제공됩니다. 즉, 개발자는 데이터베이스에 대한 쿼리 수를 줄이는 것에 대해 걱정하는 데 많은 시간을 할애할 필요가 없습니다(이는 쿼리 효율성이 떨어지고 개발자의 효율성이 떨어질 수 있음).

그리고 대기 시간 자체를 과소평가해서는 안 됩니다. 데이터베이스와 응용 프로그램 사이의 거리를 고려하지 않으면 응용 프로그램 성능에 대한 기준을 쉽게 설정할 수 있습니다. 앱-데이터베이스 대기 시간이 수십 밀리초(때로는 수백 밀리초)로 측정되는 것은 드문 일이 아닙니다. 즉, 무엇을 하든 해당 시간 이내에 페이지에 새로운 데이터를 로드할 수 없습니다.

성능이 모든 앱의 최우선 순위는 아니지만 대부분의 경우 매우 중요합니다. 앱에 비용을 지불하고 대안이 없는 비즈니스 임원이 모든 상호 작용에 대해 얼굴에 깜박이는 스피너를 로드하는 것을 좋아하지 않더라도 확신합니다. 🌀😠

하나 줄어든 서비스

SQLite의 큰 이점 중 하나는 응용 프로그램의 포함 된 부분으로 실행된다는 사실입니다. 그러니까 베이비시터 서비스가 하나 줄어든 거죠. 솔직히 말해서 이것이 내 웹 사이트를 Postgres에서 SQLite로 마이그레이션하기로 결정했을 때 주된 동기였습니다. 나는 이미 내 응용 프로그램의 다른 데이터를 위해 마운트하는 것과 동일한 볼륨에 SQLite를 붙이고 경주에서 벗어났습니다.

이를 통해 복잡성과 비용을 절감할 수 있습니다.

그리고 이것은 인스턴스 수와 복제 고려 사항으로 곱해지지만 우리는 우리 자신보다 앞서 나가고 있습니다 ... 그럼 시작해볼까요?

다중 인스턴스 복제Multi-instance replication

디스크의 파일로서 SQLite를 직접 "배포"할 수 없습니다. 그러나 이것은 이 분야에서 발전이 있었던 곳입니다. 여러 인스턴스가 필요한 자체 애플리케이션의 경우 LiteFS를 사용합니다.

LiteFS는 SQLite 데이터베이스를 투명하게 복제하는 분산 파일 시스템입니다. 로컬 온디스크 SQLite 데이터베이스에 대해 실행되는 것처럼 애플리케이션을 실행할 수 있지만 백그라운드에서 데이터베이스는 클러스터의 모든 노드에 복제됩니다. LiteFS를 사용하면 엣지의 애플리케이션 바로 옆에서 데이터베이스를 실행할 수 있습니다. 어디서든 LiteFS를 실행할 수 있습니다!

또한 LiteFS는 "읽기 복제본 일관성" 문제를 처리할 수 있는 지원 기능을 기본적으로 제공합니다. 따라서 앱을 여러 인스턴스에서 실행해야 하는 경우 이러한 도구 중 하나를 사용해야 합니다.

또 다른 해결책은 Turso로, 내부적으로 SQLite를 사용하고 대기 시간이 0 인 읽기를위한 "임베디드 복제본"이라는 개념도 있습니다. 아주 멋지다!

데이터베이스 크기

사람들이 때때로 제기하는 또 다른 문제는 데이터베이스 크기입니다. 그러나 SQLite는 엑사바이트 크기(100만 테라바이트 또는 10억 기가바이트 🤯)인 데이터베이스를 처리할 수 있습니다. 대부분의 웹 개발자는 그 정도의 데이터로 작업하지 않습니다. 데이터베이스 크기가 SQLite의 문제 중 하나가되기 전에 많은 다른 문제가 발생합니다.

SQLite 데이터베이스 레코드에 많은 양의 데이터를 넣는 것조차도 매우 효율적입니다! 사실, 어떤 경우에는 파일 시스템😆보다 SQLite 데이터베이스에서 데이터를 검색하는 것이 더 빠를 수 있습니다 SQLite는 엔지니어링의 놀라운 위업입니다!

개발 및 테스트

지금 이 글을 읽고 있는 여러분 중 일부는 응용 프로그램 개발을 시작하기 전에 워크플로의 일반적인 부분으로 실행하는 것이 매우 편안하다는 것을 알고 있습니다. 그러나 충돌하는 데이터베이스와 포트로 한 번에 여러 앱을 실행하는 것이 성가신 일이라는 것을 인정해야 합니다. SQLite를 사용하면 전혀 문제가 되지 않습니다. 그것은 단지 파일입니다. 따라서 문제 없이 동일한 앱의 여러 인스턴스를 한 번에 실행할 수 있습니다.docker compose

또한 새로운 Postgres 데이터베이스를 시작하는 것은 상당히 관련되어 있지만 (물론 더 쉽게 만드는 도구가 있음) SQLite에는 그러한 문제가 없습니다. 다시 말하지만, 그것은 단지 파일일 뿐입니다. 프로덕션 마이그레이션/시드를 실행하면 됩니다.

그리고 이러한 용이성은 테스트 측면에도 적용됩니다. 데이터베이스 설정이 복잡하면 ORM 수준에서 데이터베이스를 모의하는 방법을 평가하는 데 시간을 소비하게 되므로 테스트 중에 데이터베이스를 실행하고 연결할 필요가 없으며 그 결과로 발생할 수 있는 격리 문제가 발생하지 않도록 할 수 있습니다.

SQLite에는 문제가 없습니다. 그것은 단지 파일입니다! 각 테스트는 거의 생각하지 않고 자체 데이터베이스를 가질 수 있습니다. 약간의 코드만 있으면 데이터베이스를 만들고 연결하면 전체 데이터베이스에서 테스트를 실행할 수 있습니다. 다른 데이터베이스에서이 작업을 수행 할 수는 있지만 SQLite만큼 쉽고 효율적이지는 않습니다.

약점

SQLite에 단점이 없는 것은 아닙니다. 그리고 그 중 일부를 다루지 않고 SQLite가 빛나는 부분에 대해서만 이야기하는 것은 불공평합니다.

• SQLite는 특정 실시간 사용 사례에 제한이 될 수 있는 구독을 지원하지 않습니다. 그러나 어쨌든 실시간 사용 사례에 데이터베이스 구독을 사용하지 말라고 권장하는 많은 이유가 있습니다. 실시간 사용 사례를 확장하는 것은 매우 어려운 일이며, 개인적으로 Partykit이 내 앱에서 그 역할을 하도록 하는 것이 정말 즐거웠습니다.
• SQLite가 디스크에 파일이기 때문에 외부 클라이언트에서 연결하는 것이 사실상 불가능합니다. 그러나 적어도 Fly.io 사용하면 프로덕션 서버에서 prisma studio를 실행하고 로컬 액세스를 위해 프록시하는 것이 쉽습니다. 다른 앱에서 연결해야하는 경우 운이 좋지 않으며 필요한 모든 데이터에 대해 호스