컬럼 2300개 정규화 점 해줭 ㅇㅅㅇ

[♨2.91™(roidz)]

그냥 이것 저것 개나 소나 생산하는 로그에서 뽑아내는거임
ㅇㅅㅇ

빅데이타는 그 똥들과 쓰레기들을 아주 소중하게 여겨서
하나 하나 정성들여 보관하는 것 같앙
ㅇㅅㅇ

[sloth(218.147)]

분석용이고 이 분석이 문자열로 로그를 찾는건지 어그리게이션해서 계산하는게 목적인지는 모르겠지만 일단 한번 전처리해서 record또는 array로 묶을수 있는지 보는게 조을거같아요 - dc App

[sloth(218.147)]

저장소는 칼럼스토어여야 할테고 실시간 요건이 있었던걸로 하둡이라 그러셨으니 hbase에 cf로 잘 묶고 어그리게이션이나 필터링 조건에 따라 row key 잘 만드셔야 되고 만일 임의의 필드나 문자열 검색이 필요하면 - dc App

[sloth(218.147)]

아시듯 es 박에 없는데 얘도 1000개 까진가 박에 필드 지원 안할거고 노드당 16기가 정도해서 다 올릴수 있는 데이터 사이즈인지도 봐야하구요 - dc App

[♨2.91™(roidz)]

ㅇㅅㅇ

[♨2.91™(roidz)]

목적은 둘 다 ㅇㅅㅇ

[sloth(218.147)]

검색이 문제인데 es 가 필드수의 디폴트 맥스 값이 1000개고 더 많게 설정은 가능할텐데 그렇게 써보지를 않아서 잘 돌진 모르겠어요 - dc App - dc App

[♨2.91™(roidz)]

저장소는 apache ignite이고 백업은 하둡 ㅇㅅㅇ 오늘 gridgain 담당자와서 물어보니 1만 컬럼 쓰고 있는 곳도 있다고함 ㅇㅅㅇ

[sloth(218.147)]

제가 ignite를 써본적이 없어서 모르겠는데 문서를 보니 칼럼 오리엔티드는 아니고 key value 스토어에 snap tree 인덱스 지원하네요 사실 말씀만 들어봐서는 베스트 옵션은 아닐거같이 보이지만 (물론 제가 요구사항을 모르지만은) 이미 얘만도 메모리 먹는 하마라 또 다른 메모리 먹는 hbase니 es니 하는 - dc App

[sloth(218.147)]

메모리 먹는 애들 또 올리긴 힘들거 같네요 제가 ignite를 안 써보기도 했고 요구사항도 전혀 몰라서 사실 요구사항엔 이그나이트가 베스트 옵션인데 제가 모르는것일수도있구요 ㅎㅎ 신규 도입이 아니고 이미 운영 담당자가 있으시면 노하우가 있으실테니 잘 마무리되기를 바랍니다!! - dc App