Хранение JSON в столбце базы данных - NVARCHAR (MAX), FileStream?

У меня есть таблица с несколькими стандартными полями плюс документ JSON в одном из столбцов. Мы используем SQL Server 2017 для хранения всего, и данные потребляются приложением C # с использованием Entity Framework 6. Сама таблица, возможно, будет иметь десятки тысяч записей, и эти записи (или, скорее, столбец JSON на них) необходимо будет обновлять ежедневно. Я пытаюсь понять, какой тип данных использовать для максимальной производительности.

Я читал это:

Производительность FILESTREAM SQL Server 2008

В настоящее время документы JSON поступают в виде файлов размером от 30 до 200 КБ. Существует вероятность превышения барьера в 256 КБ, но вероятность превышения 1 МБ в настоящее время очень мала. Это указывает на NVARCHAR. Также здесь:

Какой тип данных SQL лучше всего подходит для хранения строки JSON?

Люди предполагают, что хранение JSON как NVARCHAR (MAX) - это лучший способ.

Однако меня беспокоят две вещи:

  1. Во-первых, это фрагментация с течением времени при таком большом количестве писателей (это одна из областей, в которых Filestream имеет преимущество независимо от размера столбца). Я не уверен, как это повлияет на производительность ...
  2. Во-вторых, я не уверен, не замедлит ли хранение такого количества текстовых данных в базе данных только из-за размера? Насколько я понимаю, еще одним преимуществом FileStream является то, что стоимость размера базы данных довольно постоянна, независимо от размера файла на диске, и это помогает поддерживать производительность с течением времени. Или я не прав?

Что бы вы выбрали, учитывая мой вариант использования?


json sql sql-server sqlfilestream
person user2384366    schedule 21.07.2020    source источник

Ответы (1)


arrow_upward
1
arrow_downward

Это не только вопрос производительности, но и времени разработки, знаний и обслуживания. Если все уже написано на C # с использованием структуры сущностей, зачем вам использовать что-то более сложное? Мой подход заключался бы в использовании решения, которое наиболее удобно разработчикам, до тех пор, пока не возникнет узкое место в производительности, а затем для тестирования.

Сравнение двух решений с реалистичными размерами таблиц даст вам реальное представление о целесообразности каких-либо изменений.

person casenonsensitive    schedule 21.07.2020
comment
Мы уже реализовали это с помощью нормализованного SQL в нескольких отдельных таблицах. Вот почему я знаю, что в эту таблицу будут записаны десятки тысяч записей - сохраненные данные должны обновляться ежедневно. Прямо сейчас у нас есть около 5000 строк, которые необходимо регенерировать, но они должны (медленно) расти вместе с платформой. Лично я выбираю NVARCHAR (MAX) из-за времени разработки и простоты обслуживания. Но я просто хотел знать, использует ли кто-нибудь FileStream для хранения таких небольших данных аналогичным образом, и считает ли это лучше. - person user2384366; 22.07.2020