기본 콘텐츠로 건너뛰기

7월, 2020의 게시물 표시

ORACLE서버간 복사를 위한 팁들..

오라클은 sql을 실행하여 DDL SQL을 만든다거나 하는 것들이 가능한데 문제는 파일로 저장하면 애매한 부분에서 줄넘김이 되면서 에러를 발생시킨다.  이번에 이동해야 하는건 테이블만 12만개나 있어서  하나식 보면서 할 수가 없어 찾아보니.. 여러가지 옵션들이 있어  내 나름대로 정리해 봤다.  #get_ddl.sql set  long  100000 set  head  off set  feed  on set  wrap  on set  linesize  3200 set  pagesize  0 set  trimspool  on set  longchunksize  1024 spool insertout.txt select dbms_metadata.get_dll('TABLE', 'MyTablename', 'MyOwner'); exit long : 한 필드에 표시되는 문자 수. 적으면 내용이 중간에 잘린다.  head off : 필드명을 없앤다.  feed on : 한 필드 내의 줄넘김을 표시한다. off면 한줄만 표시되면서 다음 줄 이후는 잘린다.  wrap on : ?? 기억이;; linesize 3200 : 한 줄에 3200글자까지 지원.. 이게 작으면 오른쪽이 잘린다.  pagesize 0 : 한 줄에 표현하는 페이지.. 숫자가 커도 별로 의미 없이 공백만 생기므로 0으로 설정 trimsppo on : 이건 그냥 붙여봤는데 아직 테스트 안함. lognchunksize 1024 : 오른쪽 글자 잘림을 막아줌(linesize가 있어도 잘리는 경우 이것까지 넣으니까 다음줄로 안넘어가고 옆으로 잘 붙어준다.) spool filename.sql : filename.sql 파일로 출력해준다.  이렇게 처리하면 sql만 들어가기 때문에  echo "exit" >> filename.sql  등으로 exit을 넣어줘야 cli로 실행하는 경우 먹통이 되지 않는다.  Procedure, Function을 복사하

NLP를 위한 LDA등을 사용한 문서 정리 및 검색을 위한 머신러닝 방법론

코드를 공부하는 글이 아니므로  샘플 코드등은 없으니  코드를 찾으시는 분들은 패스하셔도 됩니다.  개념 적인 접근, 그리고 사용법은 아는데  추가적인 돌파구를 위한  아이디어를 원하시는 분들을 위한 글입니다.  대부분 도큐먼트(글뭉치?)의 의미를  한 눈에 캐치하여  인덱싱하여  도큐먼트를 관리하기 위해  Topic Modeling을 사용하려 하고 있습니다.  하지만 단순히 LDA를 사용해봤자,  사용된 단어의 개수가 많은 글들끼리의 묶음 정도로 밖에 분류가 안됩니다.   https://en.wikipedia.org/wiki/Latent_Dirichlet_allocation LDA : 잠재적 디리클렛 배분법 google스러운  정보의 정리를 위해서는 하나만 사용하는 것이 아니라  다양한 ML모듈을 활용해야 하는데요..  예를 들어 이렇게 합니다.  LDA모듈로 문장을 읽어내면 단어의 기본형과 Document에서 사용된 단어수가 나오고 이를 기반으로 이 document의 topic에 해당할 법한 상위 단어들이 표시됩니다.  여러 document를 던질 수록  각각의 document그룹에서  사용된 빈도가 높은 단어들이 나옵니다.  여기서 topic이 다른 문서가 많이 섞일 수록 topic을 유추하는 확률이 많이 떨어집니다.  그리고 언어가 여러 언어일 수록  서로 모르는 언어가 되버리고 마는 것이지요.  여기서 제가 많이 사용하는 방법은,  모든 언어를 영어로 번역합니다.  google translate API는 무료로 소량의 번역을 해주는데 만약 google sheet의 translate 함수를 사용하면  속도는 조금 느릴 수 있으나 많은 제약이 사라집니다.  뭐, 구글 어카운트를 여러개 만들어서 돌리는 것도 방법이구요.  서비스로 사용할 분이라면 유료로 구입하는 게 당연하겠지만 이렇게 블로그의 글을 보시는 분들이라면 공부 정도의 레벨이겠죠? 이렇게 영어로 번역하면  문장이 어색해도 상관없습니다.  LDA는 자주 쓰인 단어에 대한 카테고라이징을 목적으로 하는

테슬러는 전기 자동차 회사 입니다.

언제부터 테슬러가 무인 자율주행 자동차 회사가 되었나요? 우리나라 기사에서는 무인 자율 주행 자동차가 나오지 않으면 테슬러가 성립되지 않은 듯한 글이 많네요.  물론 모 기업의 주가를 방어하기 위한 사설이겠지만.. 테슬러는 전기 자동차의 구조에 많은 특허를 가지고 있습니다.  그 중에는 자율 주행에 대한 특허는 한 건도 없는 것으로 알고 있습니다.  테슬러를 이루고 있는 많은 기능(function)중에 자율 주행이 있습니다.  만약 현대 자동차가 시트를 메모리 하여 타는 사람에 자동으로 맞춰주는 기능을 개발하겠다 했다가  개발이 실패하면 현대차는 탈 수가 없는 것일까요? 광고가 과대인지 뭔지에 대해서는 전 모르겠습니다.  하지만 실제로 세일즈맨을 통한 설명과 실제 운전을 해본 결과 충분히 다른 차에서 테슬러로 갈아탈 수 있는 매력을 보여 주었습니다.  AI가 뭔지도 모르고 머신러닝이 뭔지도 모르고 어디서 주워들은 지식만을 가지고 이게 AI네 아니네 하고 끼워 맞추는 사람들이 갑자기 생각나네요.  영문 wikipedia에 글이 올라가면,  잘못 된 정보는 수많은 딴지 및 수정이 올라옵니다.  때문에 제 생각에는 실제 사전보다 진화하는 최신의 정보를 올리는 사전으로 신뢰도가 높다고 봅니다. (로컬 wikipedia는 그 언어 사용자에게 특화되어 신뢰도를 보장하긴 어렵지만) 때문에 최소한 서로 대화를 하기 위해서 사용하는 단어에 대해서는  사전이나 wikipedia(네OO 아닙니다!)를 서로 보면서 그 단어에 대해 인지하고 나서 얘기해야 하지 않을까요? 같은 말을 하면서 사용하는 용어의 인식이 달라 결과가 어긋나는 것을 너무 많이 보다보니 답답한 마음을 금치 못하겠네요.  테슬러는 자율 주행 자동차가 아니라 혁신적인 전기 자동차이며 자율 주행 기능을 탑재하며 그 자율 주행 기능이 발전하고 있습니다.  giip :: Free mixed RPA orchestration tool!  https://giipasp.azurewebsites.net/

요즘은 아키텍트(Architect) 되기가 더욱 힘들어진 거 같아요.

얼마전 aws위에서 mongodb를 올려서 서비스를 구성한 구성표를 보았다.  이 구성표를 만든 팀은 예전에 내가 도와준다고 했을 때 이미 많은 서비스를 mongodb를 이용해서 서비스 했다고 자만하던 팀이라 그냥 지켜보기로 했던 팀이었다.  2Core/4GB의 mongos 2대가 서비스 헤더, 1대가 관리헤더 2Core/4GB의 mongoc 3대가 metadata, 3대가 로그의 metadata.  4Core/16GB VM을 5대를 올려서 3대를 mongod를 올리고 2대를 서비스로그를 저장하도록 구성 했다.  물론 세세한건 보지 않았지만,  당연히 EBS가 30GB이니 30GB모두 하나의 shard로 하여 1 shard 3 replica 이지 않았을까? 안에서 추가로 쪼개기에는 EBS사이즈가 작으니.. 개발 서버 포함 총 15대의 VM으로 구성된 예상비용은 월 약1200달러.  이것을 26대로 늘리고 월 약 1100달러로 줄이는 설계를 보여줬다.  그리고 성능은 기존의 약 6배. 비용으로 환산한다면 월 7200달러 어치의 성능을 1100달러로 보여준 것이다.  AWS HW의 특성상 IOPS성능이 일반 HW보다 1/5 수준으로 떨어지는 것을 어떻게 메꿀 수 있는지가 중요하다. 특히나 EBS가 SSD라고 할지언정 물리적으로 연결되어 있는 디스크가 아닌 이상 Storage Network의 처리 성능이 가장큰 병목이 발생한다. (AWS 및 Storage를 Network로 연결하는 클라우드 아키텍쳐는 모두 같은 문제) 그리고 AWS의 특성상 1vCPU는 1Core가 아니다. 예전에는 1vCPU의 성능 수치가 있었지만 지속적인 하드웨어 추가로 인해 기존 하드웨어와의 CPU모델이 달라져 성능이 다르게 나오고 있어 이 지표는 사라졌다. 1vCPU의 성능이 얼마만큼 나오는지를 이해하여야 한다.  그 다음으로 Virtualization의 성능(Para-virtualization, Full virtualization)에 따른 퍼포먼스 저하가 얼마나 일어나는지, Linux라는

Excel의 버그인가? 이미 열린 파일이 null이 되거나 두 개 열면 문제가.. - UiPath RPA

MS의 저주일지도 모르지만,  역시 윈도우에서 발생하는 버그는 상상을 초월한다.  많은 부분을 Exception을 처리해도 알 수 없는 오류가.. 이번에는 Excel을 두 개 열어서 A파일의 S시트를 B파일로 복사해서  데이터를 그 포맷에 Write Range 로 쓰도록 하였다.  A파일의 S시트는 템플릿이 아니고 현재 사용하는 시트이다 보니 데이터가 있다.  그래서 Delete Range를 이용해서 삭제를 하니.. 에러가.. Excel Application Scope를 여러개 열면 뭔가 충돌이 난다.  그래서 이번에는 close workbook을 이용해서 매번 닫도록 해봤다.  그런데도 역시 Delete Range에서 알수없는 오류로 종료... B파일의 Excel Application Scope를 열어서 그 안에서 A파일의 Excel Application Scope를 열고, Copy -> Delete -> Write를 해보았다.  역시 에러.. 이번엔 분기를 해봤다.  Copy하는 경우는 Delete를 하지 않고,  Copy하지 않는 경우는 Delete를 하고..  기존 시트명이 있는 경우만 데이터를 삭제를 하는 방식이다.  이렇게 하니까 Delete Range는 성공 했으나 몇 개 실행하다보니 Excel workbook이 닫히지 않기 시작하면 다음 처리에서 에러가 발생..  두 개이상 workbook이 열리면 Write Range나 Delete Range에서 해당 파일을 찾지 못하는 것 같다.  결국 마지막 부분에 close workbook을 하여 강제로 죽여주니까 성공.. 그냥 놔둬도 닫히지만 안닫힐 때도 있는 경우에 따른 변수가 생겨서 close workbook의 타이밍에 따라서 에러가 나오기도 안나오기도 하네.. 윈도우즈의 버그는 ...  익셉션 처리하는게 코드 짜는 거보다 많은 거 같다.. -------- 추기1.  나중에 해보니 똑같은 에러가 빈도는 줄었지만 또 났다.  그래서 시도한 것이, Excel이 열리지 않은 경우는 workboo

태양광 패널의 필수품 solar power regulator - PWM vs MPPT - Power logistics를 만든다!

전기차를 전기 생산이 어려운 곳에 여러 대를 가져가서 연결하여 발전기 대신 사용하는 기술이 나왔다.  일본의 전기/하이브리드 자동차는 전체 자동차 시장의 이미 87%를 넘어서고 있다.  전기 자전거는 이제 일반화 되어 일반 자전거와 큰 가격차이가 안나고 있다.  배터리 기술이 발전하면서 전기에 대한 활용도가 점점 높아지고 있는 와중에 캠핑, 여행 등에서 필요한 전력 공급을 살펴보는 도중 태양광 패널에 관심을 가지기 시작했다.  참고로 태양열 발전은 보일러가 있고, 태양광선을 보일러에 집중시켜 보일러를 덥혀서 증기 기관을 돌리는 방식이고, 태양광 발전은 전극소자에 태양광을 집중시켜 발생한 전하의 흐름을 캐치하여 충전하는 방식이다.  즉, 사람들이 태양열.. 이라고 하는 것의 대부분은 태양광 발전을 뜻한다.  태양광 발전을 효율적으로 축전 시키는 컨트롤러가 필요한데 이 컨트롤러(Solar power regulator)는 MPPT방식과 PWM방식이 현재 가장 널리 쓰이고 있다.  그럼 태양광 패널을 직접 배터리에 붙이면 안되냐고? 배터리에 역류 방지 및 과충전 방지 회로(BMS, Battery Management System)가 있으면 문제는 없다. 만약 없는데 직접 연결한다면 리튬이온 배터리의 위험성을 몸소 체험할 수 있다.  충전 컨트롤러 방식을 소개하는 글은 아주 많은데,  초보자도 알기 쉽게 소개하는 글은 하나도 보이지 않고, 그냥 이게 좋다 라던가, 어려운 회로도만 어디서 퍼와서는 내용은 아무것도 없는 글이 많다.  초보자도 알기 쉽게 설명을 하자면 PWM(Pulse Width Modulation)은 충전가능한 전압으로 낮추면서도 전류는 그대로 유지하는 불필요한 전압을 버리는 방식이다. 굳이 단어의 의미를 이용해서 이해하려 하지 말자.. MPPT(Maximum Power Point Tracking)은 DC-DC 인버터가 내장되어 있어 전압을 떨구면 자동으로 전류가 강해지는 변압코일의 특성을 살린 부품이 추가로 들어 있어 가격이 비싼대신에 전압이 떨어져도 전

필드명 지정없이 For Each로 csv나 xlsx를 json으로 변환 - UiPath

정리는 시간나면 하고.. 일단 생각나는대로 적어둠. VBS에서는 for each를 이용해서 필드명을 가져오는 방법등이 있었지만 이는 원래 Recordset등의 필드명이 지정되었을 경우에만 해당한다.  datatable을 vbs에서 어떻게 for each로 만들지는 아직 연구하지 않았기 때문에 일단 패스, 아마 csv에서 첫 행을 헤더로 읽거나 xlsx에서 첫 행을 header로 읽으면 가능할 듯 하지만,  쉬운 방법으로 일단 기술해 본다.  ## csv의 경우 파일을 header있음으로 우선 datatable에 저장. 그리고 다시 파일을 text읽기로 하여 첫 로우만 변수로 저장. 저장된 변수를 sFields라고하면 aryFields = split(sFields, ",")  로 assign activity에 집어 넣음 물론 aryFields의 속성은 text속성의 array 타입 그리고 각 필드의 전후에 스페이스를 없애기 위해  Trim을 사용해서 스페이스를 없애줌. replace로 먼저 없애고 split을 하는 것도 가능. 그리고 datatable의 for each row 를 이용하여  매 row마다 for each로 aryFields를 호출(for each에서 row를 가져오면 안됨!) jLine = jLine + """" + item.toString + """:""" + row(item).toString + """" 이렇게 하면 필드 개수를 모르더라도 한 라인을 Json타입으로 가져올 수 있음.  물론 좌우는 {}를 적절히 넣어주고, 콤마도 적절히 if를 이용해서 넣을 것.  row(item).toString이 숫자인 경우의 처리는  Microsoft.VisualBasic.Information.IsNumeric 을 이용하여 판단 가능.  VBScript를 선택하였다 하더라도 MS Visual Basic과는 코드가