Типы данных таблицы базы данных для хранения кеша ключа/значения

Question

Я работаю над проектом, который требует функции кеширования ключа/значения, но приложение будет существовать в очень ограниченной среде, в которой не поддерживает любой из отраслевых стандартов методы кэширования памяти, такие как ASP.NET Cache, memcached, AppFabric.

Единственная опция, которую мы имеем в этой ограничительной среде, - это база данных MS SQL. Мы должны создать простую таблицу ключей/значений для удовлетворения наших потребностей в кешировании/ценности. Скорее всего, мы будем сериализовать данные как JSON, но я не уверен, какой будет лучший тип данных для ключа. Очевидно, что он должен быть уникальным ключом и должен быть доступен для чтения программистом, получающим и устанавливающим кеш. Он также должен быть быстрым, так как мы уже потеряем производительность, не имея доступа к кеш-памяти «в памяти».

Я использую для того, чтобы мой основной столбец ключей был значением int или bigint. В этом случае следует первичный ключ (ключ кэша) быть типом CHAR или VARCHAR данных, так как все запросы будут:

SELECT value FROM CacheTable WHERE key = 'keyname' 

Я также видел сообщения об использовании md5 хэша, но и другие сообщения указало, что хеширование не может быть полагался на создание уникальных ключей все время. Я в основном после некоторых советов по типу данных, и скорее, или не в столбце «ключ» должен быть первичный ключ, или если я все же должен создать первичный ключ int или bigint (хотя он, вероятно, не будет использоваться).

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

CustomDatabaseCache.Set(string key, object value); 
CustomDatabaseCache.Get(string key) 

Answer 1

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

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

Надеюсь, что это поможет.