메모리 데이터베이스 사용 시기

메모리 데이터베이스는 메모리 자원을 희생하는 대가로 실시간 데이터 처리를 교환한다. 메모리 데이터베이스와 디스크 데이터베이스는 오늘날 정보 사회의 모든 기업에 필요한 관계형 데이터베이스 제품입니다. 디스크 데이터베이스는 대용량 스토리지 및 데이터 분석 문제를 해결하고 메모리 데이터베이스는 실시간 처리 및 높은 동시 문제를 해결합니다. 이 둘의 존재는 상호 보완적이며, 기본 메모리 데이터베이스의 실시간 트랜잭션 성능은 디스크 데이터베이스보다 훨씬 뛰어납니다. 그러나 상대적으로 그의 데이터 보안은 아직 디스크 데이터베이스 수준에 미치지 못했다.

메모리 데이터베이스는 물리적 메모리를 데이터의 첫 번째 스토리지 미디어로, 디스크를 백업으로 사용합니다. 통신 사업이 발전함에 따라 시스템은 실시간 유연한 업무 수정에 대한 요구가 매우 높다. 이 경우 메모리 데이터베이스에 대한 수요도 증가하고 있습니다. 디스크 데이터베이스는 데이터를 메모리에 저장하여 처리하며 관리 용이성과 데이터 보안 신뢰성이 보장되지 않습니다. 주 메모리 데이터베이스는 이러한 약점에 맞게 개선되었습니다.

실제로 메모리 데이터베이스는 세련된 기술이 아닙니다. 60 년대 말에 나타났지만, 시장 수요로 인해 90 년대 말에 발전하기 시작했다. 차세대 데이터베이스인 Altibase 제품은 이미 하이브리드 데이터베이스로 이동했으며, 그 버전 Altibase 4.0 에는 이미 자체 디스크 데이터베이스가 있습니다. 사용자가 Altibase 의 주 메모리 데이터베이스를 구매하면 디스크 데이터베이스를 구입할 필요가 없습니다. 핫 데이터 (자주 사용, 액세스 및 자주 계산되는 데이터) 를 메모리 데이터베이스에 배치하고 기록 데이터를 디스크 데이터베이스에 보관하여 사용자의 투자를 더욱 줄일 수 있습니다.

메모리 데이터베이스의 경우 동일한 데이터베이스의 일부를 디스크에 저장하고 다른 부분은 메모리에 저장할 수 있습니다. 사용자는 즉각적인 데이터 액세스를 위해 데이터를 메모리 테이블에 저장할 수 있습니다. 액세스 시간이 긴급하지 않거나 메모리에 저장된 데이터가 너무 많은 공간을 차지하는 경우 디스크 테이블에 데이터를 저장할 수 있습니다.

예를 들어, 휴대 전화 사용자가 전화를 걸기 시작할 때 메모리 데이터베이스 기술을 기반으로 하는 혼합 데이터 관리 엔진을 적용하면 메모리 테이블을 통해 서비스 옵션을 검색하고 사용자의 신원을 즉시 확인하는 반면 통화 목록과 청구 목록은 디스크 테이블에 보관됩니다. 따라서 속도와 자원 사용 사이의 균형이 이루어졌다.

메모리 데이터베이스 기술의 중요한 특징 중 하나는 메모리의 모든 데이터를 처리할 수 있다는 것입니다. 이는 단순히 데이터를 배열로만 메모리에 넣는 것과는 완전히 다릅니다. 그리고 주 메모리 데이터베이스는 응용 프로그램과 무관하기 때문에 분명히 이 아키텍처는 합리적이다. 메모리 엔진은 쿼리 및 아카이브 기능을 위해 동일한 데이터베이스를 사용할 수 있으며 메모리 및 디스크 테이블은 동일한 액세스 방법을 사용합니다. 스토리지 선택은 애플리케이션 개발자에게 완전히 투명합니다.

메모리 데이터베이스의 경우 데이터베이스 캐시뿐 아니라 메모리의 데이터를 관리할 수 있습니다. 디스크 데이터 블록을 주 메모리에 캐시하는 다른 데이터베이스와 달리 주 메모리 데이터베이스의 메모리 엔진은 랜덤 액세스 메모리용으로 특별히 설계된 데이터 구조와 알고리즘을 사용하여 정렬 명령을 사용하여 캐시 데이터베이스 성능을 자주 손상시키는 문제를 방지합니다. 기본 메모리 데이터베이스를 통해 디스크 I/O 를 줄이면 기존의 디스크 I/O 기반 데이터베이스와 비교할 수 없는 처리 속도를 얻을 수 있습니다.

따라서 메모리 데이터베이스 기술의 응용은 데이터베이스 속도를 크게 높이고 통신, 금융 등 고속 응답이 필요한 데이터베이스 애플리케이션에 대한 강력한 지원을 제공합니다.

대부분의 데이터는 메모리에서 작동하기 때문에 메모리 데이터베이스의 성능은 디스크 데이터베이스보다 훨씬 뛰어나 통신 기업 운영 지원 시스템의 실시간 요구 사항에 적합합니다.

통신업계 경쟁의 전방위적인 발전은 반드시 새로운 가치 사슬 모델과 새로운 유료 방식을 가져올 것이다. 이러한 변화는 기존의 통신 운영 지원 시스템에 도전을 제기했다. 예를 들어, 다양한 비즈니스의 청구 링크는 더 이상 길이나 통신 거리를 기준으로 하지 않고 길이, 컨텐츠, 사용량 등 다양한 매개변수의 조합을 기준으로 할 수 있습니다. 이러한 과제를 해결하기 위해 통신 기업은 백그라운드 데이터 관리의 실시간, 정확성 및 유연성을 향상시키기 위해 메모리 데이터베이스를 도입했습니다.

기본 메모리 데이터베이스는 더 이상 기존 디스크 데이터베이스의 개념이 아니지만 기본적으로 여전히 데이터베이스이며 일반 데이터베이스의 기본 기능도 갖추고 있습니다.

■ 데이터베이스의 정의, 저장 및 유지 관리를 포함한 영구 데이터 관리

■ 쿼리 처리, 액세스 및 무결성 검사와 같은 다양한 데이터 작업을 완료합니다.

■ 스케줄링 및 동시성 제어를 포함한 트랜잭션 관리;

■ 출입 통제 및 안전 검사;

■ 데이터베이스 신뢰성 복구 메커니즘을 갖추고 있습니다.

메모리 데이터베이스는 프로그램 개발을 통해 메모리 처리를 호출하는 것보다 자체 장점이 있습니다. 첫째, 주 메모리 데이터베이스는 제품 기반 데이터베이스 관리 소프트웨어로 개발 주기를 크게 단축합니다. 둘째, 주 메모리 데이터베이스에는 오픈 플랫폼과 인터페이스가 있어 프로그램 개발 및 이식이 유연하고 편리하며 유지 관리 및 2 차 개발이 용이합니다. 셋째, 통합 SQL 언어를 사용하여 메모리의 데이터를 쉽게 조회할 수 있습니다. 마지막으로 데이터베이스에 있는 데이터의 보안과 무결성이 보장됩니다. 이러한 장점은 신속한 배포 및 유지 관리 단순화에 도움이 됩니다.

그러나 주 메모리 데이터베이스에는 불가피한 단점이 있습니다. 예를 들어, 복구가 쉽지 않고, 주 메모리 데이터베이스의 데이터가 항상 영구적인 것은 아니며, 실시간성을 보장하기 위해 반드시 일관되고 절대적으로 정확한 것은 아니며, 어떤 것은 일시적이거나, 어떤 것은 일시적으로 일관되지 않거나 절대적으로 정확하지 않은 경우도 있습니다. (데이비드 아셀, Northern Exposure (미국 TV 드라마), 성공명언)

통신 기업은 항상 메모리 데이터베이스의 주요 사용자였습니다. 최근 몇 년 동안, 컴퓨터 하드웨어 기술의 급속 한 발전과 함께, 메모리 용량의 증가, 가격 하락, 그리고 64 비트 시대 운영 체제를 입력 한 후 컴퓨터가 더 큰 주소를 지원할 수 있습니다, 그래서 메인 메모리 데이터베이스의 실현이 가능 합니다. 현재, 메모리 데이터베이스는 통신업계에서 점점 더 성숙해지고 있다. 90G 이상의 통신 시스템 사례, 메모리 공간 자동 확장, ESOL 맞춤형 저장 프로시저 제공, 데이터베이스 재부팅 불필요, 멀티스레드 지원, 개발 효율성, 프로그램 마이그레이션 용이성

다음은 메모리 데이터베이스의 응용 프로그램에 대한 두 가지 예입니다.

텔레콤 청구 데이터 로드

통신의 2 차 가격 승인과 실시간 계정 누적은 청구 시스템에서 없어서는 안 될 두 가지 기능입니다.

소위 두 묶음의 가격이란, 한 묶음의 가격에 상대적인 것이다.

한 가지 가격 사정은 바로 국가 표준요금에 따라 가격을 계산하는 것이다. 예를 들어 GSM 의 현지 통화는 분당 0.4 위안입니다. 첫 번째 가격 승인이 완료되면 사용자의 패키지에 따라 다시 계산됩니다. 베이징 글로벌 이용자가 4 분 동안 전화하는 것을 예로 들어 보겠습니다. 첫 번째 가격 승인 후, 이 통화료의 가격은 1.6 위안이다. 이 사용자가 10 원짜리 전세 코스에 참가한다면 2 차 가격 승인 후 이 통화의 비용은 0 원입니다.

첫 번째 가격 승인은 각 주요 사업자 간의 결제에 사용되고, 두 번째 가격 승인은 개별 사용자를 대상으로 합니다.

실시간 통화료 누적은 사용자가 매월 1 부터 현재까지 모든 비용을 누적하는 것입니다. 즉, 사용자는 10086 을 통해 전날까지 실시간 통화료를 조회할 수 있습니다. 누적 계정 가치는 사용자가 고액의 통화료를 통제하거나 사용자에게 즉각적인 소비 정보를 제공하는 데 도움이 될 수 있습니다.

2 차 가격 승인 및 실시간 계정 누적 프로세스에는 통신 지원 시스템이 가격 승인을 시작할 때 로드해야 하는 사용자 데이터, 사용자 패키지 등의 사용자 관련 정보가 포함됩니다. 조금 더 큰 성급 사업자의 데이터는 654.38+백만 원을 넘을 것으로 예상되며, 패키지, 제품, 다양한 혜택 규칙의 조합으로 인해 청구 처리 모델이 상당히 복잡하다. 이러한 데이터를 로드하는 것은 시스템에 많은 오버헤드가 있어 현재 청구 처리 속도가 느리고 실시간으로 데이터를 업데이트하기가 어렵습니다. 메모리 데이터베이스의 도입은 이 문제를 어느 정도 해결했다.

데이터 양이 가장 많은 것은 2 차 청구 과정의 상세 청구 데이터입니다. 이 데이터 부분은 메모리 데이터베이스에 넣을 필요가 없습니다. 하나의 어음 파일을 처리하거나 설정된 커밋 레코드 수에 도달할 때 디스크 데이터베이스를 직접 조작해도 시스템 성능에 영향을 주지 않습니다. 사용자 데이터, 패키지, 비즈니스 패키지 및 청구 패키지에 해당하는 데이터, 청구 패키지 모델 데이터 및 누적 사용자 데이터를 메모리 데이터베이스에 저장하는 것이 급선무입니다. 이 데이터 쿼리 작업은 데이터 추가 및 업데이트 작업보다 훨씬 빈번합니다. 물론 이 데이터 외에 응용 프로그램에 필요한 다른 데이터도 주 메모리 데이터베이스에 로드할 수 있습니다.

메모리 데이터베이스를 사용한 후 사용자는 영업부나 고객을 통해 실시간 통화료를 조회할 수 있으며, 현재 전날까지만 조회할 수 있는 실시간 통화료에 비해 업무상 질적인 도약을 할 수 있다. 이 데이터 부분을 처리할 때 시스템의 쿼리 프로세스는 이전과 동일하므로 메모리의 데이터와 디스크 데이터베이스의 데이터 간의 동기화 링크가 필요 없으므로 실시간 쿼리를 수행할 수 있습니다. 신용통제도 마찬가지다. 이전에는 시스템이 계좌 누적 후 일정 주기에 따라 신용통제 데이터를 새로 고쳐야 했기 때문에 시간차가 있어 완전히 실시간일 수 없었다.

메모리 데이터베이스를 사용하면 신호 제어가 메모리 데이터베이스의 실시간 통화료 누적 테이블의 데이터를 직접 가져와 실시간 경보 및 종료를 완벽하게 수행할 수 있습니다. 2 차 가격 승인 및 누적 계좌에서 메모리 데이터베이스를 사용한 후 사기 방지 및 소득 보장 체계에 큰 도움이 되어 경영자의 절실한 이익을 충분히 보장할 수 있다.

또한 메모리 데이터베이스를 사용하면 시스템 가격 승인 및 누적 장부의 처리 속도가 전반적으로 향상되어 디스크 데이터베이스에 액세스하는 압력이 크게 완화되고 데이터 조회, 수정, 삭제 효율성이 향상되며, 사후 지불과 사전 지불의 통합이 가능합니다.

텔레콤 청구 데이터 동기화

통신 비즈니스 데이터 및 청구 시스템의 데이터는 항상 변경되며, 여기에는 메모리 데이터베이스의 데이터와 디스크 데이터베이스의 데이터 동기화 문제가 포함됩니다 (명확성을 위해 디스크 데이터베이스는 Oracle DB 를 예로 들어 설명함). 데이터 동기화는 메모리 데이터베이스에서 Oracle DB 로의 데이터 동기화 및 Oracle DB 에서 메모리 데이터베이스로의 데이터 동기화라는 두 부분으로 구성됩니다.

1. Oracle 데이터베이스에서 메모리 데이터베이스로의 동기화

이 데이터 동기화는 비즈니스 시스템 또는 CRM 에서 새로 추가되거나 갱신된 데이터가 Oracle 의 증분 테이블로 생성되는 증분 테이블 방식을 사용하며, 청구 데몬은 먼저 이러한 증분 테이블의 데이터를 질의합니다. 이러한 증분 테이블에서 데이터를 찾을 수 있는 경우 주 메모리 데이터베이스의 해당 테이블로 데이터를 업데이트하고, 찾을 수 없는 경우 주 메모리 데이터베이스에서 직접 데이터를 쿼리하여 데이터 무결성과 실시간을 보장합니다. 증분 테이블의 데이터 양은 일반적으로 작기 때문에 이 부분의 작업은 시스템 성능에 영향을 주지 않습니다.

2. 메모리 데이터베이스에서 오라클 데이터베이스로의 동기화

Oracle 의 청구 백그라운드 대량 가격과 누적 계정 데이터는 거의 모두 메모리 데이터베이스에 로드되기 때문에 Oracle 데이터베이스에 해당하는 데이터 테이블은 주로 메모리 데이터베이스의 데이터 백업에 사용됩니다.

사용자의 최신 실시간 통화료 등의 정보는 메모리 데이터베이스에 저장되고 실시간 통화료 조회는 메모리 데이터베이스에 직접 연결되어 사용자가 최신 비용 정보를 얻을 수 있도록 합니다. 정보 제어도 주 메모리 데이터베이스에서 직접 데이터를 조회하므로 Oracle 에서는 이 데이터 부분에 대한 실시간 요구 사항이 없습니다. 이때 응용 프로그램에서 기본 메모리 데이터베이스와 Oracle 의 동기화를 생성하고, Oracle 데이터베이스에 정기적으로 백업하거나, 시스템이 비교적 유휴 상태인 동안 Oracle 저장 프로시저를 사용하여 데이터를 가져올 수 있습니다.

전반적으로 시장과 기술의 급속한 발전으로 인해 통신 업무가 확대되고 운영 및 관리가 지속적으로 최적화되고 있습니다. 기존의 일부 지원 시스템은 점점 늘어나는 비즈니스 요구 사항과 고객 요구 사항을 충족하지 못하고 있으므로, 생산 과정에서 발생하는 문제를 해결하기 위해 새로운 기술을 도입하는 것은 불가피합니다. 예를 들어, 이전 메모리 공유 기술 대신 메모리 데이터베이스를 사용하여 인터페이스, 형식, 관리 등 메모리의 비표준 것들을 표준화했습니다.

주 메모리 데이터베이스는 수많은 신기술 중 대표적인 것일 뿐이다. 우리가 마음을 해방시키고 적절하게 선택하기만 하면, 최소한의 투자로 제도의 병목 현상을 극복하고 최소한의 비용으로 최대의 수익을 얻을 수 있다.

우리는 최근에 비교적 인기 있는 Oracle, Db2, SQL 서버, Sybase, Informix, Mysql, Pqllite 와 같은 많은 범용 데이터베이스를 보았다. 물론 오픈 소스 PostgreSQL 도 잊어서는 안 됩니다. 일반적으로 이러한 데이터베이스는 중요한 업무를 감당할 수 있지만 고성능을 요구하는 데는 여전히 약간 부족합니다. 청구 시스템에서 사용자 정보가 자주 변경되면 지연은 청구 시스템의 정상적인 작동에 큰 영향을 미칠 수 있습니다.

내가 접촉한 유일한 메모리 데이터베이스는 아신이 차이나 모바일 청구 센터의 감사 시스템에서 사용하는 것이다. 감사 시스템은 사용자 상태 정보와 가입 정보를 동기화한 다음 생성된 청구서를 감사해야 하기 때문에 응답 속도가 느리면 잘못된 결과가 발생할 수 있습니다. 처음에는 감사 시스템이 없었을 때, 유료기준은 기본적으로 sp 에서 발급한 것이다. 그러나, 사용자들은 그들이 실제로 이 서비스를 이용하거나 서비스를 취소하지 않을 때 여전히 계산서에 요금을 받는다는 것을 종종 발견한다. 이에 따라 차이나 모바일 (WHO) 는 sp 의 청구서를 감사하고 자신의 데이터를 기준으로 sp 의 유료 수단을 완전히 차단하기로 했다.

사용자 상태 정보 및 가입 정보를 얻으려면 여러 시스템에서 동기화하고 대화 상자를 검토해야 합니다. 중간 처리 시간은 엄격해야 하며 (사용자가 짧은 시간 내에 자신의 통화료 정보를 볼 수 있음), 시스템에 대한 응답 시간은 가능한 한 짧아야 합니다.

범용 데이터베이스는 이와 관련하여 열세에 처해 있다. Yaxin 은 3 개의 rx8420 을 데이터베이스 호스트로 사용하여 3 1 주 사용자 정보를 번호순으로 3 개의 호스트에 공유합니다. 각 지방에는 하나 이상의 보관 프로세스가 있으며, 사용자가 많은 경우 여러 프로세스를 사용하여 체크 인합니다. 데이터 수집의 출처는 주로 BOSS 및 1 차 청구 시스템을 통해 이루어집니다.

데이터가 메모리에 저장되기 때문에 저장된 데이터 구조는 일반 데이터베이스와 다릅니다. 또한 데이터 보안을 위해 디스크에는 메모리 데이터의 미러링이 있어 일정 간격으로 메모리의 데이터를 디스크에 동기화하고 호스트 장애 발생 시 디스크를 통해 데이터를 복구할 수 있습니다. 호스트에 장애가 발생하면 대체 호스트가 HA 를 통해 인계됩니다. 그러나 데이터 작업의 로그와 롤백은 Oracle 만큼 좋지 않으며 간단한 복구 메커니즘만 제공합니다.

청구 시스템에서는 먼저 sp 에서 보낸 청구서를 검토해야 합니다. 주요 기준은 사용자 상태 및 가입 정보입니다. 예를 들어, 사용자가 7 일 동안 전원을 끈 경우 서비스 공급업체의 청구서에 새 주문 정보가 나타나면 청구서는 잘못된 청구서로 간주됩니다. 이렇게 움직이면 sp 와의 게임에서 주도권을 잡는다. 감사 시스템이 온라인상에 올라온 후, sp 에 대한 사용자 불만이 현저히 줄었다.

링크 1: 메모리 데이터베이스와 기존 데이터베이스의 유사점과 차이점

기존의 데이터베이스 시스템은 영구적으로 안정적인 데이터를 처리하기 위해 개발된 관계형 데이터베이스입니다. 관계형 데이터베이스는 데이터의 무결성과 일관성을 유지하는 것을 강조하지만 관련 데이터 및 처리 시간 제한을 고려하기가 어렵고, 실시간 트랜잭션에서는 트랜잭션 실행 시간을 정확하게 예측해야 하기 때문에 산업 생산 관리의 실시간 애플리케이션 요구를 충족시킬 수 없습니다.

디스크 데이터베이스의 경우 디스크 액세스, 데이터 출입 메모리, 버퍼 관리, 대기열 대기 및 잠금 지연으로 인해 트랜잭션의 실제 평균 실행 시간이 예상 최악의 실행 시간과 크게 다릅니다. 전체 데이터베이스 또는 주요' 작업' 부분을 메모리에 넣으면 각 트랜잭션이 실행되는 동안 I/O 가 없으므로 시스템이 트랜잭션 실행 시간을 정확하게 예측하고 예약할 수 있는 강력한 지원이 제공됩니다. 보다 동적이고 예측 가능합니다. 이것이 메모리 데이터베이스가 나타나는 주된 이유입니다.

메모리 데이터베이스에서 처리하는 데이터는 일반적으로 "일시적인" 데이터입니다. 즉, 특정 유효 시간이 있고, 구식이 되면 새로운 데이터가 생성되고, 현재의 의사 결정 추정은 무효화됩니다. 따라서 실제 응용 프로그램에서 메모리 데이터베이스는 실시간 비즈니스 논리 처리 데이터를 처리하는 데 사용됩니다. 전통적인 데이터베이스는 영구적으로 안정적인 데이터를 처리하는 것을 목표로 하고 있으며, 성능 목표는 높은 시스템 처리량과 저렴한 비용으로 인해 실시간 데이터 처리에 대해 비교적 적은 고려를 해야 합니다. (데이비드 아셀, Northern Exposure (미국 TV 드라마), 성공명언) 실제 응용 프로그램에서 기존 데이터베이스는 실시간 요구 사항이 비교적 낮은 데이터를 저장하는 데 사용됩니다.

실제 응용 프로그램에서는 기존 데이터베이스 대신 주 메모리 데이터베이스를 사용하는 대신 두 데이터베이스를 함께 사용하는 경우가 많습니다.

링크 2: 여러 메모리 데이터베이스 제품

■ 갑골문 타임즈

Oracle TimesTen 은 Oracle 이 Timeten 에서 인수한 메모리 최적화 관계형 데이터베이스로서 통신, 자본 시장, 국방과 같은 실시간 엔터프라이즈 및 산업에 필요한 즉각적인 대응 능력과 높은 처리량을 애플리케이션에 제공합니다. Oracle TimesTen 은 표준 SQL 인터페이스를 사용하여 물리적 메모리에서 데이터 저장소를 완전히 조작하는 캐시 또는 내장 데이터베이스로 애플리케이션 계층에 배치할 수 있습니다.

■ 알티베이스

Altibase 는 트랜잭션 우선 환경에서 높은 성능과 고가용성을 제공하는 소프트웨어 솔루션입니다. 통신, 온라인 뱅킹, 증권 거래, 실시간 애플리케이션 및 임베디드 시스템에 적합한 고성능, 내결함성 및 트랜잭션 관리 기능을 제공합니다. Altibase 는 데이터베이스 서비스 시스템의 잠재력을 극대화하고 데이터 서버의 처리 능력을 향상시킬 수 있습니다. Altibase 는 클라이언트/서버 또는 임베디드 아키텍처를 지원합니다. 클라이언트/서버 아키텍처는 일반 어플리케이션에 적합합니다. 임베디드 아키텍처는 데이터베이스 서버에 응용 프로그램을 내장하여 실시간 요구 사항이 높은 실시간 시스템에 적합합니다.

■ 한계 b

EXtremeDB 실시간 데이터베이스는 McObject 가 실시간 및 임베디드 시스템 데이터 관리를 위해 특별히 설계한 데이터베이스로 50K 에서 130K 까지 오버헤드가 마이크로초 정도입니다. EXtremeDB 는 주 메모리에 완전히 상주하며 메모리 디스크를 포함한 파일 시스템을 사용하지 않습니다. EXtremeDB 는 디스크를 가상 메모리로 사용하여 디스크로 메모리를 확장하는 새로운 디스크 컨버전스 기술을 사용합니다. 실시간 성능은 마이크로초이며 32BIT 에서 최대 20G 의 데이터 관리 용량을 제공합니다.