LINUX.ORG.RU

MySQL выборка больших данных

 ,


0

2

Добрый день, имеется следующая проблема. В базе данных хранятся полигоны для отрисовки в json-формате. Сама структура таблицы очень простая: id(int) coords - с-но координаты(MEDIUMTEXT). Размер может быть в районе 8-10 Мб. section_id(int) - привязка к сущностям CMS, к делу не относится

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

SELECT coords from polygons WHERE section_id=23423423
может выполнятся 5-7 секунд, что недопустимо. Понятно, что на сайте используется кеширование, но такое время загрузки неприемлемо.

Что пробовал сделать: добавил еще одну колонку: coords_min, где хранится урезанная версия полигонов - условно говоря, я прошелся по всем записям и выкинул, допустим каждую вторую точку в полигонах и выбираю вместо полных координат урезанные. Помогло, но не сказать, что сильно.

Отсюда вопрос, каким образом я еще могу оптимизировать это дело?

Возможно есть смысл упаковывать данные, но не будет ли распаковка в итоге занимать больше времени, чем простой SQL-запрос?

Буду благодарен за любые советы

PS ламерский вопрос - если в таблице осталась оригинальная колонка с полными координатами, но она не выбирается, может ли она влиять на скорость запроса и ее лучше удалить, или все равно?

Давай сюда DDL. И в каком формате координаты?

Anoxemian ★★★★★ ()

можно посмотреть на массивы и базы которые в них умеют.

На вскидку Postrges и MonetDB. Последний вообще column-oriented и очень активно кеширует. Оба SQL и переезд с MySQL не должен вызывать чрезмерных сложностей

MKuznetsov ★★★★★ ()
Ответ на: комментарий от MKuznetsov

Ответ неправильный и в части MonetDB вредный. А в части PostgreSQL бесполезный, так как если из-за каждой пустячной проблемы менять СУБД , то никакой работы не получится.

Вопрос задан неправильно. У автора маленькая база. Большая -это если результат запроса с трудом влезает в память, а у него хоть всю базу можно поместить в память.

Partisan ★★★ ()

Индекс то есть по section_id?

Elyas ★★★★★ ()

ОП нужно сделать индекс по sect_id (у него в таблице вообще нет индексов), и это все, что нужно.

goingUp ★★★★★ ()
Ответ на: комментарий от Elyas

Спасибо большое, что-то я действительно натупил...сильно

gwyllum ()
Ответ на: комментарий от MKuznetsov

Так а какая разница, если автор по полю с координатами не ищет. А если бы искал, то есть специальный тип данных для этого - полигон. Пространственные типы данных есть во всех популярных sql СУБД, и переезжать, чтобы ими пользоваться, не нужно.

nguseff ()

Размер может быть в районе 8-10 Мб

Почему вообще не хранить в файлах?

kiotoze ★★★★ ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.