|
Redis로 애플리케이션 개발은 즐거운 과정이지만, 모든 기술과 마찬가지로 Redis 기반 애플리케이션을 설계할 때 몇 가지 주의해야 할 점이 있습니다. 관계형 데이터베이스 개발의 전체 루틴에 익숙했을 수도 있고, Redis 기반 애플리케이션 개발은 많은 유사점이 있지만, 다음 두 가지를 명심해야 합니다 - Redis는 인메모리 데이터베이스이며 단일 스레드입니다. 따라서 Redis를 사용할 때는 다음 사항들을 주의해야 합니다: 1. Redis에 저장된 모든 키를 제어합니다 데이터베이스의 주요 기능은 데이터를 저장하는 것이지만, 애플리케이션 요구사항이나 데이터 사용 방식 변경으로 인해 개발자들이 데이터베이스에 저장된 일부 데이터를 무시하는 것이 일반적이며, Redis에서도 마찬가지입니다. 만료되는 특정 키를 놓칠 수도 있고, 애플리케이션의 한 모듈이 폐기되어 데이터를 잊어버릴 수도 있습니다. 어느 경우든 Redis는 더 이상 사용하지 않는 데이터를 저장하여 이유 없이 공간을 차지합니다. Redis의 약한 구조화된 데이터 패턴 때문에 중앙에 무엇이 저장되어 있는지 파악하기 어렵습니다. 매우 성숙한 키 명명법을 사용하지 않는 한 말이죠. 적절한 명명 방식을 사용하면 데이터베이스 관리가 간소화되고, 애플리케이션이나 서비스를 통해 키의 네임스페이스를 생성할 때(보통 콜론을 사용해 키명을 구분함), 데이터를 마이그레이션, 변환, 삭제할 때 쉽게 식별할 수 있습니다. Redis의 또 다른 일반적인 사용 사례는 핫 데이터 항목의 두 번째 데이터 저장소로서로, 대부분의 데이터가 PostgreSQL이나 MongoDB와 같은 다른 데이터베이스에 저장되는 경우입니다. 이러한 사용 사례에서 개발자들은 데이터가 주 저장소에서 삭제될 때 해당 데이터를 Redis에서 삭제하는 것을 종종 잊어버립니다. 이 경우 보통 연쇄 삭제가 필요하며, Redis 구성에서 특정 데이터 항목의 모든 식별자를 저장하여 데이터가 기본 데이터베이스에서 삭제된 후 클리너를 호출해 관련 복사본과 정보를 삭제하도록 할 수 있습니다. 2. 모든 키네임의 길이 제어 앞서 말했듯이, 적절한 명명 규칙과 접두사를 추가해 데이터가 어디로 가는지 식별했기 때문에, 이 방식은 그 규칙에 반하는 것 같습니다. 하지만 Redis는 인메모리 데이터베이스라는 점을 잊지 마세요. 키가 짧을수록 필요한 공간이 적습니다. 당연히, 데이터베이스에 수백만 또는 수십억 개의 키가 있을 때, 키 이름의 길이가 큰 영향을 미칩니다. 예를 들어, 32비트 Redis 서버에서 32자 길이의 백만 키를 저장하면 6자리 키네임을 사용할 때 약 96MB의 공간을 차지하지만, 12자 키네임을 사용하면 공간 소모가 약 111MB로 증가합니다. 키가 많아지면 추가로 15%의 간접비가 큰 영향을 미칠 것입니다. 3. 적절한 데이터 구조를 사용하세요 메모리 사용량이든 성능이든 데이터 구조가 큰 영향을 미칠 수 있습니다. 참고할 만한 몇 가지 모범 사례를 소개합니다: 수천(또는 수백만) 개의 개별 문자열로 데이터를 저장하는 대신, 관련 데이터를 그룹화하기 위해 해시된 자료구조를 사용하는 것을 고려해 보세요. 해시 테이블은 매우 효율적이며 메모리 사용량을 줄일 수 있습니다; 동시에, 해싱은 세부 추상화와 코드 가독성 측면에서도 더 유리합니다. 적절할 때는 set 대신 list를 사용하세요. Set 기능이 필요 없다면, List는 설정보다 빠른 속도를 제공하면서 적은 메모리를 사용할 수 있습니다. 정렬 집합은 메모리 소비와 기본 연산의 복잡성 측면에서 가장 비용이 많이 드는 자료구조입니다. 레코드를 쿼리하는 방법만 필요하고 그런 속성 정렬에 신경 쓰지 않는다면, 해시 테이블을 사용하는 것이 강력히 권장됩니다. Redis에서 자주 간과되는 기능 중 하나는 비트맵 또는 비트셋(V2.2 이후)입니다. 비트셋은 Redis의 값에 대해 여러 비트 수준 연산을 수행할 수 있게 해주며, 예를 들어 경량 분석도 가능합니다. 4. 스캔 사용 시 키를 사용하지 마세요 Redis v2.8 기준으로는 이미 SCAN 명령어가 제공되어 커서를 사용해 키 공간에서 키를 가져올 수 있습니다. KEYS 명령어와 비교할 때, SCAN이 모든 일치 결과를 한 번에 반환할 수는 없지만, 시스템 차단 위험을 피하여 일부 작업을 마스터 노드에서 실행할 수 있습니다. SCAN 명령어는 커서 기반 반복자라는 점을 유념하는 것이 중요합니다. SCAN 명령어가 호출될 때마다 새로운 커서가 사용자에게 반환되며, 사용자는 다음 반복에서 이 새로운 커서를 SCAN 명령어의 커서 매개변수로 사용하여 이전 반복 과정을 계속해야 합니다. 동시에 SCAN을 사용하면 키네임 모드와 카운트 옵션을 통해 명령어를 조정할 수도 있습니다. SCAN과 관련된 명령어에는 SSCAN 명령어, HSCAN 명령어, ZSCAN 명령어도 포함되며, 각각 컬렉션, 해시 키, 그리고 후속 명령에 사용됩니다. 5. 서버 측 Lua 스크립트 사용 Redis를 사용하는 과정에서 Lua 스크립트 지원은 개발자들에게 매우 친근한 개발 환경을 제공하여 사용자의 창의력을 크게 해방시켰습니다. 올바르게 사용될 경우, Lua 스크립트는 성능과 자원 소비에 상당한 개선을 가져올 수 있습니다. CPU에 데이터를 전달하는 대신, 스크립트는 데이터에 가장 가까운 로직을 실행할 수 있게 하여 네트워크 지연과 중복 데이터 전송을 줄입니다. Redis에서 Lua의 매우 고전적인 사용 사례는 데이터 필터링이나 데이터를 애플리케이션에 집계하는 것입니다. 처리 워크플로우를 스크립트로 캡슐화하면, 적은 자원으로 더 짧은 시간에 더 작은 답변을 얻을 수 있습니다. 프로 팁:Lua는 훌륭하지만, 버그 보고나 버그 처리 문제 같은 몇 가지 문제도 있습니다. 현명한 방법은 Redis의 Pub/Sub 기능을 활용해 스크립트가 전용 채널을 통해 로그 메시지를 푸시하도록 하는 것입니다. 그 다음 구독자 프로세스를 만들고 그에 맞게 처리하세요.
| 
게시됨 2015. 12. 29. 오후 12:22:28
|
|
|
