ビッグデータのポスターの子シナリオ–小さなデータを抽出するには、大量のデータをふるいにかける必要があります。情報のナゲット」。また、それは可能な限り短い時間で行われる必要があり、あなたのビジネスはそれに依存しています。歴史的に、従来のリレーショナルデータベース管理システム（RDBMS）テクノロジを使用すると、この種のシナリオには大規模なチームと時間とお金の投資が必要でした。ほとんどの従来のRDBMSは垂直方向にしか拡張できないため、ターンアラウンドタイムを短縮するには、ますます大型のマシンを購入し続ける必要があります。パブリッククラウドとMongoDBのようなNoSQLデータベースの出現により、チームがこのシナリオについてどのように考えているかが完全に混乱しました。
最近、お客様の1人が興味深い問題を抱えて私たちのところに来ました。彼らは定期的に、データセット全体をスキャンする非常に複雑なクエリを実行する必要がありました。このクエリは、コレクション内のすべてのドキュメントに影響を与えるコレクションスキャンであり、次の詳細が含まれていました。
- 合計データは約100GBでした。
- データのマスターコピーは他の場所にあるため、データの安全性は問題ではありませんでした。
- クエリの速度は非常に重要でした。目標は、クエリ全体を10〜15分以内に実行できるようにすることでした。
- システムは、クエリの実行中にのみ稼働する必要がありました（コストを最小限に抑えます）。
最後の要件により、システム全体をパブリッククラウドで実行することは理にかなっています。データが更新され、クエリが実行されるまで、マシンは毎週数時間だけオンになります。お客様はすでにAmazonEC2に慣れているため、AWSでシステムのプロトタイプを作成することにしました。
この目標を達成するための最適な構成は、「シャーディングされた」MongoDBデプロイメントでした。決定した構成は次のとおりです。
- 3つのシャード–各シャードには30 GBのRAMを備えたスタンドアロンインスタンス（r3.xlarge）があります
- 1つの構成サーバー
- 15 GBのRAMを搭載した1つのシャードルーター（m3.xlarge）
私たちの選択について指摘すべきことがいくつかあります：
-
スタンドアロンとレプリカのセット
マスタデータは別のシステムに保存されるため、データの安全性はここでは重要な要件ではありません。そのため、コストを節約するために、レプリカセットではなくスタンドアロンサーバーを使用しました。
-
3つの構成サーバーと1つの構成サーバー
上記の理由。データの安全性は重要な問題ではありません。通常の実稼働環境では、3台の構成サーバーを使用していました。
この構成の本当の美しさは、シャーディングされた構成により、100GBのデータのほぼ全体が完全にメモリに保存されることです。したがって、基本的に実行しているのは「メモリ内」スキャンです。これにより、クエリの実行時間が数時間から10分未満に大幅に短縮されました。パブリッククラウドを使用すると、マシンの稼働時にのみ料金を支払うため、設備投資も大幅に削減されました。
これは、過去10年間にチームがこのシナリオを処理してきた方法に対するかなり劇的な変化です。したがって、「干し草の山で針を見つける」ビジネスをしている場合は、Cloud + NoSQLを考えてください！
いつものように、ご不明な点がございましたら、[email protected]までお問い合わせください。