データベース

MySQLの整数データ型 INT/TINYINT/SMALLINT/MEDIUMINT/BIGINT を考える

数値のデータ型を大きく分けると、整数型、小数点型、ビット型がありますが、今回は、整数型に焦点を絞ります。
CREATE TABLE文で、たとえばデータ型 INT のカラムを作成する場合に下記のように指定して使いますが、このときの M、UNSIGNED、ZEROFILLの意味を改めて考えてみたいと思います。

CREATE TABLE tablename(
columnname INT[(M)] [UNSIGNED] [ZEROFILL]
)

整数型

MySQLで使える整数型には、INT、SMALLINT、TINYINT、MEDIUMINT、BIGINT の5つがあります。
それぞれの違いは記憶域のサイズです。
適切にデータ型を選択することでシステムを効率的に使えるようになります。
記憶域のサイズによって、挿入できる最大値が決まります。
*SIGNEDとUNSIGNEDについては後述します。

データ型 記憶域のサイズ SIGNEDの場合 INSIGNEDの場合
TINYINT 1バイト -128 ~ 127 0 ~ 255
SMALLINT 2バイト -32768 ~ 32767 0 ~ 65535
MEDIUMINT 3バイト -8388608 ~ 8388607 0 ~ 16777215
INT 4バイト -2147483648~ 2147483647 0 ~ 4294967295
BIGINT 8バイト -2の63乗~2の63乗-1 0 ~ 2の64乗-1

M(最大表示幅)

冒頭のCREATE TABLE文の例にあった「INT[(M)]」の M は最大表示幅を示します。
「INT(3)」とすると3桁格納でき、3桁表示されます。
「1」を挿入するとスペースが2つと数字の「1」が、つまり「(スペース)(スペース)1」が挿入されるわけです。
この(スペース)をゼロに自動置換するのが次に説明するZEROFILL属性です。

*整数データ型の表示幅属性は、MySQL 8.0.17では非推奨になり、将来のバージョンではサポートされなくなる予定です。

ZEROFILL(ゼロ埋め処理)

挿入された値が M桁 に満たない場合、左から「0」を自動挿入します。
たとえば、INT(3) の場合で「1」を挿入した場合、「001」となります。

ZEROFILLを指定した場合、自動的にUNSIGNEDも追加されます。
よって、マイナスの値を挿入できなくなります。

*ZEROFILL属性は、MySQL 8.0.17では非推奨になり、将来のバージョンではサポートされなくなる予定です。

SIGNEDとUNSIGNED

整数のデータ型にはSIGNEDとUNSIGNEDを指定できます。
SIGNEDは署名済、UNSIGNEDは未署名とも言われ、「+」や「-」の符号を付ける(SIGNED)か付けない(UNSIGNED)かを表しています。

1バイト(8ビット)しか使わないTINYINTを例に、挿入できる値について説明します。
SIGNEDの場合、1ビットは符号で使われますから、TINYINTは残りの7ビットに数値が入ります。
つまり、挿入できる値の範囲は2進数表記で、符号がマイナス「1」、プラス「0」とした場合、10000000~01111111。10進数表記だと-128~127となります。

UNSIGNEDの場合は符号がないので、8ビット全部使えます。
なので、同じく挿入できる値の範囲は2進数表記で 00000000~11111111(10進数で0~255)となります。

MySQL AUTO_INCREMENTテーブルにIDを指定してデータをINSERT

MySQLデータベースで、PRIMARY KEYであるID列にAUTO_INCREMENTが設定されている。
このテーブルにIDを指定してデータを挿入することができるのか?
答えは「できる」だ。

では、実演。

実演の準備

まず、テーブルを作成する。
ID列にAUTO_INCREMENTを指定し、PRIMARY KEYを設定する。

次にデータを3行INSERTする。

SELECTしてINSERTの結果を確認する。
きちんと3行あり、ID1、2、3があることが確認できる。

この時のAUTO_INCREMENT値(次に使われる数値)を確認すると「4」となっている。

次にID=2のデータを削除し、歯抜け状態にする。

すぐさま3行追加する。

SELECTしてテーブルのデータを確認してみよう。
最初に3行挿入して1行削除し、追加で3行挿入したから5行あるはずだ。
ID=2のデータを削除したからそれがないこともわかる。

ちなみに、この時のAUTO_INCREMENT値(次に使われる数値)を確認すると「7」となっている。

IDを指定してデータを挿入する

INSERT文 IDに「2」を指定して実行する。

SELECTして結果を見てみる。
ID=2のデータがあることがわかる。当然だが、最初のID=2のデータとはpost_dateの値が違う。

AUTO_INCREMENT値(次に使われる数値)は「7」のままだ。

続けて、ID=100のデータを挿入したらどうなるか

ここでは、AUTO_INCREMENT値(次に使われる数値)は「7」だ。
IDが100のデータを挿入したらどうなるのだろうか。

もちろん、INSERTはできる。
SELECTしてテーブルを確認するとこうなっている。
当然の結果だ。

AUTO_INCREMENT値(次に使われる数値)はどうなっているかもうわかるだろう。
「101」だ。

まとめ

AUTO_INCREMENTが設定されていても、IDを指定してデータをINSERTできる。
テーブルにあるデータよりも大きなAUTO_INCREMENTを指定すると、AUTO_INCREMENT値(次に使われる数値)がそれ以上の値に更新される。

気付けばデータベースエンジニア

ブックルックチーム代表の小山内です。
今日は私がIT未経験の新社会人としてテクニカルサポートから出発し、データベースエンジニアになるまでの道のりと、データベースエンジニアとしての経験を紹介したいと思います。

データベースエンジニアになるまで主に次の3つのステップがありました。

1つ目がクライアントPCの基本的な技術の獲得

2つ目がネットワークとサーバーサイドの知識と経験

3つ目がデータベースエンジニアの知識と経験

それぞれのステップとステップの間には「ツナギ」となる仕事がありました。必然的偶然のようなツナギの仕事です。
ツナギの仕事がデータベースエンジニアへと私を導きました。
突然データベースエンジニアになったわけではありません。自然と、本当に気付いたら、データベースエンジニアになっていたというのはそういうことだからです。
振り返れば、これら「ツナギ」の仕事がいかに重要だったかがわかります。

後半はデータベースエンジニアとしての失敗談や苦手なデータベース操作についてもお話しします。

悲鳴を上げるECサイト、1つしかないデータベース

2000年初期、米デル(現、デル・テクノロジーズ)の日本向けECサイトはいつも悲鳴を上げていました。
毎日何万の人がサイトに訪れ、何百ものパソコンがオーダーされます。
人手ではとうてい対応しきれないほどの注文が絶え間なく自動的に入ってきます。
そのため営業部門はサイトの24時間稼働は当然のことと考えていました。
それなのに、ちょっとした躓きでサービスダウンが発生する、という毎日でした。

ECサイトのWEBサーバーを増やし、いくら負荷分散したところで、サイトのパフォーマンスは改善されません。
なぜならば、データベースはたったの1台。
1台しかないデータベースは、フロント(ECサイト)を構成する複数のサーバーからのリクエスト処理がやってくるだけでなく、バックエンドで実行されているバッチ処理数だけでが毎日数千あり、リクエスト数は数えきれないほどありました。
そのため当時のデータベースサーバーは最高水準のスペックでしたが、常に高負荷になっていました。

この山に真正面から向かい、越えられたことが私のデータベースエンジニアとしてのスキルと経験を飛躍的に高める結果となりました。

ITエンジニアになったきっかけ

私がITエンジニアになったきっかけは、デルとの出会いが大いに関係しています。
その出会いに先駆けて、1995年、私は当時2部上場のトランス・コスモスに入社することとなり、入社前の2月頃から同期数十名と一緒に技術研修を受けました。
学生時代からパソコンに慣れ親しんでいる同期は当然のこととして話を聞いていました。
私はパソコンにほとんど触れたことがなく、見聞きすることが初めてのことばかりでした。
研修後も毎日、機械慣れしていない女子たちと一緒に、詳しい男子に教えてもらっていました。

筆者が新人研修の時の研修日誌

そうこうしていると4月になり、同期のみんなは某プリンタメーカーのサポート業務部門に配属されていきました。
スタートから出遅れていた私だけが本社に取り残されました。
この先どうなるのかと心配しましたが、ゴールデンウイーク明けになってようやくデルでのパソコンのテクニカルサポートの仕事があてがわれました。

それは1995年、デルの日本進出2年目でした。当時の社名はデル・コンピュータ。
デルでは、「立ち止まって考えるな、走りながら考えろ」、「早くやれ、完璧は求めない、8割できれば成功だ」、「自分で判断しろ、人に聞くなら自分の答えを決めてからにしろ」という個人のパフォーマンスと成長を優先する合理的な行動をよく求められました。
私にとってはとても理解し易い、シンプルな考え方に思えました。しかも、多くのことを任せてもらえるし、やりがいもありました。

デルはハードウェアメーカーですが、仕事に必要な知識は非常に広範囲でした。
マザーボード、CPU、メモリ、ハードディスクに留まらず、OS、ネットワーク、サーバー、プリンター、ディスプレイアダプタ、サウンドカード、SCSI機器など。毎日毎日聞いたことのない単語がサポートを求めるお客様から出てきてその度に調べていました。
本で読んで実機で試すことを繰り返し行いました。ハードウェアとソフトウェアの関係性を学ぶことも多くありました。
一定の知識がなければ即刻退場となる厳しい環境でしたから必死で知識を身に付けました。

でもこれはまだステップ1。ハードウェアとソフトウェアの基本的な技術、つまり主にクライアントPCを使うために必要な知識の獲得に過ぎませんでした。

サーバーサイドのスキルアップ

データベースエンジニアにたどり着くまでにもう2段階あります。
ステップ2は、ネットワークとサーバーサイドの知識と経験の獲得です。

2年目になると私はテクニカルサポートに必要な知識を身に付け、チーム内で常にナンバーワンの業績を出すようになりました。
一方で、鳴りやまないお客様からの電話対応に疲れ果てていました。
私の仕事量を減らすにはどうしたらよいか考えました。それは私以外のメンバーがもっとたくさんの電話を取ってくれることです。

私がナンバーワンを維持する秘訣である自作のQ&A集を社内に公開することにしました。
私は電話で問い合わせを受けたらFAXで回答を送ることで、1件あたりの対応時間の短縮を図っていました。
1度作成したドキュメントは保存しておき、同じ問い合わせが来たらFAXで送信するだけ、ということを繰り返していました。

社内の情報共有はNotesで行われていましたが、大小100以上あるドキュメントの更新や検索のし易さの点で、HTMLで作成して共有することとしました。

これがツナギの仕事です。ステップ1とステップ2をつなぐきっかけになったのです。
クライアントPCからネットワークやサーバーサイドへ行かざるを得なくなったのです。

当時の米Yahooを真似てディレクトリ型のページを作成しました。複数カテゴリへの登録、ドキュメント間のリンクなど今では当たり前ですが、当時は画期的でした。
それでも目的のドキュメントが見つからない、とメンバーから何度も言われ、私が検索して見つけて渡すということが度々ありました。

そんなこんなでデルでの2年半の仕事の後、ソニーのVAIOのコールセンターの立ち上げを行うこととなりました。
VAIOのコールセンターはデルの何倍もの人数の部隊でした。
私はデルでの業績を買われ、メンバーを支援する後方部隊の仕事を任されました。
同じように「こういうお問い合わせにはこう答えましょう」というQ&A集「chaco」を提供しました。
chacoは私が小学生のときに飼っていたメスの三毛猫の名前です。

chacoの設計書の一部

chacoはVAIOのお客様の特性に合わせ発展させていきました。
BIOSのシミュレーション画面や、パソコンに同梱される物やソフトウェアの情報なども追加し、実機が手元に無くても電話でサポートできるようにしました。
間もなくHTMLでは対応しきれなくなり、WEBサーバーを構築し、サーバーサイドのコーディングが必要になりました。
プログラミングもしたことがなかったので、社内の誰か出来る人がいないかと本社にお願いしましたが、そこまでできないということで、最初のやり方だけ教えてもらいました。
あとは本を片手に試行錯誤でとりあえず構築しました。

しかし、見様見真似だけではわからないことが多く、一から本を読んで勉強する必要性を実感し、ネットワークの基礎、Windows Server、TCP/IP、IISなど手近なところからやりました。

ここまでで、ステップ1(パソコンの基本スキル)、ステップ2(ネットワーク/サーバーの知識と経験)と来たわけですが、これが次のステップ3(データベースエンジニア)へと進む大きな自信になりました。

WEBサイト管理のコアはデータベース

ソニーVAIOコールセンターでサポートシステムchacoが軌道に乗ったところで転職活動をしたらたまたまデルに入社することとなりました。2000年1月のことです。
chacoのことは後輩に任せましたが、その後10年ほど進化しながら利用され続けたと聞きました。

デルではカスタマーサポート部に配属され、サポートサイトで公開するコンテンツ開発を行いました。
よくあるお問い合わせをコールセンターから仕入れドキュメント化し、WEBで公開する仕事です。サーバーも触らないし、コーディングもしません。

しかしこれがステップ3へのツナギの仕事になったのです。

サポートサイトではどれほどコンテンツを追加しても、コールセンターへの電話の数は減ることはありませんでした。その原因を追究していくとサイトのユーザビリティに行きつきました。
欲しい情報がすぐ見つかる、使い易いサイトを目指し改善を重ねました。

一方で、私は社内用のコールセンター向けのコンテンツサーバーを立上げ、検索エンジンを導入し、社内イントラサーバーの開発を行っていました。

しばらくすると同じ部署でサーバーを管理していたエンジニアが退職することになりました。
そのため私が外部向けのサポートサイトを構成する複数のサーバーを管理することになりました。

やがて私はカスタマーサポート部から、それらサーバーと一緒にIT部門に異動することになり、ECサイトも面倒を見ることとなりました。
IT部門に異動した当初はWEBサイト管理ということで、サーバー単位で管理していました。
当時はまだクラウドのサービスは一般的ではなく、データセンターに物理サーバーを置いていた時代です。
サーバー単位なので、ハードウェア、OS、ミドルウェア(WEBサーバーとデータベースサーバー)が責任範囲でした。データベースはMicrosoftのSQL Server。
その時のECサイトは先ほど述べた通りで、ほぼ毎日事件(システム障害)続きでした。

毎日起こるシステム障害。『これは何とかしなければならない』と半ば強引に対策を施しました。
対策のメインはデータベース。チューニング、一極集中する状況の打破、システムの見える化、キャパシティプランニングなど、できることはないか、すべきことはないかとデータベースの勉強をしながら行いました。

データベースのマニュアルや教科書を読みながら、効果がありそうなことを見つけたら実際に試してみることを繰り返すことで、データベースエンジニア、データベース管理者としてのスキルと経験を身に着けていきました。

当然この私のデータベースエンジニアとしての仕事だけではありませんが、事件続きのECサイトを安定稼働させることができるようになりました。安心できるようになるまで1~2年はかかったと思います。

筆者のデータベースの勉強をしながら書き溜めたノート

いよいよデータベースエンジニア

ECサイトが安定稼働したことで、社内のその他のデータベースも面倒を見ることになりました。
MicrosoftのSQL Serverだけでなく、Oracleも含まれ、またもやチャレンジングな状況になってしまいました。

サーバー30台、データベース300以上あったと思います。
その中にまさにビッグデータがありました。世間でその単語が取り上げられるよりも先に取り扱っていました。
社内ではこのビッグデータを使ってガリガリ、ガリガリと分析をする人たちが大勢いて、頻繁に「遅い」、「時間がかかる」、「処理が終わらない」、「結果が返ってこない」、「どうやってデータを結合したらいいのか」、「欲しいデータがない」などなど私のところへ要望、質問、文句が山ほど寄せられました。

システム障害は起こらないものの、社内ユーザーからの同じことの繰り返しの問い合わせに、またもや『これは何とかしなければならない』と立ち上がるに至りました。
ビッグデータのデータベースはOracle。手法は異なるものの原理はSQL Serverと同じ。
データベースファイルの配置、インデックスの管理、バッチの管理などを見直しました。

全社のデータ分析、レポーティング業務をほぼ1日止めてしまったこともあります。
パフォーマンスチューニングのためにインデックスの再作成したのですが、データ量が多すぎて一晩経っても終わらなかったのです。
朝になり、皆が出勤してくるとどんどんリクエストがやってきてCPUを消費され、インデックスの作成が滞り、さらに時間がかかるという状況になりました。
ユーザーに謝罪しつつ、ひたすら手動でリクエストを切断し続け、ようやく午後3時ころに完了したのを覚えています。

筆者のデータベースノートの中身

データベースにまつわる人為的ミスといえば、データベースエンジニアなら1度は経験したことがあるのではないでしょうか。それはデータ削除です。
データ削除は、データの完全性を担保すべきデータベースエンジニアとして最悪なミスです。
データ削除とは、データを間違って削除したり上書きしたり、中にはデータベースを丸ごと削除したり、バックアップで本番データベースを上書きしてしまったりすることです。
バックアップから復元できればまだましです。利用頻度が高いデータベースでは、バックアップからだけでは復元できないことがあります。
実は私も1度だけあります。レコード8行を間違って削除してしまい、慌ててバックアップから復元を試みたものの、2行はどんなデータだったかもわからず永久に失われてしまいました。
間違って削除したことに気付いた瞬間、血の気が全部引きました。体温が低下し、緊張のあまり手を震わせながらデータベース操作をしました。

データベースエンジニアとして最も重要な仕事は何かと聞かれれば、私はバックアップとリカバリだと思います。
必要なバックアップを取り、万が一の時に迅速にリカバリすることができれば怖いものはだいぶ減ります。
しかし、個人的にOracleデータベースのリカバリは何度やっても慣れませんでした。
SQL ServerとOracleを管理していたのですが、前者はほぼ目をつむっていてもリカバリできます。しかし後者は確認事項が多くうまくいかないこともありました。
まず、バックアップ対象が複数あり、漏れなくバックアップをしておくことから始まります。
人が管理していたものだとそれが不十分なことがしばしばありました。SWITCH LOGを実行してからバックアップをしていないとか、初期化パラメータファイルがないとか。。。
そのためリカバリは気を使います。すべてのデータファイルが同じSCNを持っているかとか、REDOログどうするかとか。
ビッグデータを保管するデータベースの場合、試しに他のサーバーでバックアップからリカバリできるか確認するということができなかったので、リカバリしなければならないような事態にならないことを祈るだけでした。

データベースエンジニアの重要性

今やデータベースは必要不可欠な機能です。
一番最初にあった出来事のように、複数のECサーバーやバックエンドシステムからも参照されます。
常にデータの整合性、完全性、可用性、安全性を担保するシステムが求められます。

ブックルックチームでは、物理サーバーは管理していません。AWSといったクラウドのサービスを利用しています。クラウドのサービス管理は物理サーバーのそれとは比べ物にならないほど楽です。びっくりするくらい楽です。そのためエンジニアリングにより多くの時間を割くことができるようになりました。

基本的にはMySQLがメインです。しかし、リレーショナルデータベースだけでなく、アプリケーションの求めに対しNoSQLを採用したり、AuroraやRedshiftといったAWSのサービスを使ってみたりしながら最適解を探しています。

データベースエンジニアの採用情報

データベースエンジニアとして活躍したい方、是非ご応募ください。
データベースエンジニアはこのようなニーズに応えるとてもやりがいのある仕事です。
未経験の方もお気軽にお問い合わせください。最初から何でもできる人はいません。まずは出来ることをやり続け、時にチャレンジすることで経験が積み上がります。そうして気づけば高い所に立っているものです。

データベースエンジニア (DBA) の募集要項