단일 제품으로 row & column , 아키텍처로는 A-A, A-S, Share nothing 형태로 구성이 가능합니다.
업무 연관성이 있다면 동일한 곳에, 연관성이 적다면 분리를 추천드리겠습니다.
사용 -> 상용 ^^
클라우드로 전환하는 이유가 부하가 몰릴 경우 자동 scale up 또는 scale out 이 되서 부하를 분산하게 됩니다. 이럴 경우 사용 DBMS 는 라이센스 이슈가 발생하게 됩니다. 이런 이유로 클라우드로 전환이 되면서 오픈 DBMS 증가는 어느 정도 예상됩니다.
유익한 시간이 되셨다고 하시니 감사드립니다.
DBMS 밴더마다 옵티마이저 특성이 있습니다. 대부분 통계를 기준으로 액세스 플랜을 만드는데... 대부분의 경우는 신뢰를 할 수 있으나, 일부 비정상적인 plan 에 대해서는 약간의 튜닝이 필요할 수 있습니다.
업종에 따른 분류 보다는 용도에 맞는 분류가 적절하리라 생각이 되구요. 업무 적으로 critical 하거나 할 경우는 상용을 사용하시는 맞을 듯 하구요. 중요도가 떨어지거나, 장애에 따른 빠른 복구가 필요하지 않을 경우라면 오픈 dbms 도 적절하리라 생각됩니다.
컬럼형 테이블의 경우는 성능을 위해 apend 형태로 저장이 됩니다. 따라서 row 테이블은 해당 데이터 블럭을 찾아서 값을 직접 update 수행하나, 컬럼 테이블의 경우는 update는 기존 데이터 삭제 후 insert 하는 형태로 작동하게 되어 update 가 속도 면에서 느려지게 됩니다.
데이터 보안은 SW 방식(plugin, API)로 구현하거나, 스토리지 자체를 암호화하는 방식이 있습니다. SW 방식은 특정 컬럼 또는 데이터를 암호화하여 저장하고, 이를 복호화함으로 성능 이슈가 발생할 수 있으나, 스토리지 암호화의 경우는 이 과정은 없으나, 데이터는 가독한 형태로 보입니다. 단, 스토리지가 유출이 되더라도 해당 데이터가 노출되지는 않게 됩니다.
백업 및 복구 속도는 결국 스토리지 용량에 비례하게 됩니다. 또한 I/O가 많아질 경우 처리 속도에도 영향을 주게 됩니다. IBM Db2는 OLTP 환경에서도 압축 형태(데이터, 인덱스, 트랜잭션로그)로 성능 저하 없이 운영되고 있으며, 이로 인해 백업 및 복구 속도도 개선이 됩니다.
이커머스 사이트 뿐만이 다양한 분야에서, IBM Db2 경우 단일 제품으로 OLTP 및 분석 (DPF - Shared Nothing 또는 Columnar 형태) 로 구성이 가능합니다.
일반적인 마이그레이션은 테이블 단위 1:1 로 이루어지며, 이 경우 건수 및 수치 데이터의 경우 연산(MIN, MAX, AVG 등..)으로 검증이 이루어지나, 테이블 형상이 변경이 되거나, Biz 요건이 변경되는 경우라면 이행팀 자체 검증만으로는 전수 검사할 수 없으며, 업무 담당자 분들의 주요 업무에 대한 검증 SQL을 제공해주시면 이를 통한 추가 검증을 진행하고 있습니다.
클라우드는 처음이라... 데이터는 일반 운영데이터를 적재 분석 및 시각화를 하게 되는건가요?