Разве плохо обновлять одну и ту же строку в SQL Server?

Question

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

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

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

Answer 1

У вас могут возникнуть проблемы при масштабировании в текущем решении, когда обновления и входы в систему происходят одновременно. Производительность при входе в систему может снизиться, или вы даже можете столкнуться с блокировкой, если используете небрежные операторы SELECT *.

Если обновление широты / долготы является полностью динамическим из нескольких источников, вам определенно следует сохранить его в новой таблице и даже, возможно, создать новую строку для каждого обновления. Если несколько источников постоянно обновляют одну и ту же строку, вы наверняка столкнетесь с проблемами производительности / блокировки. Создание новой строки может показаться нелогичным, но это позволит вам вводить данные из многих источников практически одновременно и запрашивать эти данные с отметкой времени или аналогичной информацией, чтобы найти последнее обновление, сохраняя при этом запросы на обновление очень быстрыми и быстрыми. Обрезка может быть автоматической и быстрой по отметке времени.

Answer 2

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

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

Преимущество заключается в том, что вы передаете только необходимые данные из / в базу данных, что снизит задержку и нагрузку на сеть, клиентов и базу данных.

Answer 3

Если вы продолжаете перезаписывать LAT / LON текущими значениями, вы теряете потенциально ценные / полезные данные.Я думаю, что лучше просто вставить новую строку в таблицу PersonLocation:

       id  autoincrementing integer
       personid  int  fk references persons(id)  [indexed non-unique to speed queries on person location history)
       lat   float
       lon   float
       asof  datetime  default getdate()

РЕДАКТИРОВАТЬ: Если вам нужно часто получать текущее местоположение, вы можете рассмотреть составной индекс (personid, datetime).

Answer 4

10 000 обновлений в день - это не то, о чем вам когда-либо придется беспокоиться.10000 обновлений в минуту могут стать проблемой.Смоделируйте свою базу данных, чтобы она была простой и не пыталась увлечься моделью из соображений производительности.Совет Одеда об обновлении только изменяемых столбцов является обоснованным, независимо от того, какой у вас объем обновления, потому что вы все равно хотите уважать пропускную способность, независимо от того, как часто вы обновляетесь.

Answer 5

Если столбцы, которые вы обновляете, являются частью индекса кластеризации (при условии, что он существует), вы будете вызывать довольно большие издержки для сервера SQL, так как он реорганизует структуру таблицы / индекса для поддержки кластеризации последовательность. Если они являются частью некластеризованного индекса, возникают затраты на поддержание структуры индекса.

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

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

Answer 6

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