DB / 데이터 저장소에 관련된 기술자가 절대 읽어야 할 기사

4 년 반 정도 전에 되는가? 들어 2 일째의 PJ에서의 대화.

"XX 씨, MySQL 서버 만진 적이 있습니까"
"조금이라면"
"그럼, DB 서버의 설계 부탁드립니다"

...에서 필사 새겨 공부했다. 그때의 궤적이이 사이트 상단의 "MySQL"태그로 남아있는 것이다.

현재, MySQL은 O 사에 인수되고 나서 기세가 둔화되고 감이 부정하지 않으며 "시든"제품이다. 4 년 반 전의 시점에서도 복제는 이미 시든 기술이었다. 일년 조금 지나면 Cassandra 등이 나오고 점점 MySQL 니 손때가 붙은 지팡이에 보이지 버리게되었다. 현장에서 "MySQL 가급적 사용하고 싶지 않 지요"라는 목소리가 나오고 자신이 필사적으로 배운 것은 무엇이었을 까, 그리고 동기 부여가 내리락했다.

그러나 지금은 이렇게 생각한다.

MySQL 복제하거나, InnoDB의 구조 라든지, 뒷면까지 낚시 공부해라, 역시 좋았다.

저런 것을 실컷하고 있었던 때문에 Hadoop과 NoSQL 주변 기술에 부드럽게 들어갈 수있는 것이고, 데이터 통합​​이나 데이터 흐름 같은 것을 생각하는 "xx 만 알고하고 있으면 좋다」라고하는 아니라 전체적인 관점이 반드시 필요한 것이다. 시든 기술 이니까 빨아 걸려 있으면 발밑 구원거야. PostgreSQL도, DWH 관련으로 크게 반격있다 잖아.

그리고, 갑자기이지만, 우연히 이런 기사를 발견했다. 데이터베이스 및 데이터 스토어 관련 커밋 엔지니어 특히 요구 사항 정의 및 설계에 관련된 사람이라면 이것은 절대 읽어야 해요! ! 라는 내용이다.

MySQL과 MongoDB, Amazon Redshift 및 기타 제품 등 데이터베이스와 DWH의 선정 기준. 성실하고 명쾌한. 특정 제품에 한정하지 않고 범용 적으로 응용 가능한 아이디어라고 생각한다. 이 기사에 쓰여져있는 일을 예를 들어 Hadoop 주변 제품으로 대체 봐도 "이다이다!"라고 납득할 수있다. 여기에서는 더 이상 불필요한 말은하지 때문에, 어쨌든 읽어 줘.

끝, 그 저자의 이름에 왠지 익숙한 소리. 어라, 혹시.

그것은 우리들이 4 년 반 전에 구입 한 참고서 "현장에서 사용할 MySQL」의 저자 그 사람이었다.
많은 MySQL 참고서 중에서 손에 잡았다, 꽤 탄탄한 내용으로, 결과적으로 굉장히 활용 해 주었다. 이 책을 선택 좋았다,라고 생각했다. 이 블로그에서 인용 해대고있다.

여러가지 의미로, 역시 시대가 바뀌어도 보편적 진리라고 있어요,라고 혼자 납득하고 있습니다.
(플랫폼을 빨아 걸리면 무척 보는거야, 왜냐하면 작은 목소리로 중얼 둔다)