Производительность SQL-запросов, архив и изменение состояния

2

Прямо к делу, я пробовал искать в google и на SO, но не могу найти то, что я ищу. Это может быть из-за неправильной формулировки моего поиска.

Мой вопрос в том,
У меня есть пара столов, которые будут держаться от 1000 до 100 000 в год. Я пытаюсь выяснить, я/как я должен обрабатывать архивирование данных? Я не очень хорошо разбираюсь в базах данных, но ниже есть несколько методов, которые я придумал, и я не уверен, что лучше. Разумеется, учитывая эффективность и простоту кодирования. Я использую Java 1.8, Sql2o и Postgres.

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

Метод 2 Архивируйте данные в отдельную базу данных для данных старше 2-3 лет.
И используйте статус на линиях, чтобы повысить производительность. (См. Метод 3). Это то, к чему я склоняюсь, как "оптимальное" решение, где код не так сложный, но он также поддерживает DB относительно чистым.

Метод 3 Просто укажите статус для каждой строки (например: A = active, R = Archived), чтобы повысить производительность запроса. Просто наличие "выберите * из таблицы, где status =" A ", чтобы уменьшить количество строк для просмотра.

  • 1
    Метод 3 вместе с правильными индексами (это важно) должен подойти. Или вообще никакого метода, только правильные индексы. 100000 / год звучит не так уж и много (если вы не в сети после большого взрыва).
  • 0
    Похоже, этот вопрос лучше задать на dba.stackexchange.com.
Показать ещё 1 комментарий
Теги:
sql2o

2 ответа

1
Лучший ответ

100 000 рядов в год - это не так много. [1]

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

Тем не менее, если вы хотите быть абсолютно уверены, вы могли бы добавить в year колонку и создать индекс для этого (или добавить, что существующие индексы). Но действительно, сделайте это только для таблиц, где вы знаете, что вам это нужно. Например, если таблица уже имеет date столбец, который является частью вашего индекса (ов), вам не нужен отдельный year столбец.

[1] Если у вас нет тысяч столбцов и/или столбцов, содержащих большие двоичные капли, что, похоже, не так.

Поделиться
0

Как отмечает Vog, 100 000 строк не так уж много. Также не составляет 1 000 000 или 5 000 000 - размеры, на которые могут расти ваши столы.

Во многих базах данных вы можете использовать кластерный индекс, где первым ключом является "активный" столбец. Однако Postgres не поддерживает кластеризованные индексы.

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

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

Тем не менее, я не уверен, что лучше разделить active флаг или на year. Это зависит от того, как вы получаете доступ к данным, особенно к более старым данным.

Поделиться

Ещё вопросы

Сообщество Overcoder
Наверх
Меню