リレーショナルDBMSがスタートアップに最適な理由：加藤メッセンジャーの開発履歴の例

歴史的に、コンピューターの開発はデータベース管理の分野の進歩と並行して行われました-これは、研究者や実践者が解決したタスクの中で、受信したデータの処理、コンパクトストレージ、最速の検索のタスクによって大きな役割が果たされた（そして現在も継続している）という事実によるものです。



したがって、技術の進歩は、プロセッサの電力、メモリの増加、またはデバイスサイズの縮小の分野だけでなく、データ効率の改善の分野でも進みました。 その結果、多数の異なるデータベース管理システム（DBMS）が登場しました。



当社の製品である加藤コーポレートコミュニケーションメッセンジャーは、PostgreSQL DBMSを使用しています。 今日、私たちはこの素晴らしいツールの歴史を思い出し、情報技術の分野でスタートアップに使用することの利点を示したいと思います。

リレーショナルモデルとSQL

DBMSの3つの主な方向は、これらの方向の基礎となるさまざまなデータモデル（ネットワーク、階層、およびリレーショナル）によって伝統的に区別されます。



リレーショナルデータモデルは、現在3つの名前の中で最も人気があり、高度なものですが、IBMの従業員である英国の科学者Edgar Coddによって、前世紀の60年代後半に最初に開発されました。 1970年に、彼はリレーショナルデータモデルに関する最初の研究である大規模共有データバンクのデータのリレーショナルモデルを発表しました。







エドガー・コッド、リレーショナルデータモデルの作成者



Coddは、データに対して実行できる8つの基本操作のセットを提案し、このセットがリレーショナル代数の基礎を築きました 。 前世紀の70年代半ばにCoddによって作成された代数に基づいて、1986年に標準化されたSQLと呼ばれるリレーショナルデータベースのデータを操作するためのプログラミング言語が開発され始めました（他の多くのものもあります）。

バークレーでの研究：ポストグレスの出現

最初のリレーショナルデータベース管理システムの1つはオープンIngresシステムでした。これは、プロジェクト、Project Rリレーショナルデータベースに関するIBMの出版物に興味を持つようになったバークレーの研究者によって作成され、独自のシステムを開発しようとしました。 IngresはクエリにSQL以外の言語を使用しました。これはQUELと呼ばれていました。



その後、以前Ingresの作成に携わったMichael Stonebreakerは、バークレーの学生と一緒に、新しいプロジェクト-Post In gres （Postgres）を立ち上げました。 新しいシステムは1986年から1995年にかけて開発され、QUELの後継であるPOSTQUELクエリ言語を使用しました。







マイケル・ストーンブレイカー



その後、StonebreakerはいくつかのDBMS企業を設立しました（例： Informixが購入した Illustra 、 StreamBase Systems 、HPが購入した Vertica 、 VoltDB ）。



Postgresに取り組んだ彼の学生は、POSTQUELがSQLに置き換えられた独自のバージョンのデータベースを作成しました。 このプロジェクトはもともとPostgres95と呼ばれ、カリフォルニア大学バークレー校が熱狂的なチームの手でこの開発を譲渡した後、現在の名前-PostgreSQL-を取得しました。

データベースエンジンの問題：NoSQLの誕生

90年代後半から2000年代初頭に、DBMS市場にはかなりの数の一般的なデータベースが存在する状況がありましたが、それぞれに重大な欠点がありました。 商用のOracle、IBM DB2、およびMicrosoft SQL Serverの場合、これらの欠点は非常に大きく、最も人気のある無料のMySQLプロジェクトは機能が制限されていました（たとえば、ストアドプロシージャ、トリガー、ビューは2005年にこのDBMSにのみ登場しました）。



同時に、PostgreSQLは、その開発者が膨大な量と一般に非常に高品質の作業を行ったという事実にもかかわらず、商業プロジェクトでの使用を制限した高速性と管理の容易さを自慢できませんでした。



一般にSQLとリレーショナルモデルを使用する既存の製品の問題により、愛好家は他の標準を使用して機能するデータベースを作成するようになりました。これは、共通のNoSQLカテゴリに結合できるプロジェクトの数です。







多くのNoSQLデータベースが登場しました（いくつかの有名な例：MongoDB、Redis、Riak）。 この方向性の開発は、断片化と高度に専門化された製品の作成のパスに沿って行われました。

DBMSとスタートアップ

多数の新しいNoSQL開発の出現は、ある時点でスタートアップの態度を従来のSQLシステムに変えました。ITプロジェクトの作成者は、ITプロジェクトの作成者に、現代の動的アプリケーションで作業するのが複雑すぎ、古く、困難であると認識し始めました。



しかし、徐々に、NoSQLカテゴリーのDBMSには次の重要な（そして非常に不快な）プロパティがあることが明らかになりました-それらは非常に狭く定義された問題のみを解決するのに適しています。 このプロパティにより、スタートアップでの条件付きMongoDBの使用は非常に危険なステップになりました-初期段階では、条件付きMongoDBは特定の範囲のタスクに理想的な選択かもしれませんが、スタートアップがその戦略を多少変更した瞬間（そしてこれはほとんど常に発生します）新しい定式化の問題を解決するのにより適しています。 ほとんどの場合、この他のDBMSへの「移動」は複雑すぎて費用のかかる操作になるため、初心者のビジネスではできません。



一方、NoSQLカテゴリからのDBMSの急速な開発の間、従来のリレーショナルDBMSの開発者も怠けていませんでした。 特に、PostgreSQLの作成者は、プロジェクトの生産性、管理の容易さ、文書化に取り組みました。その結果、2000年代の終わりに、「高齢者のひげを生やした太鼓腹のbげたおじさんのための退屈でわかりにくいアンティークツール」から、 「テクノロジーヒップスター」の武器庫。

PostgreSQLおよびKatoメッセンジャー

加藤チームの開発者は、さまざまなテクノロジー企業やスタートアップ（ Rdioプロジェクトなど）で採用されており、彼ら自身の経験から、多くの既存のDBMSで作業することの長所と短所を感じました（そして、ゼロからシステムを構築することに関連するほとんどすべての可能性のある熊手を同時に踏みました）。 その結果、プロジェクトの作業を開始するために、PostgreSQLを選択しました。



商業プロジェクトでは、さまざまな側面を拡大する良い機会を持つことが非常に重要です。 各プロジェクトには独自の側面があります。たとえば、加藤では、部屋のメッセージ履歴のベースをスケーリングする必要があります。







データスキーマの不変性は、NoSQLの一般的な利点の1つです。 PostgreSQLのhstoreモジュール（ちなみにMuscovites製）を使用すると、キーと値をテーブル列に書き込むことができます。これにより、開発者は新製品の機能を追加するプロセスでデータスキームを絶えず変更する必要がなくなります。 同時に、インデックスを作成する機能は残ります。



PostgreSQL 9.2では、新しい型JSONが導入されています 。 hstoreとは異なり、JSON型はネストされた構造をサポートするため、PostgreSQLはドキュメントを操作するための便利なツールになります。 jsonbタイプでは、GINインデックスを作成できることも重要です。これにより、JSONオブジェクトをすばやく検索できるようになります。



hstoreとJSON型の導入により、PostgreSQLテーブル内にNoSQLスタイルのデータベースを作成できるようになりました。これにより、NoSQLとSQLの利点を同時に使用できます。



hstoreモジュールの機能を説明するためのいくつかの典型的な操作を次に示します。



hstore拡張機能とhstore型の列を持つテーブルを作成します。

postgres=# create extension hstore; WARNING: => is deprecated as an operator name DETAIL: This name may be disallowed altogether in future versions of QL. CREATE EXTENSION postgres=# create table hstore_test (data hstore); CREATE TABLE
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

hstoreエントリを追加します。2つのキーは、値が「hello」の「a」と値が「world」の「b」です。

 postgres=# insert into hstore_test values (hstore(array['a', 'hello', 'b', 'world'])); INSERT 0 1 postgres=#
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

キー「a」の値を確認します。

 postgres=# SELECT data->'a' FROM hstore_test; ?column? ---------- hello (1 row) postgres=# ▄
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

キー「a」と「c」が存在するかどうかを確認します。

 postgres=# select data ? 'a', data ? 'c' from hstore_test; ?column? | ?column? ----------+-------------- t | f (1 row)
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

キー「b」の値を変更します。

 postgres=# update hstore_test set data = data || ('b' => 'world!'); UPDATE 1 postgres=# select data->'b' from hstore_test; ?column? -------------- world! (1 row)
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

hstoreタイプのすべての操作は、PostgreSQLプロジェクトドキュメントの対応するセクションで説明されています 。



Katoメッセンジャーでは、hstoreテーブルを使用して、アカウント、ルーム、チーム、組織などのさまざまなオブジェクトの設定と属性を保存します。

歴史の輪

ストーリーは輪になっており、多くの場合、「すべてが新しい-それは忘れられている」というフレーズが真実です-DBMSの構築とデータの操作における多くの現代の傾向は、リレーショナルモデルの作成者とSQL開発者によって理解され、予想されていました。



PostgreSQLは、世界をリードする専門家の研究結果を絶えず取り入れているプロジェクトの標準的な例です。 その結果、このDBMSは一種のユニバーサルデザイナーとして機能し、スタートアップはその詳細を使用して、予期しないタスク範囲の拡大に悩まされることなく、実用的な商用製品を非常に迅速に作成できます。