奇妙なカップル：MongoDBと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 why?@192.0.2.3/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'） 。