При каких обстоятельствах вы должны сериализовать данные? Когда не стоит?

Question

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

Что я более конкретно спрашиваю, так это то, при каких обстоятельствах вам следует принять решение о хранении данных (используя serialize() в PHP, pickle модуль в Python и т. Д.)?

Допустим, у нас был веб-сайт с высоким трафиком, и на нашей странице /blog мы используем xml-файлы статического контента, mo-файл gettext и динамически генерируемый контент из базы данных.

Пример № 1:

Файл, на который мы полагаемся для статического содержимого, en/blog.xml:

'<content><![CDATA[
<h1>Welcome to my blog!</h1>
<p>Lorem ipsum dolor sit amet..</p>

]]></content>'

Хотели бы мы сериализовать сам этот xml-файл и сохранить его в кеше?

Пример № 2:

У нас также есть динамически генерируемая форма, обычно я бы предположил, что я не буду сериализовать что-либо, потому что она генерируется на стороне сервера и динамична, но наши метки полей формы интернационализированы, и пользователь запросил эту страницу на испанском, поэтому мы используем класс перевода, который захватывает метки полей формы, хранящиеся в формате mo/csv/xml.

Содержимое contact-us.php:

<label for="first_name"><?php echo $L->_("First Name");?></label>
<input id="first_name" name="first_name" type="text">

Преобразование идентификатора сообщения «Имя» извлекается из файла перевода уровня приложения, который мы анализируем и храним в массиве, который находится в нашем классе перевода. Таким образом, для нашего кода было бы идеально не анализировать файл mo при каждом запросе страницы, а вместо этого сериализовать весь массив после анализа mo, а затем полагаться на сериализованный дамп этого?

Пример № 3:

Допустим, на нашей странице блога мы добавили 5 самых последних сообщений в блоге.

$posts = BlogClass->sql('SELECT blog_message, blog_author FROM blog_posts LIMIT 5 ORDER BY blog_date DESC');

Хотели бы мы полагаться на что-то вроде memcache и просто установить ключ к результату оператора sql, будет ли он сериализовать результаты запроса, или?

Бонус:

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

Answer 1

Пример 1

Профиль.

• Стоит ли создавать ваши страницы контента непозволительно дорого?
• Значительно ли дешевле десериализовать созданный вами контент?

Если оба ответа положительные, примите это во внимание.

Пример 2

Профиль.

• Стоит ли создавать ваши страницы контента непомерно дорого?
• Значительно ли дешевле десериализовать созданный вами контент?

Если оба ответа положительные, примите это во внимание.

Пример 3

Профиль.

• Этот запрос слишком дорогой?
• Значительно ли быстрее получить данные из memcached?

Если оба ответа положительные, примите это во внимание.

Бонус

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

Выполнение сортировки или других операций с сериализованным набором данных

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

Сообщения

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

Обновление сериализованных данных

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

Удобочитаемость

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

Edit:

Я только что снова посмотрел на запрос в Примере 3. Это очень простой запрос, вы выбираете только 2 поля и упорядочиваете по полю даты. При правильно проиндексированной таблице этот запрос должен быть тривиальным, и я бы не советовал кэшировать что-то подобное в memcached.

Answer 2

В каких обстоятельствах вы на самом деле должны решить хранить данные (используя serialize () в PHP, модуль pickle в Python и т. Д.)?

На этот вопрос легко ответить. Различные сценарии на самом деле не имеют большого значения.

Вот ответ Вы сериализуетесь, когда вам нужно . Не раньше.

Многие API не принимают объекты Python. Когда API не может принять объект Python, тогда вы часто можете предоставить строку. Вот когда вы сериализуете.

Пример. Вы хотите сохранить объект Python в постоянном хранилище. К сожалению, объект file не может написать объект Python. Итак, вы сериализуете.

Пример. Вы хотите отправить объект Python другому процессу. Вы используете сокет, именованный канал или что-то еще. Это все file объекты, а файловые объекты не могут писать объекты Python. Итак, вы сериализуете.

Это когда вы сериализуете.

1. XML-файлы являются сериализованными деревьями DOM. Объект Python является деревом DOM. Файл XML является одним из способов сериализации дерева DOM. Я не понимаю этот пример.

2. Строки меток формы являются строками. Они не должны быть сериализованы. I18N обрабатывается отдельно от вашего приложения. http://docs.python.org/library/i18n.html Я не понимаю этот пример.

3. Это запрос. Вы ничего не сериализуете. Вы просто делаете запрос. Результаты (в принципе) всегда меняются, поэтому любая сериализация является предыдущим, а не текущим результатом, поэтому вы просто не делаете этого.

Бонус. Многостраничная, огромная форма? Вы ничего не сериализуете. Вы просто обновляете сеанс в своей веб-структуре Менеджер сеансов веб-фреймворка может сериализовать объект Python, но именно поэтому вы использовали фреймворк, так что вам не нужно об этом заботиться.

Сериализация используется для записи объекта Python в файл. Это - в веб-приложениях - редко. В основном вы пишете в базы данных, используя SQL.