대량의 데이터 중에서 필요한 것을 빨리 반환할 수 없다 → Search(탐색, 인덱스)의 기술 영역

• B+Tree 인덱스나 해시 인덱스를 활용하여 가능함

대량의 데이터를 메모리 내에서 만으로는 취급할 수 없음

• HashMap 클래스를 이용하여 키와 쌍으로 관리할 수 있고 키를 이용하면 초고속으로 접근가능하지만, 메모리 내에서만 사용가능하므로 시스템 다운 되면 다 날아감

• 날아간 데이터 복구를 위해 디스크에 기록한다면?
• 시스템 충돌 발생한다면 이전 기록과 다음 기록 사이의 값들은 사라짐
• 디스크로 기록 시간 또한 오래 걸림(값싼 HD의 읽고 쓰기 속도는 기껏해야 초당 50MB) ⇒ 서버 망가진 경우 복구하는 데 꽤 오랜 시간이 걸리게 됨

장애가 발생했을 때 빠른 복구가 어렵다

• 장애 대응의 방법과 수준은 다양한데, 복구 노력이라는 관점에서 큰 요인이 되는 것은 데이터가 사라졌는지에 대한 여부임 → 이를 방지하기 위해 백업을 하는데 백업은 아래와 같은 문제가 있음
• 최종 백업 이후에 업데이트된 결과를 되돌릴 수 없다
• 백업 데이터를 다시 로드하는 데 시간이 걸리고, 그 기간 동안 다운 타임이 됨
• 백업 중에 섣불리 업데이트 하면 백업이 손상될 위험이 있음

• 어느 경우에도 백업 으로부터의 복구는 매우 시간이 걸리는 작업이며, 이러한 작업이 필요하지 않도록 설계하는 것이 서비스 운영자의 실력임

• 괜찮은 시스템에서는 서버의 복제(Replication)를 갖게 하는 구성을 많이 취함

• HDD가 손상되었다는 등의 이유로 데이터가 날아가 버리는 것 이외에도 단순히 서버 룸의 전원이 꺼지는 등의 이유로 파일이 손상되는 장애도 발생할 수 있음 → 이러한 상황에도 데이터베이스는 유용. DB는 탄력성을 고려하여 설계되었고 쓰기 도중에 크래쉬하는 경우에도 다시 시작할 때에는 자동으로 장애 부분 감지하여 일관성 있는 상태로 복구

병렬성 제어(배타제어)가 어렵다

• 배타 제어 : 동일한 파일에 대해 여러 사람이 동시에 쓰면, 아무런 배타 제어를 하지 않은 경우에 먼저 쓴 사람의 결과는 나중에 쓴 사람에 의해 덮어짐

• 구현 시, 배타의 범위에 대해서 고려해야 할 필요 있음
• 가장 간단한 것은 Lock File → 동시에 한 명만 갱신 액세스 할 수 있기에, 실행 성능 면에서는 큰 제약

• 데이터 세트의 배타 제어가 DB의 전문적인 부분임

데이터 무결성을 보장하는 것은 어렵다

• 데이터 자체가 불일치를 일으키지 않게 하는 구조를 만드는 것이 매우 중요함

• db의 참조 무결성 제약 조건