제2회 열린세미나 100도씨의 발표자료입니다.
Unique Count를 구하기위한 몇가지 특징과 자료구조등을 정리한 발표자료입니다.
* 열린세미나 그룹
https://www.facebook.com/groups/576473599127259/
* 블로그
http://blog.indf.net
제2회 열린세미나 100도씨의 발표자료입니다.
Unique Count를 구하기위한 몇가지 특징과 자료구조등을 정리한 발표자료입니다.
* 열린세미나 그룹
https://www.facebook.com/groups/576473599127259/
* 블로그
http://blog.indf.net
[ http://infiniflux.com/download ]
The world's fastest time series DBMS.
What is InfiniFlux?
1) InfiniFlux is a time-series database which performs real-time data processing, i.e., data are inserted at high speed, retrieved and analyzed without elapsed time.
2) InfiniFlux also compresses and stores data in real-time. Its query language and syntax complies with the SQL standard. The extended SQL syntax provides additional features such as the text search tool.
사례로 알아보는 MariaDB 마이그레이션
현대적인 IT 환경과 애플리케이션을 만들기 위해 우리는 오늘도 고민을 거듭합니다. 최근 들어 오픈소스 DB가 많은 업무에 적용되고 검증이 되면서, 점차 무거운 상용 데이터베이스를 가벼운 오픈소스 DB로 전환하는 움직임이 대기업의 미션 크리티컬 업무까지로 확산하고 있습니다. 이는 클라우드 환경 및 마이크로 서비스 개념 확산과도 일치하는 움직임입니다.
상용 DB를 MariaDB로 이관한 사례를 통해 마이그레이션의 과정과 효과를 살펴 볼 수 있습니다.
MariaDB로 이관하는 것은 어렵다는 생각을 막연히 가지고 계셨다면 본 자료를 통해 이기종 데이터베이스를 MariaDB로 마이그레이션 하는 작업이 어렵지 않게 수행될 수 있다는 점을 실제 사례를 통해 확인하시길 바랍니다.
웨비나 동영상
https://www.youtube.com/watch?v=xRsETZ5cKz8&t=52s
어느 해커쏜에 참여한 백엔드 개발자들을 위한 교육자료
쉽게 만든다고 했는데도, 많이 어려웠나봅니다.
제 욕심이 과했던 것 같아요. 담번엔 좀 더 쉽게 !
- 독자 : 백엔드 개발자를 희망하는 사람 (취준생, 이직 희망자), 5년차 이하
- 주요 내용 : 백엔드 개발을 할 때 일어나는 일들(개발팀의 일)
- 비상업적 목적으로 인용은 가능합니다. (출처 명기 필수)
Cloud DW technology trends and considerations for enterprises to apply snowflakeSANG WON PARK
올해 처음 오프라인으로 진행된 "한국 데이터 엔니지어 모임"에서 발표한 cloud dw와 snowflake라는 주제로 발표한 내용을 정리하여 공유함. (2022.07)
[ 발표 주제 ]
Cloud DW 기술 트렌드와 Snowflake 적용
- Modern Data Stack에서 Cloud DW의 역할
- 기존 Data Lake + DW와 무엇이 다른가?
- Data Engineer 관점에서 어떻게 사용하면 좋을까? (기능/성능/비용 측면의 장점/단점)
[ 주요 내용 ]
- 최근 많은 Data Engineer가 기존 기술 스택(Hadoop, Spark, DW 등)의 기술적/운영적 한계를 극복하기 위한 고민중.
- 특히 Cloud의 장점과 운영 및 성능을 고려한 Cloud DW(AWS Redshift, GCP BigQuery, DataBricks, Snowflake)를 고려
- 이 중 Snowflake를 실제 프로젝트에 적용한 경험과 기술적인 특징/장점/단점을 공유하고자 함.
작년부터 정부의 데이터 정책 변화와 Cloud 기반의 기술 변화 가속화로 기업의 데이터 환경에도 많은 변화가 발생하고 있고, 기업들은 이에 적응하기 위한 다양한 시도를 하고 있다.
그 중심에 cloud dw (또는 Lake house)가 위치하고 있으며, 이를 기반으로 통합 데이터 플랫폼으로의 아키텍처로 변화하고 있다. 하지만, 아직까지 기존 DW 제품과 주요 CSP(AWS, GCP, Azure)의 제품군을 다양하게 시도하고 있으나, 기대와 다르게 생각보나 낮은 성능 또는 비싼 사용료, 운영의 복잡성으로 인한 많은 시행착오를 거치고 있다.
이 상황에서 작년에 처음 검토한 snowflake의 다양한 기능들이 기업들의 고민과 문제를 상당부분 손쉽게 해결할 수 있다는 것을 확인할 수 있었고, 이를 이용하여 실제 많은 기업들에게 적용하기 위한 POC를 수행하거나, 실제 적용하는 프로젝트를 수행하게 되었다.
본 발표 내용은 이러한 경험을 기반으로 기업(그리고 실제 업무를 수행할 Data Engineer) 관점에서 snowflake가 어떻게 문제를 해결할 수 있는지 cloud dw를 도입/활용/확장 하는 단계별로 문제와 해결 방안을 중심으로 설명하였다.
https://blog.naver.com/freepsw?Redirect=Update&logNo=222815591918
5. 5년 전 저는 해양 관련 IT 시스템을 개발하게 되었습니다.
- 해상에서 수신되는 선박의 위치,
해양기상,항해 표지 정보를
실시간으로 수집하여 전자해도위에
표출 되는 시스템
- 시기적으로 조금씩 다르긴 하지만
데이터가 너무 많이 쌓이기 때문에
한달에 한번씩 데이터를 삭제해야
할 정도 였음
- 점점 관련 시스템이 늘어나서
시스템 마다 각각의 요구사항을
반영하기 위해 뷰를 만들게
되었습니다.
- 자연스레 성능이슈와 튜닝해야하는
포인트가 늘어났습니다.
6. 당시의 이슈
• 예산부족으로 서버 증설 과 SW 신규구매(MS-SQL)가 불가 (성명불상의 놀고있는 서버는 몇 대 있었음)
• 데이터 스키마의 변경이 자주 이루어지고 다양한 서비스와 시스템을 위해 뷰 테이블을 다수 만들어야
했음
• 비정형으로 들어오는 데이터를 스키마로 재정의 하는 게 쉬운 일이 아니었음 (기상 정보나
레이다이미지)
• 하루에도 어마어마한 데이터의 인서트 및 업데이트가 이루어지고 있어서 데이터베이스 부하가 있었음
• C/S 시스템을 WEB으로 전환하기 위한 계획이 있었음
• 단기간의 개발기간을 고려 해야 했음
7. 엔지니어로써 의 고민
시스템을 SCALE UP(하드웨어성능을 높일것인지) 할것인지 SCALE OUT(분
산처리) 할것인지 ?
대용량 데이터가 들어 왔을 때 분산부하처리를 어떻게 효율적으로 할 것인지?
다양하고 빈번한 요구사항이 들어왔을 때 스키마를 변경할것인지 아니면
어플리케이션단위의 방안을 세워야할지?
그러면서 공간정보를 DBMS 상에서 관리가 가능해야 할 것 같다.
8. 시스템 아키텍쳐 의 문제
기존의 RDBMS 상에서도 scaleout은 가능하나 관리 와 개발 리소스가 많이 듬
9. 대용량 데이터의 처리
• 대용량 읽기쓰기에 있어서 적정한 인덱스 정책을 세우면 큰 문제 없음. 그러나 빅데이터
시대에 들어오면서 인덱싱 정책을 다양하게 세울 수 있어야 함
• 퍼포먼스를 상향하려면 분산부하처리가 가능해야 하고 디스크 기반보다는 메모리에서
처리할 수 있는 방안수립이 필요
• 대량의 반복적인 insert 동작의 사용이 있는 경우 operation 장애가 없어야 함
10. 다양한 요구사항에 대한 대응
• 스키마 변경에 대하여 계속적인 작업은 결국 IT 시스템의 질저하로 이어짐
• XML, JSON 등은 이러한 스키마 변경에 대한 적절한 대안
{
"name" : “aliasgis",
"age" : 45,
“job" : “Developer“
}
{
"name" : "David Oh",
"age" : 24,
"major" : "Japanense“
}
12. MONGODB란
• mongoDB는 C++로 짜여진 오픈소스 데이터베이스이다. 문서지향(Document-Oriented)적이
며 뛰어난 확장성과 성능을 가지고 있음
• NOSQL 기반이며 문서기반의 데이터 베이스 구조를 가짐
• 다양한 인덱싱을 제공하며, AUTOSHADING 기능을 제공하여 자동으로 데이터를 분산하여
저장하며, 하나의 컬렉션처럼 사용가능
• 간단한 설정만으로도 데이터 복제를 지원. 가용성 향상.
• Commercial Support : 10gen에서 관리하는 오픈소스
• 기본적인 공간정보 기능을 지원
14. MONGODB의 사용시 기술적고민
• NOSQL 기반이므로 기존의 SQL Query를 바꿔야 한다.
학습의 양이 그리 많지는 않음. 오히려 코딩은 간결해짐 (Query문 xml file로 별도관리하거나
stringbuffer를 사용하는 것보다는)
사실 부딪혀보면 해결된 문제 (SQL 문과 유사함)
관리자 들이나 개발자들이 보수적인 개발문화를 가지고 있다면 어려울 수도
• 공간정보 의 기능을 잘 지원 할 수 있는가?
여타 DBMS 에 비해 공간함수가 많이 부재 한 것은 사실
허나 요구사항과 비교해 보았을 때 적정하면 사용가능
15. 다른 NOSQL기반 DB와의 비교
종류 장점 단점
Cassandra -대량으로 쓰기가 발생하는 서비스에 좋음
-확장성이 뛰어남
- Scale-Out 원활함
-최소 3대 이상 구성(클러스터 환경)
-복잡한 조건 검색 불가
-데이터 갱신 및 입력시 Atomic한 처리가 힘듬
Mongodb -스키마 없이 사용 가능
-1분 단위로 Flushing하는 Write back 방식을 사
용하므로 Write 성능 강함
-Read시에는 memory mapped file 방식차용 하
여 신속한 검색속도
-다양한 기능 제공
-JOIN이나 트랜잭션 처리가 불가능
-디스크에 쓰기가 비동기식으로 이루어진다. 경우에 따라
데이터가 유실될 가능성도 있다.
HBase -하둡 기반에서 동작하고 다양한 하둡 의
도구들과 상호 운영성이 좋음
-데이터 일관성 보장 우수(상대적)
-5대 미만에서는 사용할 수 없다(대규모 전용)
-성능이 좋진 않다 (상대적)
17. MONGODB는 RDBMS와의 비교하여 퍼포먼스를
어느정도 낼 수 있는가?
속도 MONGODB(index) POSTGIS(index) MS-SQL(index)
POINT(1000개당 연산속도:단위 ms) 16(14) 23(22) 24(23)
POINT(2000개당 연산속도:단위 ms) 43(26) 47(43) 48(44)
POINT(10000개당 연산속도:단위 ms) 101(93) 187(167) 192(189)
POLYGON(10000개당 연산속도: 단위
ms)
13907(9174) 12983(9090) 12401(11404)
- 다른 RDBMS 와 비교 하였을 때 비교우위에 있는 항목도 많음 (동일서버/OS 에서 테스트)
18. 3. 익힘의 단계
- 공간정보추가/조회
- 공간연산 및 공간인덱싱
- 오픈소스 제품과의 연동
19. 공간정보 추가/조회하기
• 애초에 모든 문제 중 가장 큰 문제는 mongodb에 공간정보를 insert하고,select 할수있는냐 가 관건이었으나
NOSQL 기반 하의 Geojson 포맷으로 서비스가 가능 했음
Example) scheme명칭.command
db.ogckoreaplaces.insert({ name: '부경대 대연캠퍼스', location: { type: 'Point',
coordinates: [
129.103065834, 35.13478282
]
}
})
21. 공간연산
POSTGIS 나 다른 여타 DBMS 에서 지원 하는 공간연산 기능 중 within,
intersect 등을 지원(4가지)
1) $geoIntersects =ST_INTERSECTS
2) $geoWithin = ST_WITHIN
3) $near = ST_ClosetPoint
4) $nearSphere = ST_3DClosetPoint
22. 공간연산
POSTGIS 나 다른 여타 DBMS 에서 지원 하는 공간연산 기능 중 within,
intersect 등을 지원(4가지)
1) $geoIntersects =ST_INTERSECTS
2) $geoWithin = ST_WITHIN
3) $near = ST_ClosetPoint
4) $nearSphere = ST_3DClosetPoint
23. 공간표현방식
• $box: 좌표 쌍을 사용하여 사각형 상자를 지정
• $center: $geowithin의 평면형상 함수 사용시에 쿼리 할 중심점과 원을 지정
• $centerSphere : $geowithin의 구면형상 함수 사용시에 쿼리 할 중심점과 원을 지정
• $geometry : geojson 형식의 모든 형식을 표현
• $polygon: 좌표정보들을 다각형형태로 표현
• $maxdistance
• $mindistance
25. 공간인덱스는 지원하나?
• 2dsphere 인덱스라는 방식을 지원 함
• 인덱스가 있는 필드는 항상 좌표 쌍 혹은 Geojson 방식의 데이터가 있어야 함
• 모든 Geojson 객체 타입에서 사용이 가능 함 (버전 2.0 이상)
• 사용방법은 매우 자동화되어서 MBR 바운더리 계산도 필요없음
db.collection(객체명).createIndex( { <location field> : "2dsphere" }
26. 거리연산
최대 거리 및 최소거리 두가지를 함수로 지원 함(기본은
- $maxDistance
- $minDistance (2d Sphere 인덱스속성이 있어야만 사용가능)
{ $nearSphere: {
$geometry: { type: 'Point’,
coordinates: [126.86611, 36.114444] },
$maxDistance: ,
$minDistance: } }
27. 오픈소스를 활용한 연동
• DBMS 상에서 공간정보를 다룰 때 두가지 의 고민
- 어떻게 파일을 DB로 전환 시킬 것인지?
- 서비스는 어떻게 해야 할지
- 사실 다른 DBMS에 비하여 지원은 부족하나 길은 있음
28. 오픈소스를 활용한 연동
• 사실 Geojson 타입이어서 쉽게 mongodb 플러그인 이나 3rd party tool 이 많
을 것으로 생각되나 의외로 잘 지원 되지 않음
• QGIS 에서 도 직접적인 연결은 되지 않으나 Pyqgis 코드를 활용한다면 연결은
가능
• Geoserver는 전용 플러그인이 존재 하므로 연동이 가능
• openlayers 의 경우 geojson 을 drawing 가능하므로 연동이 가능
29. SHP 파일을 MONGODB에 적용하기 위한 팁
1. Ogr2Ogr 에서 Geojson 으로 바꿈
$ ogr2ogr -f GeoJSON -t_srs crs:84 point.geojson point.shp
2. Mongoimport 사용
C:Program FilesMongoDBServer4.2bin>mongoimport --db dev -c points --file "points.json" --
type json
2019-10-07T23:54:17.530+0900 connected to: mongodb://localhost/
2019-10-07T23:54:17.763+0900 1 document(s) imported successfully. 0 document(s) failed to
import.
3. 평면 인덱스 사용
db.sfsweeproutes.ensureIndex({"geometry":"2dsphere"})
32. MONGODB 도입 시 고려사항
• 아키텍쳐 확장은 확실히 강점으로 빅데이터 기반하의 시스템에서는 도입 고려 할 만 함
• 아직은 GIS 시스템에서 필요로 하는 공간 함수가 부족하며 THIRD Party 툴의 지원이 부족
함
• 정합성이 떨어지므로 트랜잭션이 필요한 경우에는 부적합 (ex. 금융, 결제, 회원정보 등)
-> 자주 변경이 이루어지는 데이터가 아니라면 좋은 성능 발휘
• 그러나 간단한 공간정보 관련 open API를 만들 시에는 매우 쉽게 개발이 가능 함(node.js,
spring )
• 향후에 계속적인 오픈소스 진영에 PUSH를 받는다면 좋은 무기가 될 수 있음
• 또한 공간정보 덕후 들에게는 좋은 장난감이 될 수 있음