- NoSQLソリューションを使用する代わりに、SQLを使用して構造化データをデータベースに保存するのはなぜですか？
- クラウドホスティングサービスを使用する代わりに、独自のハードウェアを使用するのはなぜですか？
これらの質問はどちらも論理的で興味深いものです。 今日は、最初の質問に答え、別の投稿のために2番目の質問を保存します。
正しく使用すると、連想配列（キー値）にデータを保存するための最新のメカニズムにより、SQLサーバーの単一インスタンスと比較して、パフォーマンスとスケーラビリティが大幅に向上します。 ただし、すべてのアカウント情報をMySQLに投稿することにした理由はいくつかあります。
SQLの利点
まず、MySQLを備えたInnoDBなどのトランザクションデータベースのACIDプロパティは 、アプリケーションと同期モデルにとって重要です。
サーバーデータベースにメモ帳とメモを保存するためのデータベーステーブルの小さなフラグメントを次に示します。
CREATE TABLE notebooks (
id int UNSIGNED NOT NULL PRIMARY KEY,
guid binary(16) NOT NULL,
user_id int UNSIGNED NOT NULL,
name varchar(100) COLLATE utf8_bin NOT NULL,
...
) ENGINE=InnoDB DEFAULT CHARSET=utf8;
CREATE TABLE notes (
id int UNSIGNED NOT NULL PRIMARY KEY,
guid binary(16) NOT NULL,
user_id int UNSIGNED NOT NULL,
notebook_id int UNSIGNED NOT NULL,
title varchar(255) NOT NULL,
...
FOREIGN KEY (notebook_id) REFERENCES notebooks(id)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;
Evernote Windowsクライアントで「Recipes」というノートブックを作成し、すぐにお気に入りのキャセロールレシピをこのノートブックにコピーすると、クライアントは次の同期中に以下を実行します。
- NoteStore.createNotebook（）を呼び出して、サーバー上でノートブックの作成を要求します。 これにより、作成されたノートブックの識別子（GUID）が返されます。
- NoteStore.createNote（）を呼び出して、メモ帳のGUIDが既に設定されているサーバー上でメモの作成を要求します。
これらの高レベルAPIリクエストはそれぞれ、単一のSQLトランザクションを介して行われます。これにより、クライアントはサーバーの応答を完全に信頼できます。
ACID準拠のデータベースには、次のような利点があります。
原子性。 API呼び出しが成功した場合、100％の変更が行われ、API呼び出しが失敗した場合、いずれも行われません。 つまり、4番目の画像をメモに入れることができない場合、アカウントには半分の形式のメモがなく、さらに、データをダウンロードするための残りの月額から計算されます。
一貫性 API呼び出しが終了すると、アカウントは完全に機能し、内部的に一貫した状態になります。 各メモには独自のメモ帳があり、そのうちの1つは不明です。 データベースでは、FOREIGN KEY制約のため、まだノートがあるノートブックを削除できません。
保証 サーバーがノートブックが作成されたことを報告すると、クライアントはノートブックが既にあると見なし、これをさらなる操作（メモの作成を呼び出すなど）で考慮することができます。 この変更は保証されており、クライアントはいつでも常にサービスのステータスを反映していることを知っています。
保証の原則は、同期プロトコルにとって最も重要な役割を果たします。 クライアントアプリケーションが、サービスによって行われた変更の発生が保証されていることを確信していなかった場合、同期プロトコルははるかに複雑になり、効果が低下します。 同期された各クライアントは、各サーバーオブジェクトが現在の状況に一致するかどうかを常に確認する必要があります。 そのような変更が保証を意味しない場合、2万のメモ、4万のリソースファイル、および1万のタグを持つアカウントの一貫性に対する絶対制御のこのような実装は非常に高価になります。
大量のデータはどうですか？
トランザクションデータベースの場合のACIDの利点により、単一のサーバーを超えてデータをスケーリングすることは非常に困難になります。 データベースのクラスタリングと複数のマスターサーバーでの複製は非常に暗いビジネスであり、連想データストレージは、単一のリポジトリを複数のサーバーにスケーリングするためのはるかに簡単なアプローチを提供します。
幸いなことに、Evernoteはこの問題を今すぐ解決する必要はありません。 サーバーにはすでに約10億のメモと20億近くのリソースファイルがありますが、これは実際には単一の大きなデータセットではなく、ユーザーごとに1つずつ、2,000万の個別のセットです。
このような断片化は、大きな単一のデータボリュームを保存する問題がないことを意味し、多くの分離された中規模データセットのストレージを処理します。
おそらく将来的には...
その間、厳格なACIDトランザクション性を必要とせず、水平方向のスケーラビリティを提供する将来のプロジェクトのために、データストレージの分野で最新のテクノロジーに遅れないようにしています。 たとえば、当社のレポートおよび分析システムはすでにMySQLプラットフォームの機能を超えており、より大きく、より速く、より興味深いものに置き換える必要があります。
ただし、シャードベースのMySQLユーザーデータリポジトリには非常に満足していますが、一部の人によると、これはそれほどクールではありません。