Comments 26
Советы справедливы и очевидны для разработки большинства систем (плюс-минус мультиязычность).
Но вот в стартапах, как мне кажется, перебор. Если вы работаете над стартапом, вам нужно как можно быстрее запуститься с минимумом вложений и проверить все свои теории. А иначе есть риск потратить не один месяц на мультиязычность, шардинг БД, все мыслимые и немыслимые API, съесть весь собственный бюджет и все инвестиции (если таковые имелись), а потом окажется, что ваш проект никому не нужен.
Но вот в стартапах, как мне кажется, перебор. Если вы работаете над стартапом, вам нужно как можно быстрее запуститься с минимумом вложений и проверить все свои теории. А иначе есть риск потратить не один месяц на мультиязычность, шардинг БД, все мыслимые и немыслимые API, съесть весь собственный бюджет и все инвестиции (если таковые имелись), а потом окажется, что ваш проект никому не нужен.
+19
При правильном подходе большинство советов не вызовет значительных задержек. Мы не предлагаем сразу же переводить все на другие языки, сразу же делать шардинг БД и при запуске выставлять API для общественности. Важно держать мысль об этих вещах в голове, тогда можно избежать кучи логических ошибок при написании приложения.
+16
На начальном этапе трат особых и нет. Такие вещи, как использование текстовых идентификаторов вместо полных фраз — это скорее вопрос дисциплины, чем времени. Средство вывода текста все равно придется выбирать и интегрировать — убедиться, что компонент поддерживает юникод, совсем не долго. Да и орфографию в том же экселе проверять гораздо проще, чем в исходном коде. Даже если переводов не будет — отдельно сложенные тексты экономят много времени.
+2
Статья понравилась, но о большинстве этих вещей стоит задумываться не на самом старте, а когда проект уже запущен, иначе есть риск так и не запуститься.
+2
Каждый под «задумываться» подразумевает что-то свое. Главное, чтобы архитектор проекта понимал основной вектор развития проекта и не отрезал различные возможности для изменений в системе. Хорошая статья!
+3
Мы не хотели бы знать ни одного совета по построению стартапов. Таких статей тут по 100 штук на неделю появляется, все они унылы.
Мы хотели бы больше хардкора и интересный статей, вроде этой habrahabr.ru/post/189066/
Мы хотели бы больше хардкора и интересный статей, вроде этой habrahabr.ru/post/189066/
+4
А еще лучше таких habrahabr.ru/post/188992/
-2
Статья качественная, но если вникать так же подробно, как Вы описали в этих 15-и пунктах, то можно написать ещё порядка 50 шт.
Большинство программистов когда начинает писать свой стартап, хочет побыстрее увидеть результат (хоть какой-то), и это вполне нормально.
Так же пока тебе нечего терять, ты относишься к этому не так серьезно, как тогда, когда уже проект запущен (хоть его beta-версия) и в нем завелись первые посетители. А вот когда эти, первые посетители, появились — желание довести все до идеала будет естественным, так как попросту — есть для кого стараться.
Большинство программистов когда начинает писать свой стартап, хочет побыстрее увидеть результат (хоть какой-то), и это вполне нормально.
Так же пока тебе нечего терять, ты относишься к этому не так серьезно, как тогда, когда уже проект запущен (хоть его beta-версия) и в нем завелись первые посетители. А вот когда эти, первые посетители, появились — желание довести все до идеала будет естественным, так как попросту — есть для кого стараться.
0
А вы не думали, что все ваши выводы — это «ошибка выжившего»? Ну то есть вот у вас же всё получилось и теперь вы говорите «блин, надо было сразу делать мультиязычность, использовать шаблонизаторы и собирать статистику». А откуда вы знаете, что вложив с самого начала время в эти вещи у вас бы всё вышло ещё лучше (ну или хотя бы не хуже)? Может быть вышло как-раз потому, что этого на первых порах не делали?
+7
Спасибо за советы. В целом это объединение рекомендаций к любому масшатабному проекту, не обязательно к стартапу.
Я пожалуй не останусь в долгу. Пару месяцев назад нам в компанию звонил Ваш менеджер, которому мне пришлось 20 минут объяснять, что нас не интересует его предложение. Когда мне это надоело я просто бросил трубку. Он перезванивал еще несколько раз. В общем, жесть.
Метод «продайте мне ручку» может и оправдывает себя, но впечатление о компании тот чувак испортил изрядно.
Я пожалуй не останусь в долгу. Пару месяцев назад нам в компанию звонил Ваш менеджер, которому мне пришлось 20 минут объяснять, что нас не интересует его предложение. Когда мне это надоело я просто бросил трубку. Он перезванивал еще несколько раз. В общем, жесть.
Метод «продайте мне ручку» может и оправдывает себя, но впечатление о компании тот чувак испортил изрядно.
+1
Скорее всего вы перепутали нас с какой-то другой компанией, предоставляющей аналогичные услуги. Мы подобными средствами продвижения не занимаемся совершенно точно.
0
Собственно, ни я, ни компания не пользуемся такими услугами. Но Ваш сайт я запомнил определенно точно. Не исключено, что мне просто «повезло» с консультантом, т.к. звонок пришел с call-центра.
0
Очень странно. Единственный возможный вариант — вам звонил кто-то из наших партнеров, которые продвигали наш проект в рамках партнерской программы, тут, сами понимаете, контролировать невозможно.
Однако непосредственно наши сотрудники этого сделать не могли.
Однако непосредственно наши сотрудники этого сделать не могли.
0
Хочется узнать больше технических подробностей:
Было бы славно услышать историю разработки, которая подводит к озвученным в статье выводам, с некоторыми из которых я пока не могу согласиться.
- стек технологий и как он менялся со временем, какие варианты рассматривались и что повлияло на выбор
- конфигурация серверов
- в чём заключается упомянутая ненадёжность репликации mysql
- какой движок использовался таблицей, хранившей переходы
- как собирается статистика
Было бы славно услышать историю разработки, которая подводит к озвученным в статье выводам, с некоторыми из которых я пока не могу согласиться.
0
Тут уже нужен ответ, который тянет на целую статью. Мы соберемся с силами и попробуем описать подробную историю проекта.
Что касается репликации, то от неё мы отказались еще на первый порах — она постоянно слетала и не всегда вовремя срабатывала из-за данные в двух БД разнились. Постоянно приходилось, что-то докручивать. Наверное можно было продолжить настройку и рано или поздно довести её до ума, но мы решили пойти более простым путем. Это было два года назад — возможно сейчас с репликацией у MySQL стало получше.
Движок таблицы MyISAM, поэтому блокирующие запросы вполне объяснимы. На innodb перейти не получилось, при бэкапе вешался сервер.
Статистика подсчитывается и хранится в отдельных таблицах, из которых удобно потом делать выборки.
Что касается репликации, то от неё мы отказались еще на первый порах — она постоянно слетала и не всегда вовремя срабатывала из-за данные в двух БД разнились. Постоянно приходилось, что-то докручивать. Наверное можно было продолжить настройку и рано или поздно довести её до ума, но мы решили пойти более простым путем. Это было два года назад — возможно сейчас с репликацией у MySQL стало получше.
Движок таблицы MyISAM, поэтому блокирующие запросы вполне объяснимы. На innodb перейти не получилось, при бэкапе вешался сервер.
Статистика подсчитывается и хранится в отдельных таблицах, из которых удобно потом делать выборки.
0
Движок таблицы MyISAM, поэтому блокирующие запросы вполне объяснимы. На innodb перейти не получилось, при бэкапе вешался сервер.А движок MEMORY рассматривался как вариант?
0
Статистика подсчитывается и хранится в отдельных таблицах, из которых удобно потом делать выборки.Интересно, какие данные хранятся в этих сводных таблицах, какую аналитическую ценность они представляют и каким образом обновляются (на лету или периодически).
0
Спасибо за статью. Мы делаем стартап, и некоторые пункты, описанные вами, очень кстати.
Например, решил доработать, и даже переработать модель ценообразования, сделав ее более логичной.
Например, решил доработать, и даже переработать модель ценообразования, сделав ее более логичной.
0
Полезные советы. Но вот у меня все чаще возникает вопрос — почему так часто для высоконагруженных проектов используется mysql, который разрабатывался для баз данных среднего объема и требует дико шаманских настроек чтобы работать достаточно быстро?
Я уже 2 раза (1 раз сам, 2й раз досталось по наследству) напоролся на грабли с производительностью mysql и зарекся его использовать для проектов с потенциально высокой нагрузкой. Те проекты и новые используют posgresql. Уже 3 года я не сталкивался с проблемами производительности — работает как часики + куча полезных возможностей типа триггеров.
Может мне кто-нибудь объяснить почему postgresql использут значительно реже чем mysql?
Я уже 2 раза (1 раз сам, 2й раз досталось по наследству) напоролся на грабли с производительностью mysql и зарекся его использовать для проектов с потенциально высокой нагрузкой. Те проекты и новые используют posgresql. Уже 3 года я не сталкивался с проблемами производительности — работает как часики + куча полезных возможностей типа триггеров.
Может мне кто-нибудь объяснить почему postgresql использут значительно реже чем mysql?
+1
Больше статей, больше легаси проектов, больше программистов которые в глаза не видели постгрес, но имеют «большой опыт в мускуле» и которые считают что героически побеждать траблы мускуля — это нормально.
Перконы, марии — конечно «круты» по сравнению с мускулем — но все они меркнут по сравнению с постгресом и ораклом.
Только один минус у постгреса по сравнению с мускулем — вас станут намного реже будить по ночам со всякими мистик траблами, и вы разучитесь в режиме аврала воскрешать мертвецов.
Перконы, марии — конечно «круты» по сравнению с мускулем — но все они меркнут по сравнению с постгресом и ораклом.
Только один минус у постгреса по сравнению с мускулем — вас станут намного реже будить по ночам со всякими мистик траблами, и вы разучитесь в режиме аврала воскрешать мертвецов.
0
Да, минус ужасен, надо возвращатся на мускл =)
Я уже прилично порботал с обоими СУБД и сложилось устойчивое мнение, что мускл значительно проще для освоения т.к. в нем слабая типизированность и много допущений и упрощений, которые в итоге губят производительность. Постгрес же — строгий, я когда только начал на него переходить очень сильно этому обрадовался. Строгость многих отпугивает ибо заставляет думать. Потом еще выяснилось что постгрес умеет кучу всего, что в мускле считается нестабильным, медленным или недостаточно допиленным функционалом. Или вообще отсутствует. Как по мне — в постгресе нет ничего сверх сложного, нужно лишь усвоить несколько отличий и привыкнуть к ним.
Я уже прилично порботал с обоими СУБД и сложилось устойчивое мнение, что мускл значительно проще для освоения т.к. в нем слабая типизированность и много допущений и упрощений, которые в итоге губят производительность. Постгрес же — строгий, я когда только начал на него переходить очень сильно этому обрадовался. Строгость многих отпугивает ибо заставляет думать. Потом еще выяснилось что постгрес умеет кучу всего, что в мускле считается нестабильным, медленным или недостаточно допиленным функционалом. Или вообще отсутствует. Как по мне — в постгресе нет ничего сверх сложного, нужно лишь усвоить несколько отличий и привыкнуть к ним.
0
Мускул очень прост и удобен (в моем случае MariaDB, но и для Percona Server все тоже). При грамотном подходе на нем можно держать любую нагрузку. Производительность очень высокая. Просто грамотный подход довольно редко встречается.
0
Тогда получается, что основное различие — сложность реализации грамотного подхода и знании косяков и особенностей СУБД. Лично мне куда проще грамотно реализовать БД на постгресе чем на мускле и я точно буду знать что все что я делаю будет работать так как описано в документации, ни больше, ни меньше. Да, не все в постгресе делается просто и удобно, зато работает как надо, а это куда важнее удобства =)
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 и сохранения плана выполнения запроса) — сколько не запускай запрос, он будет выполнятся столько же сколько и предыдущий. В постгресе — после первого запроса, последующие аналогичные запросы выполняются в разы быстрее. Да и все неправильные запросы, проходящие в мускле вылетаю в постгресе, что на самом деле правильно — лучше знать об ошибке, чем потом биться головой об стены пытаясь понять что и где косячит
+1
Sign up to leave a comment.
15 вещей, которые мы хотели бы знать перед разработкой стартапа