우리 회사는 프런트 엔드를 설계 할 타사 웹 서비스를 제공합니다. 이 웹 서비스에서 사용되는 "객체"는 매우 크고 (생성 된 하위 엔티티의 수에 따라 다름) 웹 서비스는 전체 개체 계층 구조 만 하위 엔터티를 커밋 /로드하는 메서드를 노출하지 않습니다.웹 응용 프로그램에 큰 임시 "세션"데이터를 저장하는 좋은 방법은 무엇입니까
UI 자체는 여러 개의 하위 화면으로 나뉘며 마스터/세부 정보 뷰는 많은 양의 데이터를 효율적/쉽게 편집 할 수 있습니다.
문제는 현재보고 있지 않은 모든 데이터를 저장하는 곳입니다.
큰 레코드의 경우 웹 서비스 커밋을 수행하는 데 최대 30 초가 걸리므로 간헐적 인 데이터 저장을 위해 웹 서비스를 사용할 수 없습니다. 언급 한 바와 같이
데이터는 MS-SQL 백엔드와 (메가 바이트, 에지의 경우에 데이터의 행 가능성 기가 바이트)
이 ASP.Net 4.0이고, 상당히 클 수 있으며, 수 타사 SOAP 웹 서비스.
웹 서비스 계약 변경은 선택할 수 없습니다.
다음은 몇 가지 아이디어입니다. 선택 또는 더 나은 것을 식별하도록 도와주세요!
1) 초기 개발자가 직렬화 된 XML을 세션 (온 - 머신 세션)에 던졌습니다. 이 방법으로 세션을 사용하면 메모리 사용량과로드 균형 조정 문제 등으로 인해 성능에 큰 영향을 줄 수 있으므로이 문제를 신속하게 파악했습니다.
2) 세션 서버 - 가능하지만 추가 하드웨어를 구매해야합니다. 아마 옵션이 아닙니다
3) SQL 세션 - 큰 개체를 저장하는 성능?
4) 디스크/공유에 XML 쓰기 (압축)
5) (압축)
6) SQL 관계형 데이터베이스를 SQL에 XML 쓰기 -? 각 개체 유형에 대한 테이블을 만들 수 있습니다. 이것은 개별 서브 엔티티의로드/세이브를 허용하여 성능면에서 우수합니다. 너무 큰, 반환 한
어쩌면 json 객체 http://www.json.org/을 살펴 봐야합니다. 요즘 XML을 대체하고 있습니다. XML에 비해 간단한 표기법으로 인해 데이터 볼륨도 줄어들 것입니다. –
좋은 제안이지만 웹 서비스를 작동시키기 위해 XML 직렬화를 유지해야하므로 JSON은 두 세트의 수화 논리를 유지해야합니다.(비록 XML 부분이 대부분 자동으로 생성 되더라도). –
제목에 "세션"데이터라고 말하면이 정보는 사용자 별 정보라고 생각합니다. 그 맞습니까? –