1. 데이터베이스 선정
- 각 데이터베이스는 다른 문제를 풀 수 있도록 설계되었습니다.
- 모든 요구 사항에 대해 하나의 데이터베이스 엔진을 사용해 만든 솔류션은 성능 기준을 충족시키지 못할 수 있습니다.
- RDBMS 분야조차 OLAP, OLTP 시스템의 요구사항은 매우 다릅니다.
- 데이터 관계를 생각해보면 RDBMS는 이미 존재하는 관계를 강제할 때 좋지만, 관계를 새로 발견하고 싶거나 같은 객체에 속하는 데이터를 다른 테이블에서 찾아야 할 경우 사용하기가 어려워진다.
2. 이종 데이터 저장소의 필요성
- 많은 기업에서 비즈 니스 트랜잭션, 세션 관리 데이터를 저장하는 데 그리고 이와 다르 종류의 저장소를 필요로 하는 리포팅, BI, 데이터 웨어하우징, 로깅에 같은 데이터베이스를 사용하는 경향이 있습니다.
- 세션, 장바구니 데이터에 대한 가용성과 일관성, 백업 요건의 수준은 주문 데이터에 필요한 수준과 같아야 할까요?
- 닐포드는 문제마다 이를 해결하는데 유리한 언어가 있으므로 애플리케이션을 여러 언어로 작성하는 다중 언어 프로그래밍이란 용어를 만들었습니다.
- 이와 마찬가지로 여러 종류의 저장소를 사용하는 방법을 다중 저장소 지속성이라고 합니다.
- 데이터 저장소 기술을 추가할수록 프래그래밍 운영 복잡도가 증가하므로, 도입의 장점과 복잡도 증가 문제의 경중을 고려해야 합니다.
3. 서비스를 통한 데이터 접근
- 서비스를 통해 데이터에 접근하는 것은 데이터베이스를 직접 사용하는 것보다 더 많은 이점을 제공합니다.
- 모든 데이터베이스를 서비스로 래핑하면 애플리케이션이 서비스하고만 통신할 수 있게 됩니다.
- 이렇게 하면 데이터베이스를 변경하거나 새로운 데이터베이스를 추가할 때 애플리케이션을 변경할 필요가 없습니다.
- 실제로 리악, 네오 같은 많은 NoSQL 데이터베이스는 RESTful API를 제공합니다.
4 프로그래머 생산성
- 관계형 데이터베이스로 작업한데 불만 사항은 객체-관계 매핑 계층을 구축하는 것입니다.
- 하이버네이트의 등장으로 부담감이 많이 줄었지만, 여전히 문제가 완전히 해결되지 않았습니다.
- ORM은 구멍 뚫린 추상화로 주의를 기울여야 할 경우가 생깁니다.
- 특히 충분한 성능이 나오게 하려면 많은 노력이 필요합니다.
- 이런 상황에서 집합 지향 데이터베이스는 좋은 대안이 됩니다.
- ORM을 제거하고 집합을 우리가 사용하는 그대로 데이터베이스에 저장할 수 있습니다.
- 그래프 데이터는 다른 종류의 단순화를 제공합니다.
- 관계형 데이터베이스는 많은 종류의 관계를 잘 처리하지 못합니다.
- 균일하지 않은 데이터에 대해서는 NoSQL 시스템이 더 나은 대안이 될 수 있습니다
- 관계형 데이터베이스에서 이를 해결하기 위해서는 많은 노력이 필요합니다.
- 스키마가 없는 NoSQL은 이런 문제를 쉽게 해결할 수 있습니다.
- 안타깝게도, 다른 설계가 얼마나 생산적인지 측정하는 적절한 방법은 없습니다.
- 생산성 확인을 위해 데이터베이스를 사용해 볼 때 잘 맞지 않는 경우에 대해서도 시도해 보는 것이 중요합니다.
- 가장 중요한 점은 실제 프로그래밍 경험을 기반으로 결정해야 한다는 것입니다.
- 단 일주일이라도 직접 사용해본다면 100개 벤더의 발표를 들어도 배울 수 없는 사실을 알게 될 것입니다.
5 데이터 접근 성능