Як створити базу даних для зберігання відсортованого списку?

Я хочу зберігати відсортований список всередині бази даних. Наступні операції хочу виконати ефективно.

1. Вставити (x) - Вставити запис x у таблицю
2. Видалити (x) - Видалити запис x з таблиці
3. До (x, n) - Повернення записів 'n' перед записом x у відсортованому списку.
4. Після (x, n) - Повернення записів 'n', що завершили запис x, у відсортованому списку.
5. Перший (n) - Повернення перших записів 'n' зі списку відсортованих.
6. Останнє (n) - Повернення останніх «n» записів із відсортованого списку.
7. Порівняйте (x, y) - Давши два записи x і y з таблиці, знайдіть, якщо x> y.

Простий метод, про який я міг би придумати, - це зберігати якийсь атрибут 'rank' у таблиці та запитувати шляхом сортування за цим атрибутом. Але в цьому методі вставлення / зміна запису з рангом стає дорогою операцією. Чи є кращий метод?

Зокрема, я хочу реалізувати таблицю за допомогою SimpleDB Amazon. Але загальна відповідь на реляційну базу даних також повинна бути корисною.

Оновлення профілю завантаження:

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

Якщо є 100 тис. Активних користувачів (супер оптимізм: P), то моя дуже приблизна оцінка за день

500k вибирає, 100k вставляє та видаляє, 500k оновлення

Я б очікував, що стіл виросте в цілому до 500 тис.

Я хочу оптимізувати оновлення, вставити та порівняти операції. Ранг елементів буде постійно змінюватися, і мені потрібно постійно оновлювати таблицю.

Якщо ранг не є абсолютно довільним, але натомість є похідним з якогось іншого властивості (наприклад, ім'я, рахунок гравця тощо), тоді добре погляньте на відповідь Джоела .

Якщо це довільне властивість даних, то , що має бути збережене в якості стовпця в таблиці рекордів. Якщо припустити, що SimpleDB Amazon схожий на типовий RDBMS, ви можете проіндексувати цей стовпець і швидко задовольнити всі ваші вищезазначені запити відповідною стратегією індексації. Це нормально для RDBMS.

Зважаючи на те, що ви очікуєте високої активності вставки та оновлення, а також відносно високої активності читання, рекомендую зробити наступне:

• Кластеризуйте таблицю за рангом, особливо якщо переважна більшість ваших запитів проти рангу. Якщо ні, або якщо вибір кластеризації недоступний у SimpleDB, просто створіть індекс з рангом як провідний стовпець. Це задовольнило б запити 3-6.
• Індекс на записі спочатку, а потім ранжування (або, у світі SQL Server, лише запис та INCLUDE-ing ранг, або просто запис, якщо ви кластеризовані на ранг), задовольнив би запит 7.
• Операції 1 і 2 можна оптимізувати, розставивши ваші дані належним чином (тобто встановивши FILLFACTORв SQL Server). Це особливо важливо, якщо ви кластерите за рангом.
• Коли ви вставляєте чи оновлюєте ранги, зберігайте якомога більше проміжку між номерами рангів, щоб мінімізувати таку можливість, що вам знадобиться перевпорядкувати існуючу запис для розміщення вставки чи оновлення. Наприклад, якщо ви класифікуєте свої записи за кроком 1000, ви залишаєте достатньо місця для приблизно половини стільки змін і вставок з мінімальними шансами, вам знадобиться перевпорядкувати запис, який безпосередньо не бере участь у цих змінах.
• Кожен вечір проводить повторне ранжування всіх записів, щоб скидати прогалини між ними.
• Ви можете налаштувати частоту масових перерейтингів, а також розмір розриву рангів, щоб вмістити очікувану кількість вставок або оновлень відносно кількості існуючих записів. Тож якщо у вас є записи в 100 тис. І очікуєте, що вставки та оновлення становитимуть 10% від цього, залиште достатньо місця для 10-кілограмових нових рангів та перейдіть на ночі.
• Переоцінка записів 500K - це дорога операція, але виконана один раз на день або тиждень у неробочий час має бути чудовою для такої бази даних. Таке масове переозброєння неробочих годин для підтримання прогалин у рейтингах - це те, що дозволяє заощадити багато рекордів для кожного оновлення чи вставки протягом нормальних і пікових годин.

Якщо ви очікуєте, що 100K + прочитає таблицю розміром 100 К +, я не рекомендую використовувати підхід зв'язаного списку. Він не підходить до таких розмірів.

Я, як правило, використовую описаний вами метод "рангу". Замість того, щоб поплутатися з оновленням рядків, коли елементи потрібно було впорядкувати, я часто мав змогу піти зі видалення всіх записів у списку та повторної вставки нових елементів у належному порядку. Цей метод чітко оптимізований для пошуку.

Альтернативним підходом було б моделювання записів як зв'язаного списку за допомогою рефлексивного стовпчика "попередник" на таблиці:

ID   setID   item       predecessor
---  ------  ------     ------------
1    1       Apple      null
2    1       Orange     1
3    2       Cucumber   null
4    1       Pear       2
5    1       Grape      4
6    2       Carrot     3

Ви можете легко отримати список і додавати та видаляти елементи з невеликими накладними витратами, але вивести записи в належному порядку буде складним. Можливо, є розумний спосіб зробити це за один запит, ймовірно, з великою кількістю приєднаних таблиць.

Цей останній підхід я часто використовую, коли моделюю відносини у стилі дерева (категорії, папки, набори та підмножини). У мене в основному була якась рекурсивна функція реконструкції повного дерева в моїй програмі.

Я думаю, що потрібно зробити, це зберегти властивість або властивості, які використовуються для обчислення рангу, а потім побудувати індекс над ними. Замість того, щоб намагатися змусити базу даних фізично зберігати дані в ранговому порядку або використовувати зв’язаний вручну список, чому б не дозволити двигуну бази даних робити те, що було призначено?

Це обмеження не-RDBMS, як simpleDB. Необхідні функції не можуть бути реалізовані на стороні БД у simpleDB, вони повинні бути реалізовані з боку програмування / програми.

Для таких RDBMS, як SQL serverпотрібні функції, рудиментарні до кластерного індексу.

• Вставка (x) - Вставте запис x у таблицю> Проста вставка.
• Видалити (x) - Видалити запис x із таблиці> Просте видалення.

• До (x, n) - Повернення записів 'n' перед записом x у відсортованому списку. > Виберіть верхній результат n, де x менше значення та порядок за пунктом.

• Після (x, n) - Повернення записів 'n', що завершили запис x, у відсортованому списку. > Виберіть верхній результат n, де x більше значення та порядок за пунктом.

• Перший (n) - Повернення перших записів 'n' зі списку відсортованих. > Виберіть топ n результатів.

• Останнє (n) - Повернення останніх «n» записів із відсортованого списку. > Виберіть топ n результатів після замовлення за дес.

• Порівняйте (x, y) - Давши два записи x і y з таблиці, знайдіть, якщо x> y. > Оператор TSQL IF.

Ось що я використовував для перевпорядкування таблиці Postgres після кожної вставки:

CREATE OR REPLACE FUNCTION re_rank_list() RETURNS trigger AS $re_rank_list$
DECLARE
    temprow record;
    row_idx integer := 1;    
BEGIN
    FOR temprow IN
    SELECT * FROM your_schema.your_list WHERE list_id = NEW.list_id ORDER BY rank ASC
    LOOP
        UPDATE your_schema.your_list SET rank = row_idx * 100 WHERE id = temprow.id;
        row_idx := row_idx + 1;
    END LOOP;
    RETURN NEW;
END;
$re_rank_list$ LANGUAGE plpgsql;


CREATE TRIGGER re_rank_list AFTER UPDATE ON your_schema.your_list_value
    FOR EACH ROW 
    WHEN (pg_trigger_depth() = 0)
    EXECUTE PROCEDURE re_rank_list();

Що стосується мого використання, продуктивність не викликає занепокоєння, але важлива впевненість у тому, що вона ніколи не зламається чи діятиме дивно.