AWSのRDSを使えばSQLなんていらね〜って考えているエンジニアと話をすると、今時のフレームワークに真新しいライブラリを使って、最新システムを構築して喜んでいる姿を見て、その後発生するであろうトラブル対応の事を何も思考していなくて、残念な気持ちになることがあります。
10年ぐらい前に、とある会社（今は東証一部上場会社）にWEBエンジニアとして入社した時に、B2BのASPサービスが１つ運用されていましたが、毎日の様に発生するシステムトラブルやユーザー問い合わせに大変な思いをしている運用サポート担当者の姿を見て、「システム障害調査」を行ってみました。
ユーザーが利用する管理画面でデータを送信したが画面にエラーが出て正常に登録されないという問題は、システムの登録箇所にバリデーションが構築されておらず、想定外文字列がデータベースに登録されてしまったために、不具合に発展してしまったようです。
また次の日には、そのことが原因でデータベースサーバーがダウンしてしまったため、緊急のシステムメンテナンス作業を数時間かけて行う羽目になっており、
別の日には、アクセスの多さにフロントサーバーはバランシングされているのに、データベースがサーバーが1つしかなかったため、負荷値がオーバーしてOSごとダウンしている状態。
こうしてサポート業務のほとんどがデータベースサーバー障害であることが判明して、その会社で次のWEBサービスを構築する時に、こうした運用トラブルを少なくしたいと言う思考から、データベース障害が無いサービスを作ろうと言う事で、データベースを設けないシステム構築を検討したことがきっかけで、SQLとおさらばすることにしました。
概念紹介
そもそもLAMPという言葉を真に受けて、システムにはSQLが必須と考えるエンジニアが非常に多いようですが、インターネット黎明期のWEBシステムは、SQLなどなく、データはテキストに書き込んで保存しているだけだったのですが、実はその方式の方がSQLよりも管理もメンテナンスも扱いも簡単なため、残された問題として、アクセスクオリティとして、ビッグデータレベルのデータが扱えれば、そもそもSQLなど必要ないという事になります。
と言う事で、データは全てテキストファイルに書き込む方式でどのように効率的な管理が行えるかを考えた実績に基づく方式なので、初心者もLAMPを信じてやまない人もこの方式を覚えてスピード開発を実感してみてください。
基本的にはPHPなどのサーバーサイドプログラムでテキストに書かれた文字列を読み書きするだけで実行するだけなのですが、やり方を細かく解説しておくので、自分で読み書きプログラムを書いて汎用性を持たせておくともはやSQLなどは必要がなくなることに気がつくでしょう。
データファイル構成
データファイル形式は、大きく3つあり、これらを柔軟に使いこなすことでSQLに負けないスピードが得られます。
CSV形式
カンマ(,)区切りで文字列をカラム区切りにする方式てレコード単位に改行(\nのみ)していきます。
非常にシンプルですが、Excelなどのアプリから出力されるネイティブのcsvとは互換性が無く、各セル内部の改行をダブルクォート内で柔軟に行うネイティブCSVに対して、このテキストCSV形式は改行する場合は、置き換え文字にするか、エスケープ処理を行います。
理由としては、データ検索の時に改行=レコードという扱いにする為です。実際に構築するとその扱いが理解できると思いますが、ネイティブCSVはインポータなどを作ってコンバート対応するのがいいでしょう。
そして、最も気をつけなければいけないポイントはカンマ(,)区切りを使う為、セルの内部でのカンマは置き換え文字対応しなければいけません。
この際に使用する置き換え対応文字はカンマのHTML文字コード変換した、,にするのがいいでしょう。
書き込む時に , => ,に変換し、読み込んだ時に、, => , に復元するのがいいでしょう。
そしてここで一つ注意したいポイントは、文字列として,を書き込みたい時に勝手にデコードされてしまうという問題が発生します。
そのため、この手法の時は、カンマの他にもう1文字アンパサンド(&)もその文字コードの&変換しておくのがセオリーです。
この変換と復元方式は、 エスケープ処理ではダメな為、きちんとこの辺の変換プログラムをライブラリとして作っておくことが重要です。
この方式は、Linuxなどのシステムログで使われている方式なので、馴染みやすいと思います。
JSON形式
csvデータでは、カラムにkey情報が持たせられない為、マトリクスデータの位置関係を固定化する必要があります。
感まで区切られた先頭から何番目にどういう情報を持たせるかといういわゆるテーブル設計書をきちんと作っておかなければ、その後の追加開発などでトラブルになってしまいますが、csv形式の大きなデメリットは、カラム位置の変更が、一旦構築してしまうと極めて難しくなる点です。
SQLのように、テーブルに書き込む順番などは何も考えなくてもできる方が効率が良い場合は、JSON形式での登録が便利に使えます。
PHPでも、他のCGI言語でも、ほぼネイティブでサポートされるようになったJSON言語は、テキストデータベースには極めて相性のいい方式です。
1ファイルにJSON形式を１データ保存できるこのやり方は、管理画面のマスター設定をする場合などに便利に利用でき、データ更新する際は、1ファイルの全てのデータをそのまま上書きするやり方でいいのですが、上書きがいやで履歴を残したい人は、ファイルをリネームして毎回新規ファイル作成するという事もできます。
ただし、ファイル数が増えた時の管理も大変になるので、ファイル管理の仕組みを作るのも忘れないようにしましょう。
JSONレコード方式
JSONによる1つのデータで1つのJSON形式を保持するのでは、物足りない場合は、1ファイルデータを1行JSON形式にして、それをレコード毎に改行登録するJSONレコード方式を採用するといいでしょう。
絡む情報がシステム構築後に変動することが想定される場合や、key値を使って、ユーザーデータ一覧の管理をしたい場合などは、この方式が非常に便利に使えます。
PHPではデータ配列をjson_encodeとして簡単に扱えます。
管理が楽な分、csv方式よりも、スピードが劣る為、ビッグデータとして使いたい場合は、csv形式をおすすめします。
テキストデータベースに慣れてくると、実データをcsv方式、そのcsvデータテーブルの管理情報をjson形式で管理するのが僕のよくやる方式で、それはもはやSQLのテーブル設計と同じやり方で、便利な言い方をすると、SQLのテーブル設計をそのままテキストデータベースに置き換える事も可能ということです。
0 件のコメント:
コメントを投稿