Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности
|
|
|
Мешают ли колонки полям ти text или varchar?
|
|||
|---|---|---|---|
|
#18+
У меня таблицы на миллионы записей (от 2 млн до 30 млн, по несколько гб). Данные в таблицах достаточно уникальны, использую отношения только при явной необходимости. С данными проводится много внешних обработок, при чем если запись 1 раз обработана, то ее либо больше не надо обрабатывать совсем, либо обрабатывать через время (например, через месяц). Обработка может на выходе давать текстовой результат. Обработки иногда добавляются новые. Что я делаю сейчас. Есть таблица, типа Код: plsql 1. При этом если мне надо добавить или удалить поле в таблицу, я это спокойно делаю. Особенно часто добавляю boolean поля, бывает и другие типы. Например, сейчас мне логично добавить 3 поля байт, а text убрать. Вопрос? А правильно ли я понимаю, что для системы postgresql не имеет значения как я балуюсь полями, если я настроил автоочистку на 200 тысяч записей, то вполне допустимо хранить поле text и другие поля в одной таблице? Или поле text должно быть вынесено в отдельную таблицу и использоваться как key - value, а все остальные поля только в отдельной таблице? Производительность меня пока устраивает, просто хочу понять как правильно делать. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.06.2016, 15:34 |
|
||
|
Мешают ли колонки полям ти text или varchar?
|
|||
|---|---|---|---|
|
#18+
... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.06.2016, 19:37 |
|
||
|
Мешают ли колонки полям ти text или varchar?
|
|||
|---|---|---|---|
|
#18+
azsxПри этом если мне надо добавить или удалить поле в таблицу, я это спокойно делаю. Особенно часто добавляю boolean поля, бывает и другие типы. Например, сейчас мне логично добавить 3 поля байт, а text убрать. Вопрос? А правильно ли я понимаю, что для системы postgresql не имеет значения как я балуюсь полями, неправильно. посмотрите pg_attribute[s] -- все ваши дропнутые поля остаются в таблице. более того -- остаются с данными (до вакуум фулла). можете написать тестовый скриптик на добавление и удаление полей -- рано или поздно вы вылезете за предел спеки. логично на этапе макетирования не обращать на это внимания. но для работы -- надо много думать, прежде чем дропнуть поле в большой табличке. иногда лучше его перестать пользовать и заполнять. а по надобности -- опять заюзать. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.06.2016, 22:05 |
|
||
|
Мешают ли колонки полям ти text или varchar?
|
|||
|---|---|---|---|
|
#18+
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. А теперь создайте новые колонки и опять — размер: Код: sql 1. 2. 3. 4. 5. 6. 7. 8. Также можно сравнить размеры таблиц, в которых: одно текстовое поле фиксированной длины, скажем `varchar(10)` одно поле `text` c "простыми" данными длиной более 4000, скажем `repeat('a', 4000)` одно поле `text` со "сложными" данными (уж сгенерируйте как-то) Мое мнение — необходимость частых изменений в структуре таблиц говорит о плохой модели данных и приводит к ненужному геморою у админов. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.06.2016, 00:46 |
|
||
|
Мешают ли колонки полям ти text или varchar?
|
|||
|---|---|---|---|
|
#18+
Всем спасибо за ответы. Таким образом, получается: 1. Таблица чиститься более менее только при vacuum full, который блокирует таблицу. При этом на тестовой таблице чистка воспроизвелась не полностью, но атоочистка на тесте не очистила совсем ничего. 2. Немного помогает сжать таблицу постоянные update. Зато благодаря им же возможны пропуски внутри таблицы на десятки байт на каждой странице, которые уже не заполняться ничем и никогда. 3. Радикальным решением (как и с индексом) будет создание копии таблицы, удаление старой, переименование новой. Я всё правильно понял? --- Таким образом в моей ситуации надо: 1. не удалять поле фиксированной длины в большой таблице, а переименовать его в поле "clear_1", а затем когда понадобиться поле такой же размерности снова его использовать. Это для экономии места. Верно? 2. Зато непонятно, что делать с полем переменной длины и тем более полем text больше 2 кбайт. Его таки лучше удалять и пусть pg сам чистит базу как хочет автоочисткой? Или использовать потом снова, не смотря на то, что данные будут однозначно другими и другой размерностью? Или что то еще? 3. Радикальным решением судя по всему является вынесение всех служебных полей, особенно тех, которые возможно придется удалять, в другие таблицы. То есть если поле переменной длины, записи часто удаляют - то лучше для места на диске под такое поле делать отдельную таблицу. Верно? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.06.2016, 04:16 |
|
||
|
Мешают ли колонки полям ти text или varchar?
|
|||
|---|---|---|---|
|
#18+
любопытно, а есть БД где полная очистка таблиц от старых записей проходит без общей блокировки всей таблицы? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.06.2016, 04:18 |
|
||
|
Мешают ли колонки полям ти text или varchar?
|
|||
|---|---|---|---|
|
#18+
azsx, ORACLE, там механизм версионности другой. Соответственно, что-то лучше (в таблицах и индекс всегда только актуальные данные), а что-то — совсем нет (время ROLLBACK, snapshot too old). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.06.2016, 09:10 |
|
||
|
Мешают ли колонки полям ти text или varchar?
|
|||
|---|---|---|---|
|
#18+
vyegorovORACLE, там механизм версионности другой. Ну... да... это не отменяет блокировок при DDL-ах... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.06.2016, 11:50 |
|
||
|
Мешают ли колонки полям ти text или varchar?
|
|||
|---|---|---|---|
|
#18+
azsx2. Немного помогает сжать таблицу постоянные update. Зато благодаря им же возможны пропуски внутри таблицы на десятки байт на каждой странице, которые уже не заполняться ничем и никогда.вы можете перед дропом / вместо дропа сказать апдейт сет НУЛЛ в "дропаемое" -- а потом пустить простой вакуум. этот апдейт можно отдать джобу, и резать хвост по частям. всяко можноazsx3. Радикальным решением (как и с индексом) будет создание копии таблицы, удаление старой, переименование новой. Я всё правильно понял?а это и есть вакуме фуул. только рукаме. хотя нет , ваккуум--фулл не удаляет дропнутых столбцов, но обнуляет. а пересоздание -- удаляет но при наличии конкурентов это невозможно. (надо где--то в середине подсунуть конкурентам витрину вмест старого/нового, понапихать инстеад--оффов, запустить джобы на перекачку, т.е. масса хенджоба. и то -- если фкеев нет) azsx3. Радикальным решением судя по всему является вынесение всех служебных полей, особенно тех, которые возможно придется удалять, в другие таблицы. То есть если поле переменной длины, записи часто удаляют - то лучше для места на диске под такое поле делать отдельную таблицу. Верно? сначала подумайте об индексах. а так -- соображение верное -- хранить большие не меяющиеся куски отдельно от часто меняющихся записей, до тех пор, пока сквозные индексы не потребуются. радикальным было бы решение с мультитабличными индексами, или вообще с индексами "без овнеров" (с мультиовнером) -- которые вы могли бы поддерживать триггерами, но это -- очень большой логический скачок -- как его втемяшить оптимайзеру -- тут какой--то простой арифметики не получается. и придется прямо обращаться руками к индексам -- что--то типа М--систем, наверное вылезет. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.06.2016, 13:29 |
|
||
|
|

start [/forum/topic.php?fid=53&msg=39262482&tid=1997144]: |
0ms |
get settings: |
9ms |
get forum list: |
14ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
178ms |
get topic data: |
8ms |
get forum data: |
2ms |
get page messages: |
47ms |
get tp. blocked users: |
1ms |
| others: | 260ms |
| total: | 525ms |

| 0 / 0 |
