In these days, I've been thinking, behaving with these... especially the below.


Rock bandThe picture seems like a screenshot of some video game - Rock band. But that's not what I'm trying to say, instead, now I'm a member of a real rock band.


아, 영어로 주욱 써보려 했는데,, 우리말만큼 내 생각의 속도를 따라잡지 못하기 땜시, 따라서 짱나서 걍 다시 우리말로 복귀(하하, 이 말은 - 십중팔구 여기저기 문법에 문제가 있을 - 내 영어 표현... 그 쪽팔림이 아무런 걸림돌이 안된다는 뜻이다. 그 만큼이나 면상이 두꺼워지고, 심장이 딴딴해졌다는 뜻이기도 하겠다).


먼저 음악에 대해서.


그간 걸어온 내 인생 절반에 걸쳐 원했던 band 멤버가 되었다는 것이 여기에 썰풀기 좋은 가장 큰 이벤트이겠지만,,, 그거 소개하는거,,, 귀찮기도 하고, 해야 할 당위성도 느껴지지 않고. 걍 이러한 background 하에 한 마디 하자면,

  1. Keyboard Split을 Logic Pro와 Sample Tank를 통해 이룰 것..
    • 그래야지 한 번에 두 가지의 음색을 낼 수 있겠다. 왼손은 string(Orchestra 또는 Cello)을, 오른손은 Lead 또는 piano를.
    • http://www.logicprohelp.com/forum/viewtopic.php?t=63895
    • http://www.logic-users-group.com/forums/showthread.php?t=3011 
    • 대강 각 track에 key range를 주는거 가튼데...
    • 근데 Sample Tank는 왠지 안되는거 같다.... 된다! http://anyflow.net/500 참고. 
  2. 음메, 낼까지 Song Form 5개 분석해가야는데! 뭐라 핑계대야하나.
  3. Chord Practice를 위한... 적당한 패턴 - 전체 찾기 - Jordan Rudess의 Keyboard Wizdom의 것만으론 뭔가 빠진 감이.
  4. 원맨밴드 미션 - 일단 The spirit carries on 그 담은 Beneath the surface 이거 두 개 다하면 금년 후딱 다가겠군.


그 다음은.. 안심심해지기에 대해서.

  1. 일단 음악하는거 하나로 상당 부분 커버가 되는거 가튼데, 여전히 맘속 깊은 곳에서는 불만이 자리잡고 있다.... 그 원인은 아주 잘 알렸다? 음양의 조화가 이루어지지 않았기 때문인 즉 ㅎㅎ.
  2. 현황을 써야하는 시점인데, 이건 도저히 솔찍히 까발기지 못하겠다. 추상적으로라도 적자면, 여튼 작년에 비해서라도 많이 발전한거 같다. 수없이 많은 넘어짐에도 panic 비스무리 가는거 이젠 극히 드물다. 그러다보니 시도 자체가 많아졌다. 기회도 많아졌다. 홈런도 쳐봤다. 이젠 좀 아는거 같다(그런 생각이 나니깐 아직 한참 갈길 먼 상태인 듯 보이지만). 왠간해선 안 쫀다.
  3. 그래도 boring time이 너무 많다.... ㅡㅡ;;


그 다음은... 인생 관조에 대해서.


얼어죽을. '물은 물이요 산은 산이다'란 관점에서 판단해보자면, 여전히 한참을 끝 안보이는 바다를 헤엄치고 있는 중. 걍 때려잡자면 한 30% 건너온걸까? 이 포스팅 행위 자체가 관조의 일부가 되겠지만, 인생 전체의 뼈대조차도 희미하게나마 보이지 않는다. 여전히 본능에 아주 충실하게 사는 중. 본능의 바닥은 도대체 어디일까요~?



이 포스트하려고 맘먹기 바로 전까지는,, 뭔가 모르게 생각이 많았는데.... 이들 생각은 모두 적어둘만한 무엇이다...라고 생각했는데... 정작 쓰다보니, 그 많던 생각 가닥들 중 한 3/4정도만 뽑아낸 듯. 나머지는 죄다 잊었다는 뜻이다. 뭐 좋은 방법 없나. 짭. 여튼, 요기서 끝~~!



저작자 표시 비영리 변경 금지
신고
Posted by 어쨌건간에

순서대로라면 '요즘 쓰고 있는거 리포팅, 소감 #1'의 #2가 나와야겠지만, 뭐 언제부터 내가 순서 따졌냐.

당장 쓰고 싶은대로 NoSQL부터.

NoSQL그림 별로 안이쁘다. 근데 이 것만한 그림이 구글에 안보이더라.

요즘 진행하는 프로젝트에 Cassandra를 포팅해보고 있는데, 먼저 밝히고 가야할 것 먼저.

  1. 대용량 데이터? 오우 노. 일단 global 서비스다보니 대용량이 될 가능성은 있지만, 게다가 log성 데이터이기에 또 다시 가능성이 있지만, 굳이 NoSQL을 쓸 필요는 없단게 현재의 판단.
  2. performance 이슈 가능성? 이 역시 희박. 게다가 대기업 답게 눈먼 돈이 많아서 peformace 이슈는 인프라 투자로 생각 외로 쉽게 풀 수 있다는.

그럼에도 불구하고 NoSQL을 건드리는 이유는,

  1. 현재의 화두이니깐(현재라고 말하는 것도 우스울 정도로 몇 년 지났지만, 여전히 화두임에는 의심의 여지가 없지?).
  2. 뭘 알아야 쓰건 안쓰건 선택이라도 할 수 있지.
  3. 기술이 요구를 창출하는 건 비일비재하니깐.
  4. 요즘 시간 많이 남아 도니깐.

NoSQL 솔루션 중 가장 잘나가는 듯한 형국을 보이는 Cassandra 낙점. 그 많은 솔루션 중 Cassandra를 선택한 여러 이유 중 가장 큰 건 아마도 Twitter가 Cassandra를 앞으로도 더 많이 적용할 예정이란 소리를 들어서겠지(by Ryan King of Twitter. 이외에 NoSQL 비교를 잘(?)한 요런 포스트도 있는데,, 비교를 너무 평면적으로 했다는 생각이..)


CassandraCassandra.. 그리스신화의 그녀 이름을 딴 요 센스는, Cassandra의 가장 잘 나가는 high level client인 hector의 명명에까지 영향을 미치네. 근데 난 hector를 안쓰고 그의 아들인 Astyanax를 썼다. CQL3를 지원한다는 단 하나의 이유로.

일단 컨텍스트 먼저 말하자면, 

SQL table 중 in/output이 많고도 join 등의 (쫌) 복잡 연산이 작은 두 놈을 고르고, 첨 배우는 상황이라 요 두 table scheme 모양새까지 그대로 똑같이 포팅. Cassandra의 column family란 개념은 SQL의 table과 그닥 별반 차이가 안나서리,, 용이하게. 게다가 CQL이란 SQL clone인 언어까지 제공하다보니,, 해피하게 진행. 그러다보니 사실 NoSQL을 쓴다는 설계 상 어떤 주요 특이점이 없어진 상황.


  • 실제 고민했던게,, 그럼 내가 왜 고생하면서 NoSQL을 쓰지? 란 근본적 질문까지 자문했다는. 내 초반 설계가 잘못한건 아닌게, 이렇게 시작하는 것이 그닥 틀리지 않았다는 걸 말해주는 요런 포스트가 보인다.
  • CQL을 첨부터 쓴건 아닌데, 이를 본격 쓰게 된 이유는 CQL(version 3 not 2)을 안쓰면 composite key 생성 코드가 아주 지저분하기 때문이다. Cassandra의 composite key는 SQL의 그것과는 다른데, 일단 composite key란 것은 없고, 무조건 단일 key만 수용하는데, composite key 요구에 대해서는 pivoting 비스무리한 개념을 통해 처리한다. 이로 인해 wide row란걸 권장하는 편. 자세한 건 'cassandra composite key'라 구글링하면 우후죽순으로 포스트가 떨어지니 요기선 생략.


근데,, 아니 이게 왠 일인가.


복잡하다고 전혀 말할 수 없는 Where 절의 조건 몇 개.. column 4개 정도 참조하는 그 절 처리 속도가 입이 딱 벌어지게 느린거다(사실, client에서는 connection timeout에 걸려 아예 실패를 해버렸다..).

secondary index 생성 속도가 느려서 나중가면 빨라지겠지..라고도 생각했는데, 이는 헛 생각(Cassandra는 key가 아닌 column에 조건을 걸려면 무조건 해당 column에 index를 넣어야 한다)임으로 결과 보기를 포기.


이리저리 뒤져봤지만 딱히 답이 안보여, 걍 내 설계에 문제가 있겠거니 하고 잠시 진행을 중단하고 데이터 모델을 되돌아보는 상황 ㅜㅠ.


이제부터는 그간의 깨달음(?)과 의문.

물론 아래 나열할 깨달음은 추후 update될 즉, 잘못된 깨달음일 가능성이 아주 풍부하다(내가 지금 NoSQL을 얼마나 안다고 '깨달음'씩이나 언급할까 ㅡㅡ;;).


  1. denormalization은 내게 duplication과 별로 다른 개념이 아니다(물리적 관점에서). 그나저나 denormalization한 데이터에 대한 update는 어떻게 이루어야 하나? 해당 중복 데이터의 일치성 보장은 어떻게 이루나? => 내 잠정적 결론은 update가 필요없는 데이터에만 denormalization을 적용하는 것임(Cassandra의 초창기에는 insert, delete, retrieve 연산만 있었다나? CRUD 중 Update가 빠졌다는 데에 힌트가).
  2. join은 말할 것도 없고 where 절 사용할 만한 query가 있다면 이는 잘못된 scheme design을 탓해야. 만약 design으로도 해결 못본다면 그건 NoSQL을 사용할 곳이 아니라는 뜻.
  3. query를 먼저 생각하고 scheme design을 하라는 NoSQL design practice가 보이는데(위의 링크도 마찬가지), 이 말은 NoSQL은 용도 확장성에 닫혀 있다는 뜻으로 들린다. 대강 potential과 performance/scalability를 트레이드오프한 것이라 봐도 될까?
  4. NoSQL이 그토록이나 SQL과는 다른 놈이라면, Cassandra는 SQL이나 다름없는 CQL을 도대체 왜 제공할까?(CQL 뿐 아니라 JDBC까지 제공하고 있는 형편이다!) 많은 NoSQL practice에서 SQL 설계 패턴을 잊으라는데, CQL을 제공한건 그 잊으라는 설계 방향과 완전히 반대로 나아가는 진행이다.

뭐 이리저리 질문만 많이 던지며 NoSQL - Cassandra에 대한 의구심을 잔뜩 표한 듯 한데, 이 모든 것은 무지의 소치이겠지... 하는 맘으로 더 디벼볼 예정. 어여 위와 같은 데이터 모델링 문제를 끝내고 sharding 등의 물리 설계 부문으로 나아가고픈 맘과 함께 말이다.

저작자 표시 비영리 변경 금지
신고
Posted by 어쨌건간에