Если Вам интересно моё мнение, то оно такое: в 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 всё правильно сказал. Так что, рукой я тебе разве что направление могу показать. Удачи.
Вот так всегда. Никто меня не любит!
У меня _уже_ проблемы. Мой моск взорван этими вопросами. Это ничего?
