Форум успешных вебмастеров - GoFuckBiz.com

  Форум успешных вебмастеров - GoFuckBiz.com > Бизнес-решения > Скрипты, программы и технические решения
Дата
USD/RUB58.9870
BTC/USD0.0000
Скрипты, программы и технические решения Обсуждаем скрипты, программы и новые технологии.

Закрытая тема
Опции темы Опции просмотра
Старый 26.12.2011, 17:38   #1
oso
кодер
 
Аватар для oso
 
Регистрация: 21.01.2008
Сообщений: 316
Бабло: $69585
Question Какой вид кэширования лучше?

Необходимо сохранять ответы API, чтобы потом выводить страницы на основе полученных данных.
Всего около 1 млн записей, но может и 10млн.
Размер одной записи около 4кб.
Посоветуйте какой метод кэширования лучше.

Сначала думал сохранять в файлы по md5 с разделением по папкам, но как узнал, что 10 млн может быть, думаю не очень хорошая идея.
Стоит ли в БД хранить?
с APC и Memcached не работал, имеет ли смысл?

Заранее спасибо
__________________
php скрипты от $25 Отзывы: 2013-2011, 2010, 2009. acя: 384 846 ноль два шесть
oso вне форума  
Старый 26.12.2011, 17:59   #2
chesser
автоматизирую интернеты
 
Аватар для chesser
 
Регистрация: 05.07.2009
Адрес: chesser.ru
Сообщений: 3,382
Бабло: $470735
По умолчанию

раз ты про APC написал, значит у тебя PHP - окей
какие варианты кеширования:
- память
- диск
- память-диск или виртуальная память

из твоего списка порядок использования по приоритетам будет такой:
1. php memory
2. APC shared vars
3. memcached/redis/whatever
4. mysql/postgres/whaever

RAM, может хватит? наверно нет: 4к*10кк = 40Г
получается вариант с виртуальной памятью, или виртуальными БД, или с какой-то другой сложно логикой распределения типа кеширования.

как вариант - в redis есть режим виртуальной БД, в мемкеше есть тоже надстройка, что-то типа memcachedb. можно и на mysql сделать, но смысла нет.
key-value будут эффективнее, если есть hotset'ы - они будут лежать в раме, а другие данные будут на диске.
Если хотсетов нет - будет тормозить.

вариант с ФС тоже норм, еще зависит от ФС и ее настроек.
Смотря какая цель и нагрузка и какое желание сидеть и придумывать свой алго
__________________
USA и NL серверы и VPS | wiki | блог | Drupal | NginxТДС
Ave, Google, morituri te salutant! © chesser
chesser вне форума  
Старый 26.12.2011, 18:39   #3
oso
кодер
 
Аватар для oso
 
Регистрация: 21.01.2008
Сообщений: 316
Бабло: $69585
ТС -->
автор темы ТС По умолчанию

спасибо за развернутый ответ

по пхп немного однобокий опыт, восполняю пробелы)

по времени ограничен, нагрузка сомневаюсь что будет большая.
Наиболее простым и быстрым в плане реализации представляется Mysql.
Индексы ведь в памяти будут? Или изначально мертвый вариант?
Как я понял, memcached, apc хранят все исключительно в памяти, а это не подходит.
В Редисе поглядел, там вроде просто включается (vm-enabled yes), но боюсь подводных камней навалом..

Если нагрузка будет расти, то придется уже увеличивать количество серверов, а тут и memcached/redis/whatever будут очень кстати.

по теме топика - сравнение разных вариантов habrahabr.ru/blogs/php/124212/
__________________
php скрипты от $25 Отзывы: 2013-2011, 2010, 2009. acя: 384 846 ноль два шесть
oso вне форума  
Старый 26.12.2011, 21:26   #4
chesser
автоматизирую интернеты
 
Аватар для chesser
 
Регистрация: 05.07.2009
Адрес: chesser.ru
Сообщений: 3,382
Бабло: $470735
По умолчанию

mysql:
ну не мертвый вариант, а просто немного не логичный. Кеш - это изначально key-value данные. А ты их хочешь запихать в сложную реляционную модель обвешенную всякими индексами и тд.
Индекс в память влезет, ну может чуть расширишь key_buffer_size. Кеширование запросов тут поможет, да, но в редисе/мемкеше похожий механизм, когда протухшие данные вытесняются в vm или стираются, если памяти не хватает.
Но в использовании мускула другой вопрос: чем он лучше файловой системы? У ФС те же индексы в памяти, тот же алгоритм использования хотсетов, те же алгоритмы прогнозирования и тд

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

1) я бы на твоем месте делал на файлах, т.к. лень курить маны по редису
2) но правильный вариант - redis
3) а тебе наверно хочется по-быстрому все сделать на mysql

все три варианта рабочие, если нет цели выжать максимум.
также надо видеть структуру данных и как их будут использовать, I/O распределение и распределение частотности обращения к объектам. Плюс не понятно соотношение требуемой памяти к имеющейся
__________________
USA и NL серверы и VPS | wiki | блог | Drupal | NginxТДС
Ave, Google, morituri te salutant! © chesser
chesser вне форума  
Старый 26.12.2011, 21:41   #5
oso
кодер
 
Аватар для oso
 
Регистрация: 21.01.2008
Сообщений: 316
Бабло: $69585
ТС -->
автор темы ТС По умолчанию

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

думаю сделаю на файлах тогда. Только вопрос есть.. а не получится, как в винде, что файл меньше 4кб, занимает весь кластер, т.е. 4кб ?
__________________
php скрипты от $25 Отзывы: 2013-2011, 2010, 2009. acя: 384 846 ноль два шесть
oso вне форума  
Старый 26.12.2011, 21:48   #6
medar
кодер-энтузиаст
 
Аватар для medar
 
Регистрация: 04.04.2007
Адрес: Джамайка
Сообщений: 3,410
Бабло: $447110
По умолчанию

mongodb - самый универсальный вариант.
medar вне форума  
Старый 26.12.2011, 21:53   #7
chesser
автоматизирую интернеты
 
Аватар для chesser
 
Регистрация: 05.07.2009
Адрес: chesser.ru
Сообщений: 3,382
Бабло: $470735
По умолчанию

Цитата:
Сообщение от oso Посмотреть сообщение
думаю сделаю на файлах тогда. Только вопрос есть.. а не получится, как в винде, что файл меньше 4кб, занимает весь кластер, т.е. 4кб ?
ну естественно будут накладные расходы. Сами имена файлов, папок и тд - это все нужно где-то хранить.
на счет размеров кластеров - зависит от настроек ФС, как ее форматировали. Дефолтные настройки у разных ФС разные. Я хз как там у тебя будет.
Ну если из 40 гигов будет занято 45 - думаю ничего страшного.

и кстати, тебе кеш на каком этапе нужен? если выше бекенда, то во фронтенде можно свои способы кеширования поискать.
__________________
USA и NL серверы и VPS | wiki | блог | Drupal | NginxТДС
Ave, Google, morituri te salutant! © chesser
chesser вне форума  
Старый 26.12.2011, 22:11   #8
oso
кодер
 
Аватар для oso
 
Регистрация: 21.01.2008
Сообщений: 316
Бабло: $69585
ТС -->
автор темы ТС По умолчанию

спасибо за помощь!
мне для бекэнда..
а что во фронтенде кэшировать? весь вывод слишком накладно..
API просто результат возращает через 0.5-2 секунды, т.е. если в момент обращения к сайту запрашивать, то время отклика будет неприемлимым, поэтому и кэшировать приходится.
__________________
php скрипты от $25 Отзывы: 2013-2011, 2010, 2009. acя: 384 846 ноль два шесть
oso вне форума  
Старый 27.12.2011, 06:30   #9
sergeospb
коплю на феррари
 
Регистрация: 03.07.2008
Сообщений: 1,262
Бабло: $148195
По умолчанию

Семраш парсишь?). Как вариант:
Фронт:
1. юзер что-то запрашивает
2. юзеру полностью получает страницу с аяксом, что данные сча будут у него
3. аякс опрашивает сервер на предмет готовы ли данные
Бэк:
1.кэширование может быть как на уровне и рендеринга страницы, так и на уровне данных
2.большое кол-во маленьких файлов вполне нормально по производительности - управлять ими разве что тяжело (есть старый дорген, кэширование на диске было у него - работает пока). Управлять - даже банально бэкапить. А про поиск в данных я вообще молчу. Даже посчитать кол-во файлов в директории офигешь ждать.
3.мускуль тоже можно использовать для key=>value данных, просто накладно.

Последний раз редактировалось sergeospb; 27.12.2011 в 06:42.
sergeospb вне форума  
Старый 27.12.2011, 06:49   #10
sergeospb
коплю на феррари
 
Регистрация: 03.07.2008
Сообщений: 1,262
Бабло: $148195
По умолчанию

Забыл добавить - если будешь использовать мускуль - тебе самостоятельно надо будет следить за временем жизни кэша. Если данные текстовые и довольно объемные, можно юзать стандартное zlib сжатие на стороне мускуля.
PHP код:
SELECT UNCOMPRESS(COMPRESS('any string')); 
Так же, после получения данных можешь юзать INSERT DELAY и выводить сразу в браузер пользователю. Проблемы начнутся когда посещалка возрастет. Так как если пользователи почти одновременно запросят одни и те же данные и их в кэше нет или истек жизни кэша, скрипт одновременно начнет ломится за дынными и потом почти одновременно вставить их, хотя по сути они абсолютно одинаковые.

Последний раз редактировалось sergeospb; 27.12.2011 в 07:00.
sergeospb вне форума  
Закрытая тема



Опции темы
Опции просмотра