ReSQL.ru
     
powered by simpleCommunicator - 2.0.61     © 2026 Programmizd 02
Мобильная версия    Контакт    Правила    FAQ    Помощь
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр
Форумы / PostgreSQL [игнор отключен] [закрыт для гостей] / Вопрос по оптимальной структуре БД
4 сообщений из 4, страница 1 из 1
Вопрос по оптимальной структуре БД
    #39144931
Leonid Kudryavtsev
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Leonid Kudryavtsev
Участник
Нужна таблица примерно из трех полей:

KEY, TIMESTAMP, VALUE

Данные только добавляются, запросы только по KEY, нужно вернуть данные с последним TIMESTAMP.

Как это эффективно сделать в PostgreSQL ?

1) Табличка в которую INSERT only + какой нибудь хитрый SELECT (что эффективнее?)
2) Табличка с данными INSERT only + табличка в которой хранить KEY+VALUE последнего значения и UPDATE

Кто-что может по опыту работы с PostgreSQL посоветовать? Насколько AutoVacum сейчас эффективно работает, не будет ли табличка, которую постоянно update'ят, безумно тормозить?

Объемы:
Уникальный KEY от 100 000 до нескольких миллионов. Размер Value от 15 кб до 150 кб. Активное обновление. Достаточно активное чтение (отношение обновление - чтение наверное 1:1, т.к. поверх в аппликейшен слое будет еще кэш прикручен).
...
Рейтинг: 0 / 0
11.01.2016, 19:46
| Ответить | Цитировать | Написать  
Вопрос по оптимальной структуре БД
    #39144998
Alexius
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Alexius
Участник
Leonid Kudryavtsev,

если в среднем запись с одним key несколько раз обновляется, и данных будет достаточно много, то второй вариант.
т.е. таблица с последними часто читаемыми данными отдельно и триггер в ней, который в insert only таблицу пишет при update/insert.

автовакуум при должной настройке будет работать, но нужно следить чтобы не было длинных транзакций.
...
Рейтинг: 0 / 0
11.01.2016, 22:11
| Ответить | Цитировать | Написать  
Вопрос по оптимальной структуре БД
    #39145388
Павел Лузанов
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Павел Лузанов
Участник
Leonid,

Я бы перед тем как перейти к варианту со второй таблицей, попробовал сделать индекс по key, timestamp.
Ну и запрос select * from t where key = ? order by timestamp desc limit 1;

Тестовый пример:
Код: sql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
db=# create table t as select x.*, generate_series ('01-01-2015'::timestamp, '31-12-2015'::timestamp, '1 day') as ts, repeat('a',20000) as value from generate_series (1,1000) x(key);
SELECT 365000
Time: 43193,653 ms
db=# create index on t (key, ts desc);
CREATE INDEX
Time: 1794,873 ms
db=# analyze t;
ANALYZE
Time: 124,348 ms
db=# explain analyze select * from t where key = 100 order by ts desc limit 1;
                                                         QUERY PLAN                                                         
----------------------------------------------------------------------------------------------------------------------------
 Limit  (cost=0.42..2.21 rows=1 width=253) (actual time=0.034..0.034 rows=1 loops=1)
   ->  Index Scan using t_key_ts_idx on t  (cost=0.42..934.01 rows=523 width=253) (actual time=0.032..0.032 rows=1 loops=1)
         Index Cond: (key = 100)
 Planning time: 0.154 ms
 Execution time: 0.072 ms
(5 rows)



Со значением value я, конечно, сильно утрирую. Постгрес такие штуки, как repeat(), умеет хорошо сжимать при хранении.
...
Рейтинг: 0 / 0
12.01.2016, 12:52
| Ответить | Цитировать | Написать  
Вопрос по оптимальной структуре БД
    #39145459
p2.
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
p2.
Участник
Leonid Kudryavtsev,

Очередность таймстампа неоднозначна - таймстампы могут и совпасть и другая неприятность, более ранний таймстамп может закомититься позже. В случае второй таблицы надо иметь ввиду, что доступ к одному KEY будет сериализован на блокировке строки и тот самый более ранний по значения TIMESTAMP может оказаться последним. Этого можно избежать, если проверять заменяемое значение при апдейте. Вообще, правильнее рассматривать такой подход наоборот - есть основная таблица с актуальными данными KEY-VALUE, а с TIMESTAMP вторична как журнал значений.
Еще вариант реализации - использовать дополнительный признак актуальности в той же таблице. Для доступа использовать частичный индекс. Внесение значения тогда заключается в сбросе признака текущей актуальной строки (update) и вставке новой. Но тут проблема сериализации усугбляется тем, что бывшая актуальной на момент старта двух конкурентных обновлений строка переезжает после коммита первенца.
...
Рейтинг: 0 / 0
12.01.2016, 13:48
| Ответить | Цитировать | Написать  
4 сообщений из 4, страница 1 из 1
Форумы / PostgreSQL [игнор отключен] [закрыт для гостей] / Вопрос по оптимальной структуре БД
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
Польз. соглашение   Полит. конфиден.  
NoSQL.ru       Кролег: Проекты, Новости, Чат       РЕД ФОРУМ       Фотоальбом: Участники, Встречи
Закрыть
start [/forum/topic.php?fid=53&gotonew=1&tid=1997529]:
 0ms
get settings:
 5ms
get forum list:
 13ms
check forum access:
 3ms
check topic access:
 3ms
track hit:
 66ms
get topic data:
 12ms
get first new msg:
 6ms
get forum data:
 2ms
get page messages:
 47ms
get tp. blocked users:
 1ms
others: 226ms
total:  384ms
созд. / загр.: 384ms
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]