Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 26
Советы справедливы и очевидны для разработки большинства систем (плюс-минус мультиязычность).
Но вот в стартапах, как мне кажется, перебор. Если вы работаете над стартапом, вам нужно как можно быстрее запуститься с минимумом вложений и проверить все свои теории. А иначе есть риск потратить не один месяц на мультиязычность, шардинг БД, все мыслимые и немыслимые API, съесть весь собственный бюджет и все инвестиции (если таковые имелись), а потом окажется, что ваш проект никому не нужен.
Но вот в стартапах, как мне кажется, перебор. Если вы работаете над стартапом, вам нужно как можно быстрее запуститься с минимумом вложений и проверить все свои теории. А иначе есть риск потратить не один месяц на мультиязычность, шардинг БД, все мыслимые и немыслимые API, съесть весь собственный бюджет и все инвестиции (если таковые имелись), а потом окажется, что ваш проект никому не нужен.
При правильном подходе большинство советов не вызовет значительных задержек. Мы не предлагаем сразу же переводить все на другие языки, сразу же делать шардинг БД и при запуске выставлять API для общественности. Важно держать мысль об этих вещах в голове, тогда можно избежать кучи логических ошибок при написании приложения.
На начальном этапе трат особых и нет. Такие вещи, как использование текстовых идентификаторов вместо полных фраз — это скорее вопрос дисциплины, чем времени. Средство вывода текста все равно придется выбирать и интегрировать — убедиться, что компонент поддерживает юникод, совсем не долго. Да и орфографию в том же экселе проверять гораздо проще, чем в исходном коде. Даже если переводов не будет — отдельно сложенные тексты экономят много времени.
Статья понравилась, но о большинстве этих вещей стоит задумываться не на самом старте, а когда проект уже запущен, иначе есть риск так и не запуститься.
Каждый под «задумываться» подразумевает что-то свое. Главное, чтобы архитектор проекта понимал основной вектор развития проекта и не отрезал различные возможности для изменений в системе. Хорошая статья!
Мы не хотели бы знать ни одного совета по построению стартапов. Таких статей тут по 100 штук на неделю появляется, все они унылы.
Мы хотели бы больше хардкора и интересный статей, вроде этой habrahabr.ru/post/189066/
Мы хотели бы больше хардкора и интересный статей, вроде этой habrahabr.ru/post/189066/
А еще лучше таких habrahabr.ru/post/188992/
Статья качественная, но если вникать так же подробно, как Вы описали в этих 15-и пунктах, то можно написать ещё порядка 50 шт.
Большинство программистов когда начинает писать свой стартап, хочет побыстрее увидеть результат (хоть какой-то), и это вполне нормально.
Так же пока тебе нечего терять, ты относишься к этому не так серьезно, как тогда, когда уже проект запущен (хоть его beta-версия) и в нем завелись первые посетители. А вот когда эти, первые посетители, появились — желание довести все до идеала будет естественным, так как попросту — есть для кого стараться.
Большинство программистов когда начинает писать свой стартап, хочет побыстрее увидеть результат (хоть какой-то), и это вполне нормально.
Так же пока тебе нечего терять, ты относишься к этому не так серьезно, как тогда, когда уже проект запущен (хоть его beta-версия) и в нем завелись первые посетители. А вот когда эти, первые посетители, появились — желание довести все до идеала будет естественным, так как попросту — есть для кого стараться.
А вы не думали, что все ваши выводы — это «ошибка выжившего»? Ну то есть вот у вас же всё получилось и теперь вы говорите «блин, надо было сразу делать мультиязычность, использовать шаблонизаторы и собирать статистику». А откуда вы знаете, что вложив с самого начала время в эти вещи у вас бы всё вышло ещё лучше (ну или хотя бы не хуже)? Может быть вышло как-раз потому, что этого на первых порах не делали?
Спасибо за советы. В целом это объединение рекомендаций к любому масшатабному проекту, не обязательно к стартапу.
Я пожалуй не останусь в долгу. Пару месяцев назад нам в компанию звонил Ваш менеджер, которому мне пришлось 20 минут объяснять, что нас не интересует его предложение. Когда мне это надоело я просто бросил трубку. Он перезванивал еще несколько раз. В общем, жесть.
Метод «продайте мне ручку» может и оправдывает себя, но впечатление о компании тот чувак испортил изрядно.
Я пожалуй не останусь в долгу. Пару месяцев назад нам в компанию звонил Ваш менеджер, которому мне пришлось 20 минут объяснять, что нас не интересует его предложение. Когда мне это надоело я просто бросил трубку. Он перезванивал еще несколько раз. В общем, жесть.
Метод «продайте мне ручку» может и оправдывает себя, но впечатление о компании тот чувак испортил изрядно.
Скорее всего вы перепутали нас с какой-то другой компанией, предоставляющей аналогичные услуги. Мы подобными средствами продвижения не занимаемся совершенно точно.
Собственно, ни я, ни компания не пользуемся такими услугами. Но Ваш сайт я запомнил определенно точно. Не исключено, что мне просто «повезло» с консультантом, т.к. звонок пришел с call-центра.
Хочется узнать больше технических подробностей:
Было бы славно услышать историю разработки, которая подводит к озвученным в статье выводам, с некоторыми из которых я пока не могу согласиться.
- стек технологий и как он менялся со временем, какие варианты рассматривались и что повлияло на выбор
- конфигурация серверов
- в чём заключается упомянутая ненадёжность репликации mysql
- какой движок использовался таблицей, хранившей переходы
- как собирается статистика
Было бы славно услышать историю разработки, которая подводит к озвученным в статье выводам, с некоторыми из которых я пока не могу согласиться.
Тут уже нужен ответ, который тянет на целую статью. Мы соберемся с силами и попробуем описать подробную историю проекта.
Что касается репликации, то от неё мы отказались еще на первый порах — она постоянно слетала и не всегда вовремя срабатывала из-за данные в двух БД разнились. Постоянно приходилось, что-то докручивать. Наверное можно было продолжить настройку и рано или поздно довести её до ума, но мы решили пойти более простым путем. Это было два года назад — возможно сейчас с репликацией у MySQL стало получше.
Движок таблицы MyISAM, поэтому блокирующие запросы вполне объяснимы. На innodb перейти не получилось, при бэкапе вешался сервер.
Статистика подсчитывается и хранится в отдельных таблицах, из которых удобно потом делать выборки.
Что касается репликации, то от неё мы отказались еще на первый порах — она постоянно слетала и не всегда вовремя срабатывала из-за данные в двух БД разнились. Постоянно приходилось, что-то докручивать. Наверное можно было продолжить настройку и рано или поздно довести её до ума, но мы решили пойти более простым путем. Это было два года назад — возможно сейчас с репликацией у MySQL стало получше.
Движок таблицы MyISAM, поэтому блокирующие запросы вполне объяснимы. На innodb перейти не получилось, при бэкапе вешался сервер.
Статистика подсчитывается и хранится в отдельных таблицах, из которых удобно потом делать выборки.
Движок таблицы MyISAM, поэтому блокирующие запросы вполне объяснимы. На innodb перейти не получилось, при бэкапе вешался сервер.А движок MEMORY рассматривался как вариант?
Статистика подсчитывается и хранится в отдельных таблицах, из которых удобно потом делать выборки.Интересно, какие данные хранятся в этих сводных таблицах, какую аналитическую ценность они представляют и каким образом обновляются (на лету или периодически).
Спасибо за статью. Мы делаем стартап, и некоторые пункты, описанные вами, очень кстати.
Например, решил доработать, и даже переработать модель ценообразования, сделав ее более логичной.
Например, решил доработать, и даже переработать модель ценообразования, сделав ее более логичной.
Полезные советы. Но вот у меня все чаще возникает вопрос — почему так часто для высоконагруженных проектов используется mysql, который разрабатывался для баз данных среднего объема и требует дико шаманских настроек чтобы работать достаточно быстро?
Я уже 2 раза (1 раз сам, 2й раз досталось по наследству) напоролся на грабли с производительностью mysql и зарекся его использовать для проектов с потенциально высокой нагрузкой. Те проекты и новые используют posgresql. Уже 3 года я не сталкивался с проблемами производительности — работает как часики + куча полезных возможностей типа триггеров.
Может мне кто-нибудь объяснить почему postgresql использут значительно реже чем mysql?
Я уже 2 раза (1 раз сам, 2й раз досталось по наследству) напоролся на грабли с производительностью mysql и зарекся его использовать для проектов с потенциально высокой нагрузкой. Те проекты и новые используют posgresql. Уже 3 года я не сталкивался с проблемами производительности — работает как часики + куча полезных возможностей типа триггеров.
Может мне кто-нибудь объяснить почему postgresql использут значительно реже чем mysql?
Больше статей, больше легаси проектов, больше программистов которые в глаза не видели постгрес, но имеют «большой опыт в мускуле» и которые считают что героически побеждать траблы мускуля — это нормально.
Перконы, марии — конечно «круты» по сравнению с мускулем — но все они меркнут по сравнению с постгресом и ораклом.
Только один минус у постгреса по сравнению с мускулем — вас станут намного реже будить по ночам со всякими мистик траблами, и вы разучитесь в режиме аврала воскрешать мертвецов.
Перконы, марии — конечно «круты» по сравнению с мускулем — но все они меркнут по сравнению с постгресом и ораклом.
Только один минус у постгреса по сравнению с мускулем — вас станут намного реже будить по ночам со всякими мистик траблами, и вы разучитесь в режиме аврала воскрешать мертвецов.
Да, минус ужасен, надо возвращатся на мускл =)
Я уже прилично порботал с обоими СУБД и сложилось устойчивое мнение, что мускл значительно проще для освоения т.к. в нем слабая типизированность и много допущений и упрощений, которые в итоге губят производительность. Постгрес же — строгий, я когда только начал на него переходить очень сильно этому обрадовался. Строгость многих отпугивает ибо заставляет думать. Потом еще выяснилось что постгрес умеет кучу всего, что в мускле считается нестабильным, медленным или недостаточно допиленным функционалом. Или вообще отсутствует. Как по мне — в постгресе нет ничего сверх сложного, нужно лишь усвоить несколько отличий и привыкнуть к ним.
Я уже прилично порботал с обоими СУБД и сложилось устойчивое мнение, что мускл значительно проще для освоения т.к. в нем слабая типизированность и много допущений и упрощений, которые в итоге губят производительность. Постгрес же — строгий, я когда только начал на него переходить очень сильно этому обрадовался. Строгость многих отпугивает ибо заставляет думать. Потом еще выяснилось что постгрес умеет кучу всего, что в мускле считается нестабильным, медленным или недостаточно допиленным функционалом. Или вообще отсутствует. Как по мне — в постгресе нет ничего сверх сложного, нужно лишь усвоить несколько отличий и привыкнуть к ним.
Мускул очень прост и удобен (в моем случае MariaDB, но и для Percona Server все тоже). При грамотном подходе на нем можно держать любую нагрузку. Производительность очень высокая. Просто грамотный подход довольно редко встречается.
Тогда получается, что основное различие — сложность реализации грамотного подхода и знании косяков и особенностей СУБД. Лично мне куда проще грамотно реализовать БД на постгресе чем на мускле и я точно буду знать что все что я делаю будет работать так как описано в документации, ни больше, ни меньше. Да, не все в постгресе делается просто и удобно, зато работает как надо, а это куда важнее удобства =)
MariaDB, я тоже пробовал, но по производительности на той же БД с выключенным кешированием на сайте постгрес ее выиграл с довольно большим отрывом в условиях большого количества запросов (не помню точно сколько было запросов в БД, но на страницу лилось 40 запросов в секунду, мускл сдох на 25-30, мария — пережила спам, но довольно туго). С кешированием итак все понятно, хотя мускл и тут умудрился сдохнуть (я так и не выяснил почему, перепробовал кучу настроек, переустановил сервер, снес и заново залил БД — толку 0)
Мне, видимо, повезло в универе поучить стандартный sql с основными его возможностями. Стандарт — прекрасен. А вот диалект mysql довольно сильно отличается от стандартного sql как минимут своей условной типизированностью и особенностями в выполнении запросов (на сколько помню group by делает совершенно не то, что должен по стандарту). Да и что-то я не заметил чтобы запросы в mysql кешировались (я имею ввиду query cache и сохранения плана выполнения запроса) — сколько не запускай запрос, он будет выполнятся столько же сколько и предыдущий. В постгресе — после первого запроса, последующие аналогичные запросы выполняются в разы быстрее. Да и все неправильные запросы, проходящие в мускле вылетаю в постгресе, что на самом деле правильно — лучше знать об ошибке, чем потом биться головой об стены пытаясь понять что и где косячит
MariaDB, я тоже пробовал, но по производительности на той же БД с выключенным кешированием на сайте постгрес ее выиграл с довольно большим отрывом в условиях большого количества запросов (не помню точно сколько было запросов в БД, но на страницу лилось 40 запросов в секунду, мускл сдох на 25-30, мария — пережила спам, но довольно туго). С кешированием итак все понятно, хотя мускл и тут умудрился сдохнуть (я так и не выяснил почему, перепробовал кучу настроек, переустановил сервер, снес и заново залил БД — толку 0)
Мне, видимо, повезло в универе поучить стандартный sql с основными его возможностями. Стандарт — прекрасен. А вот диалект mysql довольно сильно отличается от стандартного sql как минимут своей условной типизированностью и особенностями в выполнении запросов (на сколько помню group by делает совершенно не то, что должен по стандарту). Да и что-то я не заметил чтобы запросы в mysql кешировались (я имею ввиду query cache и сохранения плана выполнения запроса) — сколько не запускай запрос, он будет выполнятся столько же сколько и предыдущий. В постгресе — после первого запроса, последующие аналогичные запросы выполняются в разы быстрее. Да и все неправильные запросы, проходящие в мускле вылетаю в постгресе, что на самом деле правильно — лучше знать об ошибке, чем потом биться головой об стены пытаясь понять что и где косячит
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
15 вещей, которые мы хотели бы знать перед разработкой стартапа