powered by simpleCommunicator - 2.0.59     © 2026 Programmizd 02
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Форумы / Сравнение СУБД [игнор отключен] [закрыт для гостей] / Выбор БД для быстрой работы с большими таблицами.
52 сообщений из 52, показаны все 3 страниц
Выбор БД для быстрой работы с большими таблицами.
    #32665129
Carrie
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Есть postgresql 7.4.x, есть таблица, в которой кол-во записей ~35млн, одно из полей типа SMALLINT (2bytes) и по нему создан Btree индекс.
так вот запрос вида
select count(*) from tbl_name where это_поле>17::smallint;
выполняется ~40секунд при том что результат запроса - всего 9003 записей.
Explain показывает, что БД юзает индекс.

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

Так же тестировался mysql 4.0.18, где результаты существенно печальней. Конфиги для mysql и postgresql, как мне кажется, настроены сейчас оптимально; машинка с БД более чем приличная (2x2.4 Xeon, 2Гб RAM, 4x36Гб SCSI etc..)
...
Рейтинг: 0 / 0
Выбор БД для быстрой работы с большими таблицами.
    #32665153
Фотография ScareCrow
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
а что счетчики показывают?
...
Рейтинг: 0 / 0
Выбор БД для быстрой работы с большими таблицами.
    #32665198
Yo!
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Yo!
Гость
ту которая позволяет парионинг ...
...
Рейтинг: 0 / 0
Выбор БД для быстрой работы с большими таблицами.
    #32665213
Carrie
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
v3=# \d exp
Table "public.exp"
Column | Type | Modifiers
--------+----------+-----------
...вырезано...
pr | smallint |
cost | bigint |

Indexes:
"exp_idx1" btree (pr)

v3=# select count(*) from exp;
count
----------
34700903
(1 row)

Time: 91860.301 ms
v3=# explain select count(*), sum(cost) from exp where pr>17::smallint;
QUERY PLAN
---------------------------------------------------------------------
Aggregate (cost=831801.15..831801.15 rows=1 width=8)
-> Seq Scan on exp (cost=0.00..773966.30 rows=11566968 width=8)
Filter: (pr > 17::smallint)
(3 rows)

Time: 243.354 ms
v3=# set enable_seqscan=off;
SET
Time: 1.307 ms
v3=# explain select count(*), sum(cost) from exp where pr>17::smallint;
QUERY PLAN
---------------------------------------------------------------------------------------
Aggregate (cost=4746664.26..4746664.26 rows=1 width=8)
-> Index Scan using exp_idx1 on exp (cost=0.00..4688829.42 rows=11566968 width=8)
Index Cond: (pr > 17::smallint)
(3 rows)

Time: 1.703 ms
3=# select count(*), sum(cost) from exp where pr>17::smallint;
count | sum
-------+------------
9008 | 2644131197
(1 row)

Time: 29359.521 ms

explain analyze выложу попозже, если интересно ... - закэшировалось все и timing'и не посмотреть)
...
Рейтинг: 0 / 0
Выбор БД для быстрой работы с большими таблицами.
    #32665247
Фотография ScareCrow
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
все с тобой ясно...
...
Рейтинг: 0 / 0
Выбор БД для быстрой работы с большими таблицами.
    #32665257
Серега
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Carrieвыполняется ~40секунд при том что результат запроса - всего 9003 записей.
Explain показывает, что БД юзает индекс.

машинка с БД более чем приличная (2x2.4 Xeon, 2Гб RAM, 4x36Гб SCSI etc..)
А сеть какая? 9000 записей протащить тоже время надо. Кстати зачем столько? Не в грид случаем?
...
Рейтинг: 0 / 0
Выбор БД для быстрой работы с большими таблицами.
    #32665374
LeXa NalBat
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
У меня постгрес 7.3 и оракл 8.1 на запросе аналогичном вашему показали примерно одинаковый результат, причем в 10 раз быстрее 40 секунд. Эксперимент проводил с незакэшированными данными, повторный запрос и на постгре и на оракле отрабатывает за пять сотых секунды. На одной и той же железке по мощности примерно такой же как ваша. В таблице plprice_00 немногим менее 3 миллионов строк.

Код: 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.
33.
update@thyella:~$ time echo "select count(*) from plprice_00 where plno > 170813001;" | sqlplus pl/pl@local

SQL*Plus: Release 8.1.7.0.0 - Production on Wed Aug 25 16:49:15 2004

(c) Copyright 2000 Oracle Corporation.  All rights reserved.


Connected to:
Oracle8i Enterprise Edition Release 8.1.7.3.0 - Production
With the Partitioning option
JServer Release 8.1.7.3.0 - Production

SQL>
  COUNT(*)
----------
      9000

SQL> Disconnected from Oracle8i Enterprise Edition Release 8.1.7.3.0 - Production
With the Partitioning option
JServer Release 8.1.7.3.0 - Production

real    0m4.877s
user    0m0.030s
sys     0m0.020s
update@thyella:~$ time echo "select count(*) from plprice_00 where plno > 170813001;" | psql -U pl -d pl
 count
-------
  9000
(1 row)


real    0m4.991s
user    0m0.000s
sys     0m0.000s
...
Рейтинг: 0 / 0
Выбор БД для быстрой работы с большими таблицами.
    #32665443
Константин Лисянский
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
У меня Teradata.

Таблица такая:


Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
CREATE SET TABLE rpdm30.w_HOURLY_PRODUCT_SALES ,NO FALLBACK ,
     NO BEFORE JOURNAL,
     NO AFTER JOURNAL,
     CHECKSUM = DEFAULT
     (
      DayDT INTEGER,
      HourID INTEGER,
      ItemID INTEGER,
      ItemRev FLOAT COMPRESS  0 .00000000000000E  000  )
UNIQUE PRIMARY INDEX XPK_wHPS ( DayDT ,HourID ,ItemID )
PARTITION BY RANGE_N(DayDT  BETWEEN DATE '2001-01-01' AND DATE '2004-12-25' EACH INTERVAL '1' DAY )
INDEX w_hs_IDX ( ItemID );

Видно (в последней строке), что есть индекс по ItemID.


Запрос:
Код: plaintext
SELECT COUNT (*) FROM w_HOURLY_PRODUCT_SALES

Возвращает 257 730 888 строк (немного побольше, чем у Вас :).

Выполняется 12 секунд.


Запрос:
Код: plaintext
SELECT COUNT (*) FROM w_HOURLY_PRODUCT_SALES WHERE ItemID< 1000 

Выполняется 11 секунд.
Возвращает 8808 строк.

План запроса:

Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
Explanation
   1 ) First, we lock a distinct RPDM30."pseudo table" for read on a
     RowHash to prevent global deadlock for
     RPDM30.w_HOURLY_PRODUCT_SALES. 
   2 ) Next, we lock RPDM30.w_HOURLY_PRODUCT_SALES for read. 
   3 ) We do an all-AMPs SUM step to aggregate from
     RPDM30.w_HOURLY_PRODUCT_SALES by way of a traversal of index #  4 
     without accessing the base table with a residual condition of (
     "RPDM30.w_HOURLY_PRODUCT_SALES.ItemID < 1000").  Aggregate
     Intermediate Results are computed globally, then placed in Spool  3 . 
     The input table will not be cached in memory, but it is eligible
     for synchronized scanning.  The size of Spool  3  is estimated with
     high confidence to be  1  row.  The estimated time for this step is
      2  minutes and  58  seconds. 
   4 ) We do an all-AMPs RETRIEVE step from Spool  3  (Last Use) by way of
     an all-rows scan into Spool  1  (group_amps), which is built locally
     on the AMPs.  The size of Spool  1  is estimated with high
     confidence to be  1  row.  The estimated time for this step is  0 . 03 
     seconds. 
   5 ) Finally, we send out an END TRANSACTION step to all AMPs involved
     in processing the request.
  -> The contents of Spool  1  are sent back to the user as the result of
     statement  1 . 


Железка такая:
2 XEON 2.8 ГГЦ, 4 ГБ ОЗУ. 10 зеркальных пар SCSI по 36 ГБ. Дисков побольше, чем у Вас, это существенно помогает.


Кстати, за то время, которое у Вас происходит сканирование индекса, у меня вся таблица сканируется.
По HourID у меня нету индекса.
Запрос:
Код: plaintext
SELECT COUNT (*) FROM w_HOURLY_PRODUCT_SALES WHERE HourID> 15 
Выполняется за 42 секунды.

Вот план запроса:
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
Explanation
   1 ) First, we lock a distinct RPDM30."pseudo table" for read on a
     RowHash to prevent global deadlock for
     RPDM30.w_HOURLY_PRODUCT_SALES. 
   2 ) Next, we lock RPDM30.w_HOURLY_PRODUCT_SALES for read. 
   3 ) We do an all-AMPs SUM step to aggregate from
     RPDM30.w_HOURLY_PRODUCT_SALES by way of an all-rows scan with a
     condition of ("RPDM30.w_HOURLY_PRODUCT_SALES.HourID > 15"). 
     Aggregate Intermediate Results are computed globally, then placed
     in Spool  3 .  The input table will not be cached in memory, but it
     is eligible for synchronized scanning.  The size of Spool  3  is
     estimated with high confidence to be  1  row.  The estimated time
     for this step is  7  minutes and  59  seconds. 
   4 ) We do an all-AMPs RETRIEVE step from Spool  3  (Last Use) by way of
     an all-rows scan into Spool  1  (group_amps), which is built locally
     on the AMPs.  The size of Spool  1  is estimated with high
     confidence to be  1  row.  The estimated time for this step is  0 . 03 
     seconds. 
   5 ) Finally, we send out an END TRANSACTION step to all AMPs involved
     in processing the request.
  -> The contents of Spool  1  are sent back to the user as the result of
     statement  1 . 


Конечно, у меня данных побольше. Но если я уменьшу количество данных до 35 миллионов, время отклика пропорционально уменьшится (в силу особенностей СУБД Teredata). Соответственно, я ожидаю отклик за примерно 1,5 секунды.
Соответственно, запрос без индекса (фул-скан) выполнится примерно за 5,7 секунд.

Конечно, всё зависит от количества столбцов в таблице.
Например фул-скан таблицы с 14 млн. записей и с 34 столбцами занимает у меня 10 секунд.

А, если не секрет, что за задача?


СерёгаА сеть какая? 9000 записей протащить тоже время надо. Кстати зачем столько? Не в грид случаем?

Смотрите внимательнее текст запроса. Там стоит select count(*). Такой запрос возвращает всего одну строку.


С уважением,
Константин Лисянский
http://lissianski.narod.ru
...
Рейтинг: 0 / 0
Выбор БД для быстрой работы с большими таблицами.
    #32665593
Gold
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
По-любому на версионнике SELECT COUNT(*) будет томозить больше чем на блокировочнике, так что такие запрося на блокировочниках выполняются быстрее однозначно.
...
Рейтинг: 0 / 0
Выбор БД для быстрой работы с большими таблицами.
    #32665646
Carrie
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
ScareCrowвсе с тобой ясно...
? ээ...чувствуется насмешка. Ну так намекните просто. Не каждому системному Unix-прораммеру приходится вдруг иметь дело с задачей, которая ему явно не по зубам...Пока. Раньше только с mysql'ем работал, последние 2 месяца с postgres'ом. "Ничего слаще редьки не пробовал"

LeXa NalBatВ таблице plprice_00 немногим менее 3 миллионов строк.
На такой таблице тоже все "махом" работает. А ожидается, что таблица будет увеличиваться на 40-50млн строк в месяц. Причем данные после INSERT'а менятся не будут: по ним будут делатся многочисленные статистические запросы.
Решение необходимо под Linux.

Константин ЛисянскийА, если не секрет, что за задача?
Да в общем не секрет. Небольшая провайдерская контора всегда предоставляла клиентам детальную статистику по трафику. Она представляет собой бинарный файл выдаваемый маршрутизатором раз в 15 минут, который содержит фиксированные (по 20 байт) агрегированные по полями src ip, dst ip, proto, src port, dst port, mark, bytes записи. Объемы трафика таковы, что хранить эти данные в одной таблице стало невозможно: выборки даже при наличии индексов (partial) на src ip, dst ip выполняются неимоверно долго. Потому вся статистика хранится в базе в виде blob'ов: один бинарный файл=один blob в табличке. И есть некая библиотечка, которая делает работу с этим хранилищем прозрачным для приложений: разворачивает каждый необходимый блоб по требованию в свою временную таблицу, если таковой не существует, удаляет автоматически такие таблицы, к которым давно не происходило обращений, создает таблицы с суммарными показателями трафика для каждого ip за день и прочее.
Все это все же накладывает определенные неудобства при работе с такими данными. Вот собственно хотелось бы пересмотреть "дизайн".
Если говорить о числе записей, выдаваемых маршрутизатором за месяц - это порядка 500млн. Если о суммарных показателях - такая таблица сейчас порядка 30млн записей/месяц.

P.S.: SELECT COUNT(*) - это как пример самого простого запроса, использующего индекс.
...
Рейтинг: 0 / 0
Выбор БД для быстрой работы с большими таблицами.
    #32665658
Константин Лисянский
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
авторНа такой таблице тоже все "махом" работает. А ожидается, что таблица будет увеличиваться на 40-50млн строк в месяц. Причем данные после INSERT'а менятся не будут: по ним будут делатся многочисленные статистические запросы.
Решение необходимо под Linux.

А бюджет имеется или бесплатно хотите?
А можно пример одного "многочисленного статистического запроса"?


С уважением,
Константин Лисянский
http://lissianski.narod.ru
...
Рейтинг: 0 / 0
Выбор БД для быстрой работы с большими таблицами.
    #32665683
Carrie
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Константин Лисянский
А бюджет имеется или бесплатно хотите?
А можно пример одного "многочисленного статистического запроса"?

Я думаю, если разница от использования коммерческой БД вместо postgresql/mysql/firebird будет значительна, то возможно "захотим" и платно. В общем не так все однозначно: нужно смотреть достоинства от такого перехода и TCO.

Запросы просты. К примеру расмотрим текущий вариант, когда netflow-статистика с маршрутизатора хранится в блобах, тогда бы в идеале "суммарная" таблица была бы такой (размер которой прогнозируется до 50млн/месяц; упрощенный вариант):

CREATE TABLE traffic_history (
id BIGSERIAL PRIMARY KEY,
ip INTEGER NOT NULL, //или INET, если угодно
dir boolean NOT NULL, //направление трафика: входящий или исходящий для ip
class SMALLINT NOT NULL, //класс трафика: http, smtp, pop3 etc
bytes INTEGER NOT NULL, //объем в байтах
blob_ref INTEGER NOT NULL REFERENCES blobs(id) //REFERENCE на блоб в табличке блобов, откуда была "сделана" эта запись
);

и табличка с блобами:
CREATE TABLE blobs (
id SERIAL PRIMARY KEY,
ts_start TIMESTAMP NOT NULL, //интервал, за который содержится статистика...
ts_stop TIMESTAMP NOT NULL,
blob_bin BYTEA //...в этом блобе
);

и индексы (для PRIMARY KEY создаются автоматически):
CREATE INDEX traffic_history_idx1 ON traffic_history (ip);
CREATE INDEX traffic_history_idx2 ON traffic_history (ip, id); //нужен для JOIN'а

CREATE INDEX blobs_idx1 ON blobs (ts_stop);
CREATE INDEX blobs_idx2 ON blobs (ts_stop, id); //нужен для JOIN'а

диапазон значений ip строго ограничен размерами адресного пространства, выданного нам РОСНИИРОС: 64 сети по 256 адресов, так что разброс значений составляет 64*256=16384.

запрос для выборки суммарной статистики по заданному ip и интервалу времени:
SELECT sum(a.bytes), a.class FROM traffic_history a LEFT JOIN blobs b ON b.id=a.blob_ref WHERE b.ts_stop BETWEEN '2004-08-01 00:00:00' AND '2004-09-01 00:00:00' AND a.ip='192.168.117.3' GROUP BY a.class;
...
Рейтинг: 0 / 0
Выбор БД для быстрой работы с большими таблицами.
    #32665709
LeXa NalBat
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Каково распределение значений в этом_поле?

Вы пробовали vacuum analyze, reindex?
...
Рейтинг: 0 / 0
Выбор БД для быстрой работы с большими таблицами.
    #32665712
Carrie
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
LeXa NalBatКаково распределение значений в этом_поле?
v3=# SELECT count(*) AS cnt, pr FROM exp GROUP BY pr ORDER by cnt DESC;
cnt | pr
----------+-------
28784676 | 6
3144128 | 17
2762907 | 1
4645 | 50
2692 | 47
1375 | 51
296 | 94
184 | 4

LeXa NalBatВы пробовали vacuum analyze, reindex?
Пробовал.
Пример из первого моего сообщения практической ценности не имеет. Просто хотел показать свое удивление скоростью выполнения этого запроса.
Реальная ситуация, описанная в моем сообщении выше, уже важна. Распределение ip-адресов в диапазоне от first до first+16384 равномерно и время выполнения указанного там же запроса порядка 30сек на таблице traffic_history в ~20-25млн записей.
...
Рейтинг: 0 / 0
Выбор БД для быстрой работы с большими таблицами.
    #32665728
LeXa NalBat
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Проведите этот тест на вашей железке. (Однако в этом тесте корреляция test2 и i2 абсолютная, попробую завтра сделать test2 перемешанной.)

Странно что 1) у вас "rows=11566968", а у меня "rows=1"; 2) ">17 Total runtime: 223.41 msec" и ">=18 Total runtime: 25.37 msec"; 3) 40 секундного времени выполнения у меня не наблюдается.

Код: 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.
33.
34.
35.
36.
37.
38.
39.
40.
41.
42.
43.
44.
45.
46.
47.
48.
49.
50.
51.
52.
53.
54.
55.
56.
57.
58.
59.
60.
61.
62.
63.
64.
65.
66.
67.
68.
pl=# create table test2 ( id smallint );
CREATE TABLE

$ cat test.pl
#!/usr/bin/perl
use strict;
use warnings;
my @data = (
  1   =>  2762907 ,
  4   =>  184 ,
  6   =>  28784676 ,
  17  =>  3144128 ,
  47  =>  2692 ,
  50  =>  4645 ,
  51  =>  1375 ,
  94  =>  296 ,
);
while ( (my $id = shift @data) && (my $num = shift @data) ) {
 for (my $i= 0 ; $i<$num; $i++) {
  printf "%d\n", $id;
 }
}


$ time ./test.pl | psql -U pl -d pl -c "copy test2 from stdin"

real    2m43.970s
user    1m26.890s
sys     0m1.030s

pl=# create index i2 on test2 ( id );
CREATE INDEX

pl=# VACUUM ANALYZE test2;
VACUUM

pl=# explain select count(*) from test2 where id> 17 ::smallint;
                              QUERY PLAN
 ---------------------------------------------------------------------- 
 Aggregate  (cost= 2 . 02 .. 2 . 02  rows= 1  width= 0 )
   ->  Index Scan using i2 on test2  (cost= 0 . 00 .. 2 . 01  rows= 1  width= 0 )
         Index Cond: (id >  17 ::smallint)
( 3  rows)

pl=# explain analyze select count(*) from test2 where id> 17 ::smallint;
                                                     QUERY PLAN
 --------------------------------------------------------------------------------------------------------------------- 
 Aggregate  (cost= 2 . 02 .. 2 . 02  rows= 1  width= 0 ) (actual time= 347 . 51 .. 347 . 51  rows= 1  loops= 1 )
   ->  Index Scan using i2 on test2  (cost= 0 . 00 .. 2 . 01  rows= 1  width= 0 ) (actual time= 307 . 59 .. 326 . 69  rows= 9008  loops= 1 )
         Index Cond: (id >  17 ::smallint)
 Total runtime:  361 . 96  msec
( 4  rows)

pl=# explain analyze select count(*) from test2 where id> 17 ::smallint;
                                                     QUERY PLAN
 --------------------------------------------------------------------------------------------------------------------- 
 Aggregate  (cost= 2 . 02 .. 2 . 02  rows= 1  width= 0 ) (actual time= 223 . 36 .. 223 . 36  rows= 1  loops= 1 )
   ->  Index Scan using i2 on test2  (cost= 0 . 00 .. 2 . 01  rows= 1  width= 0 ) (actual time= 197 . 67 .. 216 . 35  rows= 9008  loops= 1 )
         Index Cond: (id >  17 ::smallint)
 Total runtime:  223 . 41  msec

pl=# explain analyze select count(*) from test2 where id>= 18 ::smallint;
                                                    QUERY PLAN
 ------------------------------------------------------------------------------------------------------------------ 
 Aggregate  (cost= 2 . 02 .. 2 . 02  rows= 1  width= 0 ) (actual time= 25 . 31 .. 25 . 31  rows= 1  loops= 1 )
   ->  Index Scan using i2 on test2  (cost= 0 . 00 .. 2 . 01  rows= 1  width= 0 ) (actual time= 0 . 03 .. 18 . 59  rows= 9008  loops= 1 )
         Index Cond: (id >=  18 ::smallint)
 Total runtime:  25 . 37  msec
( 4  rows)
...
Рейтинг: 0 / 0
Выбор БД для быстрой работы с большими таблицами.
    #32666114
Nikolay Kulikov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Произвоидельность тупого индекс скана зависит от подсистемы IO.
Что у вас c ней??? Опять же попробуй указывать >, a >=
Потому как > 17 и 18, и 19, и 20 etc...
A если укажешь >=18 то серверу будет понятно с какой ветки индекса начинать скан.
...
Рейтинг: 0 / 0
Выбор БД для быстрой работы с большими таблицами.
    #32666278
Фотография ScareCrow
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Carrie Не каждому системному Unix-прораммеру приходится вдруг иметь дело с задачей, которая ему явно не по зубам сами мы не местные, отстали от группы, помогите люди добрые , кто чем может....
напиши показатели основных счетчиков... поищем узкое место.. не может быть чтоб на такой железяке так все медленно делалось...
...
Рейтинг: 0 / 0
Выбор БД для быстрой работы с большими таблицами.
    #32666460
Carrie
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
ScareCrow
напиши показатели основных счетчиков... поищем узкое место.. не может быть чтоб на такой железяке так все медленно делалось...
Что вы под этим подразумеваете? содержимое pg_stat_user_tables, pg_stat_user_indexes, pg_statio_user_tables касательно этой таблицы?

to LeXa NalBat:
Тесты провел. Вот что получилось:
Код: 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.
33.
34.
35.
36.
37.
38.
39.
40.
41.
$ time ./test.pl | psql -U postgres -d network_v3 -c "copy test2 from stdin"

real    6m20.749s
user    2m48.610s
sys     1m12.810s
...
network_v3=# explain select count(*) from test2 where id> 17 ::smallint;
                                QUERY PLAN
 --------------------------------------------------------------------------- 
 Aggregate  (cost= 186 . 56 .. 186 . 56  rows= 1  width= 0 )
   ->  Index Scan using i2 on test2  (cost= 0 . 00 .. 165 . 66  rows= 8359  width= 0 )
         Index Cond: (id >  17 ::smallint)
( 3  rows)

network_v3=# explain analyze select count(*) from test2 where id> 17 ::smallint;
                                                          QUERY PLAN
 ------------------------------------------------------------------------------------------------------------------------------ 
 Aggregate  (cost= 186 . 56 .. 186 . 56  rows= 1  width= 0 ) (actual time= 1527 . 160 .. 1527 . 161  rows= 1  loops= 1 )
   ->  Index Scan using i2 on test2  (cost= 0 . 00 .. 165 . 66  rows= 8359  width= 0 ) (actual time= 1495 . 861 .. 1516 . 354  rows= 9008  loops= 1 )
         Index Cond: (id >  17 ::smallint)
 Total runtime:  1527 . 217  ms
( 4  rows)

network_v3=# explain analyze select count(*) from test2 where id> 17 ::smallint;
                                                         QUERY PLAN
 ---------------------------------------------------------------------------------------------------------------------------- 
 Aggregate  (cost= 186 . 56 .. 186 . 56  rows= 1  width= 0 ) (actual time= 269 . 735 .. 269 . 736  rows= 1  loops= 1 )
   ->  Index Scan using i2 on test2  (cost= 0 . 00 .. 165 . 66  rows= 8359  width= 0 ) (actual time= 239 . 054 .. 259 . 289  rows= 9008  loops= 1 )
         Index Cond: (id >  17 ::smallint)
 Total runtime:  269 . 791  ms
( 4  rows)

network_v3=# explain analyze select count(*) from test2 where id>= 18 ::smallint;
                                                       QUERY PLAN
 ------------------------------------------------------------------------------------------------------------------------- 
 Aggregate  (cost= 186 . 56 .. 186 . 56  rows= 1  width= 0 ) (actual time= 30 . 681 .. 30 . 682  rows= 1  loops= 1 )
   ->  Index Scan using i2 on test2  (cost= 0 . 00 .. 165 . 66  rows= 8359  width= 0 ) (actual time= 0 . 041 .. 20 . 075  rows= 9008  loops= 1 )
         Index Cond: (id >=  18 ::smallint)
 Total runtime:  30 . 735  ms
( 4  rows)

К сожалению сейчас занят работой, вечером позже гляну конфиг postgres'а на предмет почему наши explain analyze выдают разные результаты.
...
Рейтинг: 0 / 0
Выбор БД для быстрой работы с большими таблицами.
    #32667866
LeXa NalBat
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
1)
Мне кажется, что различие в выдачах explain у нас может объясняться разными значениями STATISTICS_LEVEL, который может быть установлен например командой "ALTER TABLE ... ALTER COLUMN ... SET STATISTICS ...". Что может сказаться лишь на выборе иного плана оптимизатором, но не на реальной скорости выполнения запроса при одинаковом выбранном плане (выбранном опримизатором самостоятельно или с помощью хинтов типа set enable_*).


2)
Разницу во времени выполнения запросов ">17" и ">=18" я не понимаю наверное потому что не владею мат-частью поиска по B-деревьям. Не знаю, подвержены ли этому другие БД, но думаю, что здесь мы можем взять на себя "помощь" постгресу переформулировав запрос на ">=18".


3)
40-секундного выполнения запроса в моем примере не наблюдалось именно из-за полной корреляции таблицы и индекса. Я провел следующий эксперимент. Создал таблицы test2, test3, test4 одинаковым способом:
Код: plaintext
1.
2.
3.
4.
pl=# create table test# ( id smallint );
$ time ./test#.pl | psql -c "copy test# from stdin"
pl=# create index i# on test# ( id );
pl=# ALTER TABLE test# ALTER COLUMN id SET STATISTICS  1000 ;
pl=# ANALYZE test#;
С использованием разных скриптов. В таблице test2 значения >17 расположены в ~1 дисковой странице, в test3 - в ~184 страницах, в test4 - размазаны по всей таблице, размер файла которой в директории постгреса равен ~1Gb.
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
#!/usr/bin/perl
# test2.pl
use strict;
use warnings;
my @data = (
  1   =>  2762907 ,
  4   =>  184 ,
  6   =>  28784676 ,
  17  =>  3144128 ,
  47  =>  2692 ,
  50  =>  4645 ,
  51  =>  1375 ,
  94  =>  296 ,
);
while ( (my $id = shift @data) && (my $num = shift @data) ) {
 for (my $i= 0 ; $i<$num; $i++) {
  printf "%d\n", $id;
 }
}
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
#!/usr/bin/perl
# test3.pl
use strict;
use warnings;
my %data = (
  1  =>   15015 ,  #  2762907 
  4  =>   1 ,      #  184 
  6  =>   156438 , #  28784676 
  17  =>  17087 ,  #  3144128 
  47  =>  14 ,     #  2692 
  50  =>  25 ,     #  4645 
  51  =>  7 ,      #  1375 
  94  =>  2 ,      #  296 
);
my $min_cnt =  184 ;
for (my $j= 0 ; $j<$min_cnt; $j++) {
 for my $id ( sort { rand()<=> 0 . 5  } keys %data ) {
  for (my $i= 0 ; $i<$data{$id}; $i++) {
   printf "%d\n", $id;
  }
 }
}
Код: 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.
#!/usr/bin/perl
# test4.pl
use strict;
use warnings;
my @data = (
 [ 0 . 829508  =>  6  ], #  28784676 ,
 [ 0 . 920114  =>  17 ], #  3144128 ,
 [ 0 . 999735  =>  1  ], #  2762907 ,
 [ 0 . 999869  =>  50 ], #  4645 ,
 [ 0 . 999947  =>  47 ], #  2692 ,
 [ 0 . 999986  =>  51 ], #  1375 ,
 [ 0 . 999995  =>  94 ], #  296 ,
 [ 1 . 000000  =>  4  ], #  184 ,
);
my $num = scalar @data;
my $cnt =  34700903 ;
OU: for (my $j= 0 ; $j<$cnt; $j++) {
 my $rnd = rand();
 IN: for (my $i= 0 ; $i<$num; $i++) {
  if ($data[$i]->[ 0 ]>$rnd) {
   printf "%d\n", $data[$i]->[ 1 ];
   last IN;
  }
 }
}
После выполнения команд "analyze TABLE" очистил системный дисковый кэш. И провел одинаковый запрос:
Код: 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.
pl=# explain analyze select count(*) from test2 where id>= 47 ::smallint;
                                                        QUERY PLAN
 -------------------------------------------------------------------------------------------------------------------------- 
 Aggregate  (cost= 163 . 75 .. 163 . 75  rows= 1  width= 0 ) (actual time= 856 . 40 .. 856 . 40  rows= 1  loops= 1 )
   ->  Index Scan using i2 on test2  (cost= 0 . 00 .. 145 . 82  rows= 7172  width= 0 ) (actual time= 183 . 32 .. 849 . 58  rows= 9008  loops= 1 )
         Index Cond: (id >=  47 ::smallint)
 Total runtime:  895 . 07  msec
( 4  rows)

pl=# explain analyze select count(*) from test3 where id>= 47 ::smallint;
                                                         QUERY PLAN
 ---------------------------------------------------------------------------------------------------------------------------- 
 Aggregate  (cost= 9208 . 74 .. 9208 . 74  rows= 1  width= 0 ) (actual time= 9472 . 92 .. 9472 . 92  rows= 1  loops= 1 )
   ->  Index Scan using i3 on test3  (cost= 0 . 00 .. 9185 . 89  rows= 9138  width= 0 ) (actual time= 215 . 76 .. 9465 . 89  rows= 8832  loops= 1 )
         Index Cond: (id >=  47 ::smallint)
 Total runtime:  9472 . 98  msec
( 4  rows)

pl=# explain analyze select count(*) from test4 where id>= 47 ::smallint;
                                                          QUERY PLAN
 ------------------------------------------------------------------------------------------------------------------------------ 
 Aggregate  (cost= 8962 . 73 .. 8962 . 73  rows= 1  width= 0 ) (actual time= 114142 . 94 .. 114142 . 94  rows= 1  loops= 1 )
   ->  Index Scan using i4 on test4  (cost= 0 . 00 .. 8940 . 46  rows= 8907  width= 0 ) (actual time= 202 . 91 .. 114125 . 40  rows= 8937  loops= 1 )
         Index Cond: (id >=  47 ::smallint)
 Total runtime:  114143 . 01  msec
( 4  rows)
Выборка из test4 - 114 секунд. :-( Это объясняется тем, что постгрес при поиске по индексу для каждого подходящего index_tuple выбирает соответствующую ему строку из таблицы. В отличие например от оракла, который в том случае если все поля указанные в "select ..." запроса присутствуют в индексе, в таблицу вообще не заглядывает, а берет данные из самого индекса. Думаю, что бороться с этим в постгресе можно либо с помощью команды "cluster"; либо делать partition tables записывая данные с часто встречающимися id в одну таблицу, а с редко встречающимися - в другую.
...
Рейтинг: 0 / 0
Выбор БД для быстрой работы с большими таблицами.
    #32667875
LeXa NalBat
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
1)
авторCREATE INDEX traffic_history_idx2 ON traffic_history (ip, id); //нужен для JOIN'аЗдесь наверное опечатка. Вы имели в виду индекс traffic_history (ip, blob_ref )?


2)
Чем в этом запросе индекс blobs (ts_stop, id) может быть полезнее индекса blobs (ts_stop)? Ведь по первому аргументу ts_stop ограничение на интервал, а не на равенство.


3)
Какие проблемы с этим запросом в постгресе? :-) Какой план выполнения или скорость вы хотели бы иметь?


4)
Я не силен в теории, но чем-то эта задача мне напоминает OLAP. Может быть вам посмотреть в эту сторону? (Не обязательно на MS-OLAP или оракловый, я не так давно сваял что-то похожее на коленке на постгресе - в процессе массированной загрузки данных вычисляются всевозможные агрегаты, которые впоследствии используются при показе статистики.)
...
Рейтинг: 0 / 0
Выбор БД для быстрой работы с большими таблицами.
    #32667995
Зл0й
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ИМХО здесь надо не заморачиваться переходом на другую СУБД, а начинать с тюнинга той которая уже есть. И только если есть твердая уверенность в том что "тормоз" именно данная СУБД (а не конфигурация дисковой подсистемы, железяки, конфигурация СУБД, криворукость разработчика...)

Если есть бюждет - можно поставить серьезную железяку с Ораклом. Для trickle feed (т.е. когда происходит одновременное чтение и запись) самое оно. Если же данные загружать по ночам, тогда Teradata. Но это уже совсем для взрослых, с бюждетом где-то в районе 200 тыщ убитых енотов. Плюс Teradata блокирует на уровне таблицы, а если использовать loader который не блокирует данные, тогда емеем dirty read. Правда, при условии что база insert-only это решается - просто смотрим только на данные которым от роду более 15 минут.
...
Рейтинг: 0 / 0
Выбор БД для быстрой работы с большими таблицами.
    #32668479
Константин Лисянский
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ИМХО здесь надо не заморачиваться переходом на другую СУБД, а начинать с тюнинга той которая уже есть.

Согласен, надо ещё понимать, насколько та, которая есть, сможет работать и в будущем при росте объёма данных.

Если есть бюждет - можно поставить серьезную железяку с Ораклом. Для trickle feed (т.е. когда происходит одновременное чтение и запись) самое оно. Если же данные загружать по ночам, тогда Teradata.

В случае Teradata не обязательно по ночам. Можно и в on-line. Есть соответствующие средства.

Но это уже совсем для взрослых, с бюждетом где-то в районе 200 тыщ убитых енотов

Не обязательно. Если железяка уже есть, то можно обойтись только софтом.
Если речь идёт о серьёзной железяке, то для Оракла она тоже немало будет стоить.

Плюс Teradata блокирует на уровне таблицы, а если использовать loader который не блокирует данные, тогда емеем dirty read.

Это не совсем так. Самый низкий уровень блокировки в Терадате - это ROW HASH.
Да, и как Вы в Оракле сможете обойтись без dirty read? Ведь, пока идёт загрузка, транзакция не закрыта, так, что если Вы что-то сможете прочитать во время загрузки, то Вы не имеете права этому верить - это тоже dirty read. Или я не прав?


С уважением,
Константин Лисянский
http://lissianski.narod.ru
...
Рейтинг: 0 / 0
Выбор БД для быстрой работы с большими таблицами.
    #32668515
gardenman
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Посмотрите пожалуйста вот эту статью:
MDC
...
Рейтинг: 0 / 0
Выбор БД для быстрой работы с большими таблицами.
    #32668536
gardenman
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
еще информацию по MDC можно найти здесь здесь там есть tutorial - написана очень понятным популярным языком.
...
Рейтинг: 0 / 0
Выбор БД для быстрой работы с большими таблицами.
    #32669681
Зл0й
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Oracle - версионник. Соотвественно пока объемов Rollback Segment'ов хватает, вы можете одновременно писать и читать одну и ту же таблицу в разных сессиях. Без взаимных блокировок и грязного чтения. Этим Оракл выгодно отличается от Teradata и DB2. Поясню примером

<момент времени>. <событие>

T1. Сессия S1 начала читать здоровенную таблицу my_table
T2. Сессия S2 изменила запись номер 123,456,789 еще не прочитанную сессией S1
Т3. Сессия S1 дошла до записи номер 123,456,789 и обнаружила что запись была изменена в момент времени Т2 > T1. Поскольку Оракл обязан выдать данные по состоянию на Т1, он залезет в rollback segment и разыщет там старое значение записи номер 123,456,789 на момент времени Т1. Это значение и будет использовано запросом из сессии S1.

Естественно "панацеи на бывает". Допустим в момент времени Т2 сессия S2 не только изменила запись, но и прибила ее с помощью commit. Тогда тогда место в rollback segment где лежит старое значение записи номер 123,456,789 на момент времени Т1, будет помечено как "available for reuse". Если в момент времени Т3 сессия S1 обнаружит что нужные ей данные отсутствуют (поверх них уже записали что-то другое) то она выдаст ошибку ORA-1555 Snapshot too old. Поэтому в системе где загрузка происходит одновременно с запросами требуется иметь rollback segment'ы соотвествующего размера.

В СУБД-блокировщиках (Teradata, DB2, Sybase, Informix) нам приходится выбирать между грязным чтением и ожиданием на блокировке. Выбор из "двух зол" и весьма неприятный. Я уж лучше прикуплю отдельный дисковый массив и целенаправленно забабахаю туда свои rollback segment'ы. Ибо железо дешевеет с каждым днем.

У Teradata есть свои плюсы - она умеет быстро просматривать всю таблицу. Делается это вот как: у таблицы есть primary index. Это - колонка группа колонок могущая совпадать (или не совпадать) с первичным ключем. По этой колонке или группе считается хэш-функция и данные раскидываются по узлам нашей MPP-системы в соответствии со значением хэш-функции. Соотвественно полный просмотр таблицы полностью распараллеливается по всему (памяти, диску, процессору). Это - идеология "грубой силы". И она неплохо работает, особенно в организациях где народ в СУБД особо не шарит, и не занимается оптимизацией хранения вручную, то есть всякими index-organized tables, colocated tables (в Оракле - Clusters), materialized views, индексами, итд. итп.
...
Рейтинг: 0 / 0
Выбор БД для быстрой работы с большими таблицами.
    #32669714
Фотография Хрен
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
CarrieЕсть postgresql 7.4.x, есть таблица, в которой кол-во записей ~35млн, одно из полей типа SMALLINT (2bytes) и по нему создан Btree индекс.
так вот запрос вида
select count(*) from tbl_name where это_поле>17::smallint;
выполняется ~40секунд при том что результат запроса - всего 9003 записей.
Explain показывает, что БД юзает индекс.
Так же тестировался mysql 4.0.18, где результаты существенно печальней. Конфиги для mysql и postgresql, как мне кажется, настроены сейчас оптимально; машинка с БД более чем приличная (2x2.4 Xeon, 2Гб RAM, 4x36Гб SCSI etc..)

Интересно. Запрос по индексу и 40 секунд на такой машине? Что то мне про mysql не верится. Что за таблицы - innodb? myisam? и что говорит

mysqladmin ext var

после запроса? и какой explain? И как цеплялись про тестровании? tcp/ip? unix socket? И что говорит

vmstat

во время запроса? (может вы перестарались с памятью и у вас все в swap пошло)
...
Рейтинг: 0 / 0
Выбор БД для быстрой работы с большими таблицами.
    #32669868
Nikolay Kulikov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
2Злой.

Для описанной здесь задачи. Преимущества Oracle c версионностью нивелируются тем что данные не меняются. Они сняты с сетевых устройств и менять их смысла нет. По поводу грубой силы в Teradata, там тоже есть аналоги Materialized Views и др. С другой стороны ныличие большого кол-ва возможностей усложняет написание хорошего оптимизатора ибо нужно разрабатывать огромное кол-во алгоритмов которые корректно будуи учитывать все эти возможности. Так что богатый набор возможностей не всегда хорошо.
...
Рейтинг: 0 / 0
Выбор БД для быстрой работы с большими таблицами.
    #32670418
Зл0й
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
В данной конкретной задаче. Предположим что имеется пара запросов, таких что данные вставка которых происходит удовлетворяет предикату в where. Имеем конфликт читателей с писателями. В случае если СУБД блокировщик, или кто-то дрыхнет на блокировке, пока данные загружаются, или мы имеем non-repeatable read. То есть запустив 2 запроса подряд мы можем иметь данные которые не согласуются друг с другом. Что приводит к нецензурным восклицаниям и вырыванию остатков волосяного покрова при попытке отладки такой системы. Несогласованное чтение - это плохо. Можно этот недостаток СУБД-блокировщика учесть и компенсировать при разработке приложения. А можно использовать СУБД-версионник, свободную от данного недостатка, и бороться с ее недостатками (В случае Оракла - snapshot too old error). ИМХО второе - проще и дешевле, ибо вопрос решается покупкой железяки.
...
Рейтинг: 0 / 0
Выбор БД для быстрой работы с большими таблицами.
    #32670670
EugeneS
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Зл0й
А можно использовать СУБД-версионник, свободную от данного недостатка, и бороться с ее недостатками (В случае Оракла - snapshot too old error). ИМХО второе - проще и дешевле, ибо вопрос решается покупкой железяки.


Если я правильно понимаю то начиная с версии 9i уже бороться не надо.
Просто правильно подобрать Retention_time и не скупиться на диски.
...
Рейтинг: 0 / 0
Выбор БД для быстрой работы с большими таблицами.
    #32672346
Зл0й
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Если я правильно понимаю то начиная с версии 9i уже бороться не надо.
Просто правильно подобрать Retention_time и не скупиться на диски.

Точнее, начиная с 9.2.0.4 В некоторых случаях по прежнему приходится делать "ручками", но все реже и реже.
...
Рейтинг: 0 / 0
Выбор БД для быстрой работы с большими таблицами.
    #32672643
EugeneS
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Зл0й Если я правильно понимаю то начиная с версии 9i уже бороться не надо.
Просто правильно подобрать Retention_time и не скупиться на диски.

Точнее, начиная с 9.2.0.4 В некоторых случаях по прежнему приходится делать "ручками", но все реже и реже.


Мы только с 9.2.0.4 стали серьезно смотреть на 9i.
Уж больно много багов.
Реалии времени, пока не выйдет второй релиз не пользовать.

Можно как-то намекнуть, что именно надо делать ручками,
именно для сегментов отката
при установленном параметре UNDO_MANAGEMENT = AUTO?
...
Рейтинг: 0 / 0
Выбор БД для быстрой работы с большими таблицами.
    #32672716
Carrie
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Прошу прощения, что надолго пропал, но тут и без меня дискуссия уже развернулась неплохо)

LeXa NalBat1)
авторCREATE INDEX traffic_history_idx2 ON traffic_history (ip, id); //нужен для JOIN'аЗдесь наверное опечатка. Вы имели в виду индекс traffic_history (ip, blob_ref )?
Да, конечно.

LeXa NalBat
2)
Чем в этом запросе индекс blobs (ts_stop, id) может быть полезнее индекса blobs (ts_stop)? Ведь по первому аргументу ts_stop ограничение на интервал, а не на равенство.

Индексы
Код: plaintext
1.
CREATE INDEX traffic_history_idx2 ON traffic_history (ip, blob_ref);
CREATE INDEX blobs_idx2 ON blobs (ts_stop, id);
просто создал на всякий случай, чтобы посмотреть какие из них postgres будет использовать. И как выяснилось, часто (всегда) postgres использует индекс blobs_idx2, но никогда traffic_history_idx2 или просто blobs_idx1.

LeXa NalBat3)
Какие проблемы с этим запросом в постгресе? :-) Какой план выполнения или скорость вы хотели бы иметь?
План запроса меня устраивает. меня не устраивает скорость его выполнения: 30-40сек. Хотелось бы не более 5сек. Мне почему-то кажется, что пробежаться по индексу по записям число которых 10-20к - это должно быть быстро.

LeXa NalBat4)
Я не силен в теории, но чем-то эта задача мне напоминает OLAP. Может быть вам посмотреть в эту сторону? (Не обязательно на MS-OLAP или оракловый, я не так давно сваял что-то похожее на коленке на постгресе - в процессе массированной загрузки данных вычисляются всевозможные агрегаты, которые впоследствии используются при показе статистики.)
Вариант, конечно. И я про него помню, но не люблю избыточность в БД даже в таком виде, вероятно, из-за малого опыта) Конечно, все равно придется ее использовать, вопрос только где и когда.

Nikolay KulikovПроизвоидельность тупого индекс скана зависит от подсистемы IO.
Что у вас c ней??? Опять же попробуй указывать >, a >=
Потому как > 17 и 18, и 19, и 20 etc...
A если укажешь >=18 то серверу будет понятно с какой ветки индекса начинать скан.
Про > и >= не знал, спасибо.
С производительностью машины судя, по простым тестам, все нормально, конфиги postgres'а похоже оптимальны. По крайней мере изменение многих параметров не отражается значительно на производительности. Своппинга тоже нет, так что с shared_buffers, effective_cache_size не перестарался.
Хотя все же несколько смущает то, что в тесте создания таблицы, предложенного LeXa NalBat, разница в 2.5 раза :(

Что касается CLUSTER. Попробовал. Результаты - супер: все указанные запросы выполняются "махом" (<1сек). Жалко не часто эту команду можно запускать: на таблице traffic_history с 20млн записей по индексу на поле ip она выполняется почти 1.5часа) Кстати, после этого (и ес-но ANALYZE) оба multicolumn-индекса постгрес перестал использовать.
Partition tables "руками" делать не хочется: сложно с этим работать потом. Вычитал, что базы вроде Oracle и etc умеют это прозрачно. Здорово. Был бы опыт или знакомый знаток Oracle - попробовал бы эту фичу. Сам лезть пока не решаюсь.

Читаю статьи по тюнингу postgres'а еще раз, запущу еще раз тесты на другой тестовой машинке, уровнем пониже (есть все же сомнения в скорости IO), почитаю по MDC.
...
Рейтинг: 0 / 0
Выбор БД для быстрой работы с большими таблицами.
    #32672730
Carrie
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
ХренИнтересно. Запрос по индексу и 40 секунд на такой машине? Что то мне про mysql не верится. Что за таблицы - innodb? myisam? и что говорит

mysqladmin ext var

после запроса? и какой explain? И как цеплялись про тестровании? tcp/ip? unix socket? И что говорит

vmstat

во время запроса? (может вы перестарались с памятью и у вас все в swap пошло)
Использовал только innodb, т.к. хочется транзакций и без них страшно. Цеплялся через локально через unix socket, правда какая тут разница? результат-то маленький. Машинка не свопилась 100%
Вообще как выяснилось на запросе вида SELECT COUNT(*) FROM ... где WHERE только по индексу, mysql не обращается к данным таблицы и выполняет его очень быстро. Но ведь реально мне нужно не настолько простой запрос, который уже "лезет" в таблицу и это получается в 3-4 раза медленнее, чем в постгресе Протестить еще раз сложно, да и не хотелось бы на mysql обращать внимание: не нравится он мне стабильностью.
...
Рейтинг: 0 / 0
Выбор БД для быстрой работы с большими таблицами.
    #32673144
Фотография Хрен
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
авторПротестить еще раз сложно, да и не хотелось бы на mysql обращать внимание:

Ага, вот с этого надо было начинать. Тогда конечно mysql снимается с повески дня (все остальное - решаемо)

автор не нравится он мне стабильностью.

Ха-ха.. хорошо звучит.
...
Рейтинг: 0 / 0
Выбор БД для быстрой работы с большими таблицами.
    #32673365
Carrie
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
ХренАга, вот с этого надо было начинать. Тогда конечно mysql снимается с повески дня (все остальное - решаемо)

Настроен mysql-сервер был идеально (этим занимался человек, который общался с ним далеко не в первый раз). Данные в таблицу были залиты те же самые. Сервак был со 100% idle. Запрос вида select count(*), sum(cost) from tbl1 where pr>17 занял более 2-х минут.
...
Рейтинг: 0 / 0
Выбор БД для быстрой работы с большими таблицами.
    #32673431
Фотография Хрен
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Carrie (этим занимался человек, который общался с ним далеко не в первый раз).

Ха-ха... хорошая формулировка :-) вы сегодня поддерживаете мое хорошее настроение. Если серьезно - то эти 2 минуты и говорят о том насколько "идеальна" была настройка. На самом деле под mysql используютсяя _очень_ большие базы.
...
Рейтинг: 0 / 0
Выбор БД для быстрой работы с большими таблицами.
    #32673465
Carrie
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Насколько большие базы? размер/кол-во таблиц?

Ок. Вы меня убедили попробовать mysql ещё раз.
...
Рейтинг: 0 / 0
Выбор БД для быстрой работы с большими таблицами.
    #32680207
Матаня
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
При солидных объемах базы запросы с агрегатными функциями
у Постгреса выполняются достаточно долго - и галочки "турбо_count"
пока что не существует. 8-) Подробно обэтом написано где-то здесь....

инфа о настройке Постгреса

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

P.S Пишите письма машииным кодом.
...
Рейтинг: 0 / 0
Выбор БД для быстрой работы с большими таблицами.
    #32680208
Матаня
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
При солидных объемах базы запросы с агрегатными функциями
у Постгреса выполняются достаточно долго - и галочки "турбо_count"
пока что не существует. 8-) Подробно обэтом написано где-то здесь....

инфа о настройке Постгреса

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

P.S Пишите письма мЫшинНым кодом.
...
Рейтинг: 0 / 0
Выбор БД для быстрой работы с большими таблицами.
    #32680545
Зл0йOracle - версионник. Соотвественно пока объемов Rollback Segment'ов хватает, вы можете одновременно писать и читать одну и ту же таблицу в разных сессиях. Без взаимных блокировок и грязного чтения. Этим Оракл выгодно отличается от Teradata и DB2. Поясню примером

<момент времени>. <событие>

T1. Сессия S1 начала читать здоровенную таблицу my_table
T2. Сессия S2 изменила запись номер 123,456,789 еще не прочитанную сессией S1
Т3. Сессия S1 дошла до записи номер 123,456,789 и обнаружила что запись была изменена в момент времени Т2 > T1. Поскольку Оракл обязан выдать данные по состоянию на Т1, он залезет в rollback segment и разыщет там старое значение записи номер 123,456,789 на момент времени Т1. Это значение и будет использовано запросом из сессии S1.

Естественно "панацеи на бывает". Допустим в момент времени Т2 сессия S2 не только изменила запись, но и прибила ее с помощью commit. Тогда тогда место в rollback segment где лежит старое значение записи номер 123,456,789 на момент времени Т1, будет помечено как "available for reuse". Если в момент времени Т3 сессия S1 обнаружит что нужные ей данные отсутствуют (поверх них уже записали что-то другое) то она выдаст ошибку ORA-1555 Snapshot too old. Поэтому в системе где загрузка происходит одновременно с запросами требуется иметь rollback segment'ы соотвествующего размера.


Как красиво :) easy way. Купил базу и на коленке слабал продукт.

Представим бухгалтерию сесия (сеcсия S2) дебитует счет,
При этом сесия S1 дебитует тот-же счет.
То есть получится, Если сумма по транзакциям S1+S2 больше остатка на счете, одна из них должна отклониться по недостатку средств. Но этого
не произойдет. И окончательное значение остатка не будет учитывать
транзакцию которая завершилась раньше.
А потом еще вы очень долго будете искать откуда у вас касса(склад)
разезжаются с бухгалтерией.
Описанный вами пример - часный случай грязного чтения.

Oracle кстате версиониик только внешне, внутри он все такой же блокировочник.
ИХМО постоянное возникновенни ошибки ORA-1555 Snapshot too old
коственно говорит о кривости рук проектировщика базы.

Зл0й
В СУБД-блокировщиках (Teradata, DB2, Sybase, Informix) нам приходится выбирать между грязным чтением и ожиданием на блокировке. Выбор из "двух зол" и весьма неприятный. Я уж лучше прикуплю отдельный дисковый массив и целенаправленно забабахаю туда свои rollback segment'ы. Ибо железо дешевеет с каждым днем.


Уровней изоляции по стандарту гораздо больше чем 2.
Я например, не ожидаю на блокировке,
у меня есть решение(технология) pending list (C)
которая решает эти ситуации на 99 процентов
(кроме случая сна в курсоре на блокировке, этот прогЛамер
для начала лишается премии).

ИМНО Если база быстрая, то она блокировочник. Если у вас быстрый версионник то готовтесь разгребать проблемы с целоснтостью данных.
Имеется ввиду настоящее многопользовательское приложение.
И рыбку съесть и на %#~ сесть не получится.

With regards
...
Рейтинг: 0 / 0
Выбор БД для быстрой работы с большими таблицами.
    #32684158
strizh
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Може такое уже предлагали, но мне при большом времени выполнения
select count(*)
сильно помогло
select count(key_filed)
Об этом даже разработчики говорят (в этом же форуме проскакивало), что в Постгресе в функцию count лучше всего подставлять первичный ключ, иначе у сервера возникают проблемы с версионностью записей, вот он и думает хто зна сколько.
...
Рейтинг: 0 / 0
Выбор БД для быстрой работы с большими таблицами.
    #32684567
LeXa NalBat
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
авторПрошу прощения, что надолго пропал.

Также прошу прощения. Отпуск - это святое. :-)

авторМне почему-то кажется, что пробежаться по индексу по записям число которых 10-20к - это должно быть быстро.

А если все эти записей находятся на разных дисковых страницах? Прочитать 10-20к страниц дисковой системе - это быстро?

авторсмущает то, что в тесте создания таблицы, предложенного LeXa NalBat, разница в 2.5 раза :(

Я тестировал на такой машине: два проца Xeon 2.8; 2Gb ОЗУ; 320 SCSI контроллер + два 320 SCSI HDD в RAID 0; ось Linux 2.4.21-SuSE.

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

Работая в свое время на оракле, мы для этого запихивали в индексы (в конец) все поля таблицы. Размер индекса из-за этого во много раз увеличивался, но получался выигрыш в скорости выполнения выборки, так как оракл все данные брал из индекса не заглядывая в таблицу.
...
Рейтинг: 0 / 0
Выбор БД для быстрой работы с большими таблицами.
    #32684777
LeXa NalBat авторПрошу прощения, что надолго пропал.

Также прошу прощения. Отпуск - это святое. :-)

авторМне почему-то кажется, что пробежаться по индексу по записям число которых 10-20к - это должно быть быстро.

А если все эти записей находятся на разных дисковых страницах? Прочитать 10-20к страниц дисковой системе - это быстро?


Особенно если они лежат не подряд.


авторсмущает то, что в тесте создания таблицы, предложенного LeXa NalBat, разница в 2.5 раза :(

Я тестировал на такой машине: два проца Xeon 2.8; 2Gb ОЗУ; 320 SCSI контроллер + два 320 SCSI HDD в RAID 0; ось Linux 2.4.21-SuSE.

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

Работая в свое время на оракле, мы для этого запихивали в индексы (в конец) все поля таблицы. Размер индекса из-за этого во много раз увеличивался, но получался выигрыш в скорости выполнения выборки, так как оракл все данные брал из индекса не заглядывая в таблицу.

Не факт. Если по статистике в виборку попадает более 10% все данных из
таблицы oracle делает полное сканирование. И это всегда быстрее засчет
мультиблочного и опережающего чтения.
Зато на скорости вставки и удаления вы проиграли в сотни раз.
...
Рейтинг: 0 / 0
Выбор БД для быстрой работы с большими таблицами.
    #32684811
EugeneS
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Случайно заглянул
Как красиво :) easy way. Купил базу и на коленке слабал продукт.

Представим бухгалтерию сесия (сеcсия S2) дебитует счет,
При этом сесия S1 дебитует тот-же счет.
То есть получится, Если сумма по транзакциям S1+S2 больше остатка на счете, одна из них должна отклониться по недостатку средств. Но этого
не произойдет. И окончательное значение остатка не будет учитывать
транзакцию которая завершилась раньше.
А потом еще вы очень долго будете искать откуда у вас касса(склад)
разезжаются с бухгалтерией.
Описанный вами пример - часный случай грязного чтения.


Это опять тот пример, который апологеты MSSQL приводят в пику Oracle?
Ну если вы так печетесь о целостности, то наверно имеет смысл говоить, что операция дебетирования счета не может параллелиться, а она есть строго последовательна, и архитектура СУБД тук как бы ни причем.
В этом случае практичекси все едино какую СУБД вы возьмете, хоть обычный плоский файл , суть от этого не меняется и эта суть - "Последовательный доступ к данным".
Причем здесь версионность СУБД, имеет смысл говорить о последовательности исполнения транзакций, а не о конкурентном доступе к данным.
В этом случае вопрос производительности просто нет смысла поднимать, а следует уже говорить о "Transaction-Level Read Consistency".
А для этого у Oracle есть.
SET TRANSACTION ISOLATION LEVEL SERIALIZABLE;

Случайно заглянул
Oracle кстате версиониик только внешне, внутри он все такой же блокировочник.
ИХМО постоянное возникновенни ошибки ORA-1555 Snapshot too old
коственно говорит о кривости рук проектировщика базы.

Если нет желания настраивать сегменты отката, то так и будет, это скорей вопрос "кривости" рук админа.

А если мы говорил про версию 9i, то установкой retantion_time в нужное значение + наличием дополнительного дискового пространства можно добиться того чтобы ORA-1555 не появлялась.
Если говорим про 8i там настройка сегментов сложнее , но так же реально избежать ORA-1555.



Случайно заглянул
ИМНО Если база быстрая, то она блокировочник. Если у вас быстрый версионник то готовтесь разгребать проблемы с целоснтостью данных.
Имеется ввиду настоящее многопользовательское приложение.
И рыбку съесть и на %#~ сесть не получится.

With regards

Это спорно.
Пример ?
В Юконе наконец-то появиться возможность неблокирующего чтения ( читай версиионность ),
чтобы народ наконец-то почувствовал как оно без блокировок по чтению жить.
Я думаю это не спроста.
А вы ?
...
Рейтинг: 0 / 0
Выбор БД для быстрой работы с большими таблицами.
    #32684845
EugeneS
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Случайно заглянул
Не факт. Если по статистике в виборку попадает более 10% все данных из
таблицы oracle делает полное сканирование. И это всегда быстрее засчет
мультиблочного и опережающего чтения.
Зато на скорости вставки и удаления вы проиграли в сотни раз.

Не факт.
Завист от параметров настройки и в конце концов в каждом конкретном случае может использоваться по разному.
http://www.oradba.com.ru/tuning/optimizer/articles/a2_srchintellcbo/page11.shtml

Мы так же може использовать IOT вместо индекса, опять же зависит от условий задачи , и что мы хотим получить в конце.
...
Рейтинг: 0 / 0
Выбор БД для быстрой работы с большими таблицами.
    #32684878
LeXa NalBat
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Случайно заглянулЕсли по статистике в виборку попадает более 10% все данных из таблицы oracle делает полное сканирование.

У нас подавляющая часть выборок - около 20-ти строк.

Случайно заглянулЗато на скорости вставки и удаления вы проиграли в сотни раз.

Не в сотни, а в несколько раз из-за специфики задачи. Удаление/добавление происходило раз в сутки массированно по алгоритму: drop index, delete 20% строк, insert 20% строк, create index.
...
Рейтинг: 0 / 0
Выбор БД для быстрой работы с большими таблицами.
    #32685196
EugeneS Случайно заглянул
Как красиво :) easy way. Купил базу и на коленке слабал продукт.

Представим бухгалтерию сесия (сеcсия S2) дебитует счет,
При этом сесия S1 дебитует тот-же счет.
То есть получится, Если сумма по транзакциям S1+S2 больше остатка на счете, одна из них должна отклониться по недостатку средств. Но этого
не произойдет. И окончательное значение остатка не будет учитывать
транзакцию которая завершилась раньше.
А потом еще вы очень долго будете искать откуда у вас касса(склад)
разезжаются с бухгалтерией.
Описанный вами пример - часный случай грязного чтения.


Это опять тот пример, который апологеты MSSQL приводят в пику Oracle?
Ну если вы так печетесь о целостности, то наверно имеет смысл говоить, что операция дебетирования счета не может параллелиться, а она есть строго последовательна, и архитектура СУБД тук как бы ни причем.
В этом случае практичекси все едино какую СУБД вы возьмете, хоть обычный плоский файл , суть от этого не меняется и эта суть - "Последовательный доступ к данным".
Причем здесь версионность СУБД, имеет смысл говорить о последовательности исполнения транзакций, а не о конкурентном доступе к данным.
В этом случае вопрос производительности просто нет смысла поднимать, а следует уже говорить о "Transaction-Level Read Consistency".
А для этого у Oracle есть.
SET TRANSACTION ISOLATION LEVEL SERIALIZABLE;



Не будем уходить от темы начиналсь все с

Зл0й
Oracle - версионник. Соотвественно пока объемов Rollback Segment'ов хватает, вы можете одновременно писать и читать одну и ту же таблицу в разных сессиях. Без взаимных блокировок и грязного чтения. . Этим Оракл выгодно отличается от Teradata и DB2. Поясню примером


Не кажется ли вам что вы противоречите концепции версионности и
и предидущему оратору. Что говорит о том, что oracle не совсем версионник.
Зачем версионнику ISOLATION LEVEL SERIALIZABLE. У него есть версионные механизмы поддержания целосности данных. Даже само понятие ISOLATION LEVEL противоречит понятию версионности , не так ли?
В документации по oracle я нигде не встречал
описание понятия версионности. Может процитируете для меня?

Я для вас процетирую :

Oracle Concepts
Transactions and Data Concurrency
Oracle provides data concurrency and integrity between transactions using its locking mechanisms. Because the locking mechanisms of Oracle are tied closely to transaction control, application designers need only define transactions properly, and Oracle automatically manages locking.

Keep in mind that Oracle locking is fully automatic and requires no user action. Implicit locking occurs for all SQL statements so that database users never need to lock any resource explicitly. Oracle's default locking mechanisms lock data at the lowest level of restrictiveness to guarantee data integrity while allowing the highest degree of data concurrency.


Автоматическое управление блокировками это не версионность,
я это имел ввиду когда говорил о внутреннем строении oracle как блокировочника.


EugeneS
Если нет желания настраивать сегменты отката, то так и будет, это скорей вопрос "кривости" рук админа.

А если мы говорил про версию 9i, то установкой retantion_time в нужное значение + наличием дополнительного дискового пространства можно добиться того чтобы ORA-1555 не появлялась.
Если говорим про 8i там настройка сегментов сложнее , но так же реально избежать ORA-1555.


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

EugeneS
Случайно заглянул
ИМНО Если база быстрая, то она блокировочник. Если у вас быстрый версионник то готовтесь разгребать проблемы с целоснтостью данных.
Имеется ввиду настоящее многопользовательское приложение.
И рыбку съесть и на %#~ сесть не получится.

With regards

Это спорно.
Пример ?

В Юконе наконец-то появиться возможность неблокирующего чтения ( читай версиионность ),
чтобы народ наконец-то почувствовал как оно без блокировок по чтению жить.
Я думаю это не спроста.
А вы ?


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

Грязное чтение тоже никого не блокирует, но это не версионность.
Так что читать пока нечего. :) Или там не только чтение, а полная версионность.
...
Рейтинг: 0 / 0
Выбор БД для быстрой работы с большими таблицами.
    #32685304
EugeneS
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Случайно заглянул
Зл0й
Oracle - версионник. Соотвественно пока объемов Rollback Segment'ов хватает, вы можете одновременно писать и читать одну и ту же таблицу в разных сессиях. Без взаимных блокировок и грязного чтения. . Этим Оракл выгодно отличается от Teradata и DB2. Поясню примером


Не кажется ли вам что вы противоречите концепции версионности и
и предидущему оратору. Что говорит о том, что oracle не совсем версионник.
Зачем версионнику ISOLATION LEVEL SERIALIZABLE. У него есть версионные механизмы поддержания целосности данных. Даже само понятие ISOLATION LEVEL противоречит понятию версионности , не так ли?
В документации по oracle я нигде не встречал
описание понятия версионности. Может процитируете для меня?



Преждем чем я отвечу.
Дайте определение того, что вы называете версионником?
И пример программных продуктов которые по вашему являются "чистым версиионником" ?
...
Рейтинг: 0 / 0
Выбор БД для быстрой работы с большими таблицами.
    #32686468
Carrie
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
LeXa NalBat
А если все эти записей находятся на разных дисковых страницах? Прочитать 10-20к страниц дисковой системе - это быстро?

Мне кажется да. Как-нибудь попробую протестить.

LeXa NalBat
Я тестировал на такой машине: два проца Xeon 2.8; 2Gb ОЗУ; 320 SCSI контроллер + два 320 SCSI HDD в RAID 0; ось Linux 2.4.21-SuSE.

У меня 2 x XEON2.4Ghz, 2Gb RAM, интегрированный SCSI-контроллер, 4x36Gb SCSI (не в рейде). ось RHEL AS-3.0. Время теста смог уменьшить до 5мин 10сек. Но все равно в 2 раза дольше чем у вас) Кстати, очень похоже на то, что разницу такую дает использование RAID0.

В общем, я практически уже определился что как буду делать. Сейчас с недели две протестирую на реальных данных еще раз, посмотрю под нагрузкой и т.п. Структуру базы оставлю как она есть, только внесу в нее, как посоветовали, избыточные таблицы, которые будут содержать разные агрегаты основных таблиц. В общем эдакий OLAP "на коленке".
В следующей версии буду смотреть уже в сторону Sybase IQ (на первый взгляд то, что нужно), IBM DB2 (уж очень заманчиво выглядят MDC-таблицы), возможно Oracle с его partitioned tables.
Единственный вопрос, который остался, это касательно postgres'а. Размер таблицы на диске, содержащей, например, только целые поля, в среднем в 6 раз больше, чем произведение колво_строк_таблицы*размер_строки_в_байтах. Не очень критично, но хотелось бы чтобы приблизительно один к одному было, как например в myisam (в innodb, например, этот коэффициент равен уже 4).
...
Рейтинг: 0 / 0
Выбор БД для быстрой работы с большими таблицами.
    #32686608
LeXa NalBat
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
автор> Прочитать 10-20к страниц дисковой системе - это быстро?

Мне кажется да. Как-нибудь попробую протестить.

Мне кажется, что это долго. Если, как правильно уточнил Случайно заглянувший, они лежат не подряд - а это определенно имеет место в рассматриваемом случае.

авторКстати, очень похоже на то, что разницу такую дает использование RAID0.

Я тоже думаю, что это именно RAID 0. Кроме того наш админ сказал (я плохо разбираюсь в железе), что SCSI-контроллер и диски быстрые - 320 Mb/sec.

авторЕдинственный вопрос, который остался, это касательно postgres'а. Размер таблицы на диске, содержащей, например, только целые поля, в среднем в 6 раз больше, чем произведение колво_строк_таблицы*размер_строки_в_байтах. Не очень критично, но хотелось бы чтобы приблизительно один к одному было, как например в myisam (в innodb, например, этот коэффициент равен уже 4).

Я не знаю ответа на этот вопрос. Наверное надо читать где-то в разделе internals в доке. Может быть вам задать этот вопрос в конфе постгреса ?
...
Рейтинг: 0 / 0
Выбор БД для быстрой работы с большими таблицами.
    #32686626
Антилох
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Случайно заглянулЗачем версионнику ISOLATION LEVEL SERIALIZABLE. У него есть версионные механизмы поддержания целосности данных.

Как вы понимате "версионные механизмы поддержания целосности данных" ??? Если вы имеете ввиду непротиворечимость то это и есть ISOLATION LEVEL. Вне зависимости версионники это или блокировочник. Только в версионнике непротиворечимость достигается без блокировок по чтению.

Случайно заглянулДаже само понятие ISOLATION LEVEL противоречит понятию версионности , не так ли?

Не так.

Случайно заглянулАвтоматическое управление блокировками это не версионность.

А кто-то называл это версионостью ?

Случайно заглянулГрязное чтение тоже никого не блокирует, но это не версионность.

Вот когда ISOLATION LEVEL >= Read Committed и никто не блокируется по чтению, вот тогда это версионность. А Грязное чтение говорит об отсутствии версионности.
...
Рейтинг: 0 / 0
Выбор БД для быстрой работы с большими таблицами.
    #32686885
Фотография Я и ёжик
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Случайно заглянул
Не кажется ли вам что вы противоречите концепции версионности и
и предидущему оратору. Что говорит о том, что oracle не совсем версионник.
Зачем версионнику ISOLATION LEVEL SERIALIZABLE. У него есть версионные механизмы поддержания целосности данных. Даже само понятие ISOLATION LEVEL противоречит понятию версионности , не так ли?
В документации по oracle я нигде не встречал
описание понятия версионности. Может процитируете для меня?


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

Если рассматривать типы планировщиков транзакций то можно выделить следующие группы:
Код: plaintext
1.
2.
3.
4.
5.
1.Блокирующие:
   1.1 Протокол двухфазного блокирования (Two phase locking (2PL))

2. Не блокирующие:
   2.1 Упорядочевание на основе временных меток.( Timestamp ordering (TO) )
   2.2 Проверка корректности графа транзакций ( Serialization graph testing (SGT))

Механизм контроля версий (MVCC) может быть добавлен к любому планировщику транзакций в целях минимизации количества конфликтных ситуаций требующих ожидания/отката за счет затрат на необходимость хранить версии данных.
Напримеры:

TO+MVCС : InterBase (Этот подвид обычно и называют "версионник" в противопоставлении "версионник" vs "блокировочник" на форумах и в научно-популярных;) статьях ).

(2PL + TO) + MVCС : Oracle (смешанный механизм шедулера, можно рассматривать как TO для чтения и 2PL для записи).

В Yukon, на сколько я пологаю, "Версионность" это как и в Oracle смешанный механизм шедулера (2PL + TO) + MVCС, но тут я могу ошибаться.

[1] Concurrency Control & Recovery in Database Systems, By Ph. Bernstein .
[2]/topic/94928&pg=8#708730


Случайно заглянулOracle кстате версиониик только внешне, внутри он все такой же блокировочник.
ИХМО постоянное возникновенни ошибки ORA-1555 Snapshot too old
коственно говорит о кривости рук проектировщика базы.
2) Как уже написано выше в Oracle применен гибридный механизм управления паралельными заданиями и поддержания целостности (2PL + TO) + MVCС.
ORA-1555 Snapshot too old это результат некоторого компромиса в угоду скорости взамен на некоторую вероятность не выполнить транзакцию.


Случайно заглянул
Зачем версионнику ISOLATION LEVEL SERIALIZABLE. У него есть версионные механизмы поддержания целосности данных.
3) То что в Oracle называется ISOLATION LEVEL SERIALIZABLE, не является SERIALIZABLE в полном понимании (т.е. не обеспечивает удовлетворения критерию упорядоченности), в теории такой уровень изоляции обычно называют SNAPSHOT. SERIALIZABLE в Oracle его назвали благодаря нечеткому определению этого уровня в ANSI стандарте ( через отсутствие некоторого набора феноменов, которые SNAPSHOT как раз и предотвращает).
Для обеспечения реальной сериализации требуется ставить дополнительные блокировки.

Случайно заглянул
В документации по oracle я нигде не встречал описание понятия версионности. Может процитируете для меня?
4) Oracle® Database Concepts 10g Release 1 (10.1). 1 Introduction to the Oracle Database.
Concurrency
...
Oracle resolves such issues by using various types of locks and a multiversion consistency model . These features are based on the concept of a transaction

Read Consistency, Undo Records, and Transactions
To manage the multiversion consistency model , Oracle must create a read-consistent set of data when a table is queried (read) and simultaneously updated (written). When an update occurs, the original data values changed by the update are recorded in the database undo records. As long as this update remains part of an uncommitted transaction, any user that later queries the modified data views the original data values. Oracle uses current information in the system global area and information in the undo records to construct a read-consistent view of a table\'s data for a query.

Only when a transaction is committed are the changes of the transaction made permanent. Statements that start after the user\'s transaction is committed only see the changes made by the committed transaction.

The transaction is key to Oracle\'s strategy for providing read consistency. This unit of committed (or uncommitted) SQL statements:

Dictates the start point for read-consistent views generated on behalf of readers

Controls when modified data can be seen by other transactions of the database for reading or updating


5) В Вашем примере c дебетовыми транзакциями Oracle на уровне ISOLATION LEVEL SERIALIZABLE (snapshot) одну транзакцию откатит. На уровне изоляции READ COMITTED ( опять же несколько не соответствующем ANSI уровню), разработчику надо принимать дополнительные меры по блокированию счета.
...
Рейтинг: 0 / 0
52 сообщений из 52, показаны все 3 страниц
Форумы / Сравнение СУБД [игнор отключен] [закрыт для гостей] / Выбор БД для быстрой работы с большими таблицами.
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


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