@2slide спасибо, очень интересно. А по поводу оптимизации\не оптимизации - человек, отписавшийся выше и прав, и не прав одновременно, ИМХО. Если Вы уверены в количестве пользователей (есть уже пользовательская база и т.п.), то лучше заложить все сразу, так как на живой базе делать будет все очень трудно. Если это все только Ваши догадки (я про объемы данных), то лучше сделайте простейший прототип за пару месяцев с минимумом функционала, для того, чтобы понять куда дальше развиваться (почитайте 37 signals книжку). И раз зашла речь про интсаграмм - они используют очень интересный подход к шардингу, который позволяет заложить его сразу и только при необходимости масштабироваться + даже если написать весь код без учета шардинга, но используя их подход, то это значительно облегчит Вам жизнь в будущем. Статья - instagram-engineering.tumblr.com/post/10853187575/...
@kryoz не вводите в заблуждение человека. Составной индекс вида (userid, subscriberid) будет использоваться при запросах WHERE userid = xxx AND subscriberid = yyy и при запросах WHERE userid = xxx и не будет использоваться только при запросах WHERE subscriberid = yyy. Это связано со структурой индекса в виде бинарного дерева. Для индекса на поля (поле1, поле2, поле3) индекс будет работать для запросов WHERE поле1 AND поле2 AND поле3, WHERE поле1 AND поле2, WHERE поле1, но не будет работать для: WHERE поле2 AND поле3, WHERE поле3. Для запроса WHERE поле1 AND поле3 индекс будет задействован частично (по поле1 будет произведен поиск с использованием индекса, а поле3 уже фулсканом). Т.е. в индексе важен порядок!
Почитал Ваши ответы - оказалось Вы не совсем с нуля собираетесь начать. SEO + CMS... Может не стоит менять область, а осваиваться в вебе? PHP (быстро стать сеньором, но зп у сеньора PHP как у миддла JAVA и даже ниже), Python (стать сеньором сложнее, но и зп в раза 1,5 выше, чем у php и приближается к java) или node.JS (изучить язык можно очень быстро. ЗП... трудно судить. Чуть ниже, чем на питоне в среднем, но адекватных вакансий маловато)?
Нет, все таки Ваш вопрос звучит именно так, как я его перефразировал, так как 2-3 года очень мало, чтобы с нуля стать профессиональным программистом (а это именно тот уровень для желаемой Вами з\п). Ну да ладно.
При условии, что Вы действительно талант и будете усердно трудиться, то описанный мной вариант Вам подходит. Хотя, думаю, других тут и нет. По поводу сферы... Хоть я и не большой любитель java, но при всех описанных Вами условиях это наиболее реальный шанс. Но и наиболее сложный ) Чтобы стать хорошим специалистом в java Вам понадобится знать намного больше, чем специалистам на php, но это окупиться более высокой ЗП (хоть и позже, чем для пхпшников) + большим простором для карьерного роста. А также набирающая обороты Android + в Европе очень ценится Java судя по вакансиям. Вы должны быть готовым к тому, что Вам будет трудно найти вакансию в России под Java (труднее, чем php, к примеру), Вам будет труднее продвигаться к сеньору, но с поставленными Вами условиями по-другому никак ) И не забывайте, что программист должен знать не только один\два языка программирования. Это еще огромное количество технологий и теории: реляционные субд, типовые структуры и алгоритмы, паттерны проектирования (для Java Вашей настольной книгой должна стать GOF или какой-нибудь ее вариант, иначе миддла Вам не видать), очереди, нереляционные субд, построение отказоустойчивых и высоконагруженных систем, гора библиотек java и т.п. Большую часть из этого всего Вы скорее всего будете изучать на этапе работы джуниором (только читая чужой код. Вряд ли Вас допустят к изменению кода, отвечающего за стабильную работу проекта), но учиться дома Вы должны будете тоже очень усердно. Как-то так.
Зачем мне знать сколько он утилизирует из выделенного? Было два сервера под веб-сокеты (на яве писал не я, это был готовый опенсорсный сервер на нетти), на питоне (обычный питон, не пайпай. использовался gevent) написан был мной. Результат - разница в потреблении памяти в 7 раз (и пофиг сколько jvm утилизировала. Захапала она очень много), а по скорости питон сервер в тестах стал проседать примерно на том же этапе где и java, хоть и чуть раньше. Учитывая размер кода и его сложность на яве и питоне - мой выбор за питоном (и это решение до сих пор себя очень хорошо показывает). Вообще в холиваре нет смысла. Я придерживаюсь мнения, что на любом языке можно написать все что угодно. Но есть языки, которые что-то делают лучше, чем другие. У эрланга своя ниша, у явы - своя, у пхп - своя и т. п. И хотя по jvm вы легко можете написать высокоэффективный веб-сервер, но на эрлаге его эффективность будет намного выше в силу природы эрланга (он создавался для таких задач)
@TTA ну тогда вы искажаете мою мысль ) Т.е. успешные проекты получаются в одном случае из 100 (если не реже). Вероятность это все таки равномерное распределение по всей выборке. А если брать только матерых стартапостроителей с опытом развития и продвижения, то их вероятность провала значительно меньше. У меня, как и у большинства отписавшихся здесь, нет опыта построения успешного стартапа. Я не знаю как и что надо делать, чтобы это понравилось пользователю. Может фичу, которую я буду пилить 2 месяца, никто и использовать не будет. И опыт в программировании мне никак не поможет сделать именно успешный проект. Тут нужен опыт именно другого плана.
@TTA ну вашу статистику очень легко просчитать ) Здесь отписалось явно больше 10 человек. Сколько успешных проектов на них? Вроде нет таких. Ладно, выборка маленькая. Но почему тогда каждый день не появляется по успешному стартапу? Ведь каждый программист пилит свой проект и 10% от них это огромное число.
@TTA вы спрос записали как один фактор. А если начать вдаваться, то окажется что спрос может зависеть от чего угодно. И зачастую нельзя все учесть. К примеру, время года, когда проект будет стартовать, неожиданный кризис, выпуск на рынок гугл глассес (и вдруг мобильное приложение, которые вы делали стало никоку не интересно), пролетевшая мимо комета, раздавленная бабочка на другой стороне планеты. В итоге вы полагали, что спрос будет высок, а неожиданный кризис привел к тому, что тратить на ваш сервис лишние 10$ никто не будет. А вот по поводу зарубежных стартапов - тоже занимаюсь примерно этим же )
@Masterme не буду спорить. В целом идея правильная, но беда в том, что для понимания нужно учесть миллионы факторов. А это нереально. Возможно, конечно, у Вас есть опыт выстреливания (под этим я понимаю не только окупаемость (это так, мелкий пук), но и принесение значительного дохода владельцу, который позволит ему уволиться с работы\уйти с фриланса, чтобы заниматься только развитием и улучшением), но у меня пока проекты максимум окупали затраты и давали много опыта.
Я, смотря на свой код, написанный несколько месяцев назад, понимаю, что я был говнокодером. А учитывая, что когда я пишу код, то считаю архитектуру идеальной и гибкой, то я на самом деле говнокодер ) Но тем не менее написав что-то и поняв, что это говнокод, я учусь и в следующий раз напишу уже чуточку лучше.
Я бы тоже хотел найти команду единомышленников под свои проекты. Одному реализовывать нереально. Но пока из всех с кем я работал только один написал хоть что-нибудь для проекта (и тоже потом ушел, так как сменил работу). Остальные сначала рассказывали про плохую архитектуру и что все надо переписать на %супер_язык% и в качестве базы использовать %супер_субд%, потом брались за какую-нибудь задачу, потом пропадали и отмазывались высокой занятостью. По поводу высокой зп - именно так. Я прекрасно понимаю, что стартап выстреливает в 1 случае из ста. Поэтому уйти с работы и занимать только проектом я смогу только тогда, когда будет готов хотя бы прототип и обкатан на ЦА.
меньше 1 секунды ) но вы должны как разработчик рассматривать этот простой не в контексте одного запроса, а в масштабе планируемой нагрузки. Для 100 пользователей в час - 1-2 секунды не критично. Но предположим, что у вас префоркнуто 100 процессов пхп-фпм и 1000 пользователей одновременно делают запрос (вдруг очень популярным стало). Первые 100 пользователей успевают захватить процессы. Остальные ждут пока первые 100 отработают. Затем следующие 100 захватывают процессы, а 800 также ждут. В итоге тем, кому меньше всего повезло будут ждать дольше всех. А ведь за это время прибудут еще пользователи. В итоге Ваша система получит среднее время ответа куда ниже, чем среднее время выполнение скрипта. Можно, конечно, увеличить количество процессов, но делать это бесконечно не выйдет.
Я же написал, что это относительно медленно. Запросы из пхп в ноду это: делаем запрос от клиента к пхп. Это уже накладные расходы, так как мы шлем заголовки, открываем коннект + пинг. Но судя по архитектуре автора от этого не избавиться. Затем забираем из базы (открытие коннекта + запрос) и курлом шлет еще один запрос, но уже ноде (все это блокируется внутри одного процесса, который для пхп-фпма занимает несколько мегабайт и при большом количестве запросов процессов может не хватить. Этим заставим ждать пользователей). Тут ситуация лучше, так как скорее всего все это на одном сервере или с маленькой задержкой, но данных становится еще больше. Нода получает запрос и дальше пошло-поехало. Почему бы это не сократить до варианта: отправляем ноде напрямик id заявки (первый запрос, от которого не избавиться), нода открывает коннект к базе в неблокирующем режиме (да, нода она такая, все асинхронно делает. В это время другие пользователи тоже могут слать запросы не ожидая пока первый завершится), забирает данные, пошло-поехало. Разница: один лишний POST запрос. Т.е. если к вам пришло 100000 запросов, то вы на самом деле добавите еще 100000 (чтобы Вы поняли, что я имею ввиду под "медленно"). Больше расход памяти (пхп процесс будет висеть некоторое время)
Самым правильным вариантом будет написать прототип и прогнть профайлером. Затем, если что-то будет не устраивать - оптимизировать. Преждевременная оптимизация - зло.