LMDB--NosQL이 MongoDB보다 빠르다고요?

알겠습니다. 대량의 데이터를 처리해야 하는 프로젝트를 시작하겠습니다. 수백만 개의 병렬 연결을 말합니다.그래서 나는 두 가지를 검증하고 싶다. 무엇이 가장 좋은 웹 서버 프레임워크입니까?이런 데이터를 처리하는데 가장 효과적인 데이터베이스는 무엇입니까?본문은 후자를 소개했다.
데이터의 특성상 우리가 처리할 뚜렷한 선택은 NosQL 데이터베이스입니다.지금은 당신의 상황을 모르겠지만, NosQL 데이터 저장소에 대한 선택은 왕왕 MongoDB (문서 하나만 저장할 때) 또는 CouchDB/Cloudant (상대적으로 저렴한MapReduce나 동적 데이터 변환을 하고 싶을 때) 이다.나는 Memcached나 Redis와 같은 키 값 저장을 피하는 경향이 있지만, 이것은 이데올로기 충돌이 아니라 인터페이스 요구 때문이다.
그 밖에 PostgreSQL는 경계를 모호하게 하고 스위스 군대와 유사한 다중 도구로 자신을 표현하는 것을 좋아한다는 것을 잘 알고 있지만 NosQL 데이터베이스로 사용하는 문법이 매우 추악하고 번거롭다는 것을 발견했기 때문에 우리는 심지어 그곳에 가지 않을 생각이다.
그러나 최근에 저는 LMDB (the Lightning Memory-Mapped Database)에 관한 글을 읽었습니다. 그래서 저는 LMDB를 바탕으로 특정한 응용 프로그램에 대한 DB를 구축할 수 있고 현실 세계에서 MongoDB를 뛰어넘어 너무 복잡하지 않게 할 수 있는지 알고 싶습니다.

NosQL 데이터베이스

본고를 읽는 대다수 사람들은 내가 NoSQL 데이터베이스가 무엇인지, 그리고 NoSQL 데이터베이스와 관계 데이터베이스(또는 SQL 데이터베이스)의 차이를 설명할 필요가 없다고 가정한다.
그러나 이 주제에 익숙하지 않은 사람들에게 NoSQL 데이터베이스는 구조 간의 관계 데이터가 없는 간단한 대상을 검색하고 조작하는 데 사용되는 데이터 저장 유형이다.즉, 하나의 데이터 구조의 대상(또는 문서)은 다른 데이터 구조의 대상과 의존 관계가 없다는 것이다.한편, 관계 데이터베이스는 말 그대로 저장된 데이터 구조 사이에 하나 또는 여러 개의 관계를 저장하는 데이터이다.이를 위해 관계 데이터베이스는 데이터를 테이블에 저장하는 경향이 있는데 그 중에서 모든 대상은 한 줄로 저장된다.NosQL 데이터베이스는 데이터를 문서 또는 키 값 쌍으로 저장하는 경향이 있습니다.
현재 이러한 차이는 그다지 중요하지 않다. 대부분의 개발자들은 ORM(대상 인용 모델)을 사용하여 추상적인 베이스 데이터베이스 인터페이스를 사용하는 것을 좋아하기 때문에 구조화된 조회 언어를 이해해야 하는 사람이 점점 적어지고, NosQL 데이터베이스는 이런 언어로 명명된 것이다.사실 NosQL 데이터베이스의 대다수 현대 ORM은 망치로 볼트를 조이는 경향이 있는 사람들에게 관계 검색을 제공할 수 있다.말할 것도 없이, 일을 위해 적합한 도구를 선택하는 것은 모든 업무의 중요한 구성 부분이다.
독자군 중의 똑똑한 사람도 도형 데이터베이스가 완전히 다른 품종이라는 것을 의식할 수 있다.그러나 이것들은 모두 절선의 라인이다. 이것보다 간단한 해석은 이미 그렇다.그래서 나는 지금부터 SQL 데이터베이스와 NoSQL 데이터베이스 사이의 차이를 설명하기 시작한다.

교전 규칙

분명히 LMDB는 키 값 저장소이고 MongodB는 문서 저장소이기 때문에 중요한 주의사항이 있습니다.
따라서 사과와 오렌지의 비교를 줄이기 위해 몇 가지 규칙을 정의합시다.

이 두 가지 해결 방안은 모두 웹 서버 뒤에 위치하고 이 서버는 간단한 규범

에 부합되는 JSON 대상을 받아들이고 서비스할 것이다.

두 가지 해결 방안은 같은 웹 서버 프레임워크를 사용하고 이 프레임워크는 필요한 모든 데이터 형식 변환을 책임진다

두 솔루션 모두 동일한 시스템 리소스를 사용할 수 있음

JSON 객체

웹 서버에 게시될 JSON 객체의 예는 다음과 같습니다.

{
    "position": {
        "lat": 40.5340,
        "lon": -74.3778
    },
    "radius": 39.66365,
    "cidr": "192.0.2.0/24",
    "country_code": "US",
    "nearest_city": "Edison",
    "timestamp": 1623773290,
    "software_source_version": "0.0.1"
}

검색하려는 JSON 객체의 예제 형식은 다음과 같습니다.

{
    "cidr": {
        "bitmask": 24,
        "net_addr": {
            "ipv4": "196.72.0.0",
            "ipv6": "ffff:ffff:ffff:ffff:ffff:ffff:ffff:ffff",
            "version": 4
        }
    },
    "country_code": "US",
    "db_version": {
        "major": 0,
        "minor": 1,
        "patch": 0
    },
    "nearest_city": "Edison",
    "position": {
        "lat": 40.5185,
        "lon": -74.3515
    },
    "radius": 39.66365,
    "software_source_version": {
        "major": 0,
        "minor": 0,
        "patch": 1
    },
    "timestamp": 1623773290
}

그러나 MongoDB는BSON (Binary JSON) 형식으로 데이터를 저장하고 LMDB는 한 바이트 블록만 저장하기 때문에 우리는 어떤 데이터 구조를 사용할지 결정해야 한다.우리는 적당한 BSON 라이브러리를 사용하여 차이를 최소화할 수 있지만, 이것은 방정식에 추가 변수를 도입할 것이다. 왜냐하면 사용하는 BSON 라이브러리의 효율이 결과에 영향을 줄 수 있기 때문이다.저도 생산에서 BSON을 사용할 수 없습니다. 왜냐하면 데이터 구조에서 이런 수준의 유연성이 거의 필요하지 않기 때문입니다.따라서 본 예에서 저는 Python's CTypes를 사용하여 적합한 데이터 구조를 구축하고 MongoDB 데이터에 사용되는 데이터 모델과 유사한 데이터 모델을 구축하고자 합니다.

소프트웨어 레이싱

이 모든 것이 있으면 두 서버가 데이터로 가득 차서 우리의 NosQL 데이터베이스에서 어느 것이 이겼는지 볼 때가 되었다.이것은 우리 시대의 전투이다.경전의 다윗과 가리아.OpenLDAP는 세계에서 가장 유행하는 문서 데이터베이스에 비해 핵심 가치를 엔진 덮개에 저장합니다.동적 모드와 하드 인코딩 모드.누가 이길까요?

기계 규격

이 테스트에 대해 MongoDB v4를 사용했습니다.4.6,LMDB v0.구렁이7.3, 16GiB RAM과 Corsair MP510 SSD가 장착된 AMD Ryzen 7 3800X의 플라스크 2.0.1요청의 크기와 단순성을 고려하면 충분한 공간이 있어야 하기 때문에 나는 같은 기계에서 모든 조작을 실행했다.이것은 네트워크 지연이 가능한 한 0에 가깝다는 것을 의미한다. 대역폭은 우리가 물리 네트워크에서 오랫동안 볼 수 있는 대역폭보다 훨씬 크다.

첫 번째 실행 - 1 클라이언트

첫 번째 실행은 가장 좋은 상황이 무엇인지 확인하기 위한 직접적인 최소 부하 테스트입니다. 그래서 저는 10초마다 요청을 보내는 병렬 클라이언트를 사용했습니다.
그림에서 알 수 있듯이 몬고DB는 쓰기 조작에서 LMDB보다 뚜렷하게 우세하고 5ms의 우세로 앞서고 있다.나는 이것이 왜 그런지 완전히 확실하지는 않지만, 이것은 MongoDB가 업무를 사용하지 않는 것 (문서의 원자성 때문) 과 LMDB가 업무를 사용하는 것 (단일 메모리 맵에서 읽기와 쓰기가 동시에 발생하여 발생하는 손상을 방지하는 것) 과 관련이 있다고 의심한다.
그러나 읽기 분야에서 LMDB는 이미 미묘한 선두 우위를 보였다.쓰기 성능의 상대적으로 큰 차이에 비해 1ms의 개선은 보잘것없는 것 같지만, 이것은 제로 부하에서 진행되기 때문에 상황에 커다란 변화가 발생할 수 있다는 것을 기억해야 한다.

두 번째 단계--극한 찾기

4천 개의 병렬 클라이언트가 어떤 모습인지 보여 줍니다.이 예에서 나는 무작위 쓰기에 중점을 두지만 이 두 데이터베이스의 성질 때문에 쓰기 유형은 어느 정도 관련이 없다.여기서 LMDB는 몬고DB를 흡입하는 것에 불과해 14밀리초까지 낮은 평균 요청량과 296밀리초의 평균 요청량으로 큰 선두를 달리고 있음을 알 수 있다.한편, 몬고DB는 불쌍한 모습을 보였다. 중위수는 1400ms, 평균치는 2522ms!

Note: The reason we stopped at approximately 45000 requests during the write tests was that the MongoDB service had been OOM killed when it tried to reserve over 100% of the RAM on the machine. LMDB however didn't use significantly more than the 1GiB that the DB was allocated, and was happily handling the writes at a constant speed (regardless of load).
The read performance surprised me in a big way. For this test, I chose to focus on random-read (rather than sequential, or static). This is because out of the read patterns it is by far the most difficult. When performing random reads I had to cap the concurrent clients to 2000 as MongoDB was hitting the host OS's "Open File Limit" which was leading to general system instabilities. At 2000 Clients There is no contest, LMDB was on average 1000x faster, and unlike MongoDB, LMDB did not experience any errors.

이 시스템에서 LMDB의 상한선을 찾기 위해 나는 응답 시간이 몬goDB가 2000개 클라이언트에 대한 성능과 비슷할 때까지 클라이언트의 수를 점차적으로 늘렸다.LMDB 테스트가 약 10000명의 고객에게 도달했을 때 Hocust도 스트레스를 느낀 것 같아서 나는 도대체 어떤 원인이 속도 둔화를 초래했는지 100% 확신할 수 없다.마귀의 대변인 역할을 하기 위해 LMDB라고 가정하자. (내가 알기로는 메뚜기나 플라스크일 가능성이 높다.)이 극한에서, 우리는 여전히 어떤 고장도 보지 못했다. 아마도 그것을 더욱 추진할 수 있을 것이다. 그러나 평균 응답 시간이 1000밀리초에 가깝기 때문에, 나는 그것을 취소하기로 결정했다.5분의 1의 병렬 사용자를 처리할 때, 이것은 여전히 몬goDB의 응답 시간보다 3배 빠르지만, 나는 주제에서 벗어났다.

이것은 무엇을 의미합니까?

모든 사람이 몬godB에서 LMDB로 전환해야 합니까?절대 아니야!
네, LMDB는 몬고DB를 절대적으로 말살했고, 고부하를 처리할 때 거의 모든 방식으로 측정할 수 있습니다.그러니까 이게 네가 최적화해야 할 거라면 그래, 시작해.하지만 조심해야 한다.이 길을 따라 내려가면 용이 있을 것이다.MongoDB는 인덱스, 그룹, 백업, 그리고 일련의 다른 기능을 지원합니다. LMDB를 유사한 도구와 결합해서 사용하려면 이 기능을 구축해야 합니다.
또 다른 경고는 LMDB가 메모리로 매핑되기 때문에 데이터가 시스템에 존재하는 RAM의 수량으로 물리적으로 저장된다는 것이다.즉, 32비트 시스템의 경우 4GiB로 제한됩니다.64비트 시스템에 대해 다Exa 바이트의 범위 내에 이론적 상한선이 있다. 비록 현재의 x86 64 시스템 구조는 실제 64비트 메모리 주소가 아닌 56비트 메모리 주소를 사용하기 때문에 4peta 바이트의 범위 내에 제한되어 있지만 (비록 나는 네가 하드웨어가 이 점을 지원하는 것에 가깝다는 것을 다행히 발견할 수 있기를 바란다.)

마지막 생각

이것은 일회용 대체품이 아니며, 거의 영원히 그럴 수 없을 것이다. 시간과 인내심을 바탕으로 개발한 사람들에게는 우아한 도구이지만, 문서 라이브러리를 찾고 있다면 초보자들에게는 우호적이지 않다.만약 내가 여기서 보여준 성능 차이를 실현하고 싶다면, 사용자 정의 이진 형식을 설계하는 데 풍부한 경험이 필요하다.BSON(또는 다른 유사한 이진 형식)층을 사용하면 이러한 진입 장벽을 낮출 수 있지만 이것은 성능 비용을 가져오고 LMDB가 아닌 몬goDB와 성능을 유사하게 할 수 있다.
여느 때와 마찬가지로, 업무를 위해 정확한 도구를 선택하는 것이 진정한 전투이다. 만약 당신이 바이너리 형식을 자유롭게 처리할 수 있다면, 이것은 절대로 당신의 도구 상자에 추가할 수 있는 새로운 도구이다.

한층 더 읽다

에서 제 새 시리즈의 첫 번째 부분을 찾을 수 있습니다: LMDB를 사용하여 파이톤에 데이터베이스를 구축합니다
그리고 HarperDB가 엔진 뚜껑 아래에서 LMDB를 어떻게 사용하는지에 대한 흥미로운 인터뷰가 있습니다.