Там не над чем задумываться.
Давать подобные ссылки - это подход дилетанта, расчитанный на точно таких же дилетантов.
Массовый эффект "ВАУ!!! В Друпале СТОЛЬКО ДЫР????!!!!"
И только единицы способны разобраться в том, ГДЕ именно дыры, какой ущерб можно было бы нанести сайту, в каких версиях движка/модулей обнаружена уязвимость, были ли они пропатчены в следующих версиях...
Печально.
И самое печальное, что эти же дилетанты с криками "Друпал - для ГС" начинают изобретать велосипеды, тратя средства заказчиков, и в итоге ОЧЕНЬ НАИВНО считают, что результат их работы не подвержен взлому с получением доступа к сайту, что сайты нельзя будет использовать для XSS, и т.п.
Это вдвойне печально.
И для ТС мой "отзыв".
Найдите пару килобаксов и закажите разработку по ТЗ у грамотных людей или у веб-студии. Там Вам расскажут и на каком движке надо делать, и почему именно на этом, и что такое "мерчант", и как будет обеспечиваться безопасность.
Если же пары килобаксов нет, то лучше даже не думать о том, чтобы поднимать сервис с прямыми продажами.
Всё вышеизложенное - ИМХО, защищённое авторскими правами. :)
Я считаю, что когда для базы данных принципиален вопрос, сможет ли она обработать 20 000 запросов в секунду или только 15 000, то уже не идёт речь о дополнительных расходах в 100 баксов. Не так ли?
Если мы тут чисто теоретически пофлудить решили, есть ли плюсом экономия 1 Гб оперативы для абстрактной ЦМС на абстрактном сервере, то увольте... :)
На всякий случай напомню, что сервак указанной конфигурации сгодится разве что для хостинга псевдо-проектов, которые когда-нибудь может быть заработают денег. Как только траф переваливается за 10 тысяч, этот проект в умелых руках автоматически становится монетизируемым и если он не способен заработать 200 баксов за дедик, то на кой было вообще заморачиваться?
Ещё раз. Мы говорим о "принципиальной разнице" в работе разных моделей БД под конкретный спектр задач или пытаемся найти абстрактного коня в вакуме и доказать, что InnoDB на сервере со 192Мб памяти будет обрабатывать всего лишь 1500 конкурентных запросов в секунду против 2000 на MyISAM? Если второй вариант - то я откланиваюсь. Приятно было пообщаться.
Santyago добавил 04.02.2010 в 03:48
О... А вот здесь чувствуется сильный собеседник... :)
Теперь уточняем: речь идёт о "быстрой и маленькой" ЦМС "для широкого спектра задач" или о полновесном Инет-магазе? Может я не силён в терминологии, но для меня это принципиально разные задачи. И конкретно под задачу Инет-магаза, да, я выбрал бы транзакционную БД. По ряду преимуществ, которые мы оба, думаю, знаем. Для остального спектра 99% сайтов этот выбор совершенно не принципиален, т.к. как для большинства сайтов основой является несложная структура для хранения контента и большинство операций по его обновлению (не столь частому!) атомарны по своей природе, а основной упор делается на скорость выборок. Скорость выборок опять таки же для большинства сайтов не принципиальна. А когда она принципиальна, то это уже проекты такого масштаба, когда не спрашивают "какую БД выбрать?" Т.о. я настаиваю на том, что решение спора о применимости обоих моделей БД для данного спектра задач такой: скорость выборок примерно одинакова. И исходить при решении дилемы "InnoDB или MyISAM" надо не из производительности, а из реальной необходимости применения преимуществ которые даёт InnoDB в виде, скажем, транзакционности, журналирования или роу-локинг.
За сим откланиваюсь. Спокойной ночи. :)
Если Вам интересно моё мнение, то оно такое: в Zend, CodeIngiter, Prado и так далее если брать фрэймвёки, в Joomla, DLE, WordPress, Битрикс, десятки доморощенных и т.п. если брать ЦМС, вложено СТОЛЬКО человек-часов, что одиночке никогда не справиться в сколь-нибудь разумный срок. Более того, все эти проекты уже прошли столько итераций в своём развитии, что даже для команды программистов это работа на годы.
Кроме того, любая задача, отличная от массовых гавносайтов, требует индивидуального подхода к разработке, начиная с архитектуры железа на котором всё это будет крутится, и заканчивая цветом кнопок для секретарши Главного Босса. :)
Максимальные возможности роста - это прекрасно. Но ИМХО для начала надо решить свою задачу, заработать бабла и потом уже думать, стоит ли с полученной горой кода "заложенным потенциалом" что-то дальше делать и в каком направлении развивать. "Идеальные системы" - это для романтиков и фанатов своего дела.
Хе-хе
Не могу не откаментить... Знакомая история! :))
- Ой двигло - полное гавно!!! - вскричал прыщавый юнец, полчаса назад скачавший дистрибутив...
Знаем, знаем.... )) Сам кой-чего для одного из наших министерств делал. На разработку были выделены совершенно сумасшедшие деньги, выбран подрядчик, а работу делал реально один человек (т.е. я) ))))) Меня тоже финансово мягко сказать не обидели. И продукт они получили хороший. Но когда я узнал распиленную "на верху" сумму, мне эта гора бабла снится до сих пор. )))))
Так не бывает. :) Ну да ладно. Это вопрос религии и спору тут не место.
Santyago добавил 04.02.2010 в 02:44
Честно. Я не в курсе внутреней организации хранения данных и уж тем более не в курсе, как устроен кеш в Мускуле. Меня это не интересует. Но. Если проблему можно решить просто увеличенным размером кеша, то лично я считаю, что проблемы не существует вовсе. 1 Гиг оперативы стоит 50 баксов.
Индексы не кешируются.
Проблема - это когда inner join по пяти таблицам каждая из которых больше ляма записей, в разных движках будет иметь принципиально разную скорость построение выборки. Вот это уже действительно имеющий вес аргумент, основанный на методе хранения данных, работе с индексами и скорости доступа к произвольной записи. Эта сторона работы движков вообще никак не раскрыта. И всё же к данной задаче (построения ЦМС) это едва ли будет иметь какое-то отношение. Где Вы видели ЦМС, для которой решалась бы "проблема размещения на VPS не поддерживающим InnoDB", которая ворочала бы данными больше ляма записей и для неё был бы принципиален размер кеша: 1 гиг там или 2 гига?
Santyago добавил 04.02.2010 в 02:45
Имеется более аргументированное мнение по данному вопросу?
Это логично. И?
Не совсем понял, что значит "в innodb объем данных тупо больше"?
:) Хе-хе...
ВКонтакте на ЦМС не делают...
Отож.
Лучшая защита от дурака - это сделать ядро, зазендить его и отдать разрабам внешний АПИ. Да и то... Скажи дураку богу молиться - он и лоб разобьёт. ))
На самом деле, если реально нет необходимости в транзакциях (а в ЦМС этой необходимости ТОЧНО нет), то все вопросы целостности данных решаются через data-layer ядра ЦМС. Понятное дело, что найдутся умники, которые захотят работать с БД напрямую, но это уже будут их личные проблемы.
Santyago добавил 04.02.2010 в 01:55
Да, согласен. Тест спорный. table-cache=512 и после прогревки сервака почти весь объём ложится в кеш. Неплохо было бы запустить пяток запросов c SQL_NO_CACHE и оценить разницу.
Но в любом случае, посыл у поста правильный: производительность на чтение у них почти одинакова. Дальше уже идёт шаманство с настройками под конкретную задачу для обеспечения максимальной производительности с выбранным движком БД.
Решил тоже померяться сами понимаете чем... ))
Сервак с тяжёлым сайтом на Джумле разогнал недавеча до 100 запросов в секунду на 300 конкурентных потоках. Для генерации трафа использовал апачевскую ab.
Оптимизация проводилась исключительно Апача и Мускуля. За заточку самой Джумлы пока не брался т.к. ещё не всё из сервака выжал. Потом и до двигла Джумлы дело дойдёт.
Так что давайте не жужжать сильно на тему тормознутости Джумлы? :) Всё там в порядке.
И ещё для человека с новостным сайтом на файлах... БД не используется и само двигло небось 5 тысяч строк пыхпыхного кода? А чем хвастаемся, собственно? 300К хитов в сутки, более менее размазанных во времени - это максиумум 20-30 запросов в секунду. И?
Santyago добавил 04.02.2010 в 01:30
В каком виде должен быть отчёт о проведенном анализе? Какие критерии "лучшести"?
А погуглить? Не?
http://www.mysqlperformanceblog.com/2007/01/08/innodb-vs-myisam-vs-falcon-benchmarks-part-1/
И у меня 2 вопроса:
1. На кой в ЦМС быстрые modification операции?
2. На кой в массовой ЦМС заморачиваться с целостностью данных?
Или Fiddler. Цепляется проксёй на IE и заточен под просмотр и работу конкретно с HTTP трафиком. Хорошая штука.
Дорогой, ты думаешь мне делать больше нехрен? Я зашёл на форум, увидел вопрос, уточнил, ответил. Если ты за _четыре_ года пребывания на Сёрче не способен завести себе акк в Эдсенсе, то мой друг Kide всё правильно сказал. Так что, рукой я тебе разве что направление могу показать. Удачи.
