이것은 본질적으로 디자인 패턴 질문입니다.데이터베이스 대신 정적 개체를 사용하는 것이 좋지 않습니까?
주어진 주식에 대해 가장 높은 상관 관계가있는 주식 (주식/증권 등)의 목록을 얻기 위해 데이터베이스를 쿼리하려고합니다.
대신 정적 HashMap이 있고 거기에 데이터를 저장하는 객체를 만들어야한다고 생각했습니다. 그런 다음 필요할 때마다 "쿼리"하십시오.
동일한 데이터에 대해 데이터베이스를 쿼리하는 것보다 성능이 크게 향상 될 것이라고 생각하기 때문에이 접근법에 문제가 있습니까? 데이터 양은 상대적으로 작으며 문제가되지 않도록 커지지 않습니다. 나에게 나중에 물려 줄 수있는 문제가있을 수 있습니까?
나는 여전히 데이터베이스를 백업 목적으로 사용하지만 클라이언트가 빠른 액세스를 위해 로컬 파일 시스템에 데이터를 저장하기 위해 oscache와 같은 캐싱 API를 사용하면 시스템이 캐시에서 데이터베이스를 복원하고 코드에서 캐시를 사용하여 수행하십시오.
일반적으로이 방법에는 아무런 문제가 없습니다. "bad singleton"을 만들기 때문에 정적 클래스에 직접 액세스하지 않아야합니다. (글로벌 변수와 유사)
대신이 클래스를 쿼리 할 모든 객체에이 클래스를 등록하는 일종의 등록 메커니즘을 소개하십시오. 당신은 "좋은 싱글턴"을 가질 것이고 나중에 문제가 없을 것입니다. 그것은, 견고성 지속성에 관해서 물론
public class MyDataClass {
private MyDataClass() { }
public static MyDataClass getInstance() {
if (instance == null) instance = new MyDataClass();
return instance;
}
private static MyDataClass instance = null;
}
public class MyDataProcessor {
public void registerData(MyDataClass data) {
this.data = data;
}
public void process() {
assert(data != null);
data.getData(...);
}
private MyDataClass data;
}
이 방법은 건축 레이어에 결국 몇 가지 문제가있을 수 있습니다 ... 아마도 그것은 캐싱 층으로 데이터베이스를 사용하는 것이 좋습니다 수 있지만 것이라고 매우 의존 사용자의 실제 필요에 따라
정적 클래스에 직접 액세스하지 않는다고 말하면 HashMap에 직접 액세스하지 말라는 뜻입니까? get 및 set 메서드와 동일한 기능을 만들었습니다. 그게 당신이 말하는 겁니까? – Ankur
아니, 그건 내가 의미하는 바가 아니야. 나는 예제를 추가했다. –
접근 방식에 문제가있어 코드와 데이터가 분리되어 있지 않습니다. 몇 가지 단점 결과
: 당신이 필요하지 않는 것 당신이 백업 당신이 다시 컴파일해야
을 변경하려면 응용 프로그램을 다시 배포 관계형 데이터베이스 인 경우 BerkeleyDB과 같은 내장 된 키 - 값 - 데이터베이스를 사용하는 것이 좋습니다. 또한 매우 빠릅니다.
데이터를 변경하고 해시를 업데이트하고 매번 다시 컴파일해야하는 경우 문제가 발생할 수 있습니다.
데이터가 무엇인지 알면 데이터가 얼마나 영향을 미치는지 알 수 있습니다.
한 가지 옵션은 데이터를 데이터베이스에 보관 한 다음 HashMap에 캐싱하는 것입니다.
일반적으로 되돌아 오는 물음은 무엇인가 변하지 않을 것이라는 가정입니다. 따라서 나중에 값을 업데이트하고, 새 값을 추가하고, 이미 데이터베이스를 사용하고 있다면 여러 클라이언트가 데이터에 액세스하도록하는 요구 사항을 얻는다면 작업량이 줄어 듭니다. 대신 클라이언트 측에서 캐싱을 수행하여 성능을 향상 시키십시오. 그냥 내 2c.
쉽게 데이터를 HashMap에 저장하십시오.
그런 다음 XStream을 사용하여이 복사본을 serialize 할 수 있습니다. HashMap 객체의 XML 버전이 생성됩니다.
응용 프로그램에서 필요에 따라이를 디스크에 기록 할 수 있으므로 직접 편집하여 응용 프로그램에 다시로드 할 수 있습니다. 즉, HashMap과 필요에 따라 변경할 수있는 구성 가능한 표현이 디스크에 있음을 의미합니다.
정적 캐싱이 작동 할 수 있습니다. 자동으로 업데이트되지 않습니다 읽기 전용 캐시는 당신이 필요로하는 모든 경우
같은 데이터베이스에 액세스하는 여러 응용 프로그램이있는 경우는 메시징 버스의 일종과 distributed cache
을해야 함을 명심하여 이 접근법에는 아무 문제가 없습니다.
하나의주의 사항이 있습니다. 데이터의 양 (자바 객체 및 HashMap의 오버 헤드 포함)이 너무 커서 전체 RAM에 보관되지 않으면 성능이 신속하고 현저하게 감소합니다 (10,000 이상). 데이터베이스 시스템은 디스크상의 데이터에 효율적으로 액세스 할 수 있도록 설계되었습니다. HashMap은 그렇지 않습니다.
마지막 부분은 명심하기에 매우 유용합니다. – Ankur
캐시를 사용해야합니까? 예, 속도가 훨씬 빠르며 데이터를 업데이트하지 않거나 캐시 된 데이터가 실제 데이터로 최신 상태가 아닌 경우 중요하지 않습니다.
API 뒤에이 액세스 권한을 설정하고 추상화 뒤에서 캐싱을 숨겨야합니다. 그런 다음 다른 캐싱 전략을 사용하거나 매번 코드의 나머지 부분을 다시 작성하지 않고도 캐싱 아이디어를 버릴 수 있습니다.
귀하의 생각은 그렇게 나쁘지는 않지만, 개인적으로 캐싱 솔루션을 찾으러 갈 것입니다.
데이터가 변경 될 때마다 재 컴파일/재배포해야한다고 말하는 사람들은 무시하십시오. 정적으로 무엇을 의미하는지 이해하지 못하기 때문입니다. 즉, 소스에 값을 하드 코딩 할 것입니다.
다시 한 번, 당신이하는 일에 따라 이것은 괜찮을 수 있습니다. 서버 유지 관리/종료의 경우 HashMap에있는 것을 유지하는 몇 가지 방법이있는 한.
필요한 것은 직렬화 방법뿐입니다. 위에서 XStream이 언급 된 것을 보았습니다.
Prevayler이라는 라이브러리가 있습니다. 이렇게하면 변경 사항이 순차적으로 순차 화되지만 모든 것을 메모리에 유지할 수 있습니다. 따라서 갑자기 정전이 발생해도 제대로 종료 할 시간이없는 경우이 방법이 유용 할 수 있습니다.
다른 방법으로 실험 해보고 DAO 뒤에서 세부 정보를 추출하십시오.
+1 데이터베이스는 모두 관리에 관한 것입니다. RDBMS 관련 데이터베이스 관리 시스템이라고는하지 않습니다. 항상 읽기/쓰기 트랜잭션이 없으면 데이터베이스를 메모리 구조로로드하면 속도가 크게 향상 될 수 있습니다. DB가 일주일에 한 번만 업데이트되는 회사에서이 작업을 한 번했습니다. –