Добрый день!
Задача такова. Имеется банковский портал — MVC. На одной из страниц есть таблица, в которой должны показываться платежи.
Платежей очень много ~20-25 млн.записей.
На морде должно показываться последние 100 платежей. С этим вроде несложно разорбраться — берем делаем кластерный индекс в таблице по убыванию даты платежа и берем TOP 100.
Но вот на форме должна быть stable sort: т.е. пользователь может отсортировать сначала по одному параметру, потом внутри это списка по другому параметру и т.д.

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

Здравствуйте, Аноним, Вы писали:

А>Добрый день!
А>Задача такова. Имеется банковский портал — MVC. На одной из страниц есть таблица, в которой должны показываться платежи.
А>Платежей очень много ~20-25 млн.записей.
А>На морде должно показываться последние 100 платежей. С этим вроде несложно разорбраться — берем делаем кластерный индекс в таблице по убыванию даты платежа и берем TOP 100.
А>Но вот на форме должна быть stable sort: т.е. пользователь может отсортировать сначала по одному параметру, потом внутри это списка по другому параметру и т.д.

А>Как такое организовать, чтобы система давала разумное время отклика?
Слегка обмануть пользователей: отбор записей в ворксет делать с гарантированными временными и объемными ограничениями (все тем же кластерным индексом и заставляя пользователя явно и отдельно указывать интересующий его период, как в 1С и большинстве других систем того же плана), а последующие манипуляции производить с отобранным ворксетом автономно. Хотя, я не знаю какая в точности у вас задача, привел типовое решение, которое вам вполне может и не подходить.

Здравствуйте, Аноним, Вы писали:

А>Добрый день!
А>Задача такова. Имеется банковский портал — MVC. На одной из страниц есть таблица, в которой должны показываться платежи.
А>Платежей очень много ~20-25 млн.записей.
А>На морде должно показываться последние 100 платежей. С этим вроде несложно разорбраться — берем делаем кластерный индекс в таблице по убыванию даты платежа и берем TOP 100.
А>Но вот на форме должна быть stable sort: т.е. пользователь может отсортировать сначала по одному параметру, потом внутри это списка по другому параметру и т.д.

А>Как такое организовать, чтобы система давала разумное время отклика?

Не понял, вам надо сначала сортировать, а потом отображать 100 записей или сортировать эту сотню.
Если второе, то элементарно: выбираете 100 в память, а потом сортируете в памяти или даже на клиенте.
Если первое, то в общем случае нерешаемо.

Здравствуйте, gandjustas, Вы писали:

G>Здравствуйте, Аноним, Вы писали:

А>>Добрый день!
А>>Задача такова. Имеется банковский портал — MVC. На одной из страниц есть таблица, в которой должны показываться платежи.
А>>Платежей очень много ~20-25 млн.записей.
А>>На морде должно показываться последние 100 платежей. С этим вроде несложно разорбраться — берем делаем кластерный индекс в таблице по убыванию даты платежа и берем TOP 100.
А>>Но вот на форме должна быть stable sort: т.е. пользователь может отсортировать сначала по одному параметру, потом внутри это списка по другому параметру и т.д.

А>>Как такое организовать, чтобы система давала разумное время отклика?

G>Не понял, вам надо сначала сортировать, а потом отображать 100 записей или сортировать эту сотню.
G>Если второе, то элементарно: выбираете 100 в память, а потом сортируете в памяти или даже на клиенте.
G>Если первое, то в общем случае нерешаемо.

У пользователя есть 5 столбцов в таблице.
Он кликает на столбце Дата — надо отсортировать платежи по дате.
Он кликает на столбце страна — надо отсортировать платежи сначала по дате, а потом по стране
Он кликает на столбце город — надо отсортировать платежи сначала по дате, потом по городу, а потом по стране

Он удаляет сортировку со столбца страна — надо отсортировать платежи сначала по дате, а потом по городу

Здравствуйте, rtbsd, Вы писали:

R>Здравствуйте, Аноним, Вы писали:

А>>Добрый день!
А>>Задача такова. Имеется банковский портал — MVC. На одной из страниц есть таблица, в которой должны показываться платежи.
А>>Платежей очень много ~20-25 млн.записей.
А>>На морде должно показываться последние 100 платежей. С этим вроде несложно разорбраться — берем делаем кластерный индекс в таблице по убыванию даты платежа и берем TOP 100.
А>>Но вот на форме должна быть stable sort: т.е. пользователь может отсортировать сначала по одному параметру, потом внутри это списка по другому параметру и т.д.

А>>Как такое организовать, чтобы система давала разумное время отклика?
R>Слегка обмануть пользователей: отбор записей в ворксет делать с гарантированными временными и объемными ограничениями (все тем же кластерным индексом и заставляя пользователя явно и отдельно указывать интересующий его период, как в 1С и большинстве других систем того же плана), а последующие манипуляции производить с отобранным ворксетом автономно. Хотя, я не знаю какая в точности у вас задача, привел типовое решение, которое вам вполне может и не подходить.

задачу описал здесь

Автор:
Дата: 07.05.11

Здравствуйте, Аноним, Вы писали:

А>Здравствуйте, gandjustas, Вы писали:

G>>Здравствуйте, Аноним, Вы писали:

А>>>Добрый день!
А>>>Задача такова. Имеется банковский портал — MVC. На одной из страниц есть таблица, в которой должны показываться платежи.
А>>>Платежей очень много ~20-25 млн.записей.
А>>>На морде должно показываться последние 100 платежей. С этим вроде несложно разорбраться — берем делаем кластерный индекс в таблице по убыванию даты платежа и берем TOP 100.
А>>>Но вот на форме должна быть stable sort: т.е. пользователь может отсортировать сначала по одному параметру, потом внутри это списка по другому параметру и т.д.

А>>>Как такое организовать, чтобы система давала разумное время отклика?

G>>Не понял, вам надо сначала сортировать, а потом отображать 100 записей или сортировать эту сотню.
G>>Если второе, то элементарно: выбираете 100 в память, а потом сортируете в памяти или даже на клиенте.
G>>Если первое, то в общем случае нерешаемо.

А>У пользователя есть 5 столбцов в таблице.
А>Он кликает на столбце Дата — надо отсортировать платежи по дате.
А>Он кликает на столбце страна — надо отсортировать платежи сначала по дате, а потом по стране
А>Он кликает на столбце город — надо отсортировать платежи сначала по дате, потом по городу, а потом по стране

А>Он удаляет сортировку со столбца страна — надо отсортировать платежи сначала по дате, а потом по городу

Еще раз: сортируются все 25 млн записей, или только последние 100?

Здравствуйте, gandjustas, Вы писали:

G>Здравствуйте, Аноним, Вы писали:

А>>Здравствуйте, gandjustas, Вы писали:

G>>>Здравствуйте, Аноним, Вы писали:

А>>>>Добрый день!
А>>>>Задача такова. Имеется банковский портал — MVC. На одной из страниц есть таблица, в которой должны показываться платежи.
А>>>>Платежей очень много ~20-25 млн.записей.
А>>>>На морде должно показываться последние 100 платежей. С этим вроде несложно разорбраться — берем делаем кластерный индекс в таблице по убыванию даты платежа и берем TOP 100.
А>>>>Но вот на форме должна быть stable sort: т.е. пользователь может отсортировать сначала по одному параметру, потом внутри это списка по другому параметру и т.д.

А>>>>Как такое организовать, чтобы система давала разумное время отклика?

G>>>Не понял, вам надо сначала сортировать, а потом отображать 100 записей или сортировать эту сотню.
G>>>Если второе, то элементарно: выбираете 100 в память, а потом сортируете в памяти или даже на клиенте.
G>>>Если первое, то в общем случае нерешаемо.

А>>У пользователя есть 5 столбцов в таблице.
А>>Он кликает на столбце Дата — надо отсортировать платежи по дате.
А>>Он кликает на столбце страна — надо отсортировать платежи сначала по дате, а потом по стране
А>>Он кликает на столбце город — надо отсортировать платежи сначала по дате, потом по городу, а потом по стране

А>>Он удаляет сортировку со столбца страна — надо отсортировать платежи сначала по дате, а потом по городу

G>Еще раз: сортируются все 25 млн записей, или только последние 100?

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

Здравствуйте, Аноним, Вы писали:

А>Здравствуйте, gandjustas, Вы писали:

G>>Здравствуйте, Аноним, Вы писали:

А>>>Здравствуйте, gandjustas, Вы писали:

G>>>>Здравствуйте, Аноним, Вы писали:

А>>>>>Добрый день!
А>>>>>Задача такова. Имеется банковский портал — MVC. На одной из страниц есть таблица, в которой должны показываться платежи.
А>>>>>Платежей очень много ~20-25 млн.записей.
А>>>>>На морде должно показываться последние 100 платежей. С этим вроде несложно разорбраться — берем делаем кластерный индекс в таблице по убыванию даты платежа и берем TOP 100.
А>>>>>Но вот на форме должна быть stable sort: т.е. пользователь может отсортировать сначала по одному параметру, потом внутри это списка по другому параметру и т.д.

А>>>>>Как такое организовать, чтобы система давала разумное время отклика?

G>>>>Не понял, вам надо сначала сортировать, а потом отображать 100 записей или сортировать эту сотню.
G>>>>Если второе, то элементарно: выбираете 100 в память, а потом сортируете в памяти или даже на клиенте.
G>>>>Если первое, то в общем случае нерешаемо.

А>>>У пользователя есть 5 столбцов в таблице.
А>>>Он кликает на столбце Дата — надо отсортировать платежи по дате.
А>>>Он кликает на столбце страна — надо отсортировать платежи сначала по дате, а потом по стране
А>>>Он кликает на столбце город — надо отсортировать платежи сначала по дате, потом по городу, а потом по стране

А>>>Он удаляет сортировку со столбца страна — надо отсортировать платежи сначала по дате, а потом по городу

G>>Еще раз: сортируются все 25 млн записей, или только последние 100?

А>все 25 млн. т.к. юзер может нажать сортировать по любому параметру

Ну тогда в общем случае задача нерешаема. Разве что создавать дофига индексов и подсказывать каждый раз какой использовать.

Здравствуйте, Аноним, Вы писали:

А>Здравствуйте, gandjustas, Вы писали:

G>>Здравствуйте, Аноним, Вы писали:

А>>>Здравствуйте, gandjustas, Вы писали:

G>>>>Здравствуйте, Аноним, Вы писали:

А>>>>>Добрый день!
А>>>>>Задача такова. Имеется банковский портал — MVC. На одной из страниц есть таблица, в которой должны показываться платежи.
А>>>>>Платежей очень много ~20-25 млн.записей.
А>>>>>На морде должно показываться последние 100 платежей. С этим вроде несложно разорбраться — берем делаем кластерный индекс в таблице по убыванию даты платежа и берем TOP 100.
А>>>>>Но вот на форме должна быть stable sort: т.е. пользователь может отсортировать сначала по одному параметру, потом внутри это списка по другому параметру и т.д.

А>>>>>Как такое организовать, чтобы система давала разумное время отклика?

G>>>>Не понял, вам надо сначала сортировать, а потом отображать 100 записей или сортировать эту сотню.
G>>>>Если второе, то элементарно: выбираете 100 в память, а потом сортируете в памяти или даже на клиенте.
G>>>>Если первое, то в общем случае нерешаемо.

А>>>У пользователя есть 5 столбцов в таблице.
А>>>Он кликает на столбце Дата — надо отсортировать платежи по дате.
А>>>Он кликает на столбце страна — надо отсортировать платежи сначала по дате, а потом по стране
А>>>Он кликает на столбце город — надо отсортировать платежи сначала по дате, потом по городу, а потом по стране

А>>>Он удаляет сортировку со столбца страна — надо отсортировать платежи сначала по дате, а потом по городу

G>>Еще раз: сортируются все 25 млн записей, или только последние 100?

А>все 25 млн. т.к. юзер может нажать сортировать по любому параметру
Тогда, вероятно, либо надо убивать проблему железом (сверхпроизводительные сервера и ПО), либо переходить к (заранее предусмотренным разработчиком системы) предвычисленным выборкам и агрегатам (ETL+DWH и все такое). И разрабатывать требования к такой аналитике и регламенты ее актуализации.

G>>Еще раз: сортируются все 25 млн записей, или только последние 100?

А>все 25 млн. т.к. юзер может нажать сортировать по любому параметру

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

Типовой вариант, который вам все предлагают — загружать самые свежие 100 записей, и сортировать затем как угодно.

Это стоит дополнить фильтрацией — я не думаю что пользователь собирается сделать сортировку 25 млн записей по городу, и затем вручную листать до Рязани.
Достаньте требования по наиболее используемым критериям фильтрации, поддержите их на уровне БД. Опасайтесь при этом давать пользователю свободный конструктор запросов — вы должны точно знать под какие запросы оптимизируется БД. 1-5 типовых критериев, которые ложатся на индексы.

После этого, пользователь может задать фильтр, и
— под фильтр попадёт <=100 записей, и результаты последующей сортировки будут точны
— под фильтр попадёт >100 записей, и результаты последующей сортировки могут не быть точными. На UI имеет смысл сразу о такой ситуации предупредить, и предложить уточнить критерий поиска.

Здравствуйте, Аноним, Вы писали:

А>Добрый день!
А>Задача такова. Имеется банковский портал — MVC. На одной из страниц есть таблица, в которой должны показываться платежи.
А>Платежей очень много ~20-25 млн.записей.
А>На морде должно показываться последние 100 платежей. С этим вроде несложно разорбраться — берем делаем кластерный индекс в таблице по убыванию даты платежа и берем TOP 100.
А>Но вот на форме должна быть stable sort: т.е. пользователь может отсортировать сначала по одному параметру, потом внутри это списка по другому параметру и т.д.

А>Как такое организовать, чтобы система давала разумное время отклика?

Разумное это какое? Выбрать по индексу (некластерному) первые 100 записей из 25 млн любая субд на разумном железе может за разумное время, максимум придется поднять около ста страниц (это если юзер полный неудачник попался ), это копейки. Проблема начинается, когда первая сортировка идет по малоселективному полю, например максимальных значений сильно больше чем 100. Если такие поля есть, по ним надо сделать более селективные индексы с добавлением еще одного поля, либо запретить сортировку по ним, либо придумать эвристики, типа top 100 ... order by sex, birthday на таких объемах => top 100 ... where sex='M' order by birthday, с нормальной статистикой оптимизатор должен догадаться что лучше выбирать по порядку отсеевая женщин пока не наберем 100 человек.

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