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

Я ищу, чтобы хранить отсортированный список в базе данных. Я хочу эффективно выполнить следующие операции.

1. Вставить (x) - Вставить запись x в таблицу
2. Удалить (x) - удалить запись x из таблицы
3. Before (x, n) - вернуть 'n' записей, предшествующих записи x в отсортированном списке.
4. После (x, n) - вернуть 'n' записей, следующих за записью x в отсортированном списке.
5. First (n) - вернуть первые 'n' записей из отсортированного списка.
6. Last (n) - вернуть последние 'n' записи из отсортированного списка.
7. Сравнение (x, y) - Учитывая две записи x и y из таблицы, найдите, если x> y.

Простой метод, который я мог бы придумать, - это сохранить в таблице какой-то атрибут «ранг» и выполнить запрос путем сортировки по этому атрибуту. Но в этом методе вставка / изменение записи с рангом становится дорогостоящей операцией. Есть ли лучший метод?

В частности, я хочу реализовать таблицу с помощью Amazon SimpleDB. Но общий ответ для реляционной базы данных также должен быть полезным.

Обновление профиля нагрузки:

Поскольку я планирую это для веб-приложения, это зависит от количества пользователей, которые используют приложение.

Если есть 100 000 активных пользователей (супер оптимизм: P), то моя очень приблизительная оценка в день будет

500 тыс. Выбирает, 100 тыс. Вставляет и удаляет, 500 тыс. Обновлений

Я ожидаю, что таблица вырастет в общей сложности до 500 тысяч.

Я хочу оптимизировать обновления, операции вставки и сравнения. Ранг предметов будет постоянно меняться, и мне нужно постоянно обновлять таблицу.

Если ранг не является полностью произвольным, а может быть получен из какого-либо другого свойства (например, имени, счета игрока и т. Д.), Внимательно посмотрите на ответ Джоэла .

Если это произвольное свойство данных, то , что должно быть сохранено в качестве столбца в таблице рекордов. Предполагая, что Amazon SimpleDB похожа на типичную СУБД, вы можете затем проиндексировать этот столбец и быстро удовлетворить все вышеперечисленные запросы с помощью соответствующей стратегии индексации. Это нормально для РСУБД.

Учитывая, что вы ожидаете высокую активность вставки и обновления, а также относительно высокую активность чтения, я рекомендую сделать следующее:

• Сгруппируйте таблицу по рангу, особенно если подавляющее большинство ваших запросов против ранга. Если нет или если выбор ключа кластеризации недоступен в SimpleDB, просто создайте индекс с рангом в качестве ведущего столбца. Это удовлетворит запросы 3-6.
• Индекс сначала для записи, а затем для ранга (или, в мире SQL Server, просто для записи и INCLUDE-ing ранга, или просто для записи, если вы кластеризовались по рангу) будет удовлетворять запросу 7.
• Операции 1 и 2 могут быть оптимизированы путем правильного распределения данных (т. Е. Установки FILLFACTORв SQL Server). Это особенно важно, если вы группируете по рангу.
• По мере того как вы вставляете или обновляете ранги, сохраняйте как можно больший промежуток между номерами рангов, чтобы минимизировать вероятность того, что вам нужно будет переназначить существующую запись для размещения ранга или обновления. Например, если вы ранжируете свои записи с шагом 1000, вы оставляете достаточно места для примерно половины такого количества изменений и вставляете с минимальной вероятностью, что вам потребуется пересмотреть рейтинг записи, не связанной непосредственно с этими изменениями.
• Каждую ночь пересортируйте все записи, чтобы сбросить разрывы между ними.
• Вы можете настроить частоту массового повторного ранжирования, а также размер разрыва рангов, чтобы соответствовать ожидаемому количеству вставок или обновлений относительно количества существующих записей. Так что, если у вас есть 100K записей и вы ожидаете, что ваши вставки и обновления будут составлять 10%, оставьте достаточно места для 10K новых рангов и переназначьте их по ночам.
• Повторное ранжирование 500K записей - это дорогостоящая операция, но она проводится один раз в день или неделю в нерабочее время для такой базы данных. Массовое повторное ранжирование в нерабочее время для поддержания разрыва рангов - это то, что избавляет вас от необходимости переоценивать множество записей для каждого обновления ранга или вставлять его в обычные и часы пик.

Если вы ожидаете 100K + чтения для таблицы размером 100K +, я не рекомендую использовать метод связанного списка. Это не будет хорошо масштабироваться до этих размеров.

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

Альтернативный подход заключается в том, чтобы смоделировать записи в виде связанного списка, используя столбец рефлексивного внешнего ключа «предшественника» в таблице:

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

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

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

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

Это ограничения не-СУБД, как simpleDB. Необходимые функции не могут быть реализованы на стороне БД в simpleDB, они должны быть реализованы на стороне программирования / приложения.

Для подобных СУБД требуемые SQL serverфункции являются элементарными по отношению к кластерному индексу.

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

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

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

• First (n) - вернуть первые 'n' записей из отсортированного списка. > Выберите лучшие n результатов.

• Last (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();

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