- 현재 우리의 데이터 : 약 2000만건 - 연간 증가량 : 약 300만건 - 2xlarge 로 소화 가능한 데이터 건수 = 3200만건 첫번째 계획은 현재 데이터 기준으로 400만건씩 medium 또는 large 5대로 쓰고 데이터가 증가하면 medium 또는 large로 scale out 을 하려는 계획이었다. 하지만 2xlarge가 될때까지는 scale out은 안되고 scale up만 가능하다고 한다. 거기까지는 OK. 그럼 4년간 2xlarge를 쓰다가 5년째에 medium으로 scale out 해야겠다로 계획을 바꿨었다. 하지만 2xlarge에서 scale out 할때에 작은 사이즈로 scale out이 되는건 아니고 첫번째 인스턴스와 같은 사이즈(=2xlarge)로 scale out이 된다..
1. 데이터 포맷 - Date : NVL2(CRT_DT, TO_CHAR(CRT_DT,'YYYY-MM-DD"T"HH24:MI:ss.')||'000Z', '') AS CRT_DT, - 그외 필드들은 Null이 아니면 문제 없었던듯 2. 업로드용 json 파일 만들기 JSONArray list = new JSONArray(); for(TestVO testVO : testList){ ObjectMapper objectMapper = new ObjectMapper(); // null인 필드가 있으면 업로드시 오류 발생! objectMapper.getSerializationConfig().setSerializationInclusion(JsonSerialize.Inclusion.NON_NULL); JSONObject..
우리가 cloudsearch를 선택한 이유는 - 검색엔진은 만들줄 모르지만 검색엔진이 필요하다. - 사내 시스템에서 사용할거니 검색이 된다면 특별한 기능들은 없어도 된다. 30일 무료 평가판 사용중 Amazon CloudSearch 검색 인스턴스 총 750시간 문서 배치 업로드(각 배치 최대 크기는 5MB) 10,000건 IndexDocuments 요청 10건 무료 평가 프로그램은 30일 후에 만료되거나 무료 사용량 한도에 도달하면 만료됩니다(먼저 해당되는 조건이 적용됨).
AWS에는 Cloudsearch와 Elasticsearch service 두가지의 검색 서비스가 있습니다.두가지를 비교해보겠습니다. 바탕은 거의 같다Solr와 Elasticsearch 모두 루씬(Lucene)이라고 하는 검색 엔진을 베이스로 하고있어 검색에 관한 기능이 대체로 유사한 것 처럼CloudSearch와 Elasticsearch service도 거의 비슷한 기능을 합니다. CloudSearch는 베이스 엔진을 명시하고 있지는 않지만루씬(Lucene)의 쿼리 파서를 사용할 수 있다던지, 이용되는 형식이 거의 유사하기 때문에 대부분 루씬을 참고로 하고 있다고 생각됩니다. CloudSearch의 강점 뭐니뭐니해도 Full Managed Service 라는것이 CloudSearch를 사용하는 가장 큰 ..
- Total
- Today
- Yesterday
- Big xml 파싱
- OneToMany
- iTerm
- cloudsearch 비용
- aws cloudsearch
- timestamp
- 엘라스틱서치
- JPA
- ojdbc7
- oracle12
- JPA 오류
- 계층형
- StAX
- org.hibernate.LazyInitializationException
- 단축키
- Python
- tomcat
- JoinColumn
- Elasticsearch
- db connect
- could not initialize proxy - no Session
- CloudSearch
- 서버 환경변수
- getdate
- #csvreader
일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | ||||||
2 | 3 | 4 | 5 | 6 | 7 | 8 |
9 | 10 | 11 | 12 | 13 | 14 | 15 |
16 | 17 | 18 | 19 | 20 | 21 | 22 |
23 | 24 | 25 | 26 | 27 | 28 |