ReSQL.ru
     
powered by simpleCommunicator - 2.0.60     © 2026 Programmizd 02
Мобильная версия    Контакт    Правила    FAQ    Помощь
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр
Форумы / PostgreSQL [игнор отключен] [закрыт для гостей] / Работа с большими таблицами
18 сообщений из 18, страница 1 из 1
Работа с большими таблицами
    #32956473
Алексей Ключников
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Алексей Ключников
Участник
Задача принимать данные где то 10 - 50 записей в секунду круглосуточно.
Таблица растет и через некоторое время (месяц) начинает тормозить.
Надо чтобы на года 3 хватало.
Сейчас данные старше семи дней, раз в сутки перекладываюся в другую таблицу
т.е. валяться в таблицу base а перекладываются в big_base.

Это проблему не очень решает.
Во время перекладывания работа базы практически останавливается, и опятьже с течением времени процесс перекладывания занимает все больше времени, а работать база должна круглосуточно.

Также случаются иногда запросы в эту базу (необходимость индексов).

Вопрос - есть ли какието методы, решения, чтобы база
первым приоритетом принимала данные
вторым отвечала на запросы и третим вела работу по сохранению данных
Как вообще работают с такими данными, кроме как нарастить железо

ЗЫ. postgresql 8.0, freebsd.
...
Рейтинг: 0 / 0
11.03.2005, 17:32
| Ответить | Цитировать | Написать  
Работа с большими таблицами
    #32956615
domanix
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
domanix
Гость
При таком обьеме поступающих данных логичнне было бы разделить процес накопления данных от процесса анализа...
т.е. данные не сразу вносить в БД - а через некий буфер - который должен быть независимым от БД. А из этого буфера их периодически заносить в БД. причем я бы сделал две БД - одна как чистое хранилище - в нее бы перекочевывали данные из буффера - а во вторую базу данные уже заливались бы в структуированом( агрегатном?) виде- направленном на уменьшение нагрузки от характерных запросов.. Еще лучше так- это разделить все три функции по разным машинам...
...
Рейтинг: 0 / 0
11.03.2005, 18:35
| Ответить | Цитировать | Написать  
Работа с большими таблицами
    #32956744
Алексей Ключников
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Алексей Ключников
Участник
В качестве буфера использовать что то самописное?
Три машины это мало реально. Во появилась идея создать раздел в памяти
и поместить туда промежуточную таблицу. В нее сбрасывать например за сутки, а потом уже "потихоньку" перекладывать в архив.
Будет в таком решении польза?
И как сделать во это "потихоньку"
...
Рейтинг: 0 / 0
11.03.2005, 20:03
| Ответить | Цитировать | Написать  
Работа с большими таблицами
    #32956871
DkmS
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
DkmS
Участник
Алексей КлючниковЗадача принимать данные где то 10 - 50 записей в секунду круглосуточно.
У меня вот похожая системка функционирует - пишет данные счётчика трафика, от 3 до 30 записей в секунду. WinXP, PgSQL 8.01, никаких ухищрений пока не предпринимал (работает недолго пока). Всё пишется, я её не замечаю практически. До этого работал Юкон, в таблице этих отсчётов около 6 млн. записей, тоже всё работало нормально (по крайней мере, вставка, отчёты - это да, песня).
Может, у вас железо не очень? У меня, правда, тоже ничего выдающегося (P4/2400 Mhz/640 RAM, диск один).
...
Рейтинг: 0 / 0
11.03.2005, 23:51
| Ответить | Цитировать | Написать  
Работа с большими таблицами
    #32957661
domanix
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
domanix
Гость
В качестве буфера можно использовать не только самописное,проще все складывать в обычный флат файл. Из него уже периодически переносить данные в стационарное хранилище.. Из хранилища данные можно уже перекладывать в отдельную базу для анализа и т.д.
Основная идея - это максимально разделить три процесса-
1 - Получение оперативных данных
2 - Хранение всех данных
3 - анализ и другие бизнес процессы.
Очень желательно все это разнести физически ( на разные машины к примеру)

Для чего спросите это необходимо?
Ответ по моему очевиден - только при таком подходе можно еще както гарантировать что cиcтема будет работать 24 часа в сутки и семь дней в неделю.
Т.е. выход из строя или временная остановка 2 и 3 пунктов - не приведет к потере данных. Тогда как ежели все сваливать прямо в базу - мы можем получить потерю данных .Например- как вам провести вакумизацию? Ведь в этом случае -вы блокируете таблицу и фактически данные в базу данных не могут поступать - ибо ей не до этого!! В тоже время данные с внешнего оборудования продолжают поступать.. Куда они по вашему денутся?
Или вы запустили тяжелый аналитический запрос- база сильно занята - данные принимает с меньшей скоростью с какой они поступают..Такая ситуация также может приветси к потере данных.
В общем единственный совет в таких случаях - как сказал великий Путин (да светится твердостью лицо его) ОТДЕЛЯТЬ МУХ ОТ КОТЛЕТ!!!
...
Рейтинг: 0 / 0
13.03.2005, 15:22
| Ответить | Цитировать | Написать  
Работа с большими таблицами
    #32958241
Скрябин Дмитрий
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Скрябин Дмитрий
Гость
Данные принимаются постоянно? имеется ввиду, что в любую секунду база обрабатывает данные?
Предлагаю сделать, как предложил domanix.
Например постоянно принимать данные не в базу, а в файл (например, в текстовый). и периодически (раз в 10 минут) запихивать накопившиется данные в таблицу. Появится свободное время для базы, в это время она сможет выполнять другие задачи. Раз в сутки, в период минимальной загруженности, данные за предыдущий день можно аггрегировать как нужно, и помещать в другую таблицу. таким образом, вторая таблицы будет содержать меньше строк, и не будет постоянно занята - ее можно использовать для анализа.
Как вариант можно вставлять данные в две таблицы, и одну использовать только для аггрегирования, затем очищать. тогда процесс аггрегирования будет быстрее.
...
Рейтинг: 0 / 0
14.03.2005, 11:20
| Ответить | Цитировать | Написать  
Работа с большими таблицами
    #32958648
ilejn
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ilejn
Участник
Скрябин ДмитрийДанные принимаются постоянно? имеется ввиду, что в любую секунду база обрабатывает данные?
Предлагаю сделать, как предложил domanix.
Например постоянно принимать данные не в базу, а в файл (например, в текстовый).

Общая идея относительно разделения на OLTP и Warehouse
безусловно верна.

Использование файла ОС мне кажется немного неудачным
решением по ряду причин и я бы предпочел отдельную таблицу, а,
если бы это был Oracle,
то отдельную базу с репликацией из нее; PostgreSQL тоже так умеет,
но я не очень
в курсе подробностей - ключевое слово "slony".
Еще бы очень подошел механизм partitioning, но PostgreSQL,
насколько я знаю, такими возможностями не обладает.

Эта таблица имела бы один индекс по автоинкрементируемому
полю с номером записи и структуру, максимально близкую
к формату входящих данных. Я бы хранил номер последней
переписанной строки (иметь признак "переписано_в_основную_базу"
для каждой строки нежелательно) и глубокой ночью стирал бы из
OLTP таблицы строки, уже переписанные в warehouse данные.

Примерно так ;)
...
Рейтинг: 0 / 0
14.03.2005, 13:24
| Ответить | Цитировать | Написать  
Работа с большими таблицами
    #32959579
Алексей Ключников
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Алексей Ключников
Участник
Спасибо за ответы.
И все таки машина должна одна. П1800(256)
В файл тоже не получиться. т.к. база постоянно выдает текущую ситуацию. И ведет кое какую обработку данных.
Пропробую вот как.
Создать две таблицы.
Допустим первых 3 часа все валиться в одну, вторые три часа в другую, а в это время происходит переложение из первой в архив и удаление.
В результате разделиться процесс приема и обработки данных от архивирования. Ведь база должна уметь делать парралельную работу !!!

А вот с вакумизацией действительно проблема. сейчас три раза в день делается, что не допустимо
...
Рейтинг: 0 / 0
14.03.2005, 18:43
| Ответить | Цитировать | Написать  
Работа с большими таблицами
    #32959691
KRED
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
KRED
Участник
Алексей КлючниковСпасибо за ответы.
И все таки машина должна одна. П1800(256)
В файл тоже не получиться. т.к. база постоянно выдает текущую ситуацию. И ведет кое какую обработку данных.
Пропробую вот как.
Создать две таблицы.
Допустим первых 3 часа все валиться в одну, вторые три часа в другую, а в это время происходит переложение из первой в архив и удаление.
В результате разделиться процесс приема и обработки данных от архивирования. Ведь база должна уметь делать парралельную работу !!!

А вот с вакумизацией действительно проблема. сейчас три раза в день делается, что не допустимо

ny esli tam Unix to ne strashno chto tak malo RAM. postav dva vinta. i logi vinesi na vtoroi vint .... OBYAZATELNO. yvelich "wal_buffers (integer)" a takge work_mem (integer) postav 16Mb. Eto na schot proizvoditelnosti. Esli PG ne rugaetsya po povodu free spiskov (max_fsm_pages ) to pohoge yge vso. ny i shared_buffers (integer) posmotri ... metrov 30-70 postav.

Vacuum zapuskai raz v sutki ... s 100k zapisei emy tam pochti nechego delat (IMHO)
"vacuum analyze" raz v mesyaz a "Vacuum FULL" kogda systema ne dolgna bit dostupna. :-)


PS posmotri komandi po tipu "insert into table values select * from table2" na ORACLE s takimi bilo namnogo bistree... a kak v PG ?
...
Рейтинг: 0 / 0
14.03.2005, 19:51
| Ответить | Цитировать | Написать  
Работа с большими таблицами
    #32959694
KRED
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
KRED
Участник
vot pochti zabil posmotri na partition index...

CREATE index name on table (col,col) where (2+2) between 3 and 5 ;

tolko konechno po datam ...
...
Рейтинг: 0 / 0
14.03.2005, 19:53
| Ответить | Цитировать | Написать  
Работа с большими таблицами
    #32960663
Алексей Ключников
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Алексей Ключников
Участник
ок. тюнингом надо заняться.
записей наверное боболее 100к, одна запись int4, timestamp, float8, int4, int4, int4, int4.
Попробовал hash индекс, это что то ядерное! :)
надо его изучить по плотнее, чем он череват? кроме того что применяется 3 часа.
...
Рейтинг: 0 / 0
15.03.2005, 13:11
| Ответить | Цитировать | Написать  
Работа с большими таблицами
    #32960833
KRED
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
KRED
Участник
Алексей Ключниковок. тюнингом надо заняться.
записей наверное боболее 100к, одна запись int4, timestamp, float8, int4, int4, int4, int4.
Попробовал hash индекс, это что то ядерное! :)
надо его изучить по плотнее, чем он череват? кроме того что применяется 3 часа.

aga ssory ... 60*60*24*50=4.320.000 zapisey ... ochibsya. Poschital 50 row v minutu ...

togda tam est chto yborchiky delat ...
A tebe ich vse hranit ? ili cherez vremya delat statistiky i vso ? tig podymai eto primerno 30Mb v den ... na odny tablizu. Moget eti dannie analizirovat i v archiv (chitai v fail + gzip) ? a v baze tolko ostavit analitiky ... na kagdii chas. Obichno hvataet. a esli komy nado pust smotryat detalno v faile ... s archiva!!!

PS archiv mogno i DB organizovat ... chtob vse dannie bili vmeste. toest tege (textovie ili XML) faili tolko v baze +gzip konechno.
...
Рейтинг: 0 / 0
15.03.2005, 14:03
| Ответить | Цитировать | Написать  
Работа с большими таблицами
    #32961598
Алексей Ключников
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Алексей Ключников
Участник
Постоянно подмывает сохранять информацию в бинарном виде + архивация на диск, например за сутки, а в базе только хранить путь до соответствующего файла.
Но будет потеря гибкости, и трудности с составлением отчетов и т.д.
В принципе паралельно ведеться еще одна таблица куда и ложиться средние занчение за сутки + дисперсия и кол-во данных. но полные данные хранить все равно надо.
...
Рейтинг: 0 / 0
15.03.2005, 17:28
| Ответить | Цитировать | Написать  
Работа с большими таблицами
    #32961690
4321
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
4321
Участник
вопрос, чем "валятся" данные. (Т.е. из какой прилады).

Если переключить "назначение" приладой ничего не стоит, то можно так :
1. использовать 2 имени таблиц назначения, (таблицы безындексные, безконстрайнтные, безтриггерные)
2. одно имя - буфер (имя таблиц сборки данных на этапе перегрузки). (чтобы не дублировать процедур)

Работа:
1. данные грузятся в табл с именем 1, делаем новую пустую табличку с именем 2.
2. после времени Ч переименовываем 1 в буфер1, обвязываем индексами (если требуется для процесса перегрузки в "большую" таблицу архива) и собственно переливаем данные в архив.
3. создаем новую таблицу с именем 1.
4. _дропаем_ буфер1 по завершению переливки. (имя освобождается для переливки из таблицы 2 полсе времени Ч2).

единственное что нужно проверить - это чтобы процедуры работающие с пересоздаваемыми таблицами (именами) обращались к ним (и их п-кеям) через Execute. Или, чтобы кроме CREATE TABLE - оф дублировался полный набор запусков CREATE OR REPLACE xxxx. (но работу самой сборки данных это не замедлит)


ЗЫ (я бы правда попробовал переименовывать сами таблицы "на лету", благо постгрес позволяет, но есть сомнения). Опять же некоторые процедуры (триггеры и т.п.) придется с необходимостью писать через EXECUTE, вместо привычного "прямого" SQL.
...
Рейтинг: 0 / 0
15.03.2005, 18:11
| Ответить | Цитировать | Написать  
Работа с большими таблицами
    #32962090
фффф
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
фффф
Гость
4321
4. _дропаем_ буфер1 по завершению переливки. (имя освобождается для переливки из таблицы 2 полсе времени Ч2).

можно не дропать всю таблицу, а делать ей TRUNCATE TABLE и убивать только индексы. При этом pg_class.oid сохраняется и в функциях через EXECUTE() не надо заморачиваться.

Похожая схема есть в Sybase ASE - там есть свой аудит, который может генерировать дикое количество записей в секунду. Сначала пишется в одну таблицу sysaudits_01, по достижении некоторого объема сервер переключает вставку на sysaudits_02 и запускает процедуру (которую DBA должен написать). Процедура не спеша перекладывет данные из _01 в архивную базу и обрезает её. Причем можно сделать до 8 таблиц, чтобы пиковые моменты отрабатывать.
...
Рейтинг: 0 / 0
16.03.2005, 04:04
| Ответить | Цитировать | Написать  
Работа с большими таблицами
    #32962457
4321
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
4321
Участник
фффф 4321
4. _дропаем_ буфер1 по завершению переливки. (имя освобождается для переливки из таблицы 2 полсе времени Ч2).

можно не дропать всю таблицу, а делать ей TRUNCATE TABLE и убивать только индексы. При этом pg_class.oid сохраняется и в функциях через EXECUTE() не надо заморачиваться.


предполагалось, что _имя_ "буфер1" - общее _имя_ для таблиц "сборки данных" на этапе переливки (чтобы не писать дублей процедур). Тогда процедуры _обязаны_ обращаться к "таблице" "буфер1" по имени (т.к. под этим именем на самом деле несколько разных oid единтичных таблиц сборки), а также она обязана дропаться. Хотя ничто не мешает отдублировать все процедуры переливки.



PS (Может быть попробовать наследовать все таблицы сборки от одной "вечно пустой" templatetable) И переливать запросом к ней, но с ... FROM templatetable WHERE tableoid=[toid1|toid2....]? Тогда таблицы можно не дропать, а просто транкейтить, а процедура переливки будет одна, с переключателем источника типа WHERE tableoid = f_tableoid(NOW()).
...
Рейтинг: 0 / 0
16.03.2005, 10:33
| Ответить | Цитировать | Написать  
Работа с большими таблицами
    #32963379
Алексей Ключников
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Алексей Ключников
Участник
Да можно в каждой функции работающей с этими таблицами ввести переменную куда и заносить текущую таблицу. А изщней как?
С переименованием как то через не то место выглядит :)
можно еще запросы сразу по двум таблицам делать и в UNION их.. тоже что то не сходиться.
А при trancate table проблемы с вакумом возникнут!! и с делете возникнут.
...
Рейтинг: 0 / 0
16.03.2005, 14:02
| Ответить | Цитировать | Написать  
Работа с большими таблицами
    #32963712
4321
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
4321
Участник
Алексей Ключников Да можно в каждой функции работающей с этими таблицами ввести переменную куда и заносить текущую таблицу. А изщней как?

дык как хотите.
Алексей Ключников
С переименованием как то через не то место выглядит :)

ну, это особенности индивидуальной анатомии. Расположения глаза, т.е.. (Если все всегда выглядит через это место. )
Алексей Ключников
А при trancate table проблемы с вакумом возникнут!! и с делете возникнут.
с какого перепуга? Это ведь не пометка записей "удаленными" как при делет. Это, по сути, разметка таблички заново (ну че там системой выделяется под табличку), с освобождением всего старого занятого взад ОС.
авторTRUNCATE quickly removes all rows from a table. It has the same effect as an unqualified DELETE but since it does not actually scan the table it is faster. This is most useful on large tables.
...
Рейтинг: 0 / 0
16.03.2005, 15:34
| Ответить | Цитировать | Написать  
18 сообщений из 18, страница 1 из 1
Форумы / PostgreSQL [игнор отключен] [закрыт для гостей] / Работа с большими таблицами
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


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