2008년 07월 23일
오늘 검색하다가 걸린 논문 제목
'The Dilemma of Encapsulation vs. Query Optimization'. 아 죽겠다. 온갖 잡다한 정보를 화면에 보여줘야 하는데 Encapsulation에 중점을 두면 쿼리를 여러 번 해야 하고, 쿼리수를 줄이자면 Encapsulation을 깨야하고. 조인하는 큰 쿼리 한 번으로 하는게 빠른지 잔 쿼리 여러 번 날리는게 빠른지도 모르겠고. 조인하면 쿼리수를 줄일 수는 있는데 파티셔닝하면 조인도 못하고, 정렬도 별 소용없고. 그렇다고 잡다한(어디까지나 내 기준에) 정보 빼고 싶어하지도 않고. 대체 왜 화면을 빡빡하게 채우고 싶은지 이해를 못하겠다.
파티셔닝을 한다고 가정해버리면 한마디로 RDBMS 별로 쓸모가 없다. 대용량 서비스하는 딴 애들은 다 플랫폼 차원에서 이런 거 신경쓰지 않아도 되도록 해주는데(Google BigTable, Facebook Casandra, Amazon SimpleDB, Apache CouchDB, etc) 회사는 써먹지도 못하는 잡다한 기능 다들어있는 RDBMS 만든다고 몇 십 억씩 삽질하고 가관이다.
퍼포먼스 신경 끄자. 사이트 죽어나가면 그 때 문제 되는 기능 빼자고 하지 뭐. 머리가 나쁜데 손발이 고생해야지 우짜겠노. 죽어나갈 만큼 쓰면 그나마 다행이고.
차라리 여기 후원하는게 훨 효과 있겠다.
Scalaris Transactional Key/Value Store for Web 2.0 Hosting
Seattle Conference on Scalability: Scalable Wikipedia with Erlang
파티셔닝을 한다고 가정해버리면 한마디로 RDBMS 별로 쓸모가 없다. 대용량 서비스하는 딴 애들은 다 플랫폼 차원에서 이런 거 신경쓰지 않아도 되도록 해주는데(Google BigTable, Facebook Casandra, Amazon SimpleDB, Apache CouchDB, etc) 회사는 써먹지도 못하는 잡다한 기능 다들어있는 RDBMS 만든다고 몇 십 억씩 삽질하고 가관이다.
퍼포먼스 신경 끄자. 사이트 죽어나가면 그 때 문제 되는 기능 빼자고 하지 뭐. 머리가 나쁜데 손발이 고생해야지 우짜겠노. 죽어나갈 만큼 쓰면 그나마 다행이고.
차라리 여기 후원하는게 훨 효과 있겠다.
Scalaris Transactional Key/Value Store for Web 2.0 Hosting
Seattle Conference on Scalability: Scalable Wikipedia with Erlang
# by | 2008/07/23 00:07 | 트랙백(1) | 덧글(5)
☞ 내 이글루에 이 글과 관련된 글 쓰기 (트랙백 보내기) [도움말]
제목 : Scalaris 소스 공개
조 암스트롱이 얼랭 킬러 어플리케이션이 될 것이라고 한 Scalaris가 공개되었습니다....more
글을 보고 생각이 든 건데 mysql 클러스터들 전방에서 작업 중계를 해주는 것 하나 만들면 좋겠다는 생각이 드네요. BigTable이랑 구조는 유사하지만 GFS를 사용하는 대신에 mysql을 쓴다는 게 차이점이 되겠네요. 이렇게 하면 DML과 인덱스는 mysql에 맡겨도 되니깐 나름 편한 부분이 있을 것 같습니다. 근데 이미 있겠죠? ㅋ