|
|
|
Time series база данных, медленные запросы
|
|||
|---|---|---|---|
|
#18+
Всем привет. Я тут новенький, но перед тем как писать пользовался поиском и ничего похожего на мою проблему не нашел. Есть 2 таблицы users и users_ratings, первая хранит ник и id юзера, во второй таблице хранятся рейтинги пользователя с временной меткой. Пример с тестовыми данными можно скачать тут Количество рейтингов может увеличиться со временем. Тестовый запрос выбирает 100 пользователей с сортировкой по rating1, у которых, rating2 больше 1000 Код: plsql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. Сделал UNIQUE ключик в users_ratings по полям (user_id,rating1,rating2,created_date) именно в таком порядке, ключик используется, но на реальной базе, где users содержит более 70к строк, а users_ratings уже больше 185к строк, запрос стал выполняться за 700мс, что уже недопустимо. Данные по рейтингам могут добавляться в users_ratings очень часто. Т.е. если я, допутим, хочу получить 10 самых крутых по rating1 юзеров, можно результат запроса и в memcache закинуть, но обновлять после каждой записи в табилцу users_ratings для поддержания актуальности. Взываю к помощи, может быть не ту СУБД выбрал, может со структурой ошибся? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.09.2015, 20:44:16 |
|
||
|
Time series база данных, медленные запросы
|
|||
|---|---|---|---|
|
#18+
fakofskyВсем привет. Я тут новенький, но перед тем как писать пользовался поиском и ничего похожего на мою проблему не нашел. Есть 2 таблицы users и users_ratings, первая хранит ник и id юзера, во второй таблице хранятся рейтинги пользователя с временной меткой. Пример с тестовыми данными можно скачать тут Количество рейтингов может увеличиться со временем. Тестовый запрос выбирает 100 пользователей с сортировкой по rating1, у которых, rating2 больше 1000 Код: plsql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. Сделал UNIQUE ключик в users_ratings по полям (user_id,rating1,rating2,created_date) именно в таком порядке, ключик используется, но на реальной базе, где users содержит более 70к строк, а users_ratings уже больше 185к строк, запрос стал выполняться за 700мс, что уже недопустимо. ? У тебя неверные оценки допустимости. Это хорошее время для такого запроса. Быстрее не получится -- запрос не оптимизируем в принципе, у него нет даже поводов для этого. fakofskyДанные по рейтингам могут добавляться в users_ratings очень часто. Т.е. если я, допутим, хочу получить 10 самых крутых по rating1 юзеров, можно результат запроса и в memcache закинуть, но обновлять после каждой записи в табилцу users_ratings для поддержания актуальности. Взываю к помощи, может быть не ту СУБД выбрал, может со структурой ошибся? Ошибся ты вообще всем. Смена СУБД не поможет, структуры так же. На кой хрен кому нужны 100 (!!!) самых крутых пользователей ? Это список на получение нобелевской премии ? Тогда секунду-другую могут подождать, не развалятся. Или это на главной надо светить ? Тогда кому нужно 100 ? Запрос по своей сути имеет неопределённую актуальность, да и проверять его результат никто не будет и не сможет. Поэтому выполни его один раз в сутки, запихни в таблицу, и показывай весь день радостно за 200 милисекунд. В общем, предвычисляй этот рейтинг периодически и показывай предвычисленный до следующего перещёта. А ещё лучше -- выводи просто случайные 100 пользователей, всё равно никто не проверит. :-) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.09.2015, 21:25:21 |
|
||
|
Time series база данных, медленные запросы
|
|||
|---|---|---|---|
|
#18+
fakofsky, План запроса покажите. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.09.2015, 22:36:56 |
|
||
|
Time series база данных, медленные запросы
|
|||
|---|---|---|---|
|
#18+
miksoft, если я правильно понял вот это ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.09.2015, 23:45:48 |
|
||
|
Time series база данных, медленные запросы
|
|||
|---|---|---|---|
|
#18+
MasterZivА ещё лучше -- выводи просто случайные 100 пользователей, всё равно никто не проверит. :-) Ну так то дело не пойдет, точно. Суть в том, что отображается список ссылок на страницы юзеров, на страницах юзеров куча инфы из которой считаются рейтинги и сами рейтинги, а точнее все это по сессиям. Последняя сессия будет соответствовать как раз той записи, которая выберется из users_ratings запросом выше. Так вот при переходе из списка, на странице рейтинг ведь не должен отличаться, а в случае кеширования, может возникнуть когнитивный! Админ советует сделать рейд из 2 SSD по 300 ГБ и туда положить базу, мол на вырост хватит. Но я вижу именно экспоненциальный рост времени запроса, от количества записей. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.09.2015, 23:58:02 |
|
||
|
Time series база данных, медленные запросы
|
|||
|---|---|---|---|
|
#18+
... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.09.2015, 00:38:40 |
|
||
|
Time series база данных, медленные запросы
|
|||
|---|---|---|---|
|
#18+
А что это поле user_id такое огромное? Покажите DDL таблицы целиком. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.09.2015, 00:41:04 |
|
||
|
Time series база данных, медленные запросы
|
|||
|---|---|---|---|
|
#18+
miksoftА что это поле user_id такое огромное? Покажите DDL таблицы целиком. Код: plsql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.09.2015, 00:51:04 |
|
||
|
Time series база данных, медленные запросы
|
|||
|---|---|---|---|
|
#18+
Код: plsql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. Если быть точным, и ключ в предыдущем сообщении не правильный, rating1 тоже в ключе. Не нашел как отредактировать сообщение! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.09.2015, 00:54:36 |
|
||
|
Time series база данных, медленные запросы
|
|||
|---|---|---|---|
|
#18+
fakofskyMasterZivА ещё лучше -- выводи просто случайные 100 пользователей, всё равно никто не проверит. :-) Ну так то дело не пойдет, точно. Суть в том, что отображается список ссылок на страницы юзеров, на страницах юзеров куча инфы из которой считаются рейтинги и сами рейтинги, а точнее все это по сессиям. Последняя сессия будет соответствовать как раз той записи, которая выберется из users_ratings запросом выше. Так вот при переходе из списка, на странице рейтинг ведь не должен отличаться, а в случае кеширования, может возникнуть когнитивный! Админ советует сделать рейд из 2 SSD по 300 ГБ и туда положить базу, мол на вырост хватит. Но я вижу именно экспоненциальный рост времени запроса, от количества записей. Не, не хватит. Потому что рост квадратичный от числа оценок. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.09.2015, 01:10:21 |
|
||
|
Time series база данных, медленные запросы
|
|||
|---|---|---|---|
|
#18+
MasterZivПотому что рост квадратичный от числа оценок.При наличии индексов вроде N*log(N) получется. Что, впрочем, тоже хуже, чем линейно. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.09.2015, 01:26:20 |
|
||
|
Time series база данных, медленные запросы
|
|||
|---|---|---|---|
|
#18+
Можно попробовать зайти с другой стороны: Код: sql 1. 2. 3. 4. Понадобится индекс (user_id,created_date) на таблице users_ratings. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.09.2015, 01:32:28 |
|
||
|
Time series база данных, медленные запросы
|
|||
|---|---|---|---|
|
#18+
fakofskyАдмин советует сделать рейд из 2 SSD по 300 ГБ и туда положить базу, мол на вырост хватит.Если идти таким путем, то я бы предложил tmpfs в памяти сделать. А то и всю базу в оперативку положить. И, уж как минимум, дать достаточно памяти для кэша InnoDB. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.09.2015, 01:34:32 |
|
||
|
Time series база данных, медленные запросы
|
|||
|---|---|---|---|
|
#18+
fakofsky Код: plsql 1. Это зачем такой ужас? Почему не использовать специальные типы? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.09.2015, 01:35:37 |
|
||
|
Time series база данных, медленные запросы
|
|||
|---|---|---|---|
|
#18+
fakofsky Код: plsql 1. А что на InnoDB не переведете? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.09.2015, 01:37:47 |
|
||
|
Time series база данных, медленные запросы
|
|||
|---|---|---|---|
|
#18+
miksoftMasterZivПотому что рост квадратичный от числа оценок.При наличии индексов вроде N*log(N) получется. Что, впрочем, тоже хуже, чем линейно. Несильно хуже, но где там будут индексы ? Для поиска по датам ? Ну не знаю... На самом деле может можно запрос как-то и переписать, но нужно постичь эту мудрёную систему рейтингов, что мне лично -- лень. Но линейный рост -- это УЖЕ ПЛОХО. надо логарифмический, чтобы это работало. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.09.2015, 11:17:10 |
|
||
|
Time series база данных, медленные запросы
|
|||
|---|---|---|---|
|
#18+
miksoftfakofsky Код: plsql 1. А что на InnoDB не переведете? Очень правильно обозначаешь приоритеты дальнейшего развития этого дела. И с типом "даты" тоже. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.09.2015, 11:18:48 |
|
||
|
Time series база данных, медленные запросы
|
|||
|---|---|---|---|
|
#18+
MasterZiv, Объясните, почему InnoDB? я знаю что MyISAM имеет смысл использовать, когда преобладают операции insert или select, но крайне мало delete или update. Может быть я чего-то не понимаю, но select и insert у меня действительно больше. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.09.2015, 12:18:15 |
|
||
|
Time series база данных, медленные запросы
|
|||
|---|---|---|---|
|
#18+
[quot fakofsky]MasterZiv, Объясните, почему InnoDB? Потому что MyISAM - это полное говно. MySql становится СУБД только когда начинаешь использовать Innodb. конкретно для тебя инно даст возможность кэшировать данные , чего MyISAM не умеет в принципе. я знаю что MyISAM имеет смысл использовать, когда преобладают операции insert или select, но крайне мало delete или update. Может быть я чего-то не понимаю, но select и insert у меня действительно больше. ты знаешь неправильно. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.09.2015, 12:39:16 |
|
||
|
Time series база данных, медленные запросы
|
|||
|---|---|---|---|
|
#18+
Всем спасибо. Решением стало разделение данных на 2 части, есть таблица users_ratings, в ней последние рейтинги пользователей, т.е. по 1 записи на юзера. И есть таблица users_ratings_history, вот тут и хранятся все изменения. Теперь чтобы получить топ, исползуем обычный order by, без всяких подзапросов. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.09.2015, 12:08:53 |
|
||
|
|

start [/forum/topic.php?fid=47&msg=39043305&tid=1832747]: |
0ms |
get settings: |
8ms |
get forum list: |
18ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
47ms |
get topic data: |
10ms |
get forum data: |
2ms |
get page messages: |
55ms |
get tp. blocked users: |
1ms |
| others: | 207ms |
| total: | 354ms |

| 0 / 0 |
