4

単純なWebアプリケーションの場合、主な要件は、約3,000万（10m * 3テーブル）のレコードを可能な限り高速に処理することです。私はこれまでそのような量のデータを扱ったことがないので、経験豊富な人々からのいくつかの提案/アドバイスをお願いします。

データベースには、ビジネスの詳細が保持されます。約25の属性が単一のビジネスを表します。名前、住所など。テーブルの構造は次のとおりです。

CREATE TABLE IF NOT EXISTS `businesses` (
    `id` bigint(20) NOT NULL AUTO_INCREMENT,
    `type` int(2) NOT NULL,
    `organisation` varchar(40) NOT NULL,
    `title` varchar(12) NOT NULL,
    `given_name` varchar(40) NOT NULL,
    `other_name` varchar(40) NOT NULL,
    `family_name` varchar(40) NOT NULL,
    `suffix` varchar(5) NOT NULL,
    `reg_date` date NOT NULL,
    `main_trade_name` varchar(150) NOT NULL,
    `son_address_l1` varchar(50) NOT NULL,
    `son_address_l2` varchar(50) NOT NULL,
    `son_address_suburb` int(3) NOT NULL,
    `son_address_state` int(2) NOT NULL,
    `son_address_postcode` varchar(10) NOT NULL,
    `son_address_country` int(3) NOT NULL,
    `bus_address_l1` varchar(50) NOT NULL,
    `bus_address_l2` varchar(50) NOT NULL,
    `bus_address_suburb` int(3) NOT NULL,
    `bus_address_state` int(2) NOT NULL,
    `bus_address_postcode` varchar(10) NOT NULL,
    `bus_address_country` int(3) NOT NULL,
    `email` varchar(165) DEFAULT NULL,
    `phone` varchar(12) NOT NULL,
    `website` varchar(80) NOT NULL,
    `employee_size` int(4) NOT NULL,
    PRIMARY KEY (`id`),
    KEY `type` (`type`),
    KEY `phone` (`phone`),
    KEY `reg_date` (`reg_date`),
    KEY `son_address_state` (`son_address_state`),
    KEY `bus_address_state` (`bus_address_state`),
    KEY `son_address_country` (`son_address_country`),
    KEY `bus_address_country` (`bus_address_country`),
    FULLTEXT KEY `title` (`title`),
    FULLTEXT KEY `son_address_l1` (`son_address_l1`),
    FULLTEXT KEY `son_address_l2` (`son_address_l2`),
    FULLTEXT KEY `bus_address_l1` (`bus_address_l1`),
    FULLTEXT KEY `bus_address_l2` (`bus_address_l2`)
) ENGINE=MyISAM;

このような他の2つの表があります。理由は、各ビジネスの詳細が3つのソースで提示されるためです（比較のため）。1つのテーブルのみが書き込みを行います。

アプリの使い方については、

  1. 書き込みが少なく、読み取りがたくさんあります。
  2. 10 * 300万のデータは時間外に挿入されることはなく、最初に挿入されます。
  3. アプリには多くのリクエストはありません。1秒あたりのリクエスト数は10未満です。
  4. 最初のデータロード後、ユーザーはこれらの詳細を更新します。1つのテーブルのデータを他の2つのテーブルと比較し、最初のテーブルのデータを更新します。
  5. 主に名前、住所、電話番号、州で多くの検索が行われます。1回の検索で、3つのテーブルすべてが検索されます。検索は高速である必要があります。
  6. PHPを使用してビルドすることを計画しています

私の質問は、

  1. 3つのテーブルを持つのではなく、1つのテーブル内で3つのソースを処理する価値がありますか？
  2. MySQLは良い解決策を提供できますか？
  3. MongoDBは、より少ないハードウェアリソースを使用して同じシナリオを処理できますか？
  4. テスト用のサンプルデータベースをセットアップするための最良の方法は何ですか？Amazon RDS（ラージ）を購入し、10000レコードを挿入して、1,000万レコードになるまで2倍にしました。
  5. この主題について何か良い読み物はありますか？

ありがとうございました。

4

1 に答える 1

5

私はあなたの直接の質問に答えることはできませんが、私は大規模なデータセットを扱った経験があります。

私が最初に理解するのは、大多数のユースケース（あなたの場合は検索）の操作がどうなるかということです。次に、それに基づいてデータのストレージ/パーティション化を検討します。

次は、測定し、測定し、再度測定します。一部のデータベースシステムは、ある種類の操作でうまく機能し、他のデータベースシステムは他の種類の操作でうまく機能します。データの量が増え、運用が複雑になると、うまく機能していたものが劣化し始める可能性があります。これがあなたが測定する理由です-あなたが使用しているdbシステムがこれらの負荷の下でどのように機能するかについての良い証拠なしにこれを設計しようとしないでください。

次に、操作を追加するために繰り返し作業します。

すべてに最適なものを設計しようとしないでください。あなたのデザインと研究が蒸留されるにつれて、あなたは最適化が必要とされるか利用できるかもしれない場所を見るでしょう。また、過去に行ったように、さまざまなタイプのキャッシングとインデックス作成がさまざまな時期に行われる可能性があることにも気付くかもしれません。

頑張ってください-面白いプロジェクトのようですね。

于 2012-04-13T02:44:47.363 に答える