жесткая привязка к InnoDB, стоит ли?

Это логично. И?

Раньше говорили что пхп не для серьезных проектов, теперь что серьезные проекты на wvc не делают? :) На самом деле такие системы все равно работают под тем или иным фреймворком. Другое дело что его пишут как правило специально под проект, или очень сильно адаптируют существующий. Хочу чтобы мой двиг был пригоден для таких адаптаций. В любом случае такие вещи всегда пишутся в первую очередь для себя, а во вторую для других... Поэтому я изначально на этапе проектирования стараюсь заложить максимальные возможности роста, при этом оставив максимально "легкий" код.

Ну у меня лично пунктик на целостности данных.

У меня на обслуживании одна дефективная система - распределенная база на 300 пользователей на 60 подразделений. Синхронизация идет "оффлайн" с периодичностью в два часа-сутки-неделя.

Разработчик в принципе таких вещей как целостность данных не знает....

в общем банальная склейка дублей превращается в почти невыполнимую задачу.

Это только одна из сторон проблемы.

Система изначально писалась под задачи другого филиала (другой области) который по размерам как одно наше крупное подразделение... Человек использовал довольно приличный движок, но он был настолько туп, что пока я хорошо не разобрался в двиге я был уверен что это все дефекты двига :) При этом если бы в двиге некоторые фичи были бы по умолчанию, то мне бы жилось намного легче ибо не было бы зависимости от дибилов разработчиков.

(и не надо мне говорить что надо правильных подрядчиков надо выбирать - это решение на уровне министрества. и не надо мне говорить что надо правильную власть выбирать ;) сам знаю....)

Ну и плюс не стоит забывать что двиг УНИВЕРСАЛЬНЫЙ. И я почти наверняка буду под ним биллинги писать, а значит транзакции не помешают.

Больший объем данных при использовании innodb, означает что ОЗУ закеширует меньшую долю данных и индексов при прочих равных условиях. Тест этого не учитывает совсем.

очевидно что нетвинд считает что увеличение размеров базы увеличит количество обращений к винту.

Думаю это не так ибо данные то остаются те же... место идет на журналы и т.п.

опять же работа с журналами при записи а не при чтении....

Ага. И 640кб памяти всем хватит.

Если Вам интересно моё мнение, то оно такое: в 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

Имеется более аргументированное мнение по данному вопросу?

То есть вы считаете, что возможность сэкономить 1G памяти не является конкурентным преимуществом для CMS?

На всякий случай напомню обстановку на рынке хостинга : VPS с 192Мб - это "нормальный" тариф. Кое-как работающий дисковый массив с кучей клиентов - в порядке вещей. Диски 10000 RPM - вообще шик.

Как известно из логики, чтобы опровергнуть ваше категоричное утверждение, достаточно одного исключения. Вот вам такое исключение: если у вас сайт интернет-магазина, или просто продажи каких то услуг на сайте (например, вип-статусы пользователей), хотелось бы вам поиметь гемор с ручным восстановлением операций в результате падения базы ? Лично мне - нет. Значит транзакции в таком случае необходимы, а ваше утверждение ложно.

Pandabeer добавил 04.02.2010 в 03:27

В ущерб надежности - это будет называться, сам себе злобный буратино.

Напомню, для большинства серьезных проектов статья расходов на хостинг незначительна в общем списке расходов. А если у вас несерьезный сайт, то вам и надежность может не нужна, следовательно обсуждать нечего. Школьники вон вообще на Юкозе хостятся.

Никакая экономия на хостинге не превысит расходы на восстановление данных в случае аварии.

Я считаю, что когда для базы данных принципиален вопрос, сможет ли она обработать 20 000 запросов в секунду или только 15 000, то уже не идёт речь о дополнительных расходах в 100 баксов. Не так ли?

Если мы тут чисто теоретически пофлудить решили, есть ли плюсом экономия 1 Гб оперативы для абстрактной ЦМС на абстрактном сервере, то увольте... :)

На всякий случай напомню, что сервак указанной конфигурации сгодится разве что для хостинга псевдо-проектов, которые когда-нибудь может быть заработают денег. Как только траф переваливается за 10 тысяч, этот проект в умелых руках автоматически становится монетизируемым и если он не способен заработать 200 баксов за дедик, то на кой было вообще заморачиваться?

Ещё раз. Мы говорим о "принципиальной разнице" в работе разных моделей БД под конкретный спектр задач или пытаемся найти абстрактного коня в вакуме и доказать, что InnoDB на сервере со 192Мб памяти будет обрабатывать всего лишь 1500 конкурентных запросов в секунду против 2000 на MyISAM? Если второй вариант - то я откланиваюсь. Приятно было пообщаться.

Santyago добавил 04.02.2010 в 03:48

О... А вот здесь чувствуется сильный собеседник... :)

Теперь уточняем: речь идёт о "быстрой и маленькой" ЦМС "для широкого спектра задач" или о полновесном Инет-магазе? Может я не силён в терминологии, но для меня это принципиально разные задачи. И конкретно под задачу Инет-магаза, да, я выбрал бы транзакционную БД. По ряду преимуществ, которые мы оба, думаю, знаем. Для остального спектра 99% сайтов этот выбор совершенно не принципиален, т.к. как для большинства сайтов основой является несложная структура для хранения контента и большинство операций по его обновлению (не столь частому!) атомарны по своей природе, а основной упор делается на скорость выборок. Скорость выборок опять таки же для большинства сайтов не принципиальна. А когда она принципиальна, то это уже проекты такого масштаба, когда не спрашивают "какую БД выбрать?" Т.о. я настаиваю на том, что решение спора о применимости обоих моделей БД для данного спектра задач такой: скорость выборок примерно одинакова. И исходить при решении дилемы "InnoDB или MyISAM" надо не из производительности, а из реальной необходимости применения преимуществ которые даёт InnoDB в виде, скажем, транзакционности, журналирования или роу-локинг.

За сим откланиваюсь. Спокойной ночи. :)

Это конечно да, но ежедневный бекап по крону ситуацию несколько смягчит. Хотя конечно лучше приучать пользователей к прекрасному и журналируемые двиги здесь как нельзя кстати... :)

Радует что в этом списке присутствует такой зверь как Битрикс :)

Такого у меня точно не будет)))

Равно как и не будет сверхуниверсального движка с миллиардом модулей и функций, из которых каждый конкретный разработчик спользует отсилы 5%. Так что если бы у меня было свободное время то думаю за месяц я бы легко справился, а так скорее всего через месяц будет максимум бетта, а то и альфа :)

Вот с этим согласен. Совсем уж универсальности не будет. Черновое название двига "Принцип Парето" ;) По сути это основа идеологии движка....

Бывает :)

На самом деле я по сути привожу в порядок свои библиотеки которые я уже около семи лет как использую. И они использовались и в доргенах и в ГС-ах и в биллингах... (с небольшими вариациями).