Рекомендации по использованию API переходных процессов
Недавно я столкнулся с API переходных процессов в Wordpress в надежде улучшить производительность плагина, который я пытаюсь написать.
В основном плагин хранит сведения о продукте из API рекламы продуктов amazon в базе данных. Сведения о продукте хранятся с использованием представления массива в кодировке json.
Теперь я пытаюсь использовать API переходных процессов, чтобы всякий раз, когда администратор очищает записи базы данных, он также обновлялся с помощью API переходных процессов.
В настоящее время я сохраняю значение, закодированное в формате json, с помощью метода set_transient. Что-то вроде этого:
$data = array(
'123' => "{'title' : '', 'price' : '', 'brand' : ''}"
'456' => ...
);
$value = json_encode($data);
set_transient('amazon_items', $value, 60 * 60);
А затем я получаю его оттуда, используя get_transient
$asin = '123';
$data = json_decode(get_transient('amazon_items'), true);
print_r($data[$asin]);
Это нормально или я должен просто сохранить его в виде массива, чтобы я мог просто получить к нему прямой доступ без использования json_decode? Является ли мой вариант использования приемлемым или это перебор? Могу ли я все еще улучшить это? Существует ли определенное ограничение на объем данных, которые я могу хранить с помощью API переходных процессов? В этом конкретном использовании в случае, если я ожидаю, что это будет более 50 Мб данных.
2 answers
Это нормально или я должен просто сохранить его в виде массива, чтобы я мог просто получить к нему прямой доступ без использования json_decode?
В вашем случае хранить его напрямую означает хранить его сериализованным . Потому что $data является массивом и не может быть сохранен как есть, а преобразован в строку.
Даже если вы обращаетесь к нему напрямую, например:
$data = get_transient('amazon_items');
print_r( $data[0] );
Функция get_transient несериализует значение за кулисами (точно так же, как set_transient сериализуйте за кулисами), используя функцию WP maybe_unserialze, которая использует функцию serialize php.
Таким образом, используя json_encode/json_decode или при использовании стандартного метода php-сериализации есть некоторые различия, но производительность почти одинакова. Люди, которые проходили тесты, говорят, что json_encode немного быстрее.
Метод, который вы должны выбрать, зависит от того, что вы должны делать с данными: если вы планируете манипулировать ими с помощью js (или даже с другими языками, кроме php), правильный выбор наиболее вероятно, json.
Если вам нужно сериализовать объект php, содержащий исходный класс, вы должны использовать сериализацию php:
$a = new MyClass;
$b = json_encode($a);
$c = json_decode($b);
$test = is_a($c, 'MyClass'); // false
$a = new MyClass;
$b = serialize($a);
$c = unserialize($b);
$test = is_a($c, 'MyClass'); // true
Существует ли определенное ограничение на объем данных, которые я могу хранить с помощью API переходных процессов?
Переходный API использует {$wpdb->prefix}_options для сохранения данных. В этой таблице столбец option_value, в котором хранятся данные, является столбцом longtext, который может теоретически содержать 4 Гб данных . Даже если реальное пространство меньше, 50 Мб не должно вызывать никаких проблем (из конечно, если ваше пространство бд на сервере достаточно велико).
Примечания
- При работе с сериализованными данными (json или php не имеют значения) вы должны знать, что выполнение любого типа SQL-запроса, в котором они используются, практически невозможно. "Почти" есть для некоторых запросов
LIKE %..%... - Процесс сериализации/десериализации немного затратен, особенно для больших данных. Так что это может быть (и на самом деле полезно), но старайтесь, чтобы этот тип звонков был меньше как можно чаще, и, если возможно, после получения значения попробуйте каким-либо образом кэшировать его
Я бы не стал хранить 50+ мегабайт в качестве временного. Я бы хотел каким-то образом сохранить его в файловой системе или создать свою собственную таблицу БД для хранения данных.
Учтите, что если вы сохраняете переходный процесс в базе данных, то каждый раз, когда вы его извлекаете, это 50 мегабайт данных, которые необходимо отправить из базы данных на веб-сервер для обработки. И это 50 мегабайт памяти, которую PHP должен выделить для ее хранения. И так далее. Ты каждый раз используешь все эти 50 мегабайт? Нет? Тогда это расточительно и глупо.
Разделите ваши данные. Не рассматривайте его как один большой двоичный объект, вместо этого храните его в своей собственной таблице, или как свой собственный тип записи, или что-то еще. Используйте ключи для доступа к нему и получайте доступ только к тем частям, которые вам нужны. Вы увидите преимущества в скорости и получите лучшую кодовую базу для работы таким образом.