Rails, кэширование/«прогрев» частых запросов к БД.

table-based partitioning, postgresql, table inheritance, partition solver constraints. Вот эти штуки позволят тебе сделать хорошо. EXPLAIN мне, например, говорит, что это именно так.

Но в Rails есть кэширование частых запросов. Мне бы просто ссылку на мануал, сдобренную словами «я делал, брат не умер».

На мануал слишком много, проще идти на сайт посгреса и читать. На пальцах выглядит так:

Создаешь пустую таблицу для сырых данных. Индексов, констрейнтов на нее не вешай, бесполезно (она все равно останется пустой). Вешай на нее триггер на INSERT (это я исхожу из того, что сырые данные у тебя не меняются, если меняются - два триггера, на инсерт и апдейт). Триггером разруливаешь по полям в NEW, в какую конкретно партицию пихать (я, например, понедельно бью на таблицы), там вычисляется имя реальной таблицы (например, бьешь по пользователям, таблица data, пользователь с id = 1 пойдет в таблицу data_1), пихаешь в вычисленную таблицу. Далее хитрый трюк: инсерт в триггере заверни в exception, что-то типа

insert into data_1 blabla
exception when table_not_found
    create table data_1 inherits data
    create constraint user_id = 1
    create index blabla
    insert into data_1 blabla

ты не понял, он хочет не на уровне БД, а на уровне приложения это сделать.
То, что в хибернейте/эклиспслинке давным-давно уже есть (кеши двух уровней), в рельсах, видимо, так просто не делается

Спасибо, но слишко навороченно, пока я сам в этом не разобрался, рисковать не буду. Проще вторую машину поставить.

В рельсах есть несколько видов кэшей, но часть, работающая с кэшами БД, плохо документирована (была, когда смотрел).

А какой-нибудь memcache(d) делу не поможет?

Есть очень большая таблица с «сырыми» данными.

Сколько записей?

Сотни миллионов.

он всё про Фоновая обработка задач. Внештатные ситуации.

Фоновая обработка задач. Внештатные ситуации.

ТС, у тебя, по факту, только один вариант, партиции по дате. Никакие самые волшебные кеши не спасут, дальше, с ростом данных, будет только хуже.

Очень интересно. А выкину лучше я всё, кроме хвоста этой таблицы. Раз в неделю «отделение» неиспользуемых старых данных.

А почему ты уверен что кэши не спасут? Мне бы запросы одного вида держать в памяти по 5-10 минут, это бы помогло.

тебя спасёт только просчитанный план исполнения, что можно получить только навтрыкав грамотных prepared statements (что в общем-то рельсы наверняка и делают, просто не дропают их сразу после использования).

P.S. предлагаю partitioning по часам со сбрасыванием архивов в другую таблицу, хотя если у тебя mysql то будет печальненько, т.к. у него с кол-вом партиций грустно.

храни в сторе 5-10 минут (expires_in)

Линк! Мануал бы оч пригодился)

http://guides.rubyonrails.org/caching_with_rails.html#cache-stores

Как насчёт ActiveSupport::Cache::Store#fetch?

Вот, как обещал, если тебе это еще интересно:

CREATE OR REPLACE FUNCTION monitor_partition()
  RETURNS trigger AS
$BODY$DECLARE
	tablename varchar;
	tsyear int;
	tsweek int;
BEGIN
	tsyear := extract(year from to_timestamp(NEW.time))::int;
	tsweek := extract(week from to_timestamp(NEW.time))::int;
	tablename := 'monitor_y'
	|| tsyear::varchar
	|| '_w'
	|| tsweek::varchar;
	BEGIN
		EXECUTE 'INSERT INTO '
		|| tablename
		|| ' VALUES ($1, $2, $3, $4, $5, $6, $7, $8, $9, $10, $11, $12, $13, $14, $15)'
		USING
			NEW.time,
			NEW.flowt,
			NEW.unit_oid,
			NEW.proto,
			NEW.src,
			NEW.srcport,
			NEW.dst,
			NEW.dstport,
			NEW.if_in,
			NEW.if_out,
			NEW.as_src,
			NEW.as_dst,
			NEW.dpkts,
			NEW.len,
			NEW.layer7;
		EXCEPTION
			WHEN undefined_table THEN
				EXECUTE 'CREATE TABLE '
				|| tablename
				|| '( CHECK ( '
				||	' time >= ' || weekstart_unixtimestamp(tsyear, tsweek)::varchar
				|| 	' AND '
				||	' time < ' || nextweekstart_unixtimestamp(tsyear, tsweek)::varchar
				|| ')) INHERITS (monitor)';
				EXECUTE 'CREATE INDEX ' || tablename || '_time_idx ON ' || tablename || ' USING btree ("time")';
				EXECUTE 'CREATE INDEX ' || tablename || '_unit_oid_idx ON ' || tablename || ' USING btree (unit_oid)';
				EXECUTE 'INSERT INTO '
				|| tablename
				|| ' VALUES ($1, $2, $3, $4, $5, $6, $7, $8, $9, $10, $11, $12, $13, $14, $15)'
				USING
					NEW.time,
					NEW.flowt,
					NEW.unit_oid,
					NEW.proto,
					NEW.src,
					NEW.srcport,
					NEW.dst,
					NEW.dstport,
					NEW.if_in,
					NEW.if_out,
					NEW.as_src,
					NEW.as_dst,
					NEW.dpkts,
					NEW.len,
					NEW.layer7;
	END;
	RETURN NULL;
END;$BODY$
  LANGUAGE plpgsql VOLATILE
  COST 100;

CREATE TABLE monitor_y2012_w38
(
-- Унаследована from table monitor:  "time" integer NOT NULL,
-- Унаследована from table monitor:  flowt integer,
-- Унаследована from table monitor:  unit_oid integer,
-- Унаследована from table monitor:  proto smallint,
-- Унаследована from table monitor:  src bigint NOT NULL,
-- Унаследована from table monitor:  srcport integer,
-- Унаследована from table monitor:  dst bigint NOT NULL,
-- Унаследована from table monitor:  dstport integer,
-- Унаследована from table monitor:  if_in integer,
-- Унаследована from table :  if_out integer,
-- Унаследована from table :  as_src integer,
-- Унаследована from table :  as_dst integer,
-- Унаследована from table :  dpkts bigint,
-- Унаследована from table :  len bigint,
-- Унаследована from table :  layer7 character varying(80),
  CONSTRAINT monitor_y2012_w38_time_check CHECK ("time" >= 1347825600 AND "time" < 1348430400)
)
INHERITS (monitor)
WITH (
  OIDS=FALSE
);
CREATE INDEX monitor_y2012_w38_time_idx
  ON monitor_y2012_w38
  USING btree
  ("time" );

Это postgres.

explain select * from monitor where "time" >= 1347825600;
 Result  (cost=0.00..731294.96 rows=27188718 width=71)
   ->  Append  (cost=0.00..731294.96 rows=27188718 width=71)
         ->  Seq Scan on monitor  (cost=0.00..0.00 rows=1 width=71)
               Filter: ("time" >= 1347825600)
         ->  Seq Scan on monitor_y2012_w38 monitor  (cost=0.00..731294.96 rows=27188717 width=71)
               Filter: ("time" >= 1347825600)

Насчет seq scan - это у меня, кажется, индексы в pgadmin отключены. Заметь, меня не парит, из какой таблицы выбирать данные, я делаю селект из родительской, посгрес автоматом аппендит наследников.

Хм... вот в этм мануале вообще ничего про кэширование запросов. Есть кэш страничек, но это не то. Извини.

Тут можно кэшировать запросы? Не нашёл как. Я думал лучше разобраться с этим на уровне БД.

У меня мало знаний чтобы это поддерживать, не могу взять незнакомый код. Но идею уже копаю. Спасибо, в общем :)

Я как раз идею кинул, брать мой код 1-в-1 было бы глупо и бесполезно. В общем, велкам.

key-value store есть в рельсах - сохраняешь что хочешь, так долго как хочешь (если тебе это о чем-то скажет). Нет, запросы оно не кеширует лол.

У Вас запросы параметрические (все идет через prepare)?

Нет и я не представляю что это.

Почти все движки и обертки к базе поддерживают так или иначе в итоге prepare. Для БД, года Вы пишите конструкцию вида:

SELECT * FROM DATA WHERE ID=12345;
...
SELECT * FROM DATA WHERE ID=54321;
...

это не однотипные запросы, на них будут выделятся отдельные ресурсы (в некоторых СУБД отдельный процесс)

С другой стороны: сделав однажды prepare выполняем один и тот-же запрос только меняя параметры. Примерно будет так выглядеть:

db.prepare('SELECT * FROM DATA WHERE ID=?;')
...
db.execute(12345);
...
db.execute(54321);

Понял!)