mongodb - バグデータベースを処理するための最良の手法 (並列計算?)

Question

私は、私たちのウェブサイトのすべての Google アナリティクスデータを抽出して分析し、データベースに入れ、そのデータに関するレポートを作成するというタスクを与えられました。問題は、テーブルに 200 万近くのレコードができてしまうことです。レポートはいくつかの SUM() および AVG クエリで構成されており、場合によっては時間がかかりすぎることが想像できます (日付フィルターを設定せず、広範囲の条件 (レポートの種類によって異なります) で最悪の場合) は 8 ～ 10 分かかります）。ユーザーがこれらのレポートにアクセスできることを考えると、今回は受け入れられません...現在、プロジェクトはPostgresを使用しています。特に単一のマシンで実行している RDMS では、この種のデータを 10 秒未満で処理できないことは十分承知しています。

問題は、良い結果を達成するためのソフトウェアとアーキテクチャ/技術の最良の選択は何かということです。

MongoDb を試してみましたが、シングルスレッドであるため、map/reduce は 1 台のマシンで実際には高速に動作しません (少なくとも現時点では)。

おそらく並列システムを検討していることはわかっていますが、まだ確信が持てません... mongoDBを快適に使用でき、クラスタリングや複数のノードの使用などすべてに関して大幅に改善されていることを読みましたが、誰か他の意見や経験を共有したいと思います計算能力だけでなく、価格面でも最も効率的な方法で。

ありがとう

PSpostgresがこの量のデータを処理する必要があるという回答のいくつかに関して、私はいくつかの詳細を投稿しています:

テーブル構造:

   -- Table: ga_content_tracking

-- DROP TABLE ga_content_tracking;

CREATE TABLE ga_content_tracking
(
  id serial NOT NULL,
  country character varying(255),
  city character varying(255),
  page_title character varying(255),
  page_path character varying(255),
  source character varying(255),
  referral_path character varying(255),
  date date NOT NULL,
  visits integer,
  pageviews integer,
  avgtime_on_site double precision,
  yacht_id integer,
  charter_listing boolean DEFAULT false,
  sales_listing boolean DEFAULT false,
  directory_listing boolean DEFAULT false,
  news_related boolean DEFAULT false,
  visitor_type character varying(30),
  organisation_id integer
)
WITH OIDS;
ALTER TABLE ga_content_tracking OWNER TO postgres;

-- Index: ga_content_tracking_charter_listing

-- DROP INDEX ga_content_tracking_charter_listing;

CREATE INDEX ga_content_tracking_charter_listing
  ON ga_content_tracking
  USING btree
  (charter_listing);

-- Index: ga_content_tracking_country

-- DROP INDEX ga_content_tracking_country;

CREATE INDEX ga_content_tracking_country
  ON ga_content_tracking
  USING btree
  (country);

-- Index: ga_content_tracking_dates

-- DROP INDEX ga_content_tracking_dates;

CREATE INDEX ga_content_tracking_dates
  ON ga_content_tracking
  USING btree
  (date);

-- Index: ga_content_tracking_directory_listing

-- DROP INDEX ga_content_tracking_directory_listing;

CREATE INDEX ga_content_tracking_directory_listing
  ON ga_content_tracking
  USING btree
  (directory_listing);

-- Index: ga_content_tracking_news_related

-- DROP INDEX ga_content_tracking_news_related;

CREATE INDEX ga_content_tracking_news_related
  ON ga_content_tracking
  USING btree
  (news_related);

-- Index: ga_content_tracking_organisation_id

-- DROP INDEX ga_content_tracking_organisation_id;

CREATE INDEX ga_content_tracking_organisation_id
  ON ga_content_tracking
  USING btree
  (organisation_id);

-- Index: ga_content_tracking_sales_listing

-- DROP INDEX ga_content_tracking_sales_listing;

CREATE INDEX ga_content_tracking_sales_listing
  ON ga_content_tracking
  USING btree
  (sales_listing);

-- Index: ga_content_tracking_visitor_type

-- DROP INDEX ga_content_tracking_visitor_type;

CREATE INDEX ga_content_tracking_visitor_type
  ON ga_content_tracking
  USING btree
  (visitor_type);

-- Index: ga_content_tracking_yacht_id

-- DROP INDEX ga_content_tracking_yacht_id;

CREATE INDEX ga_content_tracking_yacht_id
  ON ga_content_tracking
  USING btree
  (yacht_id);

クエリの例:

superyachts=# SELECT SUM( pageviews ) as cnt, SUM( visits ) as cnt1, AVG( avgtime_on_site ) as avg1 FROM ga_content_tracking gact WHERE TRUE AND ( yacht_id IN ( 7727, 7600, 2352, 7735, 7735, 3739, 7620, 7631, 7633, 7775, 3688, 7779, 3930, 2884, 2724, 2547, 3465, 2324, 4981, 2369, 7820, 4772, 7802, 7249, 4364, 7623, 7803, 7804, 7805, 7957, 7728, 7728, 7252, 8044, 8067, 8016, 8017, 8019, 2726, 2726, 2233, 4549, 6021, 8286, 4773, 8326, 8312, 4881, 8349, 2223, 4387, 2697, 6224, 5947, 4967, 3031, 7494, 7497, 3833, 6594, 6608, 3587, 6599, 3160, 4934, 3122, 4895, 3505, 4980, 8360, 2311, 4885, 2660, 5260, 2362, 2783, 2992, 3286, 3434, 4849, 4117, 2179, 5002, 2187, 5006, 2266, 4900, 4069, 6219, 2951, 3317, 3474, 6218, 3847, 4745, 6480, 4498, 6094, 6312, 6092, 7221, 7220, 2257, 4883, 6518, 2597, 4902, 2638, 2690, 4872, 2790, 6221, 2881, 2887, 3082, 3131, 3141, 3166, 3166, 4887, 4979, 3295, 4886, 4875, 6516, 5005, 3400, 3401, 4990, 3489, 5007, 4882, 4899, 5116, 4082, 4970, 3760, 2202, 2411, 2605, 6291, 6513, 7176, 3029, 8412, 2064, 7826, 4876, 4949, 3626, 5587, 8554, 2837, 5086, 5118, 2058, 4484, 4041, 2953, 8136, 2490, 3291, 4991, 2611, 3590 ) OR organisation_id = 1 ) ;
  cnt   | cnt1  |      avg1       
--------+-------+-----------------
 640826 | 46418 | 34.408638690454
(1 row)

Time: 114652.334 ms

score 1 · Accepted Answer

特に単一のマシンで実行している RDMS では、この種のデータを 10 秒未満で処理できないことは十分承知しています。

どこから推測されているのかわかりませんが…

test=# create table test (id int not null);
CREATE TABLE
test=# insert into test select i from generate_series(1,2000000) i;
INSERT 0 2000000
test=# alter table test add primary key (id);
NOTICE:  ALTER TABLE / ADD PRIMARY KEY will create implicit index "test_pkey" for table "test"
ALTER TABLE
test=# vacuum analyze test;
VACUUM
test=# \timing
Timing is on.
test=# select sum(id), avg(id) from test;
      sum      |         avg          
---------------+----------------------
 2000001000000 | 1000000.500000000000
(1 row)

Time: 566.079 ms
test=# select sum(t1.id), avg(t1.id) from test t1 natural join test t2;
      sum      |         avg          
---------------+----------------------
 2000001000000 | 1000000.500000000000
(1 row)

Time: 5891.536 ms

上記は、5 年前の MacBook で実行されている PostgreSQL 9.1 ベータ版です (その時点では、Pro 1 でさえありません)。ご覧のとおり、0.5 秒で 2M 行を飲み込み、6 秒弱で 2M x 2M 行を結合します。

ポイントは、Postgres はこの種のデータを 10 秒未満で処理できるということです。

score 0 · Accepted Answer

私は、PostgreSQL が数百万行で大きな問題を起こすべきではないという Denis に同意します。ただし、ユーザーを Google アナリティクスに追加して、Google のサーバーに対して実行させることもできます。

きれいな色は、長い間あなたの髪からそれらを遠ざけるかもしれません.

mongodb - バグ データベースを処理するための最良の手法 (並列計算?)

2 に答える 2

Related

Reference

mongodb - バグデータベースを処理するための最良の手法 (並列計算?)