ну я и говорю, не вздумайте клюнуть... т.к. реально никого не найдут, а как получить бабки придумают.
А какой поиск будет по данным? А как они будут отображаться?
ТС не вздумайте клюнуть - какой-то кидняк будет 100%.
Эффективное кэширование.
Кстати, скоро NetVillage.ru уже заработает и там всё можно будет почитать. Пока сумбурно сюда что-то закину. Тем про кластеры очень близкая и с ней уже связан много лет. Многие админы полагают, что решение проблемы сводится к установке акселератора и кэширующего механизма на фронте. Я не зря упомянул про мемкашэд, т.к. в большинстве случаев он эффективен. Поясняю - особенность HTTP протокола в данном случае заключается в том, что если в запросе будет кука, то кэширование возможно в рамках конкретного клиента. Следовательно кэширующий HTTP прокси не будет давать должного эффекта, если только на нем не настроено срезание кук. Кэш кэш кэш - кричат многие начинающие админы. Фигня всё это. Если взять в руки калькулятор, а еще лучше живые тесты, то распределенное кэширование даст более больший эффект на низком уровне, чем если мы будем кэшировать итоговый результат - факт.
При наличии хорошей и массштабируемой раздавалки типа nginx статику вообще кэшировать не надо. С другой стороны, за неимением общего дискового пространства ИЛИ реплицируемого дискового пространства мы не можем пренебрегать массштабируемым элементов на фронте. Если нужно быстро и дешево решить задачу по массштабированию раздачи статики до 100-200k активных сессий, то без акселераторов мы быстро это не сделаем. Если акселераторы будут иметь распределенный сторадж на своем уровне, то это будет работать в разы эффективнее.
Ну само собой надо релоады резать и всё сопутствующее, т.к. в момент атак каких-то, в запрос добавляют всё то, что приведет к пробою запроса на задник. Если 100k пролетит до задника, то всё умрет.
Если рассматривать аспекты надежности, то такая система менее стабильна, нежели чем система с распределенным хранением статики на раздачу. Почему? При подыхании задника дохнет вся система. Если нам нужно увеличить надежность, то на фронте должна быть высокопроизводительная массштабируемая балансировка по куче задников, на которых стоят хорошие раздавалки, ну и хранение распределенное.
Если мы хотим 100k активных сессий раскидывать одним фронтом, к примеру по имени директории в URL, то нам надо забыть про сокеты вообще. Делаться все должно на уровне ядра, возможно в user space, возможно какими-то патчами на файрвол, что бы по первой строчке в пакете наш syn proxy делал NAT на нужный задник и/или группу задников.
ps. удачи и до встречи в моем блоге на NetVillage.ru
Что такое массштабируемый счетчик. Нужно отказаться от учета в реальном времени в тот момент когда оно не надо. Ну зачем нам знать, сколько в той или иной позиции там хитов или уников. Статистика должна сливаться в приемники, который это сливают в базу неблокируемым INSERT-ом. Т.к. цена вопроса при сбое у нас копеечная, то мы отказываемся от каких либо ключей и база может быть не только массштабируемая, а еще и распределенная.
Вот я на реальном примере описываю, как делать правильно.
INSERT на самом деле не принципиален, т.к. есть еще работа с таблицами на очень низком уровне. Конечно это в этот момент с ними ничего делать нельзя, но тем не менее это в разы быстрее даже при отключенных индексах. Если мы хотим реальное время, то должны от этого отказаться. Вот тут самое интересное, т.к. видеть статистику в реальном времени нужно только человеку, фактически по запросу. В момент происхождения запроса select-ом собираются необходимые записи во временную таблицу или еще куда-то, а там уже делаются все необходимые count. Простой INSERT и простой SELECT массштабируются до бесконечности. Ну само собой если в таблице никаких проверок нет, типа ключей уникальных или еще чего. И если кто не знает, то напомню - COUNT тоже блокировку возникает, но главное что бы она была в тот момент когда в базу записи не сыпятся... если мы про myisam и т.д.
Исходя из этого можно массштабировать простые задачи без всяких ораклов и прочего, только на одном mysql. Дешево и до бесконечности.
ps. а вообще всё упирается в ДНК архитектора системы и в ДНК программистов.
pps. если кому чего мега веселое надо, то могу построить... есть опыт массштабирования проекта до пары стоек. многие хотели второй спайлог, но не у всех получилось это дешево и красиво... если кто хочет всё и сразу, то в личку.
Ну практика у всех разная, вот в этой схеме вижу большое количество минусов. Способ совершенно не универсальный и массштабировать с помощью него бесконечно нельзя. Прилепленная ферма из memcached утилизирует ресурсы более эффективно. Если нужно еще и выходные запросы кэшировать, то лучше поставить еще и ферму из squid + wccp v2 настроить на маршрутизаторе.
Тут речь шла о массштабируемости, точнее о правильной массштабируемости. Массштабировать тем, что даёт увеличение производительности только в рамках одного элемента ессественно не правильно.
Исходя из этого вот собственно и использую memcached для эффективного кэширования между всеми элементами кластера. Следовательно SQUID использую на фронте, возможно перейду на nginx, когда он научится кэшировать. Каждый фронт на сквиде имеет доступ к кэшам соседей, что сами понимаете даёт хороший эффект, вот в случаях с дорогим запросом на задник это реально спасает. В случаях с WCCP v2 массштабировать можно фактически бесконечно... групками по 32 элемента. Но поверьте мне, что 5 хороших серверов держали на фронте до 45тыс активных коннектов... а еще сколько неактивных там было, можно даже не считать. Само собой это всё под фряшкой, с патчами на тему accf_http и т.д.
Чем массштабировать mysql? да ничем его не массштабируешь... его можно массштабировать только репликацией master-slave, что при грамотном подходе и специфике конкретного приложения может дать очень большой эффект. Почему я когда-то остановился на memcached? всё очень просто - его сейчас лепят к чему только можно. Имея на руках кластер из memcached можно задействовать его и под mysql... еще правда не смотрел на тему доделали они или нет, но вот вот доделают.
Если база постоянно дергается на запись, то нужно перерабатывать большую кучу алгоритмов. Самый простой пример это счетчики для статистики или билинги реального времени, которые изначально были сделаны под ограниченную производительность. Причина в атомарных операциях, т.е. по сути в блокировках. Следовательно что бы приложение было массштабируемым надо применять соответствующие алгоритмы, которые как раз не вызывают блокировок.
Основная иллюзия - переедем на оракл и всё будет ок, там есть оракл рак, грид и всё такое - фигня всё это. Если целостность, ограничения, исключения и прочие вещи требующие уникальности дергаются постоянно, то мы рано или поздно опять упремся в этот атомарный потолок.
Вернусь к счетчикам и биллингам. Обычно программисты делают каунтеры и в реальном времени их увеличивают. Данный метод работает до определенного уровня одновременных конектов. Опять же, важно знать не столько конектов одновременно, а их динамику во времени. Если у нас 100 конектов в секунду такой алгоритм отрабатывает, то при увеличении их количества, механизм, проверяющий целостность, внесет задержку. Если задержка эта будет существенной, то какая-то часть запросов не сможет отработать за эту секунду, а следовательно при такой интенсивности это все через какой-то момент навернется, т.к. запросы будут скапливаться.
да, пошел на фриланс и нашел кучу исполнителей... и вот в таком стиле заказал большую уйму работ -> http://bryanskonline.ru/nv/1.jpg тему можно закрывать.
если человек реальный художник, то он и за полчаса нарисует подобную работу. а если человек за час отрисовывает любой мой каприз, то я его на руках носить буду.
зы. скоро на экране будет куча перлов в подарок для всего РуНет-а.
обычно - уместно только в теории. когда дело заходит за разгребание проблем реально запущенного проекта, то программистов на вилы и мега быстрым способом расставляются подпорки и костыли.
ТС на дежурный вопрос сыпят, как правило, дежурными ответами. Из той информации, что Вы предоставили, что либо придумать мало реально.
У Вас типичная ошибка в понимании сути задачи
Аппаратное массштабирование возможно лишь только тогда, когда программное обеспечение это умеет. Нельзя с ходу выдать решение под "ресурсоемкий сайт", т.к. универсальных решений в природе нет. Есть вот Oracle RAC, но у в Вашем случае mysql же. Вот у первого есть мега термин grid, который очень эффектно действует на заказчика, а у второго есть пародие на кластер и на HA решение.
ps. тут вот на днях memcached в кластере + пару акселей на один проект прикрутили, так он еще тридцать раз столько же потянет... а он как был на двух серверах, так и остался... php/mysql + apache.
вот когда я только так платил, то у меня были постоянные проблемы с качеством и сроками... нет стульев - нет денег... нет проекта стульев - нет заказа.
ps. Набросок и будет ТЗ.
