powered by simpleCommunicator - 2.0.60     © 2026 Programmizd 02
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / Как так быстро работает поиск в love.mail.ru?
15 сообщений из 15, страница 1 из 1
Как так быстро работает поиск в love.mail.ru?
    #32902782
nforward
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Добрый день

Никак не пойму - как так смогли быстро организовать поиск по галерее в love.mail.ru? Причем мгновенно считается count, и получение записей в начале выборки ничем не отличается по времени получения записей в конце выборке (я проверял у них с offset 640 тысяч - его явно можно в url менять)

Поля таблицы (как я думаю) - по которой идет поиск
user_id
Пол
Страна
Город
Возраст
Наличие фото
7 битовых полей - подходит ли наш пол

Я создал аналогичную таблицу на 1.2 миллиона записей, как я ни развлекался с индексами, чем бсльше offset по выборке - тем больше времени идет на запрос.
А у них мгновенно работает (и, как я понимаю, нагрузка нехилая).

Что нужно, чтобы работало также быстро???
Поделитесь мыслями?
...
Рейтинг: 0 / 0
Как так быстро работает поиск в love.mail.ru?
    #32903045
Denis A.
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Кэширование в добавочных таблицах. Добавление юзера, например, происходит на порядки реже (по сравнению с выборками), на таблицу с юзерами вешается триггер, который апдейтит количество юзеров в другой табличке с учетом города. Количество городов опять же много меньше количества юзеров, т.о. вопрос "сколько юзеров из моего города" делается по таблице на из 1.5 млн записей, а по таблице из 10 тыщ записей, что собственно куда легче ;) А уж выбрать из 10 тыщ кто в данный момент онлайн - пара пустяков, хранить 20 тыщ сессий и сделать выборку по FK (городу) из этой таблицы - дело плевое и быстрое.
...
Рейтинг: 0 / 0
Как так быстро работает поиск в love.mail.ru?
    #32903059
nforward
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
О моих экспериментах -
я сделал тестовую таблицу и сделал серию из 70 запросов к ней для тестирования производительности
в табличку поместил примерно 1 200 000 записей

таблица
user_id | integer |
user_age | smallint |
sex | smallint |
country | integer |
city1 | integer |
search_order | integer |
sexwant_1 | boolean |
sexwant_2 | boolean |
sexwant_3 | boolean |
sexwant_4 | boolean |
sexwant_5 | boolean |
sexwant_6 | boolean |
sexwant_7 | boolean |

search_order - порядок сортировки - можно сделать и user_id desc но тогда появляется desc в огвук ин - и например MySQL перестает использовать индекс

Пробовал с PostgreSQL 8.0.0, 7.3.4
8я версия оказалась в 2,5 раза быстрее чем 7я - она гораздо лучше работала с индексами
лучший вариант по производительности дает составной индекс по 3м полям (search_order, user_age, city1) и cluster таблицы по этому индексу
да - важно - в конфиге PostgreSQL поставил enable_seqscan = no иначе она все время пытается индекс не использовать! - и получается горазде медленнее

Попробовал MySQL - последнюю 5ю версию
с ней проблема - если делаем много критериев сразу в поиске, то она не использует индексы и производительность жутко падает - я в ней разбираюсь не слишком хорошо, наверное поэтому...
(в 1.5-2 раза медленнее чем PostgreSQL 8)

Типовые запросы
для PostgreSQL
SELECT * FROM dm_s WHERE ( user_age>=18 AND user_age<=40 and sex in (2) and search_order>0 and city1=31677 and sexwant_1=TRUE) order by search_order limit 10 offset 10;
для МуSQL
SELECT * FROM dm_s WHERE ( user_age>=18 AND user_age<=40 and sex in (2) and search_order>0 and city1=31677 and sexwant_1=1) order by search_order limit 10,10;

при увеличении offset, производительность падает причем достаточно сильно
Непонятно, как на love.mail.ru сделали так? что все всегда работает мгновенно...

Мысли у меня
1 Таблица хранится только в памяти
2 Используем не 1 таблицу, а несколько - например по полю sex разбиение
3 Может, какие-либо многомерные кубы??? - я в этом совсем не разбираюсь
4 Супер-возможности кеширования результатов выборок? И на каких SQL серверах это может быть?
5 Может, мне стоит поставить Oracle/DB2/Cache/Sybase??? Профессионалы - подскажите - могут ли эти сервера на простых запрасах на данной таблице быть более производительными, чем MySQL и PostgreSQL???
6 Само-собой понятно, что кластеры - это хорошо под нагрузкой, но я тестировал в монопольном режиме

PS я действительно поражен. что на love.mail.ru при offset 640 тысяч ответ идет мгновенно - у меня все время получались номного большие задержки чем вначале...
...
Рейтинг: 0 / 0
Как так быстро работает поиск в love.mail.ru?
    #32903063
nforward
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Denis A.Кэширование в добавочных таблицах. Добавление юзера, например, происходит на порядки реже (по сравнению с выборками), на таблицу с юзерами вешается триггер, который апдейтит количество юзеров в другой табличке с учетом города. Количество городов опять же много меньше количества юзеров, т.о. вопрос "сколько юзеров из моего города" делается по таблице на из 1.5 млн записей, а по таблице из 10 тыщ записей, что собственно куда легче ;) А уж выбрать из 10 тыщ кто в данный момент онлайн - пара пустяков, хранить 20 тыщ сессий и сделать выборку по FK (городу) из этой таблицы - дело плевое и быстрое.

Есть несколько моментов
1 Городов десятки тысяч - понятно, что можем сделать на Москву и Питер отдельные таблицы
2 когда я говорил про поиск со сдвигом в 640 тысяч, я делал это вообще без учета города - и это работало мгновенно
...
Рейтинг: 0 / 0
Как так быстро работает поиск в love.mail.ru?
    #32903122
Yo!
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Yo!
Гость
для оракла:

>1 Таблица хранится только в памяти
да можно закрепить

>2 Используем не 1 таблицу, а несколько - например по полю sex разбиение
смысла нет, тут нада использовать bitmap index

>3 Может, какие-либо многомерные кубы??? - я в этом совсем не разбираюсь
скорее matrialized view.

>4 Супер-возможности кеширования результатов выборок? И на каких SQL серверах это может быть?

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

>5 Может, мне стоит поставить Oracle/DB2/Cache/Sybase??? Профессионалы - подскажите - могут ли эти сервера на простых запрасах на данной таблице быть более производительными, чем MySQL и PostgreSQL???

если имел дело с postgres поставь оракл, постгрес с оракла лепили - быстрей разберешся. тебя будут интересовать:
materialized view
index organized tables
bitmap index
хинт /* first rows */

>6 Само-собой понятно, что кластеры - это хорошо под нагрузкой, но я тестировал в монопольном режиме

зачем же кластер для такой простой задачки, там просто несколько процов скази диски, один запрос несколько процессов (фишка oracle parallel server) обслуживает, например 2 паралельно читают (с разных дисков) данные, а третий джоин и все это обслуживет 4 проца.

P.S. там странички у меня открывается по 5-10 секунд, не понятно что так впечатлил ...
...
Рейтинг: 0 / 0
Как так быстро работает поиск в love.mail.ru?
    #32903129
nforward
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Yo!для оракла:

P.S. там странички у меня открывается по 5-10 секунд, не понятно что так впечатлил ...

У меня они открываются меньме секунды. Это и поражает что время вначале выборки и в конце - одинаковое.

Спасибо.

Как я понял, мне надо смотреть в сторону Oracle, остальные системы и PostgreSQL/Mysql будут хуже в данном конкретном применении.
...
Рейтинг: 0 / 0
Как так быстро работает поиск в love.mail.ru?
    #32903133
Yo!
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Yo!
Гость
авторКак я понял, мне надо смотреть в сторону Oracle, остальные системы и PostgreSQL/Mysql будут хуже в данном конкретном применении.

думаю там просто желелезо нормальное и врядле что-то из наворотов используется. а то что при офсете увеличивается задержка так это кривота реализации limit, ведь не даром этой чудо конструкции нет в промышленых субд.
...
Рейтинг: 0 / 0
Как так быстро работает поиск в love.mail.ru?
    #32903137
nforward
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Yo! авторКак я понял, мне надо смотреть в сторону Oracle, остальные системы и PostgreSQL/Mysql будут хуже в данном конкретном применении.

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

а как тогда выбирается только кусок выборки???
...
Рейтинг: 0 / 0
Как так быстро работает поиск в love.mail.ru?
    #32903141
Yo!
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Yo!
Гость
>а как тогда выбирается только кусок выборки???

http://www.sql.ru/faq/faq_topic.aspx?fid=171

покажи статистику и планы, offset из начала и конца, чем они отличаются ?
может у тебя элементарно сортировка в памяти не помещается ...
...
Рейтинг: 0 / 0
Как так быстро работает поиск в love.mail.ru?
    #32903167
nforward
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Yo!>а как тогда выбирается только кусок выборки???

http://www.sql.ru/faq/faq_topic.aspx?fid=171

покажи статистику и планы, offset из начала и конца, чем они отличаются ?
может у тебя элементарно сортировка в памяти не помещается ...

Вот тестовые запросы

explain analyze SELECT * FROM dm_s WHERE ( user_age>=18 AND user_age<=40 and sex in (2) and search_order>0 and city1=31677 and sexwant_1=TRUE ) order by search_order limit 10 offset 10;

explain analyze SELECT * FROM dm_s WHERE ( user_age>=18 AND user_age<=40 and sex in (2) and search_order>0 and city1=31677 and sexwant_1=TRUE ) order by search_order limit 10 offset 1000;

explain analyze SELECT * FROM dm_s WHERE ( user_age>=18 AND user_age<=40 and sex in (2) and search_order>0 and city1=31677 and sexwant_1=TRUE ) order by search_order limit 10 offset 10000;

explain analyze SELECT * FROM dm_s WHERE ( user_age>=18 AND user_age<=40 and sex in (2) and search_order>0 and city1=31677 and sexwant_1=TRUE ) order by search_order limit 10 offset 30000;

explain analyze SELECT count(*) FROM dm_s WHERE ( user_age>=18 AND user_age<=40 and sex in (2) and search_order>0 and city1=31677 and sexwant_1=TRUE );


QUERY PLAN
---------------------------------------------------------------------------------------------------------------------------------------------
Limit (cost=16.84..33.69 rows=10 width=67) (actual time=0.402..0.435 rows=10 loops=1)
-> Index Scan using dm_s1_big on dm_s (cost=0.00..39657.61 rows=23543 width=67) (actual time=0.359..0.413 rows=20 loops=1)
Index Cond: ((search_order > 0) AND (user_age >= 18) AND (user_age <= 40) AND (city1 = 31677) AND (sex = 2) AND (sexwant_1 = true))
Total runtime: 0.834 ms
(записей: 4)

QUERY PLAN
---------------------------------------------------------------------------------------------------------------------------------------------
Limit (cost=1684.48..1701.32 rows=10 width=67) (actual time=6.825..6.864 rows=10 loops=1)
-> Index Scan using dm_s1_big on dm_s (cost=0.00..39657.61 rows=23543 width=67) (actual time=0.342..6.287 rows=1010 loops=1)
Index Cond: ((search_order > 0) AND (user_age >= 18) AND (user_age <= 40) AND (city1 = 31677) AND (sex = 2) AND (sexwant_1 = true))
Total runtime: 7.221 ms
(записей: 4)

QUERY PLAN
---------------------------------------------------------------------------------------------------------------------------------------------
Limit (cost=16844.76..16861.60 rows=10 width=67) (actual time=80.024..80.061 rows=10 loops=1)
-> Index Scan using dm_s1_big on dm_s (cost=0.00..39657.61 rows=23543 width=67) (actual time=0.344..73.952 rows=10010 loops=1)
Index Cond: ((search_order > 0) AND (user_age >= 18) AND (user_age <= 40) AND (city1 = 31677) AND (sex = 2) AND (sexwant_1 = true))
Total runtime: 80.364 ms
(записей: 4)

QUERY PLAN
---------------------------------------------------------------------------------------------------------------------------------------------
Limit (cost=39657.61..39657.61 rows=1 width=67) (actual time=348.707..348.742 rows=10 loops=1)
-> Index Scan using dm_s1_big on dm_s (cost=0.00..39657.61 rows=23543 width=67) (actual time=0.345..329.126 rows=30010 loops=1)
Index Cond: ((search_order > 0) AND (user_age >= 18) AND (user_age <= 40) AND (city1 = 31677) AND (sex = 2) AND (sexwant_1 = true))
Total runtime: 349.061 ms
(записей: 4)

QUERY PLAN
---------------------------------------------------------------------------------------------------------------------------------------------
Aggregate (cost=39716.47..39716.47 rows=1 width=0) (actual time=761.276..761.278 rows=1 loops=1)
-> Index Scan using dm_s1_big on dm_s (cost=0.00..39657.61 rows=23543 width=0) (actual time=0.325..705.573 rows=39074 loops=1)
Index Cond: ((search_order > 0) AND (user_age >= 18) AND (user_age <= 40) AND (city1 = 31677) AND (sex = 2) AND (sexwant_1 = true))
Total runtime: 762.558 ms
(записей: 4)

как видно, чем больше сдвиг по выборке - тем дольше работаем...
и count отвратительно долго считается.

Я прочитал ссылку - не понятно, почему такая конструкция работает быстрее, чем limit-offset
...
Рейтинг: 0 / 0
Как так быстро работает поиск в love.mail.ru?
    #32903187
nforward
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Сорри
Это у меня один огромный индекс по всем поисковым полям остался...
рабочий вариант - индекс по (search_order, user_age, city1)
И - обязательно - кластеризация таблицы по нему

Тогда получаем

QUERY PLAN
---------------------------------------------------------------------------------------------------------------------------------
Limit (cost=49.68..99.36 rows=10 width=67) (actual time=0.615..0.658 rows=10 loops=1)
-> Index Scan using dm_s1_big on dm_s (cost=0.00..139603.57 rows=28101 width=67) (actual time=0.568..0.633 rows=20 loops=1)
Index Cond: ((search_order > 0) AND (user_age >= 18) AND (user_age <= 40) AND (city1 = 31677))
Filter: ((sex = 2) AND (sexwant_1 = true))
Total runtime: 1.019 ms
(записей: 5)

QUERY PLAN
-----------------------------------------------------------------------------------------------------------------------------------
Limit (cost=4967.92..5017.60 rows=10 width=67) (actual time=9.240..9.283 rows=10 loops=1)
-> Index Scan using dm_s1_big on dm_s (cost=0.00..139603.57 rows=28101 width=67) (actual time=0.488..8.704 rows=1010 loops=1)
Index Cond: ((search_order > 0) AND (user_age >= 18) AND (user_age <= 40) AND (city1 = 31677))
Filter: ((sex = 2) AND (sexwant_1 = true))
Total runtime: 9.633 ms
(записей: 5)

QUERY PLAN
--------------------------------------------------------------------------------------------------------------------------------------
Limit (cost=49679.22..49728.90 rows=10 width=67) (actual time=109.304..109.349 rows=10 loops=1)
-> Index Scan using dm_s1_big on dm_s (cost=0.00..139603.57 rows=28101 width=67) (actual time=0.467..103.539 rows=10010 loops=1)
Index Cond: ((search_order > 0) AND (user_age >= 18) AND (user_age <= 40) AND (city1 = 31677))
Filter: ((sex = 2) AND (sexwant_1 = true))
Total runtime: 109.654 ms
(записей: 5)

QUERY PLAN
--------------------------------------------------------------------------------------------------------------------------------------
Limit (cost=139603.57..139603.57 rows=1 width=67) (actual time=476.349..476.386 rows=10 loops=1)
-> Index Scan using dm_s1_big on dm_s (cost=0.00..139603.57 rows=28101 width=67) (actual time=0.486..458.667 rows=30010 loops=1)
Index Cond: ((search_order > 0) AND (user_age >= 18) AND (user_age <= 40) AND (city1 = 31677))
Filter: ((sex = 2) AND (sexwant_1 = true))
Total runtime: 476.702 ms
(записей: 5)

QUERY PLAN
-------------------------------------------------------------------------------------------------------------------------------------
Aggregate (cost=139673.83..139673.83 rows=1 width=0) (actual time=944.248..944.250 rows=1 loops=1)
-> Index Scan using dm_s1_big on dm_s (cost=0.00..139603.57 rows=28101 width=0) (actual time=0.469..883.432 rows=39074 loops=1)
Index Cond: ((search_order > 0) AND (user_age >= 18) AND (user_age <= 40) AND (city1 = 31677))
Filter: ((sex = 2) AND (sexwant_1 = true))
Total runtime: 945.549 ms

и - для общей картины
tb8=# SELECT count(*) FROM dm_s;
count
---------
1234350
(1 запись)

tb8=# SELECT count(*) FROM dm_s WHERE ( user_age>=18 AND user_age<=40 and sex in (2) and search_order>0 and city1=31677 and sexwant_1=TRUE );
count
-------
39074
(1 запись)
...
Рейтинг: 0 / 0
Как так быстро работает поиск в love.mail.ru?
    #32903271
Yo!
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Yo!
Гость
ну вот что у меня на 1Ghz получилось:

Код: 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.
69.
70.
71.
72.
73.
74.
75.
76.
77.
78.
79.
80.
81.
82.
83.
84.
85.
86.
87.
88.
89.
90.
91.
92.
93.
94.
95.
96.
97.
98.
99.
100.
101.
102.
103.
104.
105.
106.
107.
108.
109.
110.
111.
112.
113.
114.
115.
116.
117.
118.
119.
120.
121.
122.
123.
124.
125.
126.
127.
128.
129.
130.
131.
132.
133.
134.
135.
136.
137.
138.
139.
140.
141.
142.
143.
144.
145.
146.
147.
148.
149.
150.
151.
152.
153.
154.
155.
156.
157.
158.
159.
160.
161.
162.
163.
164.
165.
166.
167.
168.
169.
170.
171.
172.
173.
174.
175.
176.
177.
178.
179.
180.
181.
182.
183.
184.
185.
186.
187.
188.
189.
190.
191.
192.
193.
194.
195.
196.
197.
198.
199.
200.
201.
202.
203.
204.
205.
206.
207.
208.
209.
210.
211.
212.
213.
214.
215.
216.
217.
218.
219.
220.
221.
222.
223.
224.
225.
226.
227.
228.
229.
230.
231.
232.
SQL> select count(*) from tst ;

  COUNT(*)
----------
    1429056 

Elapsed:  00 : 00 : 00 . 09 

SQL> select o.id
from (select rownum rw
           , o.id
      from (select o.id from tst o where status='Done' and created > sysdate- 900  and TYPE_ID= 72 ) o
      where rownum <  1750 
     ) o
where o.rw >=  1700  ;  

        ID
----------
     137971 
     100340 
     134311 
     138019 
      79803 
     120700 
     131950 
     100260 
      75251 
     118599 
     107602 

        ID
----------
      75026 
     102931 
     105989 
     131558 
     105793 
     123867 
      89142 
      79376 
     127033 
      78703 
      74637 

        ID
----------
     123682 
     122765 
      81663 
      82468 
      93861 
      75227 
     104068 
      80857 
     133284 
     132010 
     108511 

        ID
----------
     123931 
      75507 
     134803 
      88470 
     134672 
     125536 
     107642 
      80823 
      83878 
     110470 
      88440 

        ID
----------
      81549 
      95667 
      81642 
     134747 
      78965 
     123698 

 50  rows selected.

Elapsed:  00 : 00 : 00 . 34 

Execution Plan
----------------------------------------------------------
    0       SELECT STATEMENT Optimizer=ALL_ROWS (Cost= 4056  Card= 1749  Byt
          es= 45474 )

    1      0    VIEW (Cost= 4056  Card= 1749  Bytes= 45474 )
    2      1      COUNT (STOPKEY)
    3      2        TABLE ACCESS (BY INDEX ROWID) OF 'TST' (TABLE) (Cost= 4 
           056  Card= 122242  Bytes= 5378648 )

    4      3          BITMAP CONVERSION (TO ROWIDS)
    5      4            BITMAP INDEX (SINGLE VALUE) OF 'BITMAP_IDX' (INDEX
           (BITMAP))





Statistics
----------------------------------------------------------
           5   recursive calls
           0   db block gets
        1093   consistent gets
         579   physical reads
           0   redo size
        1174   bytes sent via SQL*Net to client
         545   bytes received via SQL*Net from client
           5   SQL*Net roundtrips to/from client
           0   sorts (memory)
           0   sorts (disk)
          50   rows processed
SQL> create index type_idx on tst(CNTCT_TYPE_ID) ;

Index created.

Elapsed:  00 : 03 : 59 . 71 
SQL> select count(o.id) from tst o where status='Done' and created > sysdate- 900  and TYPE_ID= 72 ;

COUNT(O.ID)
-----------
      106158 

Elapsed:  00 : 00 : 16 . 77 

Execution Plan
----------------------------------------------------------
    0       SELECT STATEMENT Optimizer=ALL_ROWS (Cost= 4785  Card= 1  Bytes=
           31 )

    1      0    SORT (AGGREGATE)
    2      1      VIEW OF 'index$_join$_001' (VIEW) (Cost= 4785  Card= 122242 
           Bytes= 3789502 )

    3      2        HASH JOIN
    4      3          HASH JOIN
    5      4            BITMAP CONVERSION (TO ROWIDS) (Cost= 67  Card= 122242 
           Bytes= 3789502 )

    6      5              BITMAP INDEX (SINGLE VALUE) OF 'BITMAP_IDX' (IND
          EX (BITMAP))

    7      4            INDEX (RANGE SCAN) OF 'TYPE_IDX' (INDEX) (Cost
          = 328  Card= 122242  Bytes= 3789502 )

    8      3          INDEX (RANGE SCAN) OF 'DT_IDX' (INDEX) (Cost= 41271  C
          ard= 122242  Bytes= 3789502 )





Statistics
----------------------------------------------------------
          34   recursive calls
           0   db block gets
        6561   consistent gets
        4270   physical reads
      215896   redo size
         398   bytes sent via SQL*Net to client
         512   bytes received via SQL*Net from client
           2   SQL*Net roundtrips to/from client
           0   sorts (memory)
           0   sorts (disk)
           1   rows processed

SQL> drop index type_idx ;

Index dropped.

Elapsed:  00 : 00 : 01 . 27 
SQL> create bitmap index type_idx on tst(TYPE_ID) ;

Index created.

Elapsed:  00 : 00 : 59 . 97 
SQL> select count(o.id) from tst o where status='Done' and created > sysdate- 900  and TYPE_ID= 72 ;

COUNT(O.ID)
-----------
      106158 

Elapsed:  00 : 00 : 04 . 86 

Execution Plan
----------------------------------------------------------
    0       SELECT STATEMENT Optimizer=ALL_ROWS (Cost= 4599  Card= 1  Bytes=
           31 )

    1      0    SORT (AGGREGATE)
    2      1      VIEW OF 'index$_join$_001' (VIEW) (Cost= 4599  Card= 122242 
           Bytes= 3789502 )

    3      2        HASH JOIN
    4      3          HASH JOIN
    5      4            BITMAP CONVERSION (TO ROWIDS) (Cost= 18  Card= 122242 
           Bytes= 3789502 )

    6      5              BITMAP INDEX (SINGLE VALUE) OF 'type_IDX' (I
          NDEX (BITMAP))

    7      4            BITMAP CONVERSION (TO ROWIDS) (Cost= 67  Card= 122242 
           Bytes= 3789502 )

    8      7              BITMAP INDEX (SINGLE VALUE) OF 'BITMAP_IDX' (IND
          EX (BITMAP))

    9      3          INDEX (RANGE SCAN) OF 'DT_IDX' (INDEX) (Cost= 41825  C
          ard= 122242  Bytes= 3789502 )





Statistics
----------------------------------------------------------
          82   recursive calls
           0   db block gets
        3502   consistent gets
         911   physical reads
           0   redo size
         398   bytes sent via SQL*Net to client
         512   bytes received via SQL*Net from client
           2   SQL*Net roundtrips to/from client
           0   sorts (memory)
           0   sorts (disk)
           1   rows processed

...
Рейтинг: 0 / 0
Как так быстро работает поиск в love.mail.ru?
    #32916201
LeXa NalBat
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Try Oracle!

Пробегая по индексу миллион ненужных записей (offset=1000000), для каждой из них постгрес заглядывает (читает) в таблицу. Оракл этого не делает, если все условия в where может проверить по индексу, и все поля из from есть в индексе.

Вот сравнительный тест на одной и той же железке и на одинаковых данных для Постгреса 7.3 и Оракла 8.1. Планы выполнения в обоих базах: index scan, limit. Замерял время второго запроса, чтобы данные читались из кэша, а не с диска.

Код: 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.
$ time echo "select plno from plprice_00 order by plno limit 10 offset 1000;" | psql -U pl -d pl
   plno
----------
  92243867 
  92243868 
  92243869 
  92243870 
  92243871 
  92243872 
  92243873 
  92243874 
  92243875 
  92243876 
( 10  rows)


real    0m0.017s
user    0m0.000s
sys     0m0.010s

$ time echo "select plno from plprice_00 order by plno limit 10 offset 1000000;" | psql -U pl -d pl
   plno
-----------
  279825544 
  279825545 
  279825546 
  279825547 
  279825548 
  279825549 
  279825550 
  279825551 
  279825552 
  279825553 
( 10  rows)


real    0m2.229s
user    0m0.000s
sys     0m0.000s

$ time echo "select plno from plprice_00 order by plno limit 10 offset 3000000;" | psql -U pl -d pl
   plno
-----------
  283491830 
  283491831 
  283491832 
  283491833 
  283491834 
  283491835 
  283491836 
  283491837 
  283491838 
  283491839 
( 10  rows)


real    0m6.635s
user    0m0.010s
sys     0m0.000s
Код: 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.
69.
70.
71.
72.
73.
74.
75.
76.
77.
78.
79.
80.
81.
82.
83.
84.
85.
86.
87.
88.
89.
90.
91.
92.
93.
94.
95.
96.
97.
98.
99.
100.
101.
102.
103.
$ time echo "select plno from ( select rownum as rn, plno from plprice_00 where rownum < 1010 order by plno ) a where rn > 1000;" | sqlplus pl/pl@local

SQL*Plus: Release  8 . 1 . 7 . 0 . 0  - Production on Tue Feb  15   12 : 11 : 03   2005 

(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>
      PLNO
----------
   92243867 
   92243868 
   92243869 
   92243870 
   92243871 
   92243872 
   92243873 
   92243874 
   92243875 

 9  rows selected.

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    0m0.037s
user    0m0.000s
sys     0m0.020s

$ time echo "select plno from ( select rownum as rn, plno from plprice_00 where rownum < 1000010 order by plno ) a where rn > 1000000;" | sqlplus pl/pl@local

SQL*Plus: Release  8 . 1 . 7 . 0 . 0  - Production on Tue Feb  15   12 : 11 : 10   2005 

(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>
      PLNO
----------
  279825544 
  279825545 
  279825546 
  279825547 
  279825548 
  279825549 
  279825550 
  279825551 
  279825552 

 9  rows selected.

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    0m0.554s
user    0m0.010s
sys     0m0.010s

$ time echo "select plno from ( select rownum as rn, plno from plprice_00 where rownum < 3000010 order by plno ) a where rn > 3000000;" | sqlplus pl/pl@local

SQL*Plus: Release  8 . 1 . 7 . 0 . 0  - Production on Tue Feb  15   12 : 11 : 18   2005 

(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>
      PLNO
----------
  283491830 
  283491831 
  283491832 
  283491833 
  283491834 
  283491835 
  283491836 
  283491837 
  283491838 

 9  rows selected.

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    0m1.661s
user    0m0.020s
sys     0m0.000s
...
Рейтинг: 0 / 0
Как так быстро работает поиск в love.mail.ru?
    #32916712
Denis A.
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Что вы страдаете, говорю же - агрегация рулит. По циске у меня например так информация храница. В raw данных - к 7 млн записей подбираетца, в агрегированной - 1.3 млн. Также засчет того, что размер записей в агрегированной таблице на порядок меньше - ссчитается трафик за любой период практически мгновенно.
...
Рейтинг: 0 / 0
Как так быстро работает поиск в love.mail.ru?
    #32917648
LeXa NalBat
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
2 Denis A.

Мое сообщение относится не к тому, как быстро узнать кол-во результатов поиска, а ко второму вопросу, затронутому автором, как быстрее получить несколько строк из упорядоченного набора результатов поиска с большим отступом (offset). Да, это также обсуждалось в теме limit - offset / PostgreSQL.
...
Рейтинг: 0 / 0
15 сообщений из 15, страница 1 из 1
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / Как так быстро работает поиск в love.mail.ru?
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


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