Гость
Форумы / PostgreSQL [игнор отключен] [закрыт для гостей] / Большое количество таблиц в проекте. Риски и сложности / 10 сообщений из 10, страница 1 из 1
19.09.2018, 13:45
    #39704939
Visermoz
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Большое количество таблиц в проекте. Риски и сложности
Здравствуйте.
В рабочий проект планируется ввести поддержку секционирования.

То что сейчас хранится в 4 таблицах планируется разделить на 8000 таблиц.
Примерное описание модели такое: есть некоторые типы(порядка 2000), хранящиеся в одной таблице(принадлежность типа определяется по справочному полю), плюс таблица для хранения связанных пространственных данных Postgis. И по таблице логов на каждую из этих таблиц. Таблицы довольно объемные и некоторые сложные запросы(особенно использующие пространственные операции) выполняются неприемлемое время.
Для теста я вынес типы в отдельные таблицы и повторил запросы- данные стали получаться мгновенно. Суммарный размер индексов с 15 гб уменьшился до 2 Гб.

Новая модель всех устраивает, но меня пугает такое большое количество таблиц:
(2000 типов* 4 таблицы) * количество схем 27=216000 таблиц.
Как поведет себя операционная система с таким количеством файлов в одном каталоге? Системный словарь тоже разрастется, т.к. с таблицами ведь еще создадутся индексы, триггеры, констрейнты.

Как вы считаете , допустимо ли использовать такое количество таблиц, может ли это где-то сказаться? Например, при снятии копии утилитой pg_dump процесс, хранящий описание такого количества таблиц наверняка разрастётся по памяти.
...
Рейтинг: 0 / 0
19.09.2018, 18:59
    #39705211
Maxim Boguk
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Большое количество таблиц в проекте. Риски и сложности
VisermozЗдравствуйте.
В рабочий проект планируется ввести поддержку секционирования.

То что сейчас хранится в 4 таблицах планируется разделить на 8000 таблиц.
Примерное описание модели такое: есть некоторые типы(порядка 2000), хранящиеся в одной таблице(принадлежность типа определяется по справочному полю), плюс таблица для хранения связанных пространственных данных Postgis. И по таблице логов на каждую из этих таблиц. Таблицы довольно объемные и некоторые сложные запросы(особенно использующие пространственные операции) выполняются неприемлемое время.
Для теста я вынес типы в отдельные таблицы и повторил запросы- данные стали получаться мгновенно. Суммарный размер индексов с 15 гб уменьшился до 2 Гб.

Новая модель всех устраивает, но меня пугает такое большое количество таблиц:
(2000 типов* 4 таблицы) * количество схем 27=216000 таблиц.
Как поведет себя операционная система с таким количеством файлов в одном каталоге? Системный словарь тоже разрастется, т.к. с таблицами ведь еще создадутся индексы, триггеры, констрейнты.

Как вы считаете , допустимо ли использовать такое количество таблиц, может ли это где-то сказаться? Например, при снятии копии утилитой pg_dump процесс, хранящий описание такого количества таблиц наверняка разрастётся по памяти.

Я бы сказал что в такой ситуации легко получить OOM на сервере с меньше чем 32GB памяти.
215k таблиц это всетаки неадекватно много.
Но попробовать в принципе можно (т.е. это не 2М таблиц всетаки).

--
Maxim Boguk
лучшая поддержка PostgreSQL: dataegret.ru
...
Рейтинг: 0 / 0
20.09.2018, 06:23
    #39705357
Visermoz
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Большое количество таблиц в проекте. Риски и сложности
Maxim Boguk,
спасибо большое за ответ. Как раз примерно такого я и опасаюсь. Раньше уже возникали проблемы с утилитой pg_dump из-за большого количества представлений и помогло увеличение памяти на сервере. С таким большим количеством таблиц, видимо, памяти потребуется еще больше. Попробую сделать тестовую базу и сделать замеры
...
Рейтинг: 0 / 0
20.09.2018, 09:26
    #39705404
tunknown
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Большое количество таблиц в проекте. Риски и сложности
VisermozИ по таблице логов на каждую из этих таблиц.Логи нужны для разбора полётов или используются в бизнес-логике. Если только для разбора полётов- положите в одну универсальную таблицу, пусть даже с более медленным доступом. Число таблиц несколько уменьшится.
...
Рейтинг: 0 / 0
20.09.2018, 10:07
    #39705438
Partisan M
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Большое количество таблиц в проекте. Риски и сложности
Раз никто так не делает, значит никому не нужно.
Раз никто так не делает, то трудно заранее оценить последствия. Но раз никому не нужно, то наверно и автору темы не нужно. А нужно подумать, как сделать по-другому - может, окажется лучше.

Что он хочет получить в результате - не понял и неохота гадать. Но может, ему чем-то поможет возможность наследования таблиц в PostgreSQL. Её можно использовать для добавления необязательных колонок или для деления таблицы на части, например, по периодам дат у данных.
...
Рейтинг: 0 / 0
20.09.2018, 10:55
    #39705486
Alexius
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Большое количество таблиц в проекте. Риски и сложности
Visermoz,

а эти типы, которых 2000 – они равномерно размазаны по строкам или есть такие, которые встречаются сильно чаще других ? если да, то может лучше было бы выделить в отдельные таблицы только наиболее часто встречающиеся. какого размера таблицы (в ГБ и в строках) ? имхо, от такого количества таблиц будет больше вреда, чем пользы.
...
Рейтинг: 0 / 0
21.09.2018, 06:25
    #39705935
Visermoz
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Большое количество таблиц в проекте. Риски и сложности
tunknown, в бизнес-логике логи тоже используются(например, формируются отчеты за период по изменениям). Но ваш вариант мне тоже нравится: те инструменты, работающие с логами не завязаны на скорость и более медленная их работа вполне подойдет.
Спасибо за совет. я попробую этот вариант обязательно
...
Рейтинг: 0 / 0
21.09.2018, 06:34
    #39705937
Visermoz
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Большое количество таблиц в проекте. Риски и сложности
Partisan M, я бы очень хотел не использовать такой вариант с таким количеством таблиц, конечно. И как раз хочу узнать мнение всех на форуме кто откликнется. Потому что действительно не видел упоминания такого количества таблиц(ну кроме разве презентации с попыткой сделать 1 миллиард таблиц https://www.pgcon.org/2013/schedule/attachments/283_Billion_Tables_Project-PgCon2013.pdf)

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

Спасибо за предложенный вариант с наследованием. Но следуя ему я в итоге такое же количество таблиц, т.к. каждый тип ляжет в отдельную секцию, хотя базовая таблица также останется. В этом варианте еще пугает наличие тяжелого триггера, который при обращении к основной таблице будет выбирать нужную секцию и производить вставку в нее. Хотя тут, конечно, можно изменением в коде приложения сделать чтобы вставка производилась в нужную секцию сразу
...
Рейтинг: 0 / 0
21.09.2018, 06:47
    #39705938
Visermoz
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Большое количество таблиц в проекте. Риски и сложности
Alexius, действительно распределение типов неравномерное. из 2000 типов реально данные имеют 300. Из них только в 40 строк больше 10000. в остальных десятки или даже единицы записей.
Мне очень понравилось ваше предложение: наверное, это будет самый оптимальный способ. Самые объемные и самые используемые типы вынесем в отдельные таблицы, а "мелочь" и используемые мало оставим как есть.
Большое спасибо!
...
Рейтинг: 0 / 0
11.10.2018, 21:35
    #39716382
Sergei.Agalakov
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Большое количество таблиц в проекте. Риски и сложности
Visermoz,
Вообще странно, почему так уменьшился суммарный размер индексов. Есть сильное подозрение, что весь прирост производительности произошел как побочный эффект перестройки индексов с более эффективным использованием памяти после этого. Также улучшилась кластеризации данных, но этого можно было попробовать достигнуть и просто использованием cluster в старой модели.
...
Рейтинг: 0 / 0
Форумы / PostgreSQL [игнор отключен] [закрыт для гостей] / Большое количество таблиц в проекте. Риски и сложности / 10 сообщений из 10, страница 1 из 1
Целевая тема:
Создать новую тему:
Автор:
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


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