powered by simpleCommunicator - 2.0.60     © 2026 Programmizd 02
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Форумы / PostgreSQL [игнор отключен] [закрыт для гостей] / Получение данных из большой таблицы
37 сообщений из 37, показаны все 2 страниц
Получение данных из большой таблицы
    #35599400
Здравствуйте!
Есть таблица, в которой хранится трафик.
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
                 Table "internet.trafic_20080901"
  Column   |            Type             |       Modifiers
-----------+-----------------------------+------------------------
 ip_from   | inet                        | not null
 port_from | character varying( 10 )       | not null
 ip_to     | inet                        | not null
 bytes     | bigint                      | not null
 t_t       | smallint                    | not null
 place     | smallint                    | not null
 tm        | timestamp without time zone | not null default now()
 client_id | integer                     | not null
Indexes:
    "trafic_20080901_client_idx" btree (client_id)
В таблице 80млн. записей, размер таблицы - 6Гб.
Из этой таблицы нужно взять трафик для каждого client_id и поместить его в свой файл.
client_id имеет около 16000 различных значений.
Подскажите, как лучше выбирать данные? Записывать в файл будет скрипт либо на php, либо на python (еще не определился).
Вариантов вижу несколько:
1. запрос для каждого client_id. Недостаток - очень много запросов. выполнение каждого запроса - около 3-4 секунд.
2. запрос для диапазонов - сначала от 1 до 100, затем от 101 до 200 и т.д. В скрипте можно будет открыть 100 файлов, и туда всё записать. Время выполнения одного запроса - 27секунд.
3. запрос всех данных. Не хочу загружать 6 гиг в оперативку. время выполнения не вычислял ;)
4. дамп таблицы и работа уже в текстовым файлом. время выполнения дампа - около 20 минут.
Пока других вариантов не вижу, а хочется придумать, ибо такая задача будет выполняться каждую ночь. После создания таких файлов таблица будет удаляться. Надеюсь на ваши советы :)
БД: PostgreSQL 8.3
Debian 4, 30Gb RAM, 4x2.8 CPU
...
Рейтинг: 0 / 0
Получение данных из большой таблицы
    #35599451
Фотография MasterZiv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Скрябин Дмитрий wrote:

> Table "internet.trafic_20080901"
> Column | Type | Modifiers
> -----------+-----------------------------+------------------------
> ip_from | inet | not null
> port_from | character varying(*10*) | not null
> ip_to | inet | not null
> bytes | bigint | not null
> t_t | smallint | not null
> place | smallint | not null
> tm | timestamp without time zone | not null default now()
> client_id | integer | not null
> Indexes:
> "trafic_20080901_client_idx" btree (client_id)
>
> В таблице 80млн. записей, размер таблицы - 6Гб.
> Из этой таблицы нужно взять трафик для каждого client_id и поместить его
> в свой файл.

select * from internet.trafic_20080901
order by client_id

бежать по запросу, и переписывать данные в куда надо.
Как только будет меняться client_id, закрывать предыдущий
файл клиента и открывать следующий.

Перед выполнением запроса проверьте его план, и убедитесь
в том, что сервер не будет сортировать данные, а будет
использовать индекс.
Posted via ActualForum NNTP Server 1.4
...
Рейтинг: 0 / 0
Получение данных из большой таблицы
    #35599857
MasterZiv, в этом случае все данные будут в память загружаться всей кучей, все 6 гигабайт. Думаешь, это оптимальный вариант?

Код: plaintext
1.
2.
3.
4.
5.
6.
db3=>      explain select * from internet.trafic_20080901 order by client_id;
                                    QUERY PLAN
-----------------------------------------------------------------------------------
 Sort  (cost= 23744033 . 47 .. 23944644 . 35  rows= 80244352  width= 43 )
   Sort Key: client_id
   ->  Seq Scan on trafic_20080901  (cost= 0 . 00 .. 1552201 . 52  rows= 80244352  width= 43 )
( 3  rows)

Планировщик решил, что правильнее будет индекс не использовать.
...
Рейтинг: 0 / 0
Получение данных из большой таблицы
    #35599875
Kruchinin Pahan
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Скрябин ДмитрийMasterZiv, в этом случае все данные будут в память загружаться всей кучей, все 6 гигабайт. Думаешь, это оптимальный вариант?

Код: plaintext
1.
2.
3.
4.
5.
6.
db3=>      explain select * from internet.trafic_20080901 order by client_id;
                                    QUERY PLAN
-----------------------------------------------------------------------------------
 Sort  (cost= 23744033 . 47 .. 23944644 . 35  rows= 80244352  width= 43 )
   Sort Key: client_id
   ->  Seq Scan on trafic_20080901  (cost= 0 . 00 .. 1552201 . 52  rows= 80244352  width= 43 )
( 3  rows)

Планировщик решил, что правильнее будет индекс не использовать.
Возможно проблема в SELECT *
Перечислите только те поля, которые действительно вам необходимы для суммирования.
...
Рейтинг: 0 / 0
Получение данных из большой таблицы
    #35599999
Kruchinin Pahan,
Даже если одно поле выбрать - все равно индекс не используется. Да и не много толку будет тут от индекса - все равно все данные загружать.

Код: plaintext
1.
2.
3.
4.
5.
6.
7.
explain select client_id from internet.trafic_20080901 order by client_id;
                                    QUERY PLAN
----------------------------------------------------------------------------------
 Sort  (cost= 15927262 . 97 .. 16127873 . 85  rows= 80244352  width= 4 )
   Sort Key: client_id
   ->  Seq Scan on trafic_20080901  (cost= 0 . 00 .. 1552201 . 52  rows= 80244352  width= 4 )
( 3  rows)
...
Рейтинг: 0 / 0
Получение данных из большой таблицы
    #35600013
Kruchinin Pahan
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Скрябин ДмитрийKruchinin Pahan,
Даже если одно поле выбрать - все равно индекс не используется. Да и не много толку будет тут от индекса - все равно все данные загружать.

Значит, действительно нет необходимости. В реальности, иногда сортировка всей таблы ускоряется, если по индексу. Но, в общем-то MasterZiv прав. Данный способ может оказаться самым быстрым.
Чтобы много памяти на клиенте не жрать, можно Fetch кусками делать (через курсор). И работать с небольшими блоками.
...
Рейтинг: 0 / 0
Получение данных из большой таблицы
    #35600326
Фотография MasterZiv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Скрябин Дмитрий wrote:
> MasterZiv, в этом случае все данные будут в память загружаться всей
> кучей, все 6 гигабайт.

А ты можешь как-то обработать данные, не читая их в память ?
Ну, давай, телепат ...

Думаешь, это оптимальный вариант?
Да, 100%.
Posted via ActualForum NNTP Server 1.4
...
Рейтинг: 0 / 0
Получение данных из большой таблицы
    #35600334
Фотография MasterZiv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Kruchinin Pahan wrote:

> Планировщик решил, что правильнее будет индекс не использовать.
>
>
> Возможно проблема в SELECT *
> Перечислите только те поля, которые действительно вам необходимы для
> суммирования.
А это на скорость не повлияет. Таблица всё равно будет читаться.
Posted via ActualForum NNTP Server 1.4
...
Рейтинг: 0 / 0
Получение данных из большой таблицы
    #35600337
Фотография MasterZiv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Скрябин Дмитрий wrote:

> db3=> explain select * from internet.trafic_20080901 order by client_id;
> QUERY PLAN
> -----------------------------------------------------------------------------------
> Sort (cost=*23744033*.*47*..*23944644*.*35* rows=*80244352* width=*43*)
> Sort Key: client_id
> -> Seq Scan on trafic_20080901 (cost=*0*.*00*..*1552201*.*52* rows=*80244352* width=*43*)
> (*3* rows)
>
>
> Планировщик решил, что правильнее будет индекс не использовать.

Ой, я это просмотрел.
Нет, надо его ЗАСТАВИТЬ использовать индекс и не сортировать данные.
Иначе - будет труба. Сортировать такой массив данных очень сложно.
Posted via ActualForum NNTP Server 1.4
...
Рейтинг: 0 / 0
Получение данных из большой таблицы
    #35600345
Фотография MasterZiv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Скрябин Дмитрий wrote:

> Даже если одно поле выбрать - все равно индекс не используется. Да и не
> много толку будет тут от индекса - все равно все данные загружать.

Использование индекса даст возможность не сортировать таблицу.
Она у тебя большая. А если ты заставишь сканировать индекс,
то, поскольку индекс упорядочен, серверу не придётся сортировать
таблицу. Оптимизатор вполне оправдано не берёт индекс, потому что
сканировать без индекса конечно же быстрее. Но сортировать дольше.
Posted via ActualForum NNTP Server 1.4
...
Рейтинг: 0 / 0
Получение данных из большой таблицы
    #35600427
Kruchinin Pahan
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
MasterZiv
Использование индекса даст возможность не сортировать таблицу.
Она у тебя большая. А если ты заставишь сканировать индекс,
то, поскольку индекс упорядочен, серверу не придётся сортировать
таблицу. Оптимизатор вполне оправдано не берёт индекс, потому что
сканировать без индекса конечно же быстрее. Но сортировать дольше.
Posted via ActualForum NNTP Server 1.4
Согласен. Туплю.
...
Рейтинг: 0 / 0
Получение данных из большой таблицы
    #35600469
MySQLCraft
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
А еще быстрее, не использовать индекс и не сортировать данные, выполнять full scan, обрабатывать данные кусками. Файлы открывать по необходимости, а закрывать после завершения всех операций. При поступлении очередной записи записывать ее в нужный файловый поток.
...
Рейтинг: 0 / 0
Получение данных из большой таблицы
    #35600575
Фотография MasterZiv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
MySQLCraft wrote:

> А еще быстрее, не использовать индекс и не сортировать данные, выполнять
> full scan, обрабатывать данные кусками. Файлы открывать по
> необходимости, а закрывать после завершения всех операций. При
> поступлении очередной записи записывать ее в нужный файловый поток.

Я бы так и посоветовал бы, если бы не количество групп:

"Из этой таблицы нужно взять трафик для каждого client_id и поместить его в свой
файл.
client_id имеет около 16000 различных значений."

16000 - многовато. В некоторых ОС даже столько файловых дескрипторов не
открыть.
Posted via ActualForum NNTP Server 1.4
...
Рейтинг: 0 / 0
Получение данных из большой таблицы
    #35600734
MasterZiv
Скрябин Дмитрий wrote:
> MasterZiv, в этом случае все данные будут в память загружаться всей
> кучей, все 6 гигабайт.

А ты можешь как-то обработать данные, не читая их в память ?

Posted via ActualForum NNTP Server 1.4

Вот, оказывается, могу :) Не читая их разом. Совсем не подумал про курсоры - спасибо Kruchinin Pahan! Так и сделаю. Была трудность как раз в том, чтобы по минимуму нагружать базу и использовать меньше оперативной памяти в процессе работы с этой таблицей. курсоры как раз подходят
Открыть 16000 файлов конечно не получится, думаю разбить все данные сначала на 100 файлов (по диапазонам client_id), потом каждый файл еще на 100, тогда в конечном итоге будет в каждом файле не более 100 разных client_id. Там уже каждый файл можно разложить на требуемые файлы. 100 дескрипторов система спокойно потянет :)
...
Рейтинг: 0 / 0
Получение данных из большой таблицы
    #35600811
LeXa NalBat
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Скрябин ДмитрийMasterZiv, в этом случае все данные будут в память загружаться всей кучей, все 6 гигабайт. Думаешь, это оптимальный вариант?

Код: plaintext
1.
2.
3.
4.
5.
6.
db3=>      explain select * from internet.trafic_20080901 order by client_id;
                                    QUERY PLAN
-----------------------------------------------------------------------------------
 Sort  (cost= 23744033 . 47 .. 23944644 . 35  rows= 80244352  width= 43 )
   Sort Key: client_id
   ->  Seq Scan on trafic_20080901  (cost= 0 . 00 .. 1552201 . 52  rows= 80244352  width= 43 )
( 3  rows)

Планировщик решил, что правильнее будет индекс не использовать.сделайте set enable_seqscan to off;
...
Рейтинг: 0 / 0
Получение данных из большой таблицы
    #35601009
MySQLCraft
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
MasterZiv
MySQLCraft wrote:

> А еще быстрее, не использовать индекс и не сортировать данные, выполнять
> full scan, обрабатывать данные кусками. Файлы открывать по
> необходимости, а закрывать после завершения всех операций. При
> поступлении очередной записи записывать ее в нужный файловый поток.

Я бы так и посоветовал бы, если бы не количество групп:

"Из этой таблицы нужно взять трафик для каждого client_id и поместить его в свой
файл.
client_id имеет около 16000 различных значений."

16000 - многовато. В некоторых ОС даже столько файловых дескрипторов не
открыть.
Posted via ActualForum NNTP Server 1.4
Буферизовать массивы в оперативной памяти и периодически скидывать на диск, открывая столько файлов, сколько потянет ОС.
...
Рейтинг: 0 / 0
Получение данных из большой таблицы
    #35601068
MySQLCraft
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Но лучше, открывать только один файл, чтобы не было конкуренции между потоками при записи.
Короче. Второй поток, получает порции данных от SQL сервера и сортирует их по 16000 массивам. Второй поток обходит по очереди не пустые массивы, забирает оттуда данные и обнуляет текущий массив, открывает соответствующий файл, пишет, закрывает файл. Периодичность обхода зависит от ограничений оперативки и субъективных критериев.
...
Рейтинг: 0 / 0
Получение данных из большой таблицы
    #35601076
MySQLCraft
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
очепятка "Короче. Первый поток"... ))))
...
Рейтинг: 0 / 0
Получение данных из большой таблицы
    #35601264
Фотография MasterZiv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Скрябин Дмитрий wrote:

> Вот, оказывается, могу :) Не читая их разом. Совсем не подумал про
> курсоры - спасибо Kruchinin Pahan! Так и сделаю.

Ты думаешь, что курсоры не тянут куски таблицы в память ?
Ты ошибаешься, курсор - ровно такой же запрос, как и все остальное.

> Открыть 16000 файлов конечно не получится, думаю разбить все данные
> сначала на 100 файлов (по диапазонам client_id), потом каждый файл еще
> на 100, тогда в конечном итоге будет в каждом файле не более 100 разных
> client_id. Там уже каждый файл можно разложить на требуемые файлы. 100
> дескрипторов система спокойно потянет :)


Увеличишь только свою работу внесколько раз.
Posted via ActualForum NNTP Server 1.4
...
Рейтинг: 0 / 0
Получение данных из большой таблицы
    #35601267
Фотография MasterZiv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
MySQLCraft wrote:

> Буферизовать массивы в оперативной памяти и периодически скидывать на
> диск, открывая столько файлов, сколько потянет ОС.
а если не влезет ?
Posted via ActualForum NNTP Server 1.4
...
Рейтинг: 0 / 0
Получение данных из большой таблицы
    #35601369
авторТы думаешь, что курсоры не тянут куски таблицы в память ?
Ты ошибаешься, курсор - ровно такой же запрос, как и все остальное.
Конечно тянут - но не все 6 гиг сразу, а частями. поэтому в единицу времени скрипт требует не так много памяти.
MySQLCraft, спасибо, попробую оба варианта и сравню скорость :)
...
Рейтинг: 0 / 0
Получение данных из большой таблицы
    #35601578
Sishnikov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
а SQL-комманду COPY вы не рассматривали?
...
Рейтинг: 0 / 0
Получение данных из большой таблицы
    #35601769
Фотография MasterZiv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Скрябин Дмитрий wrote:

> Конечно тянут - но не все 6 гиг сразу, а частями. поэтому в единицу
> времени скрипт требует не так много памяти.

Так и запрос тебе все 6 гигов сразу не вытащит. Точно так же
кусками и будет подтаскивать.

На самом деле курсоры сами используются внутри сервера, когда
вы запрос выполняете. Это ровно то же самое.
вы бежите fetch-ем по строкам, это и есть курсор.

> MySQLCraft, спасибо, попробую оба варианта и сравню скорость :)

Бессмысленно пробовать два варианта.
Posted via ActualForum NNTP Server 1.4
...
Рейтинг: 0 / 0
Получение данных из большой таблицы
    #35602067
Фотография Степан H.
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
как вариант
данные в таблицу подгружать и обрабатывать порциями
client_id разбить на группы group_id и партицировать эти группы .. или вовсе разнести в разные таблицы (если позволяет устройство загрузки трафика)

выгребать вашим 1-м вариантом несколькими потоками (по идее время select должно значительно уменьшиться, количество запросов в единицу времени возрасти)
...
Рейтинг: 0 / 0
Получение данных из большой таблицы
    #35602249
MasterZiv
Так и запрос тебе все 6 гигов сразу не вытащит. Точно так же
кусками и будет подтаскивать.

На самом деле курсоры сами используются внутри сервера, когда
вы запрос выполняете. Это ровно то же самое.
вы бежите fetch-ем по строкам, это и есть курсор.


На самом деле это не так. Точнее не совсем так, о чем нам и говорит первый абзац в разделе "38.7. Cursors" в документации. Я написал 2 тестовых скрипта, первый тянет данные одним запросом, второй - через курсоры. Второй использует в разы меньше памяти. Если интересует - могу выложить текст скриптов, сами убетитесь или опровергните мое утверждение.

Sishnikov, COPY TO рассматривал, но не остановился на нем. php копирует команду только в массив. А копирование в файл во-первых, требует прав postgres, во-вторых, это то же, что и дамп таблицы - проще наверно сделать дамп, если решу работать с текстовым файлом.

Степан Н., к сожалению, трафик сейчас можно загружать только в одну таблицу :(
...
Рейтинг: 0 / 0
Получение данных из большой таблицы
    #35602446
Фотография MasterZiv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Скрябин Дмитрий wrote:

> На самом деле это не так. Точнее не совсем так, о чем нам и говорит
> первый абзац в разделе "38.7. Cursors" в документации. Я написал 2
> тестовых скрипта, первый тянет данные одним запросом, второй - через
> курсоры. Второй использует в разы меньше памяти. Если интересует - могу
> выложить текст скриптов, сами убетитесь или опровергните мое утверждение.

Ну давайте.
Я вот не могу представить, почему бы это могло быть так.
Posted via ActualForum NNTP Server 1.4
...
Рейтинг: 0 / 0
Получение данных из большой таблицы
    #35602766
MasterZiv, тестовыя таблица temp из 3114832 записей.
В первом случае выполняем запрос целиком:
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
#!/usr/bin/php -q
<?
function getmem($pid){
  exec("ps -o rss -p ".$pid, $o);
  return $o[ 1 ];
}

$connect=pg_connect("host=127.0.0.1 user=test password=test dbname=g3");
$pgpid=pg_get_pid($connect);

echo "Before query\n";
echo "php Process mem: ".getmem(getmypid()),"kb\n";
echo "postgres process mem: ".getmem($pgpid)."kb\n";

$query=pg_query($connect,'select * from temp');

echo "\nAfter query\n";
echo "php Process mem: ".getmem(getmypid()),"kb\n";
echo "postgres process mem: ".getmem($pgpid)."kb\n";

pg_close($connect);
?>
Результат:
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
Before query
php Process mem:  5020kb
postgres process mem:  2144kb

After query
php Process mem: 795356kb
postgres process mem:  3504kb
PHP раздулся до 790Мб

Второй вариант, загружаем данные в курсоре по 100000 записей:
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
#!/usr/bin/php -q
<?
function getmem($pid){
  exec("ps -o rss -p ".$pid, $o);
  return $o[ 1 ];
}

$connect=pg_connect("host=127.0.0.1 user=test password=test dbname=g3");
$pgpid=pg_get_pid($connect);

echo "Before query\n";
echo "php Process mem: ".getmem(getmypid()),"kb\n";
echo "postgres process mem: ".getmem($pgpid)."kb\n";

pg_query($connect,'begin transaction');
pg_query($connect,'declare test cursor for select * from temp');
echo "\nAfter build cursor\n";
echo "php Process mem: ".getmem(getmypid()),"kb\n";
echo "postgres process mem: ".getmem($pgpid)."kb\n";

$query=pg_query($connect,'fetch 100000 from test');
while(pg_num_rows($query)> 0 ){
  echo "\nAfter query\n";
  echo "php Process mem: ".getmem(getmypid()),"kb\n";
  echo "postgres process mem: ".getmem($pgpid)."kb\n";
  unset($query);
  $query=pg_query($connect,'fetch 100000 from test');
}

pg_query($connect,'close test');
pg_query($connect,'commit');
pg_close($connect);
?>
Вывод (начало и конец):
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
Before query
php Process mem:  5028kb
postgres process mem:  2144kb

After build cursor
php Process mem:  5068kb
postgres process mem:  3008kb

After query
php Process mem: 30468kb
postgres process mem:  3464kb

....

After query
php Process mem: 30668kb
postgres process mem:  3464kb

After query
php Process mem: 30672kb
postgres process mem:  3464kb

After query
php Process mem:  9072kb
postgres process mem:  3976kb
В процессе работы процесс потреблял не более 30Мб.
По-моему, результат на лицо.
...
Рейтинг: 0 / 0
Получение данных из большой таблицы
    #35602973
Фотография MasterZiv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Скрябин Дмитрий wrote:
> MasterZiv, тестовыя таблица temp из 3114832 записей.
> В первом случае выполняем запрос целиком:

Это вы не так смотрите. Это вы FETCH тестируете и PHP.
PHP я бы вообще исключил бы из эксперимента, простой консолькой
работал бы.

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

Не, в общем, не убедили.
Posted via ActualForum NNTP Server 1.4
...
Рейтинг: 0 / 0
Получение данных из большой таблицы
    #35603089
MasterZiv, либо вы себе противоречите, либо мы друг друга не поняли. Что касается php, то изначально я сказал, что буду писать на php или python. Теория с командной строкой не канает - нужно проверять в том, в чем будешь работать. Хотя с командной строкой будет так же ;)
...
Рейтинг: 0 / 0
Получение данных из большой таблицы
    #35603187
Фотография MasterZiv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Скрябин Дмитрий wrote:

> MasterZiv, либо вы себе противоречите, либо мы друг друга не поняли. Что
> касается php, то изначально я сказал, что буду писать на php или python.

Вы можете в этом вашем PHP или питоне (думаю, в питоне точно можно)
вы-FETCH-ивать ПО ОДНОЙ строке ? Если сможете, на клиенте вообще
практически память заниматься не будет.

> Теория с командной строкой не канает - нужно проверять в том, в чем
> будешь работать. Хотя с командной строкой будет так же ;)

Нужно думать мозгами, а не проверять.
Я вам говорю, что эти два способа ничем
друг от друга не отличаются. Память жрёт ваш PHP, куда вы
запихиваете ВЕСЬ набор данных в одном случае, и 100 тыщ
записей в другой. А жрать оно не должно ВООБЩЕ ничего в
нормально написанном приложении (для вашей конкретной цели).

Возмите выполните в psql тот же запрос, и поглядите
сколько он будет сжирать памяти, я думаю, вы не заметите
большой разницы.
Posted via ActualForum NNTP Server 1.4
...
Рейтинг: 0 / 0
Получение данных из большой таблицы
    #35603189
Фотография MasterZiv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Скрябин Дмитрий wrote:
> MasterZiv, либо вы себе противоречите, либо мы друг друга не поняли.

А, я понял, почему по вашему мнению я сам себе противоречу.

Я вообще про производительность клиента не говорил. Только про серверную.
Вы же меня грузите клиентской производительностью. А она
тут вообще роли не играет, если всё нормально делать.
Производительность суммарная будет определяться производительностью
чтения PSQL-ем данных из таблицы и записи вашим клиентом туда, куда
вы там записываете (например, диска).
Posted via ActualForum NNTP Server 1.4
...
Рейтинг: 0 / 0
Получение данных из большой таблицы
    #35603906
Sad Spirit
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
MasterZiv
Нужно думать мозгами, а не проверять.
Я вам говорю, что эти два способа ничем
друг от друга не отличаются. Память жрёт ваш PHP, куда вы
запихиваете ВЕСЬ набор данных в одном случае, и 100 тыщ
записей в другой. А жрать оно не должно ВООБЩЕ ничего в
нормально написанном приложении (для вашей конкретной цели).

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


Память жрёт не PHP, а клиентская библиотека libpq. В случае с psql числа будут примерно такими же.

И вообще, MasterZiv , уровень понтов в твоих сообщениях значительно превосходит уровень понимания вопроса.
...
Рейтинг: 0 / 0
Получение данных из большой таблицы
    #35604279
MasterZiv, вы бы сначала проверили, а затем уже говорили. psql - это простейшая оболочка, тот же клиент. И она тоже получает все данные за раз.
Что касается сервера - он отдает то, что у него попросили. Попросили 100 записей - он отдал 100 записей, попросили все - он отдал всё.
Если вы считаете, что запрашивать данные с сервера по одной строке - это правильное решение, то вы, мягко говоря, ошибаетесь. Это не есть "нормально написанное приложение". И не важно, какой язык. хоть си, хоть php.
...
Рейтинг: 0 / 0
Получение данных из большой таблицы
    #35605318
Фотография MasterZiv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Sad Spirit wrote:

> Память жрёт не PHP, а клиентская библиотека libpq. В случае с psql числа
> будут примерно такими же.

В общем-то разница небольшая. Но я думаю всё же, что это именно PHP.

> И вообще, *MasterZiv*, уровень понтов в твоих сообщениях значительно
> превосходит уровень понимания вопроса.

Да пожалуйста, не хочешь - не слушай.
Posted via ActualForum NNTP Server 1.4
...
Рейтинг: 0 / 0
Получение данных из большой таблицы
    #35605325
Фотография MasterZiv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Скрябин Дмитрий wrote:

> MasterZiv, вы бы сначала проверили, а затем уже говорили. psql - это
> простейшая оболочка, тот же клиент. И она тоже получает все данные за раз.

Всё же может быть построчно...

> Что касается сервера - он отдает то, что у него попросили. Попросили 100
> записей - он отдал 100 записей, попросили все - он отдал всё.
> Если вы считаете, что запрашивать данные с сервера по одной строке - это
> правильное решение, то вы, мягко говоря, ошибаетесь. Это не есть

Да,правильное. Запрашивать, обрабатывать, и освобождать память под следующие
данные. Так именно и работают высокопроизводительные утилиты типа выгзузки
данных. Можно обрабатывать также небольшими блоками, но это на самом деле
всё равно, обычно API работы с базой данных всё равно работает буферами
по N строк, по одной строке никто не дёргает.

> "нормально написанное приложение". И не важно, какой язык. хоть си, хоть
> php.

Ну, PHP-то здесь естественно ни при чём. Там можно было бы делать
fetch в курсоре по одной записи (по 10 записей). Или какой-то
другой вызов API делать, который не тащит весь набор на клиента.
Posted via ActualForum NNTP Server 1.4
...
Рейтинг: 0 / 0
Получение данных из большой таблицы
    #35605391
Фотография MasterZiv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Скрябин Дмитрий wrote:
> MasterZiv, вы бы сначала проверили, а затем уже говорили. psql - это
> простейшая оболочка, тот же клиент. И она тоже получает все данные за раз.
> Что касается сервера - он отдает то, что у него попросили. Попросили 100

Ну, что ж вы мне тут рассказываете ?

Вот кусок кода PSQL

Код:
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
/*
  * ExecQueryUsingCursor: run a SELECT-like query using a cursor
  *
  * This feature allows result sets larger than RAM to be dealt with.
  *
  * Returns true if the query executed successfully, false otherwise.
  *
  * If pset.timing is on, total query time (exclusive of result-printing) is
  * stored into *elapsed_msec.
  */
static bool
ExecQueryUsingCursor(const char *query, double *elapsed_msec)
{




правда, оно там курсор серверный тоже явно использует.
Странно, почему. Ну да ладно, ведь может же по одной
строчке.
Posted via ActualForum NNTP Server 1.4
...
Рейтинг: 0 / 0
Получение данных из большой таблицы
    #35606686
LeXa NalBat
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
MasterZiv, почитайте про libpq
...
Рейтинг: 0 / 0
37 сообщений из 37, показаны все 2 страниц
Форумы / PostgreSQL [игнор отключен] [закрыт для гостей] / Получение данных из большой таблицы
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


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