это может быть излишним для того, что вы хотите, но вы изучили datejs ?
memcached будет быстрее для простых применений, без труда - установка соединения намного дешевле для memcached, так как нет аутентификации, выделения буфера и т. Д. Кроме того, memcached разработан для простого распределения ключей между несколькими серверами.
Однако memcached - это всего лишь простое хранилище ключей / значений. Если вам нужно сделать что-то более сложное с вашими данными (даже что-то вроде SELECT * WHERE x> 5), таблица HEAP будет гораздо более мощной.
Роберт Мунтяну поднимает хороший момент. Иерархия вашего кеша должна быть:
Если вам не нужно распространять глобальные изменения на этот данные, то их хранение в APC имеет смысл. Если вам нужно получить к нему доступ несколько раз во время выполнения скрипта, вы также должны кешировать его в глобальных объектах вашего скрипта.
Самым быстрым вариантом было бы кэширование в памяти в локальной системе. Это не будет хорошо масштабироваться для многих миллионов отношений, но будет очень быстрым и хорошо работать для небольших наборов данных.
Я не проводил тестирования производительности между Memcached / MySQL HEAP, но я ' Думаю, Memcached будет быстрее, потому что у него нет накладных расходов, чем у полноценного механизма реляционной БД. Memcached почти наверняка будет лучше масштабироваться, потому что вы можете распределять его между серверами и иметь циклическую отправку запросов между ними.
Если вам нужно выполнить какую-либо фильтрацию данных перед их извлечением, вы должны использовать MySQL. Накладные расходы на передачу нежелательных данных, вероятно, перевесят преимущества более быстрого поиска.
На вашем месте я бы » d загрузить рассматриваемый набор данных в MySQL и Memcached, затем запустить тесты производительности, чтобы увидеть, что лучше для вашего набора данных. Если есть ядро данных, к которому обращаются особенно часто, подумайте о дополнительном локальном кэше машины.
Если это не очень много, сохраните его в своем собственном процессе. Это самый быстрый.