igosja, посмотрите статейку http://habrahabr[dot]ru/post/147619/ . Возможно, она добавит понимания. На работе брали стажеров - паренек решил структурировать знания для них, а потом и на хабре выложил.
А я плаванием занимался все детство, юность и отрочество Сейчас ничем не занимаюсь - семья, дети, работа мало на что время оставляют, но планирую к лету в тайский бокс пойти.
фраза "CodeIgniter now requires PHP 5.1.6." говорит о минимальных требованиях. Я, как и многие, считаю, что чем больше платформ поддерживает фреймворк - тем лучше. Если люди могут написать красивый фреймворк, используя старые техники - они молодцы, причем молодцы больше, нежели если бы давая то же самое, они были бы более требовательны к версии php.
vanicon, на момент проектированич архитектуры приложения, возьмите хорошего, опытного программиста, желательно, с опытом разработки похожих на вашу систем ... что бы последующий переход на другие технологии был наименее болезненным.
зы
caballero, никто не говорит, что пхп - суперязык, который нужно пихать всюду, речь о простой математике - на пхп веб-приложение можно написать в 3 раза быстрее и в 2 раза дешевле, чем на яве. если за дело возьмется грамотный специалист - на этом коде можно будет сидеть пару лет совершенно спокойно при экспоненциальном росте нагрузок, ближе ко второму году перевести самые нагруженные части проекта на более производительный язык (аля ява, эрланг и тд) - это выгоднее для заказчика, только и всего ... Что бы покупать горы железа, нанимать более дорогих спецов (ява программисты в полтора - два раза дороже пыхеров), платить горы бабла за оракл и тд - нужно быть либо абсолютно уверенным в том, что это быстро окупится и разработка по первой схеме невозможна, либо нужно быть полным идиотом.
KingStar, отказ от now(), MAX(), SUM() и тд В АПДЕЙТАХ не из-за нагрузки на сервера, а из-за неконсистентности данных на разных нодах, к которым они могут привести, нагрузки они не дают Триггеры - та же песня, у вас будет огромный геморой при необходимости шардировать данные, если будут триггеры. Шардировать данные можно по-разному, у нас система решает, к какой ноде направить зпрос, решается исходя из праймари ключа (имя ноды находится по функции от праймари ключа), который мы ищем, для этого не требуется делать доп. запросы к внешней системе за инфой, на какой ноде лежат данные.
Все комментарии типа "какой идиот пишет высокопроизводительные системы на php" и "кому это надо, если есть оракл и ibm" говорят лишь о абсолютной некомпетенции высказывающегося в теме.
Все ясно, просто "не использую фреймворки в нагруженных проектах" не совсем правильно, ведь как бы фреймворк есть, просто свой, самый простейший, там роутинг, mvc, класс для работы с бд, работа с view и тд...
роутинг - 2 класса
mvc - архитектура, то, как ты делишь свое приложение на логические блоки ... доп кода не требует
класс для работы с бд - PDO
работа с view - не очень понимаю, что имеется ввиду
итого, если 2 класса ты называешь фреймворком - ОК, но я с тобой не согласен
Цитата:
Ну а по теме, насчет как определить к какому серверу за данными обращаться, думаю стоит для этого использовать nosql бд, типа redis, ну это так для размышлений...
бред какой-то ... как связан роутинг запросов между нодами шард с nosql? оО
На все случаи жизни не перестрахуешься
Оптимизировать нужно конкретные запросы к бд и куски кода
Распределять какую именно нагрузку вы планируете, вы хорошо себе представляете себе профиль этой нагрузки? Будет у вас больше записей или апдейтов, какого рода связи в таблицах планируются и примерные размеры этимх самый таблиц ? Невозможно улучшать то - не знаю что
Есть некие вещи, до которых доходишь с опытом, но у каждого они свои. Я не делаю никогда триггеры в базе данных, не использую связи таблиц на уровне бд, не использую NOW() и тд в запросах: апдейчу только инкрементально, не оптимизирую заранее, не пихаю ООП везде, где попало, не использую фреймворки в нагруженных проектах ... из остального уже зависит от обстоятельств
Система должна принимать платежи и что делать с ними дальше?
Сложность в том, что ты должен гарантировать, что с деньгами произойдет то, что ты обещаешь и в тот срок, который ты обещаешь. Что у тебя не вырубится электричество после списания бабла, но перед их обработкой, что скрипт не упадет и не перечислит бабки не туда - это скрипты другого уровня качества. Второй момент - мониторинг и логирование. Ты должен суметь ответить на абсолютно любой вопрос клиента в абсолютно любой ситуации любой давности. третий момент - законодательство, ты должен знать российские законы как осуществляется доступ к персональной информации, например. Если работать в гос. секторе - ПО должно быть сертифицированным, а это отдельная тема
Главная
Помощь
Поиск
Пользователи
Найдено сообщений: 2112
