RDBMSの基本とNoSQL その1 第04回 16年10月 / 最終更新：2016.10.18
みなさん、こんにちは。エンジニアの古庄道明です。
今回は、RDBを含む、database周りについて少しお話しをさせていただければ、と思います。
このあたりはゲームでも業務でも大枠は一緒かと思われるのですが。
データというのは、システムにとってとても大切なものになります。
「データが恒久的に消えたから会社的に大打撃が発生した」という事例は、業務でもゲームでも、過去に実例が複数存在します。
明記は避けますが、読まれている方の中には「………あぁ」と思いだされる事例がある方も、あるいはいらっしゃるのではないでしょうか。
また「プログラムよりもデータ(ベース)のほうが寿命が長い」などという事を言われる時もありますように、データは非常に(基本的には)寿命が長いもの、になります。
一瞬脱線をいたしますが。
昔々その昔、くらいの頃は「動いているシステムには1bitたりとも手を入れるな」と言われていた時代もあったように記憶をしておりますが、現代はどちらかというと「きちんとユニットテストなどを記述していることを前提に、定期的なリファクタリングはむしろ必須である」といった風潮のほうに傾いているように思われます。
かように、プログラムは現在「メンテナンス性が一定レベル担保されている」事が大切であるように思われます。
メンテナンス性が一定未満だと、運用時に大変になるので、いわゆる「DevOps」の観点からも、あまり歓迎されないように思われます。
少し本題に戻していきまして。
まず「データが重要」なのは大前提としまして。
いわゆる「データを格納する方法と手段(RDB的には、テーブル設計等)」は、もちろん「絶対に変更不可」ではないのですが、変更する際には、変更内容によっては「些か重労働になる」のも確か、になります。
さりとて「一手目で詰めまで読み切る」将棋が不可能であるように、「このビジネスが終了するまでのすべてのビジネス要件をあらかじめすべて正確かつ完璧に把握し理解し分析できる」状況、というのも、なかなかに難しいものがある、と考えます。
そういたしますと、必然的に「後で(程度問題はあるにせよ)修正がしやすい」作り、という方向が、一つの解として出てきます。
今回からしばらくの間、この「後で修正しやすい」データ設計、について、お話をさせていただければ、と思います。
さて。
昨今色々なデータベース製品が出てきてはおりますが、とはいえなんだかんだ、最有力候補にして最大手なのがRDB(relational database：関係データベース)になります。
時々は「RDBを使わないでシステムを組んだ！！」といったお話を伺う事もあるのですが、ほとんどのシステムでは、今でもRDBを使っているのではないでしょうか？
本稿では、このRDBの基本的な特徴とメリット、デメリットと欠点を見ていき、いわゆる「NoSQL」が出てくるに至った理由を考察しつつ、それらをいかにうまく使いこなしていくか、についてお話をさせていただければ、と思います。
RDBですが、基本的には「(CAP定理のうち)一貫性と可用性がある」もので、かつ大抵のRDB製品には「ACID特性をもつ、トランザクションが実装されている」のが特徴であるかと思われます。
また、CAP定理に沿って考えた場合に「分断耐性がない」事、トランザクションや柔軟なSQL文のために「重かったり遅かったりする」事がRDBの主だった欠点になり、NoSQLはおおむねそのあたりを「どうにかするために」作り出されているものが多いように思われます。
次回以降、これらの特徴について簡単に説明をした後、いかにして「変更に強い」設計をしていくか、について、技術とビジネスの双方の観点から書いていきたいと思います。
サービス・ソリューション
