"У меня не работает!" "Сделай так" "У меня не работает, помогите!" "Да сделай же так. И скажи, что у тебя там" "У меня не работает"

Flight.unscope(:order).visible_only.explain EXPLAIN for: SELECT "flights".* FROM "flights" WHERE ("flights"."invisible" != $1) [["invisible", "t"]] QUERY PLAN -------------------------------------------------------------- Seq Scan on flights (cost=0.00..297.97 rows=2887 width=132) Filter: (NOT invisible) (2 rows) и

Flight.visible_only.explain EXPLAIN for: SELECT "flights".* FROM "flights" WHERE ("flights"."invisible" != $1) ORDER BY "flights"."departure_time" DESC [["invisible", "t"]] QUERY PLAN -------------------------------------------------------------------- Sort (cost=463.91..471.12 rows=2887 width=132) Sort Key: departure_time DESC -> Seq Scan on flights (cost=0.00..297.97 rows=2887 width=132) Filter: (NOT invisible) (4 rows)

а индекс где тут?)

как часто будут такие запросы выполняться?

а то мб навесить частичный составной индекс по invisible='t', 'departure_time'?

Flight.where(origin_id: 103).explain Sort (cost=456.93..463.16 rows=2494 width=132) Sort Key: departure_time DESC -> Seq Scan on flights (cost=0.00..316.21 rows=2494 width=132) Filter: (origin_id = 103) (4 rows)

как часто будут такие запросы выполняться?

идею понял, попробую

вообще часто

Пишет что у тебя всего 2500 строк

Пишет что у тебя всего 2500 строк

это те которые попали в коллекцию

Лол, хочешь добавлю тебе проблем?

Может настало время для эластики?

да ладно, рано еще эластик, как по мне

сперва индексы надо научиться использовать и работать с ними

Релтсовый explain пишет какие индексы юзались?

да

Я тогда в его explain не вижу юзания индексов.

сдается мне что в сортировке индекс используется никак

ну в схеме add_index "flights", ["arrival_time"], name: "index_flights_on_arrival_time", using: :btree add_index "flights", ["available"], name: "index_flights_on_available", using: :btree add_index "flights", ["capacity_basic_volume"], name: "index_flights_on_capacity_basic_volume", using: :btree add_index "flights", ["capacity_basic_weight"], name: "index_flights_on_capacity_basic_weight", using: :btree add_index "flights", ["capacity_estimated_volume"], name: "index_flights_on_capacity_estimated_volume", using: :btree add_index "flights", ["capacity_estimated_weight"], name: "index_flights_on_capacity_estimated_weight", using: :btree add_index "flights", ["departure_time"], name: "index_flights_on_departure_time", using: :btree add_index "flights", ["destination_id"], name: "index_flights_on_destination_id", using: :btree add_index "flights", ["origin_id", "airline", "flight_number", "departure_time"], name: "index_departure", unique: true, using: :btree add_index "flights", ["origin_id"], name: "index_flights_on_origin_id", using: :btree add_index "flights", ["slug"], name: "index_flights_on_slug", unique: true, using: :btree add_index "flights", ["invisible"], name: "index_flights_on_invisible", using: :btree

А в базе они действительно есть?

да, в базе тоже 12 индексов

сдается мне что в сортировке индекс используется никак

ну тут никак, но никто не мешает добавить индекс, который бы использовался

ээээ, ну.... эээ... вообще если индекс не используется то его лучше не добавлять, например для поля created_at

не, я о том, что индекс по departure_time desc или по departure_time desc + invisible='t'

ээээ, ну.... эээ... вообще если индекс не используется то его лучше не добавлять, например для поля created_at

так у меня и нет на него индекса

так у меня и нет на него индекса

а может у тебя только локально тормозит?

нет

на локале я этого почти не ощущаю, а на проде стазу видно, там записей намного больше

ребята, ковырялись, но так ничего сделать и не смоги, в итоге повесили задачу на меня((

СОЗДАТЬ ИНДЕКС имя_индекса ДЛЯ flights (departure_time УБЫВ, invisible) ГДЕ invisible=ИСТИНА

СОЗДАТЬ ИНДЕКС имя_индекса ДЛЯ flights (departure_time УБЫВ, invisible) ГДЕ invisible=ИСТИНА

да я уже делаю

да я код на 1с написал - и я не стесняюсь!)

но в 1с я не видел индексы, btw

ну вообще да, больно

Index Scan using index_visits_on_created_at on visits Index Scan using index_visits_on_created_at on visits

не поможет индекс

а эластика поможет?

а какой индекс именно?

не поможет индекс

а VACUUM не поможет тоже?

https://telegram.me/pgsql

а эластика поможет?

а чем может эластик помочь?

а чем может эластик помочь?

Он вроде быстрее чем база работает, разве нет?

для поиска, а не для сортировки, во первых

во вторых, эластик использует субд

Пускают джунов в сложный прект

А потом за голову хватаются

Пускают джунов в сложный прект

пускай, только следи :)

Пускают джунов в сложный прект

Обычно это выглядит так: "Ребята я знаю как сэкономить деньги"

"джун похапэ 30к гогого"

эластик субд только для индексации использует

эластик субд только для индексации использует

а эластик что-то еще делает?

искать умеет

сортировать тоже умеет

ребята, ковырялись, но так ничего сделать и не смоги, в итоге повесили задачу на меня((

Ребята мудаки? Сколько записей в таблице? Нагрузка какая?

по индексам?

смотря какой мапинг будет

В эластике можно обратный поиск юзать

во, индекс заработал) хуево, но заработал)

сортировать тоже умеет

я не думаю что он сможет нормально сортировать да и размеры индексов по полю с датой будут огого какие

Короче эластик можно юзать, но задрачмваться надо

ну как минимум нагрузку на бд снимет

Проблемы с костом?

Сделай вакуум и посмотри

Сделай вакуум и посмотри

окей

ERROR: S client not available

То есть сравни explain

записей то нифига нет

почему так медленно?

может стоит нормализовать таблицу чутка?

EXPLAIN (ANALYZE,BUFFERS)

Попробуй так

Вообще надо смотреть запросы через psql

add_index "flights", ["invisible"], name: "index_flights_on_invisible", unique: true, using: :btree

ну в схеме add_index "flights", ["arrival_time"], name: "index_flights_on_arrival_time", using: :btree add_index "flights", ["available"], name: "index_flights_on_available", using: :btree add_index "flights", ["capacity_basic_volume"], name: "index_flights_on_capacity_basic_volume", using: :btree add_index "flights", ["capacity_basic_weight"], name: "index_flights_on_capacity_basic_weight", using: :btree add_index "flights", ["capacity_estimated_volume"], name: "index_flights_on_capacity_estimated_volume", using: :btree add_index "flights", ["capacity_estimated_weight"], name: "index_flights_on_capacity_estimated_weight", using: :btree add_index "flights", ["departure_time"], name: "index_flights_on_departure_time", using: :btree add_index "flights", ["destination_id"], name: "index_flights_on_destination_id", using: :btree add_index "flights", ["origin_id", "airline", "flight_number", "departure_time"], name: "index_departure", unique: true, using: :btree add_index "flights", ["origin_id"], name: "index_flights_on_origin_id", using: :btree add_index "flights", ["slug"], name: "index_flights_on_slug", unique: true, using: :btree add_index "flights", ["invisible"], name: "index_flights_on_invisible", using: :btree

мрак

что это за индекс?

зачем invisible делать unique?

https://m.habrahabr.ru/post/203320/

Неплохая серия статей

ну как минимум нагрузку на бд снимет

это зависит у тебя система может остановится если ты пишешь в основную базу а эластик параллельно индексы строит пстроение индеков тяжелая задача для эластика все может встать колом

если делать переиндексацию то да, очень долго

не переиндексацию

ну к примеру чистный инсерт 1мс инстерт с эластиком может быть 200

20 инсертов в минуту на 1t.nano не заметно, 200 инсертов - все падает

закидывать это в sidekiq, использую групировку

да речеь не в том как это потимизировать а в том что решая одну проблему - создаешь другую

и это не снимет нагрузку как минимум, некуда не девается нагрузку

она просто перераспределяется

база плохо масштабируется, разве это плохо что ты снимешь с нее часть нагрузки?

закидывать это в sidekiq, использую групировку

ну и при инсертах подразумевается что инсерт атомарный, что данные доступны для работы, а в сайдике 2м задач висит - плохая идея

база плохо масштабируется, разве это плохо что ты снимешь с нее часть нагрузки?

база в некоторых случаях нормально масщтабируется

база плохо масштабируется, разве это плохо что ты снимешь с нее часть нагрузки?

по крайней меред по датам можно шардить, но это тоже тот еще геморрой

Шард это когда неправильно выбранный ключ и у тебя многие дни геммороя.

??

кароче по датам лучше вообще не сортировать :)

база в некоторых случаях нормально масщтабируется

Безусловно, но это самый сложный кусок приложения для масштабирования.

кароче по датам лучше вообще не сортировать :)

У него бизнеслогика к чертям полетит если он не будет так сортировать.