Вот, кстати че я делал: http://micro.mixupload.com/style/soulful-dnb-2019?sqldebug=1 Этот сайтик работает на репликах

Question

Вот, кстати че я делал: http://micro.mixupload.com/style/soulful-dnb-2019?sqldebug=1 Этот сайтик работает на репликах

в сша, европе, москве и сингапуре. Виртуалочки полудохлые с 2гб памяти его крутят. Поэтому пришлось сделать партицирование по году и стилю на табличку catalog_tracks_styleparts. У меня была задача отдавать все страницы со скоростью <50мс

Оцените, кстати, я по ходу впервые сделал правильную постраничную развертку с подсказками по id - т.е. работает без OFFSET

#backend #devops #pgsql #programming #russian

0

29.12.2019

1 ответов

6 просмотров

Yaroslav Schekin · Accepted Answer

> Виртуалочки полудохлые с 2гб памяти его крутят. А данных-то сколько всего (на одной такой "реплике")? > Поэтому пришлось сделать партицирование по году и стилю на табличку catalog_tracks_styleparts. Или Вам просто захотелось его сделать, кто знает... ;) Я к тому, что тут сходу выгоды не видно (может быть, она есть — просто информации мало). > Оцените, кстати, Я пока вид запросов оценил, к примеру: SELECT t."id", t."title", t."srv", t."url", t."artist", t."album", t."picture", t."file_track", t."lc", t."post", t."adddate", t."sizebyte", coalesce((SELECT json_agg(json_build_object(urlname,name)) FROM catalog_styleparts WHERE ARRAY [id] <@ string_to_array('0' || t.joinset_styleparts, ',')::int[] ),'[]' ) AS styles FROM "catalog_tracks" AS t LEFT JOIN catalog_track_styleparts AS sp ON t.id = sp.tid AND sp.spid = 17 WHERE t."show" = 1 AND t.publish = 1 AND t.lock_holder = 0 AND sp.tid IS NOT NULL AND add_date >= '2019-12-01' AND add_date < '2019-12-22T12:58:51+03:00' ORDER BY sp.add_date DESC OFFSET 0 LIMIT 100 И это, мягко говоря, нехорошо (нет параметризации (!); LEFT JOIN бесполезен (это, по факту, INNER); не все ссылки на поля в запросе qualified (add_date — кстати, одна из констант с time zone, другая без); возможно, запрос под coalesce лишний (ну или просто слишком "замороченный" — но я не вчитывался); сортировка в запросе недетерминированная). И это только то, что видно на первый взгляд. И далее, любопытно, сколько данных в среднем в таких выборках без LIMIT — может, тут и индексы для сортировки никакие не нужны? И вот ещё о чём можно подумать — сколько одновременных активных клиентов ожидается? Дело в том, что если это "сотни"... партиционирование использует много locks — можно "наколоться".

172 похожих чатов

Вот, кстати че я делал: http://micro.mixupload.com/style/soulful-dnb-2019?sqldebug=1 Этот сайтик работает на репликах

1 ответов

Похожие вопросы