データベース
 Computer >> コンピューター >  >> プログラミング >> データベース

奇妙なカップル：MongoDBとMySQL

データストアの選択時に利用できる選択肢と組み合わせは、私たちがもはや万能のデータストアの世界にいないことを証明しています。

今日、SQLデータストア（MySQL、PostgreSQL、Oracle、SQLServerなど）をNoSQLデータストア（MongoDB、CouchDB、Neo4Jなど）と組み合わせて使用​​することには説得力のある理由がありますが、Oracleは依然として企業、それはもはや町で唯一のゲームではありません。

開発者は、SQLとNoSQLの組み合わせを使用して問題を解決し始めています。これは、DBAやIT部門の意向に反する場合もあります。

仕事に適したツールの選択

今日の世界には、列ファミリー、ドキュメント、グラフ、Key-Value、リレーショナルの5つの大きなカテゴリのデータストアがあります。ポリグロットの永続性とは、文字通り、データを保存または永続化するために多くの言語を使用することを意味します。より実際的な用語では、これは、同じアプリケーション内からデータにアクセスするために、Cypher、JSON、SQL、または他の多くのクエリ言語を使用する可能性があることを意味します。開発者が永続性のニーズに対するソリューションでレーザーを使用するためのより優れたツールを探すにつれて、さまざまな言語がより目立つようになっています。

SadalageとFowlerは、次のように言って、NoSQLDistilledでのポリグロットの永続性の必要性に注目しています。

さまざまなデータベースがさまざまな問題を解決するように設計されています。すべての要件に単一のデータベースエンジンを使用すると、通常、パフォーマンスの低いソリューションになります。トランザクションデータの保存、セッション情報のキャッシュ、顧客のトラバースグラフ[原文のまま]、および友人が購入した製品は、本質的に異なる問題です。

データの関係について考えてみましょう。RDBMSソリューションは、関係が存在することを強制するのに適しています。関係を検出したい場合、または同じオブジェクトに属する異なるテーブルからデータを検索する必要がある場合、RDBMSの使用は困難になり始めます。

>

データストアの選択は、次の2つの基準に分類されます。

  1. 保存されるデータの構造
  2. データの操作に使用されているクエリ

データのクエリ方法によって、データの構造が変わります。SadalageとFowlerが上記のように述べているように、リレーショナルデータストアは関連するエンティティの適用に優れています。ただし、これらのエンティティ間の他の関係を発見する必要があるとすぐに邪魔になります。

以下では、1つのユースケースであるMongoDBを使用したCraigsListデータのアーカイブについて説明し、それらがこれをどのように達成したかについて推測します。

プレーヤー：MongoDB、MySQL、CraigsList

MongoDB

MongoDBは、MySQLに代わるNoSQLとして好まれています。その多くの利点には、スケーラビリティ、自動シャーディング、今日の人気のあるプログラミング言語のネイティブバインディングの可用性などがあります。MongoDBとリレーショナルデータストアの主な差別化要因は、MongoDBがデータを考えて保存する方法です。外部キー制約のあるテーブルのコレクションを使用して関係を強制すると、MongoDBのデータはドキュメントのコレクションとして表されます。

ドキュメントは、リレーショナルデータ構造の行またはタプルに類似しています（同一ではありません）。ドキュメントデータストアの分類と命名法は、コレクションにグループ化されたJSONドキュメントとして保存されているデータから直接取得されます。これらのドキュメントの深さは無制限であり、クエリまたはインデックス。通常、リレーショナルデータベースに適したデータを非正規化することで、MongoDBのデータを適切に表現できます。もちろん、実行する特定のクエリがこのプロセスをガイドする必要があります。

MongoDBのニュアンスの詳細については、MongoDBのWebサイトを参照してください。

MySQL

誰もが知っていて愛している古典であるMySQLは、（タイムスケールの計算において）時代の幕開けから存在し、最も広く使用されているDBMSです。MySQLが提供する機能により、アプリケーションは10年近くデータをモデル化し、システムとして機能することができます。多くのビジネス目的で記録されています。最近、人々がリレーショナルデータベースについて考えるとき、おそらくMySQLについて考えます。

MySQLは、古典的なリレーショナルデータモデルの実装を提供します。タイプ理論とセット理論を使用して、1970年代にE.F. Coddによって開発されました。プログラムで正規化、計画、または内省できるため、リレーショナルデータシステムは非常に人気があります。 、これらのデータストアは、一般的な方法でデータのモデリングの問題を解決するため、引き続き支持されています。

CraigsList

MongoDBとMySQLの両方のデータストアを採用している有名なオンラインビジネスの1つがCraigsListです。2つのデータストアを並べて採用する方法はMongoDBのケーススタディで概説されていますが、以下はサムネイルスケッチです。

規制要件により、Craigslistはその分類のデジタル記録を保持する必要があります.1日あたり100万を超える新しい分類があるため、CraigsListが保持するのはかなりの量のデータです.MySQLデータストアを使用して分類に関するすべてのアクティブな情報を保持しますが、 MongoDBは、アーカイブされたデータを保存するために使用されます。おそらく30日以上です。通常のビジネス変更の一環として、保存されたデータのデータスキーマが変更されます。アーカイブされたデータにMongoDBを使用することで、CraigsListはデータを効果的にセグメント化し、スキーマの移行。

思考実験として、CraigsList風のアプリケーションでMongoDBとMySQLを並べて使用するための1つの可能な実装について推測したいと思います。これが、CraigsListが実際にデータストレージを実行している方法である可能性はほとんどありませんが、興味深いことです。使い慣れた、トランザクション性の高いWebサイトで、複数のデータストアがどのように連携できるかを確認する方法。

どのように行われますか？

開発者やエンジニアは、かさばるSQLデータベースでスキーマの更新を実行すると、必然的に問題が発生します。これは、スキーマの更新が適用された後に「修正」するデータを少なくすることで回避できます。これらの移行やスキーマの更新の苦痛は通常増加します。データ量に比例します。

この例では、CraigsListがアイテムを販売するユーザーからの新しい情報を必要としていると想像してください。スキーマを更新する必要があるため、CraigsListは影響を受けるデータのサイズを縮小して、更新の手間を最小限に抑えたいと考えています。

これらのアーカイブと移行のサイクルのいくつかの後、CraigsListは、単一の場所に存在する場合はスキーマレスデータストアを必要とする異種データの膨大なコレクションを構築します。MongoDBはこの法案に非常によく適合します。

求人広告のスキーマの例は、次のようになります（craigslist-cloneから恥知らずに再実装されます）：

CREATE TABLE `classifieds` (
  `id` int(11) NOT NULL AUTO_INCREMENT,
  `title` varchar(75) COLLATE utf8_unicode_ci DEFAULT NULL,
  `description` text COLLATE utf8_unicode_ci,
  `location` varchar(75) COLLATE utf8_unicode_ci DEFAULT NULL,
  `adtype` varchar(1) COLLATE utf8_unicode_ci DEFAULT 'O',
  `email` varchar(75) COLLATE utf8_unicode_ci DEFAULT NULL,
  `phone` varchar(75) COLLATE utf8_unicode_ci DEFAULT NULL,
  `activation_code` varchar(40) COLLATE utf8_unicode_ci DEFAULT NULL,
  `status` tinyint(4) DEFAULT '0',
  `category_id` int(11) DEFAULT NULL,
  `subcategory_id` int(11) DEFAULT NULL,
  `city_id` int(11) DEFAULT NULL,
  `permalink` varchar(255) COLLATE utf8_unicode_ci DEFAULT NULL,
  `image_file_name` varchar(255) COLLATE utf8_unicode_ci DEFAULT NULL,
  `image_content_type` varchar(255) COLLATE utf8_unicode_ci DEFAULT NULL,
  `image_file_size` int(11) DEFAULT NULL,
  `created_at` datetime DEFAULT NULL,
  `updated_at` datetime DEFAULT NULL,
  PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci;

もちろん、CraigsListは異なるスキーマを持っている可能性が高く、少なくとも数回の反復後に現在のスキーマを検出します。また、データの編成方法を変更し、将来的にスキーマを再度変更することを決定する可能性があります。<を使用します。 code> created_at およびupdated_at MySQLに含まれるデータをいつアーカイブするかを決定するフィールド。

Craigslistの求人広告ポリシーでは、求人広告は2週間ウェブサイトで引き続き利用可能であると述べているとしましょう。この後、求人広告は引き続き利用可能ですが、必ずしもアクティブである必要はありません（MySQLで）。これを実現するには、SQLAlchemyを組み合わせて使用​​できます。とpymongo：

まず、MySQLインスタンスからデータを取得する必要があります。これを実現するためにSQLAlchemyを利用し、スキーマをイントロスペクトします（この目的でこのコードをはるかに再利用できるようにします）。

import sqlalchemy.schema

m = sqlalchemy.schema.MetaData("mysql://root:I'm required [email protected]/craigslist")
m.reflect()

print m.tables.keys()

データベースに正常に接続すると、キー（列名）が標準のPython形式で出力されます： [u'classifieds'、u'cities'、u'subcategories'、u'categories' ] 。これらのテーブルから個々のデータ項目を取得する必要があります。それらを表示できるだけでなく、SQLAlchemyは、これを非常に簡単にするためのエレガントなインターフェイスも提供します。

これで、イントロスペクションからのテーブル定義が得られました。オブジェクトマップを作成するか、それらのテーブルをクエリして、それらに含まれるデータアイテムを取得します。以下のクエリは、データストアから分類を抽出します（他のテーブルは、読者）。

import sqlalchemy.sql

connection = m.bind.connect()

classifieds = m.tables['classifieds']

query = classifieds.select()

result = connection.execute(query)

for row in result:
    print dict(row.items())

このスニペットは、MySQL接続を使用して、すべての求人広告をクエリします。すべてのテーブルを処理するように簡単に拡張して、MongoDBのドキュメントスタイルに合わせてデータを非正規化できます。ただし、このデモンストレーションでは、焦点を絞るだけです。案内広告の表にあります。この時点で、クラシファイドテーブルのすべてのアイテムを辞書に変換しました。これは、pymongoを介してMongoDBに挿入するために必要なものです。

次のサンプルは、pymongoに接続して辞書を挿入する方法を示しています。

import pymongo

client = pymongo.MongoClient('mongodb://192.0.2.2')

db = client['craigslist']
collection = db['classifieds']
collection.insert({'_id': 1})

現在の唯一の問題は、SQLAlchemyとMongoDBがIDを指定する方法です。SQLAlchemyは idのキーを使用します 一方、MongoDBは _idのキーを使用します したがって、そのキーを変換する必要があります（非常に単純なプロセス）：classified ['_ id'] =classified.pop（'id'） 。

結論

SQLとNoSQLのデータストアはオールオアナッシングの命題として描かれることがよくありますが、これらを一緒に使用して複雑な問題を解決できることがわかりました。この例では、MongoDBとMongoDBの両方を利用するシステムに必要なコードはごくわずかであることがわかりました。 MySQLデータストア。実際、これはデーモン化されるのではなく、cronによって駆動される可能性があります。

複数のデータストアを利用することの難しさは、必ずしも翻訳コードや移行コードの開発にあるとは限りませんが、追加のシステムの管理は難しさを増します.1つのデータストアを維持するには、すでに専門知識（DBAまたはデータストアの知識を持つ管理者）が必要です。より多くのデータストアを導入すると、専門知識に対する需要が高まります。

ビジネスは、複数のデータストアを実行することが価値があるかどうかを判断する必要があります。これらの課題を軽減するのに役立つテクノロジーがあります。

ChefやSaltなどの自動化技術に加えて、RackspaceによるマネージドMongoDBサービスであるObjectRocketなどのサービスベンダーを利用することで、この課題を軽減できます。複雑さが増しても、問題が複数のデータストアを使用することでメリットが得られる場合は、 、仮定がそれらの解決策を探求するのを妨げないようにしてください。


  1. ObjectRocketは、MongoDBを正常で利用可能な状態に保ちます

    元々は2020年11月にObjectRocket.com/blogで公開されました Rackspaceでは、ObjectRocketチームがMongoDB®データベースの管理を支援します。災害復旧、レプリケーション、フォールトトレランス、およびMongoDBデータベースの高可用性を提供します。 はじめに ObjectRocketは現在、シャードとレプリカのMongoDBインスタンスオプションを提供していますが、舞台裏では、データの冗長性とフォールトトレランスのために常に3つのメンバーのレプリカセットを使用しています。メンバーレプリカセット。 ただし、ディザスタリカバリは別の問題です。

  2. DBAとデータアーキテクトの進化

    企業の顧客、従業員、およびパートナーがユーザーフレンドリーなシステムを介してデータに簡単にアクセスできる場合、データベース管理者とデータアーキテクトの2人に感謝します。十分に構築されたデータベースが潜在的に数千または数百万のユーザーに対して確実かつ安全に機能することを保証することは大きな責任であり、あらゆる業界の企業は、データアーキテクトとDBAに依存して、それらを使用するすべてのユーザーのニーズを満たすデータネットワークを設計および監視します。 ビジネスコミュニティのデータニーズが急増するにつれて、最新のデータベーステクノロジーに対応するために必要なスキルも拡大しています。これらの役割の