Утверждение о том, что "сервак ложиться по переполнению памяти" из-за использования memcached - это полная некомпетентность и "сказать абы что сказать".
Феерическая некомпетентность. Не позортесь, молодой человек.
Вам знакомо устоявшееся в узких кругах выражение "PHP engine"? Ну, да... Вы же не "пыхом не занимаетесь"... Тогда может хватить позориться или очень хочется поспорить?
При чём тут Апач? Сессии организовываются движком PHP. Никаких событий на эту тему этот движок не генерирует. Перед тем как посоветовать очередную глупость, неплохо было бы хоть чуть-чуть в теме разбираться.
Ничего личного, но это очередная глупость.
PHP надо собрать с ключём --with-iconv
Варианты:
1. INSERT DELAYED в помощь в случае использования MyISAM
2. Использование InnoDB
Транзакции тут ни при чём. Проблема в уровне изоляции и умении движка делать row-lock.
Грамотно это делается через memcached. Заводится шаред массив с активными сессиями пользователей. Дальше начинаются вариации в зависимости от постановки задачи.
Santyago добавил 12.02.2010 в 12:57
А ещё, говорят, бывают велосипеды с квадратными колёсами...
Как раз такой джоин при нормально построенных индексах будет эффективнее, чем подзапрос на каждую запись из таблицы постов (к тому же ещё и с группировкой). Ход мысли в исходном запросе я, честного говоря, вообще не понял. Дикость какая-то.
ЗЫ. Миллионах на 10 записях скорее всего загнётся. :) Там временная таблица будет строиться вечность.
А Вы пробовали?
А что? Не работает? :D
DELETE wp1 FROM wp_posts wp1
INNER JOIN wp_posts wp2
WHERE wp1.post_title=wp2.post_title AND wp1.id > wp2.id
Там не над чем задумываться.
Давать подобные ссылки - это подход дилетанта, расчитанный на точно таких же дилетантов.
Массовый эффект "ВАУ!!! В Друпале СТОЛЬКО ДЫР????!!!!"
И только единицы способны разобраться в том, ГДЕ именно дыры, какой ущерб можно было бы нанести сайту, в каких версиях движка/модулей обнаружена уязвимость, были ли они пропатчены в следующих версиях...
Печально.
И самое печальное, что эти же дилетанты с криками "Друпал - для ГС" начинают изобретать велосипеды, тратя средства заказчиков, и в итоге ОЧЕНЬ НАИВНО считают, что результат их работы не подвержен взлому с получением доступа к сайту, что сайты нельзя будет использовать для XSS, и т.п.
Это вдвойне печально.
И для ТС мой "отзыв".
Найдите пару килобаксов и закажите разработку по ТЗ у грамотных людей или у веб-студии. Там Вам расскажут и на каком движке надо делать, и почему именно на этом, и что такое "мерчант", и как будет обеспечиваться безопасность.
Если же пары килобаксов нет, то лучше даже не думать о том, чтобы поднимать сервис с прямыми продажами.
Всё вышеизложенное - ИМХО, защищённое авторскими правами. :)
Я считаю, что когда для базы данных принципиален вопрос, сможет ли она обработать 20 000 запросов в секунду или только 15 000, то уже не идёт речь о дополнительных расходах в 100 баксов. Не так ли?
Если мы тут чисто теоретически пофлудить решили, есть ли плюсом экономия 1 Гб оперативы для абстрактной ЦМС на абстрактном сервере, то увольте... :)
На всякий случай напомню, что сервак указанной конфигурации сгодится разве что для хостинга псевдо-проектов, которые когда-нибудь может быть заработают денег. Как только траф переваливается за 10 тысяч, этот проект в умелых руках автоматически становится монетизируемым и если он не способен заработать 200 баксов за дедик, то на кой было вообще заморачиваться?
Ещё раз. Мы говорим о "принципиальной разнице" в работе разных моделей БД под конкретный спектр задач или пытаемся найти абстрактного коня в вакуме и доказать, что InnoDB на сервере со 192Мб памяти будет обрабатывать всего лишь 1500 конкурентных запросов в секунду против 2000 на MyISAM? Если второй вариант - то я откланиваюсь. Приятно было пообщаться.
Santyago добавил 04.02.2010 в 03:48
О... А вот здесь чувствуется сильный собеседник... :)
Теперь уточняем: речь идёт о "быстрой и маленькой" ЦМС "для широкого спектра задач" или о полновесном Инет-магазе? Может я не силён в терминологии, но для меня это принципиально разные задачи. И конкретно под задачу Инет-магаза, да, я выбрал бы транзакционную БД. По ряду преимуществ, которые мы оба, думаю, знаем. Для остального спектра 99% сайтов этот выбор совершенно не принципиален, т.к. как для большинства сайтов основой является несложная структура для хранения контента и большинство операций по его обновлению (не столь частому!) атомарны по своей природе, а основной упор делается на скорость выборок. Скорость выборок опять таки же для большинства сайтов не принципиальна. А когда она принципиальна, то это уже проекты такого масштаба, когда не спрашивают "какую БД выбрать?" Т.о. я настаиваю на том, что решение спора о применимости обоих моделей БД для данного спектра задач такой: скорость выборок примерно одинакова. И исходить при решении дилемы "InnoDB или MyISAM" надо не из производительности, а из реальной необходимости применения преимуществ которые даёт InnoDB в виде, скажем, транзакционности, журналирования или роу-локинг.
За сим откланиваюсь. Спокойной ночи. :)
