Гость
Войти | Профиль | Очистить
Целевая тема:
Создать новую тему:
Автор:
Действия ...
Форумы / PostgreSQL [игнор отключен] [закрыт для гостей] / Мешают ли колонки полям ти text или varchar? / 10 сообщений из 10, страница 1 из 1
25.06.2016, 15:34
    #39262289
azsx
azsx
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Мешают ли колонки полям ти text или varchar?
У меня таблицы на миллионы записей (от 2 млн до 30 млн, по несколько гб). Данные в таблицах достаточно уникальны, использую отношения только при явной необходимости. С данными проводится много внешних обработок, при чем если запись 1 раз обработана, то ее либо больше не надо обрабатывать совсем, либо обрабатывать через время (например, через месяц). Обработка может на выходе давать текстовой результат. Обработки иногда добавляются новые.
Что я делаю сейчас.
Есть таблица, типа
Код: plsql
1.
CREATE TABLE test_table (id_pole1 bigserial, name_pole2 varchar(255) not null UNIQUE, pole3 boolean, pole4 boolean, pole5 boolean, pole6 boolean, sss_pole7 text, fff_pole8 text);


При этом если мне надо добавить или удалить поле в таблицу, я это спокойно делаю. Особенно часто добавляю boolean поля, бывает и другие типы. Например, сейчас мне логично добавить 3 поля байт, а text убрать.
Вопрос?
А правильно ли я понимаю, что для системы postgresql не имеет значения как я балуюсь полями, если я настроил автоочистку на 200 тысяч записей, то вполне допустимо хранить поле text и другие поля в одной таблице? Или поле text должно быть вынесено в отдельную таблицу и использоваться как key - value, а все остальные поля только в отдельной таблице?
Производительность меня пока устраивает, просто хочу понять как правильно делать.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
25.06.2016, 19:37
    #39262354
Локшин Марк
Локшин Марк
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Мешают ли колонки полям ти text или varchar?
azsx,

TOAST
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
25.06.2016, 22:05
    #39262415
qwwq
qwwq
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Мешают ли колонки полям ти text или varchar?
azsxПри этом если мне надо добавить или удалить поле в таблицу, я это спокойно делаю. Особенно часто добавляю boolean поля, бывает и другие типы. Например, сейчас мне логично добавить 3 поля байт, а text убрать.
Вопрос?
А правильно ли я понимаю, что для системы postgresql не имеет значения как я балуюсь полями,

неправильно.

посмотрите pg_attribute[s] -- все ваши дропнутые поля остаются в таблице. более того -- остаются с данными (до вакуум фулла). можете написать тестовый скриптик на добавление и удаление полей -- рано или поздно вы вылезете за предел спеки.

логично на этапе макетирования не обращать на это внимания. но для работы -- надо много думать, прежде чем дропнуть поле в большой табличке. иногда лучше его перестать пользовать и заполнять. а по надобности -- опять заюзать.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
26.06.2016, 00:46
    #39262449
vyegorov
vyegorov
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Мешают ли колонки полям ти text или varchar?
azsx,

Нужно помнить о том, что:
ПЖ имеет 2 типа значений — фиксированной и переменной длины

значения переменной длины, которые не могут поместиться в блок, тостируются

для ускорения доступа все фиксированные значения выравниваются по границе размерности архитектуры

существует MVCC, который при изменении записей "раздувает" таблицы

Сделайте 2 таблички и сравните их размеры:
Код: sql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
CREATE TABLE a(
  f1 int2,
  f2 int8,
  f3 int2,
  f4 int8,
  f5 int2,
  f6 int8,
  f7 int2,
  f8 int8 );

CREATE TABLE b(
  f1 int2,
  f3 int2,
  f5 int2,
  f7 int2,
  f2 int8,
  f4 int8,
  f6 int8,
  f8 int8 );

INSERT INTO a SELECT 1,2,3,4,5,6,7,8 FROM generate_series(1,1000000);
INSERT INTO b SELECT 1,2,3,4,5,6,7,8 FROM generate_series(1,1000000);

SELECT relname,pg_total_relation_size(oid) FROM pg_class WHERE relname IN ('a','b');


А теперь создайте новые колонки и опять — размер:
Код: sql
1.
2.
3.
4.
5.
6.
7.
8.
ALTER TABLE a ADD f9 int2;
SELECT relname,pg_total_relation_size(oid) FROM pg_class WHERE relname IN ('a');

ALTER TABLE a ADD f10 int2 NOT NULL DEFAULT 0;
SELECT relname,pg_total_relation_size(oid) FROM pg_class WHERE relname IN ('a');

ALTER TABLE a DROP f10;
SELECT relname,pg_total_relation_size(oid) FROM pg_class WHERE relname IN ('a');



Также можно сравнить размеры таблиц, в которых:

одно текстовое поле фиксированной длины, скажем `varchar(10)`

одно поле `text` c "простыми" данными длиной более 4000, скажем `repeat('a', 4000)`

одно поле `text` со "сложными" данными (уж сгенерируйте как-то)

Мое мнение — необходимость частых изменений в структуре таблиц говорит о плохой модели данных и приводит к ненужному геморою у админов.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
26.06.2016, 04:16
    #39262463
azsx
azsx
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Мешают ли колонки полям ти text или varchar?
Всем спасибо за ответы.
Таким образом, получается:
1. Таблица чиститься более менее только при vacuum full, который блокирует таблицу. При этом на тестовой таблице чистка воспроизвелась не полностью, но атоочистка на тесте не очистила совсем ничего.
2. Немного помогает сжать таблицу постоянные update. Зато благодаря им же возможны пропуски внутри таблицы на десятки байт на каждой странице, которые уже не заполняться ничем и никогда.
3. Радикальным решением (как и с индексом) будет создание копии таблицы, удаление старой, переименование новой.
Я всё правильно понял?
---
Таким образом в моей ситуации надо:
1. не удалять поле фиксированной длины в большой таблице, а переименовать его в поле "clear_1", а затем когда понадобиться поле такой же размерности снова его использовать. Это для экономии места. Верно?
2. Зато непонятно, что делать с полем переменной длины и тем более полем text больше 2 кбайт. Его таки лучше удалять и пусть pg сам чистит базу как хочет автоочисткой? Или использовать потом снова, не смотря на то, что данные будут однозначно другими и другой размерностью? Или что то еще?
3. Радикальным решением судя по всему является вынесение всех служебных полей, особенно тех, которые возможно придется удалять, в другие таблицы. То есть если поле переменной длины, записи часто удаляют - то лучше для места на диске под такое поле делать отдельную таблицу. Верно?
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
26.06.2016, 04:18
    #39262464
azsx
azsx
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Мешают ли колонки полям ти text или varchar?
любопытно, а есть БД где полная очистка таблиц от старых записей проходит без общей блокировки всей таблицы?
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
26.06.2016, 09:10
    #39262482
vyegorov
vyegorov
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Мешают ли колонки полям ти text или varchar?
azsx,

ORACLE, там механизм версионности другой.
Соответственно, что-то лучше (в таблицах и индекс всегда только актуальные данные), а что-то — совсем нет (время ROLLBACK, snapshot too old).
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
26.06.2016, 11:50
    #39262509
vyegorov
vyegorov
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Мешают ли колонки полям ти text или varchar?
vyegorovORACLE, там механизм версионности другой.
Ну... да... это не отменяет блокировок при DDL-ах...
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
26.06.2016, 13:29
    #39262525
qwwq
qwwq
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Мешают ли колонки полям ти text или varchar?
azsx2. Немного помогает сжать таблицу постоянные update. Зато благодаря им же возможны пропуски внутри таблицы на десятки байт на каждой странице, которые уже не заполняться ничем и никогда.вы можете перед дропом / вместо дропа сказать апдейт сет НУЛЛ в "дропаемое" -- а потом пустить простой вакуум. этот апдейт можно отдать джобу, и резать хвост по частям. всяко можноazsx3. Радикальным решением (как и с индексом) будет создание копии таблицы, удаление старой, переименование новой.
Я всё правильно понял?а это и есть вакуме фуул. только рукаме. хотя нет , ваккуум--фулл не удаляет дропнутых столбцов, но обнуляет. а пересоздание -- удаляет

но при наличии конкурентов это невозможно. (надо где--то в середине подсунуть конкурентам витрину вмест старого/нового, понапихать инстеад--оффов, запустить джобы на перекачку, т.е. масса хенджоба. и то -- если фкеев нет)
azsx3. Радикальным решением судя по всему является вынесение всех служебных полей, особенно тех, которые возможно придется удалять, в другие таблицы. То есть если поле переменной длины, записи часто удаляют - то лучше для места на диске под такое поле делать отдельную таблицу. Верно? сначала подумайте об индексах. а так -- соображение верное -- хранить большие не меяющиеся куски отдельно от часто меняющихся записей, до тех пор, пока сквозные индексы не потребуются. радикальным было бы решение с мультитабличными индексами, или вообще с индексами "без овнеров" (с мультиовнером) -- которые вы могли бы поддерживать триггерами, но это -- очень большой логический скачок -- как его втемяшить оптимайзеру -- тут какой--то простой арифметики не получается. и придется прямо обращаться руками к индексам -- что--то типа М--систем, наверное вылезет.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
27.06.2016, 09:41
    #39262714
Jonhson
Jonhson
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Мешают ли колонки полям ти text или varchar?
vyegorovvyegorovORACLE, там механизм версионности другой.
Ну... да... это не отменяет блокировок при DDL-ах...

вообще-то есть online, так что ваша информация несколько устарела
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
Форумы / PostgreSQL [игнор отключен] [закрыт для гостей] / Мешают ли колонки полям ти text или varchar? / 10 сообщений из 10, страница 1 из 1
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
Польз. соглашение  
Полит. конфиден.  
созд. / загр.: 536ms
Закрыть
start [/forum/topic.php?fid=53&mobile=1&tid=1997144]:
 0ms
get settings:
 9ms
get forum list:
 18ms
check forum access:
 3ms
check topic access:
 3ms
track hit:
 205ms
get topic data:
 10ms
get forum data:
 3ms
get page messages:
 47ms
get tp. blocked users:
 1ms
others: 237ms
total:  536ms
x
x
Закрыть


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