подозреваю что одним сервером тут даже и не пахнет...
в момент конкурентной вставки записей в базу это все чудесно грохнется... myisam короче.
Чтобы поиметь сервер очередного петяхост(тм) надо всего-то купить там хостинг за 5 баксов и потратить 5-10 минут времени. Если ты умеешь извлекать деньги из этих взломов, то логотипконторы(tm) тебе в руки... сцылок там понаставить, еще чего... это интересно только кидиссам всяким ибо для понимающего народа легальной работы более чем... и платят главное стабильно.
Миша, есть анекдот про неуловимого джо и взломы на заказ. Можно описать сто и один способ как поиметь к примеру вашу контору - вынуть все до единого пароля и фтп-шника каждого дора... включая все учетки клиентских серверов на которые они так любезно предоставляют вам доступ... все внутренние доки и всю корпоративную почту... все асечные хистори и т.д... все до единого байта... страшно?
ps. Когда мы режем любое мыло в формате отличном от plain text, то у нас на это есть свои причины... а любители красоты и панелей и дальше могут спать спокойно.
команднаястрокавопасносте....
ps. Миша, не забудь еще в панелЪ(tm) пару мегабайт графики на каждую страницу... с gprs удобнее будет.
блесну нетривиализмом...
Таблица с фото по сути избыточна, т.к. эти просто 10млн никчемных записей... а потом еще и кейворды и тэги... бр... ссылки на фото, тэги и кейворды мы будем хранить прямо в таблице с анкетами в одном поле содержащем сеарелизованную структурку, вполне возможно ассоциированный массив... удобно до дуриков. ID фото тоже избыточно и мы обычно храним в этом месте хэш по которому лукапится в т.ч. и сервер/группа серверов которые могут отдать это фото, а следовательно формируется нужный URL в т.ч. с учетом загруженности ресурсов... 10млн тянет более 1Тб даже без тумб и прочих preview... далее мы повышаем эффективность query cache использованием одного запроса вида select * from users where userid=id, что сильно экономит нервы на частом просмотре ТОП-овых анкет.
Облака, поиск по кейвордам и т.д. отстраиваем в дополнительных статичных таблицах... индекс для поиска по названию делаем в педальном исполнении, т.е. по крону.
Базу делаем распределенной с дублированием нужного уровня, массовые репликации средствами БД ессесна идут в одно место и заменяются на юзер-левел по мере необходимости... балансинг между mysql-ями конечно же по хэшу, а для более оптимальной утрамбовки индекс по диаппазонам хэшей или id поддергиваемый функцией оптимизации и мониторинга... ну там если ТОПовые весчи надо совсем по всем задникам расдистрибутить или часть задников маркировать как выведенные из эксплуатации. Это так же позволяет использовать все железо что есть под рукой... можно цеплять любую петрушку и постепенно пригружать её до возможного максимума.
Следовательно под анкеты у нас есть две таблицы... первая для всех, а вторая для владельцев... свитчинг между таблицами автоматически происходит через какой-то временной интервал, что дает нам полностью неблокируемый select.... Можно и без этого изврата, но тогда придется городить еще что-то сверху... экономия нескольких мощных юнитов минимум.... т.е. кил 15 американский рублей.
от классиков жанра мы ушли куда-то совсем далеко... 10млн нам не так интересны... мы тут про 10млрд речь вели... кто не понял я не виноват.
зы обращайтесь за консультациями если что... дорого!
в юзерспейсе достаточно ограниченный инструментарий. ни один модуль апача, используя только функции работы с сокетами, не позволит получать статистику по синфлуду в реальном времени.
лучше покажите explain на запрос
Закиньте my.cnf в топик почитать... может в нем причина.
ps. Какая ОС?
в маленькой сети...
купили за 25$ ...
