ли использовать другой способ более подходящий для юзкейса?
Юзкейс: использую mysql 8.0 (linux ubuntu 22.04). В схеме хранятся датасеты разных поставщиков - 20+ таблиц. При обновлении датасета регулярно удаляю его из всех таблиц и импортирую новые данные из дампа. На основе базы работает API.
Одна из проблемых таблиц - stop_times. Из-за большого количества данных (более 2000 уникальных feed_id - датасетов), ее размер превышает 150-200 гб - это около 550 млн записей.
Некоторые api запросы, обращающиеся к таблице stop_times для определенного feed_id работают более 10 сек.
Пытались решить проблему с помощью партиций по feed_id, разделили таблицу на 2000+ партиций (размер партиций отличается, тк. некоторые датасеты могут занимать 10% всего размера таблицы):
ALTER TABLE stop_times
PARTITION BY LIST (feed_id) (
PARTITION p582 VALUES IN (582),
PARTITION p2074 VALUES IN (2074),
PARTITION p2427 VALUES IN (2427)
);
Вот DDL таблицы stop_times:
create table if not exists mars_api.stop_times
(
id bigint auto_increment,
feed_id int not null,
feed_group_id int null,
trip_id bigint null,
trip_id_external varchar(255) null,
arrival_time varchar(255) null,
departure_time varchar(255) null,
stop_id bigint null,
stop_id_external varchar(255) null,
stop_sequence int null,
stop_headsign varchar(255) null,
pickup_type int null,
drop_off_type int null,
continuous_pickup int null,
continuous_drop_off int null,
shape_dist_traveled double null,
timepoint int null,
time_zone varchar(255) null,
primary key (id, feed_id)
);
create index IDX_feed_id
on mars_api.stop_times (feed_id);
create index IDX_stop_times_departure_time
on mars_api.stop_times (departure_time);
create index IDX_stop_times_stop_id
on mars_api.stop_times (stop_id);
create index IDX_stop_times_stop_id_feed_id
on mars_api.stop_times (stop_id, feed_id);
create index IDX_stop_times_trip_id_index
on mars_api.stop_times (trip_id);
Explain смотрите, что происходит. С учетом такого неравномерного распределения данных, чтение даже одной партиции это 15-20 Гб на чтение, что уже может упереться в IO, особенно при конкуренции
Обсуждают сегодня