Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности
|
|
|
Как так быстро работает поиск в love.mail.ru?
|
|||
|---|---|---|---|
|
#18+
Добрый день Никак не пойму - как так смогли быстро организовать поиск по галерее в love.mail.ru? Причем мгновенно считается count, и получение записей в начале выборки ничем не отличается по времени получения записей в конце выборке (я проверял у них с offset 640 тысяч - его явно можно в url менять) Поля таблицы (как я думаю) - по которой идет поиск user_id Пол Страна Город Возраст Наличие фото 7 битовых полей - подходит ли наш пол Я создал аналогичную таблицу на 1.2 миллиона записей, как я ни развлекался с индексами, чем бсльше offset по выборке - тем больше времени идет на запрос. А у них мгновенно работает (и, как я понимаю, нагрузка нехилая). Что нужно, чтобы работало также быстро??? Поделитесь мыслями? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.02.2005, 21:11 |
|
||
|
Как так быстро работает поиск в love.mail.ru?
|
|||
|---|---|---|---|
|
#18+
Кэширование в добавочных таблицах. Добавление юзера, например, происходит на порядки реже (по сравнению с выборками), на таблицу с юзерами вешается триггер, который апдейтит количество юзеров в другой табличке с учетом города. Количество городов опять же много меньше количества юзеров, т.о. вопрос "сколько юзеров из моего города" делается по таблице на из 1.5 млн записей, а по таблице из 10 тыщ записей, что собственно куда легче ;) А уж выбрать из 10 тыщ кто в данный момент онлайн - пара пустяков, хранить 20 тыщ сессий и сделать выборку по FK (городу) из этой таблицы - дело плевое и быстрое. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.02.2005, 15:50 |
|
||
|
Как так быстро работает поиск в love.mail.ru?
|
|||
|---|---|---|---|
|
#18+
О моих экспериментах - я сделал тестовую таблицу и сделал серию из 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 тысяч ответ идет мгновенно - у меня все время получались номного большие задержки чем вначале... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.02.2005, 16:12 |
|
||
|
Как так быстро работает поиск в love.mail.ru?
|
|||
|---|---|---|---|
|
#18+
Denis A.Кэширование в добавочных таблицах. Добавление юзера, например, происходит на порядки реже (по сравнению с выборками), на таблицу с юзерами вешается триггер, который апдейтит количество юзеров в другой табличке с учетом города. Количество городов опять же много меньше количества юзеров, т.о. вопрос "сколько юзеров из моего города" делается по таблице на из 1.5 млн записей, а по таблице из 10 тыщ записей, что собственно куда легче ;) А уж выбрать из 10 тыщ кто в данный момент онлайн - пара пустяков, хранить 20 тыщ сессий и сделать выборку по FK (городу) из этой таблицы - дело плевое и быстрое. Есть несколько моментов 1 Городов десятки тысяч - понятно, что можем сделать на Москву и Питер отдельные таблицы 2 когда я говорил про поиск со сдвигом в 640 тысяч, я делал это вообще без учета города - и это работало мгновенно ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.02.2005, 16:25 |
|
||
|
Как так быстро работает поиск в love.mail.ru?
|
|||
|---|---|---|---|
|
#18+
для оракла: >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 секунд, не понятно что так впечатлил ... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.02.2005, 18:38 |
|
||
|
Как так быстро работает поиск в love.mail.ru?
|
|||
|---|---|---|---|
|
#18+
Yo!для оракла: P.S. там странички у меня открывается по 5-10 секунд, не понятно что так впечатлил ... У меня они открываются меньме секунды. Это и поражает что время вначале выборки и в конце - одинаковое. Спасибо. Как я понял, мне надо смотреть в сторону Oracle, остальные системы и PostgreSQL/Mysql будут хуже в данном конкретном применении. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.02.2005, 18:56 |
|
||
|
Как так быстро работает поиск в love.mail.ru?
|
|||
|---|---|---|---|
|
#18+
авторКак я понял, мне надо смотреть в сторону Oracle, остальные системы и PostgreSQL/Mysql будут хуже в данном конкретном применении. думаю там просто желелезо нормальное и врядле что-то из наворотов используется. а то что при офсете увеличивается задержка так это кривота реализации limit, ведь не даром этой чудо конструкции нет в промышленых субд. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.02.2005, 19:15 |
|
||
|
Как так быстро работает поиск в love.mail.ru?
|
|||
|---|---|---|---|
|
#18+
Yo! авторКак я понял, мне надо смотреть в сторону Oracle, остальные системы и PostgreSQL/Mysql будут хуже в данном конкретном применении. думаю там просто желелезо нормальное и врядле что-то из наворотов используется. а то что при офсете увеличивается задержка так это кривота реализации limit, ведь не даром этой чудо конструкции нет в промышленых субд. а как тогда выбирается только кусок выборки??? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.02.2005, 19:34 |
|
||
|
Как так быстро работает поиск в love.mail.ru?
|
|||
|---|---|---|---|
|
#18+
>а как тогда выбирается только кусок выборки??? http://www.sql.ru/faq/faq_topic.aspx?fid=171 покажи статистику и планы, offset из начала и конца, чем они отличаются ? может у тебя элементарно сортировка в памяти не помещается ... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.02.2005, 19:45 |
|
||
|
Как так быстро работает поиск в love.mail.ru?
|
|||
|---|---|---|---|
|
#18+
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 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.02.2005, 20:40 |
|
||
|
Как так быстро работает поиск в love.mail.ru?
|
|||
|---|---|---|---|
|
#18+
Сорри Это у меня один огромный индекс по всем поисковым полям остался... рабочий вариант - индекс по (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 запись) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.02.2005, 21:20 |
|
||
|
Как так быстро работает поиск в love.mail.ru?
|
|||
|---|---|---|---|
|
#18+
ну вот что у меня на 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. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.02.2005, 02:11 |
|
||
|
Как так быстро работает поиск в love.mail.ru?
|
|||
|---|---|---|---|
|
#18+
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. Код: 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. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.02.2005, 12:49 |
|
||
|
Как так быстро работает поиск в love.mail.ru?
|
|||
|---|---|---|---|
|
#18+
Что вы страдаете, говорю же - агрегация рулит. По циске у меня например так информация храница. В raw данных - к 7 млн записей подбираетца, в агрегированной - 1.3 млн. Также засчет того, что размер записей в агрегированной таблице на порядок меньше - ссчитается трафик за любой период практически мгновенно. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.02.2005, 15:03 |
|
||
|
Как так быстро работает поиск в love.mail.ru?
|
|||
|---|---|---|---|
|
#18+
2 Denis A. Мое сообщение относится не к тому, как быстро узнать кол-во результатов поиска, а ко второму вопросу, затронутому автором, как быстрее получить несколько строк из упорядоченного набора результатов поиска с большим отступом (offset). Да, это также обсуждалось в теме limit - offset / PostgreSQL. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.02.2005, 09:25 |
|
||
|
|

start [/forum/topic.php?fid=32&fpage=158&tid=1546044]: |
0ms |
get settings: |
8ms |
get forum list: |
22ms |
check forum access: |
2ms |
check topic access: |
2ms |
track hit: |
28ms |
get topic data: |
9ms |
get forum data: |
2ms |
get page messages: |
97ms |
get tp. blocked users: |
1ms |
| others: | 238ms |
| total: | 409ms |

| 0 / 0 |
