Какой формат сериализации мы должны использовать для хранения сериализованных объектов в базе данных SQL Server

Question

Мы разрабатываем индивидуальное решение для кеширования, которое будет использовать базу данных SQL Server для хранения кешированных объектов. В среде хостинга приложения не предусмотрен кеш «в памяти», такой как memcached или ткань приложения, поэтому мы должны использовать базу данных SQL Server.

Хотя большинство кешированных объектов будут простыми типами (int, string, date и т. Д.), Нам также нужно будет хранить более сложные типы, такие как DataSet s, DataTable s, общие коллекции и пользовательские классы.

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

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

Answer 1

Все три параметра сериализации, которые вы упомянули (двоичные, json или XML), являются допустимыми вариантами для формата сериализации. Есть many other serialization formats, но три упомянутых вами являются наиболее распространенными. Что касается выбора между тремя, вот некоторые соображения:

1. Если вы храните данные в двоичном формате в базе данных, она не человек читаемым, если, если вы хотите взглянуть на него с помощью использования Sql Server Management Studio или через текстовый редактор. Вам нужно будет написать какой-то инструмент десериализации, если вы хотите вручную просмотреть данные.

2. Бинарный формат, скорее всего, приведет к сериализации объектов с наименьшим размером, за которыми следует json, причем XML является самым большим. Что касается фактических различий по размеру, это будет зависеть от ваших структур данных.

3. Что касается производительности, бинарная сериализация может быть быстрее, чем json или XML. Тем не менее, вам нужно будет сравнить это с вашими данными, чтобы узнать, в чем отличия.

4. Я думаю, что существуют отличные библиотеки .net и поддержка BCL для всех трех типов форматов, поэтому любой выбор должен быть выполнимым.

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

Мы использовали json для сериализации наших объектов для хранения в базе данных, используя JSON.Net, и нам это очень нравится. Иногда бывает удобно вручную просматривать данные через SSMS, а json значительно компактнее для наших данных, чем XML.

Answer 2

Я не буду повторять ответ Джо, когда он мертв. Я хочу добавить, что Binary Serialization увеличивает сложность при обновлении классов. Он управляемый, но он требует немного работы и требует, чтобы вы выкопали в двоичный сериализатор. Где, как и в текстовом подходе, вы можете перенести данные с помощью других параметров (например, XML, на котором вы могли бы запускать XSLT)

Answer 3

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

Я предлагаю protobuf-net то же самое, что использовать SO, я использую его, и скорость вместе с размером действительно хорошая. По крайней мере, на моих тестах все меньше и быстрее.

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

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