예전엔 디스크보단 메모리쪽에 많은 비중을 차지했습니다. 데이터가 지금처럼 많이 커지지 않았죠. 지금은 많이 커졌기 때문 전체 데이터를 액세스할때 디스크 속도도 많이 좌우하게 되었던거죠. DB 설계를 뭐같이 하면 아무리 SSD 달아도 그게 전혀 나아지질 않습니다. DB는 하드웨어 의존도 바라보면 안됩니다. SSD도 감당안되는 속도다? 어디 증권가 경매 붙는것도 아니고...
SSD를 쳐발랐는데도 I/O가 심하다라고 한다면 그건 설계부터 뜯어고쳐야 한다는겁니다.
1. 예전에는 데이터량이 지금보다 훨씬 적었습니다.
2. 예전에는 사용자도 간단한 자료를 원했습니다.
3. 예전에는 좀 느리더라도 사용자가 기다렸습니다.
4. 예전에는 개발자가 개발에 투자할 시간이 더 많았습니다.
요즘은 섬세하게 코드를 다듬지 않고 장비에 투자하는게 더 싸게 먹힙니다.
5. 예전에는 (특히 우리나라) 초/중급 개발자가 지금보다 훨씬 많았습니다.
6. 예전에는 ....
그게 제일 큰 문제입니다.
초중급 개발자 정말 귀합니다. 지금 업계에서 35~37이 막내인 경우가 흔하게 목격됩니다.
이게 다...버블시대에 바닥수준의 개발자(라고 부르고 알바라고 읽는)의 노임단가 + 살인적인 근무시간이 원인입니다.
시간과 예산은 안주고 초보자 갈아넣으면 답이 나오는줄 아니.. 이게 뭐...될 리가 있나요.
송주환
다만 서버 전원 떨어지면 끝장난다고...;
속도는 U160에서 꾸준히 약 100MB/S정도로 생각하시면 됩니다.
그때가 튼튼하고 좋았어요. 프로그램도 작았고
요즘은 멀티미디어가 첨가되기에 여러가지로 복잡합니다.
SSD를 쳐발랐는데도 I/O가 심하다라고 한다면 그건 설계부터 뜯어고쳐야 한다는겁니다.
보통 1개 단독으로 사용하지만
이걸 2개 4개 혹은 10개를 레이드0으로 걸어버린다면.....
문제는 이렇게 올려줘도 현재의 네트웍이 따라오잘 못할뿐이니
이론 상으로 디스크 io만 높여주자라면 이것도 해결방법이진 않을까 생각해봅니다.
2. 예전에는 사용자도 간단한 자료를 원했습니다.
3. 예전에는 좀 느리더라도 사용자가 기다렸습니다.
4. 예전에는 개발자가 개발에 투자할 시간이 더 많았습니다.
요즘은 섬세하게 코드를 다듬지 않고 장비에 투자하는게 더 싸게 먹힙니다.
5. 예전에는 (특히 우리나라) 초/중급 개발자가 지금보다 훨씬 많았습니다.
6. 예전에는 ....
요즘 프로그래머는 뇌이버에서 짜집기를 하는 듯한데 짜집기도 잘 안되는것 같습니다.
그나마 귀해서 프로잭트하면 난리도 아닙니다.
초중급 개발자 정말 귀합니다. 지금 업계에서 35~37이 막내인 경우가 흔하게 목격됩니다.
이게 다...버블시대에 바닥수준의 개발자(라고 부르고 알바라고 읽는)의 노임단가 + 살인적인 근무시간이 원인입니다.
시간과 예산은 안주고 초보자 갈아넣으면 답이 나오는줄 아니.. 이게 뭐...될 리가 있나요.
한 4년전에 SKT에서 도입해서 실시간 요금조회, 무료통화 확인 등에 사용하던데요..
속도는 정말 빠릅니다.(그러수 밖에 없겠지만요..)
충분히 SAS/SATA Array 들이 안정성 면에선 우월합니다.
SSD로 처리 못할정도면 그 시스템은 버려도 되지 않을까 생각이 드네요.
고도화 하기엔 비용이 더 들기 때문이죠.
그리고 모든 정보를 집적시킨 디비보단 EAI를 활용한 기초데이터는 인프라 영역으로 올리는 작업이 오래전부터
엔터프라이즈급 환경에서 구축되고 있습니다.
빈번히 사용되는 기초적인 정보를 담는 데이터와 실제 (활용)필요로하는 데이터 저장과 관리를 최소화 하는 거지요.
돈없으면.. 그냥 RAID..
그리고 web 단에서 정적 page처리 등등.. 이용한 최대한 직접 DB query를 줄이는 방안...
DB최적화에 집중...
memcahced와 같은 분산처리용 DB도입 등등..