лучший метод для обработки ошибок базы данных (параллельные вычисления?) - PullRequest
0 голосов
/ 09 июня 2011

Мне было поручено извлечь все данные Google Analytics для нашего веб-сайта, проанализировать их, поместить в базу данных, а затем подготовить некоторые отчеты по этим данным. Проблема в том, что я получаю почти 2 миллиона записей в таблице. Отчеты состоят из нескольких запросов SUM () и AVG, которые, как вы можете себе представить, в некоторых случаях выполняются слишком долго (в худшем случае без установки фильтра даты и по широкому диапазону критериев (зависит от типа отчета) занимает от 8 до 10 минут. ). Учитывая, что пользователи будут иметь доступ к этим отчетам, это время недопустимо ... В настоящее время в проекте используется Postgres. Я более чем осведомлен о том, что ни одна СУБД не будет обрабатывать такие данные менее чем за 10 секунд, особенно на одной машине.

Вопрос в том, что было бы лучшим выбором программного обеспечения и архитектуры / техники для достижения хороших результатов?

Я пробовал MongoDb, но на самом деле карта / уменьшение не работает быстрее на одной машине, учитывая, что она однопоточная (пока, по крайней мере).

Я знаю, что, вероятно, изучаю параллельную систему, но все еще не уверен ... Я чувствую себя комфортно, используя mongoDB, и я читаю, что они значительно улучшаются с точки зрения кластеризации и использования нескольких узлов, но я хотел бы, чтобы кто-то поделился другими мнениями и опытом, чтобы наиболее эффективно сделать это не только с точки зрения вычислительной мощности, но и с точки зрения цены. условия также.

Спасибо

P.S. Относительно некоторых ответов, которые postgres должен обрабатывать таким количеством данных, я публикую некоторые подробности:

Структура таблицы:

   -- 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

Ответы [ 2 ]

1 голос
/ 09 июня 2011

Я более чем осведомлен о том, что ни одна СУБД не будет обрабатывать такие данные менее чем за 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

Выше приведена PostgreSQL 9.1-бета, работающая на 5-летнем MacBook (и даже не Pro). Как вы можете видеть, он проглотит 2M строк за полсекунды и соединит 2M x 2M строк чуть меньше 6 с.

Суть в том, что Postgres будет рад обрабатывать такие данные менее чем за 10 секунд, даже на одной машине.

0 голосов
/ 09 июня 2011

Я согласен с Денисом, что у PostgreSQL не должно быть особых проблем с парой миллионов строк. Но вы также можете добавлять пользователей в Google Analytics и запускать их на серверах Google.

Красивые цвета могут надолго удерживать их от ваших волос.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...