(PHP) скорость работы db при больших таблицах - логика приложения

twistfire
Дата: 26.07.2006 10:07:00
Ранее все время работали с PostgreSQL - привыкли.
Не было необходимости держать больших таблиц - до нескольких дясятков тысяч записей. - все работало на ура - ыбстро и качественно.

Сегодня встал вопрос о написании приложения для коммерции - в таблице около миллиона записей.
При запросах - для выборки количества (SELECT cOUNT(*) WHERE id []) - наблуюдается очень большой тормоз - формируется страница до 10 секунд.

Такой порядок вещей не усраивает естн-но...
Причем вроде и постгре настроен верно, и логика приложения - неплохая.
Такие запросы формируются для постраничного вывода данных.

Как можно изменить логику приложения/запросы для того чтобы работать быстрее?

Ведь я так понимаю так на всех БД получается, когда таблицы большие - и выборки по условиям.
4m@t!c
Дата: 26.07.2006 10:27:28
Делайте структуру с избыточными данными. Да, это не реляционно, но при правильной логике и реализации избыточность позволит увеличить скорость работы приложения.
Например, там где вы считает общее кол-во строк. То есть смысл сделать отдельное поле, которое хранит это общее кол-во строк. Тогда вам не нужно будет каждый раз пересчитывать кол-во записей. Понятно, что при такой организации БД вы должны увеличивать число общего кол-ва строк на величину вновь добавленных строк в таблицу.
----------------------------------------
Артисты не приехали, приехали цыгане
Anjey aka PM
Дата: 26.07.2006 11:57:41
агрегаты COUNT в постгре, а до версии 8.1 также MAX и MIN не использовали данные индексов, а как и прочие агрегаты работыли путем полного (или частичного при наличии условия WHERE которое использует индекс) сканирования таблицы.

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

COUNT же (для постгре, что обещают поправить в следующих версиях) использовать было крайне нежелательно, а нужно было заменять на хранение избыточных данных.
twistfire
Дата: 26.07.2006 12:30:31
Хранение избыточных данных - это хорошо, но все дело в том, что при классификации (скажем товаров) используется динамический запрос - с большим количеством парамтеров - и невозможно учитывать все из них - тут тупо используется COUNT(*).

Я имел в виду - может стоит под каждый вид продукции скажем - огранизовывать отдельную таблицу?

А как с этим в Оракл? MySQL? тоже тормоза?
4m@t!c
Дата: 26.07.2006 12:42:14
Я пользую MySQL. Я пользую избыточность, потому что размеры таблиц от 6 000 000 и до 120 000 000. count c этим быстро не справляется. поэтому пользую избыточность. Не всегда нужно разделять таблицы на несколько. Добавляйте таблицы, в которых будете хранить избыточные значения и на основании которых можно решить проблемы выборки с использованием фильтров. Такой подход позволит сохранить реляционность основных данных.
----------------------------------------
Артисты не приехали, приехали цыгане