 |  | ||
 главная | избранное | настройки | об ALT-форуме |
Страницы форума: ← Назад | 1 … 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 … 600 | Дальше →
Оптимальное решение для кеша данных | ||
Ivan Sergeev | 20.11.10 02:27 www.parser.ru → | ответить → | | |
Оптимальное решение для кеша данных | ||
| Задача: кешировать данные (самое оптимальное в виде таблиц) с условием, что данными активно пользуются много юзеров и все это множество часто делают обновления данных в базе (читайте часто обновляют/убивают кеш). И конечно же этом может происходить парралельно. Различных наборов данных (таблиц) может быть много (и по кол-ву типов, и по объему) и конечно данные разделяются по пользователям — у каждого группы пользователей свой кеш и упаси боже что бы кто-то/как-то мог влезть в чужой кеш. Зачем: кеш должен помочь снизить кол-во запросов к базе, соотв. повысить скорость обработки запросов. Речь именно не о кеше страниц. Проект обитает на амазоне. Какое решение оптимальнее использовать для парсера? Поделитесь пожалуйста опытом. | ||
| MoKo | → Ivan Sergeev [1] | 20.11.10 12:07 www.parser.ru → | ответить → | | |
ENGINE=MEMORY | ||
| Проще всего копать в эту сторону: Понятно, что так хранить можно только строки, все более сложное надо сериализовать. Например в XML или в JSON (в HEAD версии). Про проблемы с ключами не понял - просто идентификатор пользователя добавляется в ключ, и никаких проблем... | ||
| Misha v.3 | → Ivan Sergeev [1] | 20.11.10 13:15 www.parser.ru → | ответить → | | |
| универсальных решений не существует. как вы собираетесь кэшировать, если сами говорите, что данные очень часто обновляются и кэш надо обновлять? тут надо делать что-то распределённое и что будет быстро работать без кэша. кэш эффективен там, где долго вычисляемые данные можно сохранить и не считать повторно. | ||
| Ivan Sergeev | → MoKo [2] | 20.11.10 13:52 www.parser.ru → | ответить → | | |
| Вчера читал статью на хабре с этим способом. Пока напрягает только то, что под хранение данных и кеша используется одно решение. И как все это поведет себя при нагрузках — не ясно. У меня проблем с ключами нет, в MEMORY таблицах я тож особо не узрел таких сложностей. Единственное конечно вопрос сериализци, идеально было бы повесить кеширование результов запросов минуя парсер. Т.е. идет сначала запрос к кешу, если его нет или он устарел — выполняется запрос по данным и его результат автоматом идет в кеш и отдается парсеру. Все что через парсер в данном случае как лишняя прослойка: xml не блещет скоростью, json в HEAD :-) (мне так и не удалось скомпилировать хеад на маке :-( приходится ждать релиза). | ||
| Ivan Sergeev | → Misha v.3 [3] | 20.11.10 14:07 www.parser.ru → | ответить → | | |
| Да Миш, это факт, что по началу кеш не будет таким эффективным. Но особенность проекта в том, что со временем (через неделю/две/месяц) кол-во обновлений у группы пользователей резко будет падать, а кол-во использований будет возрастать. Именно поэтому кеш актуален. Для распределения базы будет использоваться RDS. Пока мне известно 2 решения: в файлой системе и в memory таблицах. Файловая хороша тем, что весь инстанс в памяти, соотв. не так медленно, но как это поведет себя на коллективном обновлении — что-то очень сомнительно, что будет без проблем. Про memory таблицы написал коммент ниже: не очень нравится хранение данных и кеша в одном месте. | ||
| Misha v.3 | → Ivan Sergeev [5] | 20.11.10 15:04 www.parser.ru → | ответить → | | |
| memory таблицы: какой прикидочный размер кэша? памяти-то хватит? кстати хранить можно не в одном месте, а на другом сервере (или memcached?) :) файловая система: файловые операции могут стать узким местом. а вы уверены, что вас не устроит кеш запросов mysql-я? | ||
| MoKo | → Ivan Sergeev [4] | 20.11.10 22:05 www.parser.ru → | ответить → | | |
Ответ | ||
| Пока напрягает только то, что под хранение данных и кеша используется одно решение. И как все это поведет себя при нагрузках — не ясно. Не очень понимаю опасений. По мне так чем меньше разного софта, тем выше надежность. К mysql претензий по надежности не имеем. Вопрос скорее в том, сколько памяти вы готовы выделить под кеш. :) Т.е. идет сначала запрос к кешу, если его нет или он устарел — выполняется запрос по данным и его результат автоматом идет в кеш и отдается парсеру. Если вы кешируете то, что отдается браузеру (html), то никаких проблем нет - какой-нибудь nginx и вперед. Но мне показалось, что речь шла о таблицах, поэтому не очень понятно о чьих запросах в кеш идет речь. (мне так и не удалось скомпилировать хеад на маке :-( приходится ждать релиза). Посмотрим, что там может быть не так (видимо какие-то мелочи), плюс может бету соберем и для мака тоже. | ||
| Ivan Sergeev | → MoKo [7] | 20.11.10 22:25 www.parser.ru → | ответить → | | |
В тему беты 3.4.1 (HEAD) на маке | ||
| У меня все остановилось на этом: Т.к. на рабочей машине не собралось, под aws не пробовал. | ||
| Sumo | → Ivan Sergeev [8] | 20.11.10 23:02 www.parser.ru → | ответить → | | |
off: Разработка в виртуалке | ||
| Я уже давно "забил" на сборку Парсера под Мак. :) Во-первых это действительно несколько муторно - Эпл, как всегда, идет нестандартным путем. Во-вторых хостинг на маке мало у кого есть, поэтому возня с настройками отдельных конфигураций под мак и серверную систему не имеет особого смысла. Именно поэтому я просто поднимаю на виртуальной машине (Parallels Desktop) FreeBSD и разрабатываю прямо в ней (TextMate через ssh). Видимо для AWS надо будет какой-нибудь Linux поднять, хотя по моим ощущениям для разработчика полезнее FreeBSD и ее система "портов". Это очень здорово приближает разработку к "боевой" конфигурации, что очень полезно. | ||
| → Sumo [9] | 20.11.10 23:12 www.parser.ru → | ответить → | | |
Видимо это единственный путь для тех кто работает за маком | ||
| Но фак - параллелс это же еще то буэ, хотя вариантов судя по всему нет. На aws дебиан, но это не мешает вести разработку на маке — особой возни с конфигурацией как то не замечаю. | ||
| → Misha v.3 [6] | 20.11.10 23:22 www.parser.ru → | ответить → | | |
Про memcached | ||
| Ну ты понимаешь, что пока парсер с ним тесно не дружит — вариант с костылями особо не интересует. Давно пора включить в сборку патч Hexley. Вам оно конечно видней, но строить приложения на parser - python - memcached для работы с кешом мало кому захочется. | ||
| Sumo | 20.11.10 23:42 www.parser.ru → | ответить → | | |
https://launchpad.net/memcached-udfs | ||
| Штука вполне юзабельная. А вот с "патчем Hexley" беда - он для старой библиотеки написан и со сборкой есть сложности. | ||
| Ivan Sergeev | → Sumo [12] | 21.11.10 20:43 www.parser.ru → | ответить → | | |
Спасибо огромное за наводку! | ||
| |||
 | |||