『SQL ゼロからはじめるデータベース操作』の著者ミック:神は細部に宿る(圖靈訪談)
ミック, 日本のシステム開発企業で、パフォーマンス専門のエンジニアとして仕事をしています。専門分野はBI/DWHのような大規模データを解析するシステムの設計やチューニングですが、效能問題が発生すればOSリソースやJavaのメモリ解析などなんでも対応します。また、最近は教育も擔當しており、社內の若手エンジニアの育成を行っています。
趣味は學生の頃から続けている合唱(choir)ですが、最近は主に子どもの遊び相手をしています。
【本書の推薦文】
本書は、SQLやリレーショナルデータベースに觸れるのが初めてという読者が、SQLの初歩から學ぶことができます。SELECT/UPDATE/DELETEといったSQLの基本構文からはじまり、CASE式、結合、相関サブクエリ、ウィンドウ関數といった重要な機能を網羅的に學ぶことができます。また、標準SQLの構文をベースに學習できるため、データベース製品の違いによらないポータブルで長く役に立つ技術を身につけることができます。——ミック
中國語
個人的な話題
技術者は普通「オタク」の印象がありますが、ミックさんは日常生活の中でどのような人でしょうか。
昨年秋に子どもが生まれたこともあり、現在はプライベートの時間はほとんど育児をしています。一緒に動物園へ出かけたり(パンダの赤ちゃんが生まれてニュースになっています)、おもちゃで遊んだりしています。子どもの成長を間近に見られるのはとても楽しく感動的ですが、子どもはエネルギーの塊なので、相手をする親は大変ですね(笑)。なかなか技術を勉強する時間が取れなくなってしまったのも悩みの種です。
日本の技術者同士はどんな形式でお互いに交流、勉強をしますか。
勉強會やセミナーはとても頻繁に開かれており、活発です。基本的には平日に會社が終わった後に集まることが多いのですが、忙しいなか時間をやりくりして參加する人が多いです。こうした勉強會は、業界別で行われることもあり、特定の技術分野(DB、Java、Ruby、機械學習など)をテーマに開かれることもあります。私もDBの勉強會に參加することもありますし、講演を頼まれることもあります。自分だけでなくIT業界全體が発展していくことが大事なので、講演を頼まれた場合は、基本的に全部受けるようにしています。
日本は効率を重んじる社會で、生活のテンポが比較的速いです。仕事、生活、執筆の兼ね合いをつける祕訣はなんでしょうか。
祕訣・・・難しいですね(笑)。正直20代のころは、體力任せでした。會社での仕事も忙しく、夜遅く帰って來てから勉強したり、本を書いたりしていました。しかしこれはやはり長くは続けられません。若い時だけの特権です。工夫したこととしては、隙間(ニッチ)時間の活用です。私は電車通勤(會社まで45分くらい)なのですが、スマートフォンが普及して以來、電車の中でちょっとした思いつきの文章をメモしたり、英語の技術記事を翻訳したり、メールを返したり、小さいタスクを片付けられるようになりました。それによって、本當に重要な活動である勉強や本の執筆などにまとまった時間を取れるようになりました。
本書について
どのようなきっかけで技術書を書き始めましたか。
最初は、自分の[個人的なWebサイト](http://www.geocities.jp/mickindex/database/idx_database.html )に技術的な情報を掲載していました。
本を書くつもりはなく、備忘録を皆に共有しているくらいの認識でした。その後、サイトを読んだ出版社の編集者からWebマガジンに技術記事を書く誘いを受けて、少しずつライターとして活動するようになり、本も書くようになりました。
『SQL ゼロからはじめるデータベース操作』は評判がとても良くて、好評がいっぱいです。ミックさんから見れば、本書が読者に愛読される原因はなんでしょうか。
日本と中國という言語の異なる國で評価してもらったことは、大変嬉しいです。本書を書くときに注意したことは、「自分が初心者だったときに読みたかった本を書こう」ということでした。SQLに限らず、プログラミング言語の入門書は、あまり詳細な原理の解説をせず、「とりあえずこう書くと覚えてください」というスタンスものが多くあります。いわゆる「クックブック」や「レシピ」と呼ばれる本です。私は、入門書といえどもこのようなスタンスは採用しないようにしています。最初に原理的なことを理解しないと、結局、初級者を脫することができずに終わってしまうためです。
このようなわかりやすい入門書を書くために、事物に対する細かい観察と深い理解が必要だと思いますが、ミックさんはどのようにできたのですか。
まさに、「事物に対する細かい観察」を怠らないよう注意しています。言い換えると「小さな違和感を無視しない」ことです。何かの分野を勉強しはじめたとき、「なぜだろう?」という疑問を持つことはよくあります。その疑問を無視せず、本當に解決するまで調査することを心がけています。 たとえば、SQLを最初に學んだとき、NULLを検索するのに「<列名> = NULL」ではなく、「<列名> IS NULL」と書かねばならないという文法規則が非常に不思議でした。なぜ「=」を使ってはいけないのだろう? このような疑問は、深く追求せずに「そう書くのだ」と暗記してしまえば、やり過ごすこともできます。しかし、それではやはり応用的な力は身につかず、いずれ成長の限界が來てしまいます。本質的な理解へと至る最善の道は、一見すると些細な疑問を無視しないことだと思います。「神は細部に宿る(God is in the details)」が私の座右の銘の一つです。
將來、第3版を書く計畫はありますか。もしあれば、どんな方面で第2版を補充或いは更新しますか。
現在のところ第3版の予定はないのですが、もし補充するとすれば、二つの方向を考えています。一つは、SQLの応用的な技術を取り入れること。現在、SQLは Big Dataの加工・解析ツールとして以前にも増して高度な使われ方をするようになっています。ウィンドウ関數やCASE式を活用することで、非常に便利なプログラミングができます。現在はどちらも基本的な使い方の解説にとどめているので、時代にあわせて內容を拡充していくことを考えています。もう一つは、システム開発全體におけるSQL/RDBのポジションについての説明を入れることです。例えばSQLインジェクションの原理と対策など、実際にシステム開発においてSQL/RDBを使う際に役立つ情報も追加したいと考えています。
技術書の翻訳について
Joe Celkoさんの本を何冊翻訳したと存じますが、Joe Celkoさんと彼の本について、コメントとか何か言いたいことがありますか。
Celkoの『Joe Celko's SQL for Smarties』は、私がSQLを勉強した教科書です。SQLに関するほとんどすべての知識を彼から學んだといってよいくらいです。非常に膨大かつ難解な本なので、読むのに大変苦労しました。実は、私が本を書いた動機の一つが、「Celkoの本をもっと分かりやすく解説したい」というものでした。私の本は、いわば、Celkoの解説書なのです。
翻訳者として、ある本を翻訳するか否かについて、どのように決めましたか。
現在のところ、私はCelkoの本を3冊訳しています。20代の前半に初めて彼の本を読んで以來、とても尊敬していたので、いつか彼の本を訳したいと思っていました。自分から出版社に提案したくらい熱心でした。Celko以外にもデータベースについてとても良い英語の本がありますので、いつかそうした本も訳したいと思っています。
ミックさんにとって、技術書を翻訳することは、既存の知識にどのような影響がありますか。翻訳するとき、自分の理解或いは観點を加入しますか。
上述のように、Celkoの本はとても難解で、一読してもなかなか理解できません。そのため、翻訳のときはなるべく読者が理解しやすいように注釈を多く入れました。また、著者の意見に賛成できない場合は、自分の意見を表明して読者が自分で考える契機となるよう努力しています。
中國では、『論語』をはじめ難解な古典に対して膨大な注釈書が存在します。朱熹の『論語集註』や何晏の『論語集解』などは日本でもよく読まれました。それら注釈テキストは、ただ言葉の意味を説明するだけでなく、獨自の考えを展開しており、創造性があります。私も、ただ言語を変換するのではなく、原典にさらなる価値を付加できる翻訳をしたいと思っています。
リレーショナルデータベースと非リレーショナルデータベースについて
リレーショナルデータベースと非リレーショナルデータベース(NoSQL)のそれぞれの特徴、及び使用するときどうのように選択するかについて、簡単な紹介をいただけませんか。
NoSQLが登場を始めたとき、リレーショナルデータベースを置き換える存在になるのではないか、という観測が語られたことがあります。しかし數年経過した現在では、「適材適所」という形に落ち著いたように思います。NoSQLは非常に多くの種類があるので、一口には言えないのですが、代表的には種類に分かれると思います。
1) Key Value Store (KVS)
Memcached、Redis、DynamoDB(※)など
2) ドキュメント型DB
MongoDB、DynamoDBなど
※ドキュメント型DBの機能も持っている
1)の利點は、二つあると考えます。一つが、データ構造をKey-Valueの一対一対応に単純化することで、高速な検索を可能にしたことです。SQLほどの検索の自由度を諦める代わりに速さを追求したわけです。データが増えた際のスケーラビリティにも富みます。KVSは、さらにデータをインメモリ化することで相當なパフォーマンス向上が可能になります。
2)の利點は、JSONやXMLなど、従來リレーショナルデータベースの「テーブル」という形式では扱うのが難しかったデータ形式を、かなり自由に扱えるようにしたことです。これにより、正規化など厳密な設計を行うことなく様々な形式のデータを扱えるようになりました。
一方で、どちらのタイプも、リレーショナルデータベースのような高度なトランザクション機能やデータ保全を犠牲にしています。「結果整合性」という言葉で知られているように、データ更新後、最終的には正しい狀態に落ち著くことのみが保証され、一時的には整合性の取れない狀態を許容しています。そのため、1)のケースは、「高速なレスポンスが必要だが、データ不整合や消失はある程度許容できる」というデータに対して使われるようになりました。具體的な例としては、SNSへの投稿のようなストリームデータや、ECサイトにおけるユーザのセッション情報です。セッション情報は、最悪失われてしまっても、もう一度ログインしてもらえばショッピングを再開できます。一方で、購入した商品の履歴や送金データが消えてしまうことは絶対に許されません。したがって、このようなケースではKVSをフロント、リレーショナルデータベースをバックエンドという使い分けをすることが一つの設計の定石になりました。
また、NoSQLとして數えるか意見の分かれるところですが、非構造データを扱う種類のデータベースがあります。つまり、畫像や音聲といった非文字データや、グラフ構造のような従來リレーショナルデータベースが扱うのを苦手としていたデータです。こうしたデータベースの場合、リレーショナルデータベースでは扱えない(扱いにくい)データを扱うことを目的としているため、特定用途の分野ではリレーショナルデータベースそのものに取って代わる存在になる可能性があります。
しかし、それでもリレーショナルデータベースが持つ堅牢性と汎用性は傑出していますから、基幹システムをリレーショナルデータベースで構築しつつ、よりライトな用途のフロントエンドやニッチ分野でNoSQLが使われる、という住み分けが今後も続くのではないでしょうか。
非リレーショナルデータベース(NoSQL)は將來にデータ管理の將來の動向はなんでしょうか。
NoSQLには二つの発展の方向性があると考えています。一つは、NoSQLが今後も獨自に発展を遂げていく可能性。もう一つが、リレーショナルデータベースの一機能として吸収されていく可能性です。実際、過去にもXMLデータベースが登場したとき、最初は獨立したデータベース製品でしたが、今では多くのDBMSの一機能として吸収されました。最近でも、リレーショナルデータベースはJSONや地図情報(Spatial DB)を扱う機能を拡充しており、最終的にはNoSQLの機能も含んだ一つの「大家族」を構成するようになるかもしれません。いずれにせよ、我々エンジニアとしても、こうした非構造データを扱う技術の習得は今後ますます重要になっていくと思います。
後輩へのアドバイス
初心者はSQLを勉強する時、どんな習慣を身につけるべきですか。例えば効率性とか、規範性とか、アドバイスをいただけませんか。
最初から小手先のテクニックや「レシピ」を暗記するのではなく、動作原理を理解することを心がけてほしいと思います。SQLは、Javaのような他のプログラミング言語に比べれば関數や機能の數が少なく、また英語という自然言語に近いため、一見すると単純に見えます。しかし、実はその「単純な機能」(結合、CASE式、ウィンドウ関數、HAVING句etc.)を組み合わせていくことで、極めて複雑なことができます。その點で、SQLは積み木ブロックに似ているかもしれません。一つ一つの土臺となる積み木の理解をおろそかにすると、決して高い建造物は作れません。
初心者にとって、もし今後ソフトウェア開発の仕事をしたいなら、『SQL ゼロからはじめるデータベース操作』を勉強した後、それからどのように勉強し続けるかについて、何かいいアドバイスをいただけませんか。
本書は、あくまでSQLの文法の理解を助ける目的にフォーカスした本です。実際に技術者として活躍するために必要な知識は、これだけではとても足りませんので、幅広い分野へ目を向けてほしいと思います。たとえば、データベース分野だけでも、ERモデリング(jテー設計)や、Oracle、MySQLといった各製品の設計技術、SQLパフォーマンスチューニングなど、それだけで習得するのに何年もかかるような大きな技術分野があります。もし読者の皆さんがソフトウェア開発者であれば、Java、PHP、Pythonなどのプログラミング言語の習得も必要になるでしょう。
皆さんがどのような方向性を目指すかは、自身のキャリア志向と市場の需要によって決まることなので、私から一律のアドバイスをすることはできません。しかし、どのような分野であれ、常に興味をもって學習できることが重要です。そのため、自分が學ぶモチベーションを維持できる分野、興味を持ち続けられる仕事は何かを、なるべく早く見つけることが大切だと思います。
ソフトウェア概要設計の初期、プロジェクトによって違うデータベースを選択すべきですが、どのように適當なデータベースを選択するかを簡単に紹介していただけませんか。
現在、日本で選択できるリレーショナルデータベースは、Oracle/SQL Server/DB2/PostgreSQL/MySQL という5個が代表的です。これらのどれを選択するかは、エンジニアにとって非常に重要な問題であり、いくつもの要因を総合的に検討しなければならない難しい問題です。
しかし、現実にはあまり選択権がない場合もあります。一言でいってしまうと、「お金」の制約がある場合も多いからです。もしスタートアップ企業で新サービスを立ち上げようとしているなら、なるべくライセンス料を安くするために、PostgreSQLやMySQLのようなOSSベースのデータベース以外に選択肢がないでしょう。一方、もし金融機関や公共機関のような非常に高い可用性や效能を求められるシステムを構築するならば、Oracleのような高機能かつベンダによるサポートも手厚い製品を選ぶ必要があるでしょう。あるいは、ECサイトのようにトラフィックの季節変動が激しい場合には、Amazon RDSのようなクラウド上のSaaSとしてのデータベースが最もコストメリットが得られるかもしれません。
近年、いずれのデータベース製品も機能の充実は甲乙つけがたくなってきているため、選択基準としてはむしろ、上にあげたような予算制約、非機能性、サポートの充実度などが重要になってきているという印象があります。
SQLパフォーマンスチューニングについて、ミックさんの経験或いはアドバイスをシェアしていただけませんか。
例えば、複雑のSQL文(複數テーブルの関連検索)又はプロシージャに、通常は效能問題が起こりやすいところはなんですか。
SQLパフォーマンスチューニングは、私の専門分野の一つです。SQLというのは、非常に效能問題が起きやすいのですが、その理由は端的に、データベースが扱うデータ量が極めて大きいからです。WebサーバやAPサーバは、せいぜいメモリで保持できるレベルのデータ量(GBクラス)しか扱いません。しかしDBサーバではTBクラスのデータを扱うのは當たり前です。近年はBig Dataの流行でさらにデータ量が増大しています。
必然的に、SQLにおける效能問題は、ストレージからデータを読み出す際の速度がボトルネックとなって発生することが多くなります。特に、大きなテーブルの結合を行っているときにこの問題が顕著に発生します。
これに対する解決策をこのインタビューの中で語るには、紙幅が足りません。私はSQLチューニングだけで一冊の本を書いたくらいです。ただ、すぐに実踐できる改善策を一つ挙げるなら、DBサーバになるべく多くの物理メモリを搭載し、データベースに多く割り當てることです。かつてメモリは高価でしたが、最近は低価格化が進んでおり、32GBや64GB程度のメモリならば、通常のDBサーバにも十分搭載できるようになりました。メモリは、一般的なHDDに比べると極めて高速で、メモリ上にデータを保持することができれば、それだけで多くの效能問題が解消されるほどです。これは、頭の代わりにお金を使う解決策なのですが、投資に見合う効果があるのでお薦めです。(笑)
そうではなく、設計上の注意點を挙げるならば、基本方針としては、SQLで操作するデータ量をなるべく減らすように設計することです。めったに必要としない古い過去データは、履歴テーブルへ移動させる。畫面から設定できる検索條件において、なるべくデータを絞りこめる條件をユーザに設定してもらうようにする、など。
SQLチューニングは、こうした設計上の努力で解決できなかった問題に対する最後の手段です。最初からSQLチューニングに頼るのではなく、SQLチューニングが不要となる設計が大事なのだということは、忘れないでください。
特約記者:
孫淼, 從事對日軟體設計和研發工作十餘年,曾於2007年至2009年赴日學習工作,2015年至今再次長期赴日工作。精通應用Java、PHP進行Web框架的設計開發,並且有Oracle、Teradata、MySQL、NoSQL等多種資料庫的設計開發經驗。樂於品味生活細微的點滴,熱衷於品嚐和製作美食。是《SQL基礎教程》的譯者。
更多精彩,加入圖靈訪談微信!
相關文章
- クリス・ソウルズのインタビューインターネットデート したがって 農業 生き方
- 【VBA】シートの選択方法まとめ【複數選択と解除、シートをアクティブにする】
- 【VBA】シートの指定方法4選【アクティブシート、シート名、シートインデックス、シートオブジェクト】
- 【VBA】エクセルのシートを非表示にする【Visibleを使います】
- 【VBA】シートをクリアする
- パナソニックグループ プログラミングコンテスト2024(ABC 375)
- P3654 First Step (ファーストステップ)
- プログラミングコンテストチャレンジブック 題解
- 【VBA】セル範囲をセルに代入するときの注意點【RangeにValueをつける】
- 【VBA】シート名の取得と変更をする方法【.Nameを使います】
- 旅行青蛙(旅かえる)逆向筆記筆記
- 【VBA】シートの保護と解除、パスワード設定と判定【ProtectとUnprotectを使う】
- 【VBA】セル範囲の値のみをクリアする【RangeとClearを使う】
- トヨタ自動車プログラミングコンテスト2024#7(ABC 362)
- 【VBA】シート名を検索する【完全一致と部分一致の検索ができます】
- 2.12 それは命の證 ——ARC119~121
- 2.11 それは命の證 ——ARC116~118
- 2.13 それは命の證 ——ARC122~124
- 【VBA】シート名の一覧を取得【シートをループしてNameを使う】
- 【歌詞】カントリー・ロード (ヴァイオリン・ヴァージョン) - 本名陽子
- 【VBA】Rangeで取得したセル範囲をループする【For Eachを使います】
- 【VBA】表全體の範囲を取得する【CurrentRegionが便利です】
- 【EXCEL】大量のシートを名前付きで一括作成Excel
- 日付処理:文字列から日付へ変換、年月日の取得(1桁、2桁の取得結果)
- 10 個 Flutter 建議 ー 第9/10部分Flutter
- 三語介面RLC串聯電路引數計算軟體RLC2025下載RLC直列迴路パラメータ計算ソフトRLC2025ダウンロードDownload RLC series circuit parameter calculation software RLC2025UI
- 寫真を撮る(2018-05-10)
- 【VBA】可視セルの判定、削除、コピー、貼り付け【HiddenとSpecialCellsを使う】
- 在 Flutter 中編寫自定義小部件(第1部分)ー EllipsizedTextFlutterZed
- [ARC058F] 文字列大好きいろはちゃん
- 【VBA】シートの見出し色を設定【.Tabl.Colorと.Tab.ColorIndexを使う】Index
- 10 個 Flutter 建議 ー 第 8/10 部分Flutter
- 如何測試 Flutter 應用? ー 單元測試Flutter
- 圖靈訪談系列之一:陳世欣談產品經理與社群圖靈
- 圖靈訪談系列之九:CNode社群談Node.js技術及生態圖靈Node.js
- 【VBA】形式を選択して貼り付ける方法【PasteSpecialを使う】AST
- 【VBA】最終行を取得する方法3選【CurrentRegion、End、Findを使う】
- DataGirls社群創始人 Aislinn:做勇敢的少數派(圖靈訪談)AI圖靈
- 使用者訪談操作指南