На сколько я понял, задача заключается в том, чтобы «быстро» записывать статистику. Подобную вещь я бы сделал асинхронной, чтобы не тормозила вывод страницы, а просто складывалась в очередь (например, Gearman). Создал бы воркер, который записывает в БД нужные данные (время, user-agent, url и т.п.) о каждом посещении (в качестве БД я бы выбрал PG, хотя и задумался бы над выбором NoSQL решения).
Ещё можно распаралелить это дело. Для этого делаем master-master репликацию и поднимем на тех же серваках дополнительные воркеры для Gearman.
Задержка записи логов стала большой? Количество задач стало увеличиваться? Добавляем воркеров. Не помогло? Добавляем новый сервак.
Вариант помониторить сначала, побегать по собеседованиям, попытаться продать себя подороже не всегда уместен. Иногда время просто поджимает или встаёт вопрос «Либо сейчас я продаю себя за 30 т.р., либо пробую искать дальше и пытаюсь продать себя подороже», а подороже продать и не получится, а там где 30 предлагали уже поезд уехал… Тут скорее уже встаёт вопрос о том на сколько азартен соискатель=)
Поэтому надо хорошо представлять себе какую пользу ты можешь принести компании и какую прибыль и исходя из этого уже пытаться оценивать себя. Врядли кто-то будет платить вам больше (даже столько же), чем вы зарабатываете для компании (без учёта средней температуры по больнице). Но тут не всегда получается сразу оценить свою пользу в компании. Хотя мне кажется, что за время испытательного срока (от 1 до 3 месяцев) можно уже понять на сколько ты полезен для своей компании и кто ты (баласт или двигатель) и исходя из этого уже назначать себе цену. Вот тогда цена будет справедливой для обоих сторон.
Кстати, на счёт Москвы. Некоторым выгоднее открыть подразделение/филиал в глубинке, как правило они так экономят много времени. А хорошие специалисты встречаются и не в Москве, поэтому шанс сделать качественный продукт на фоне хорошей экономии тоже довольно не плохой. И, как правило, в таких ситуациях в этой самой глубинке появляются дорогие вакансии по меркам той же самой глубинки и дешевые вакансии по меркам Москвы.
Если ты думаешь, что имеешь право оценивать свой труд, то ты должен уметь обосновывать свою оценку наличием определённых навыков и знаний.
Если нет навыков и/или знаний, то ты просто не имеешь права оценивать себя, но можно быть либо согласным, либо не согласным с оценкой (потенциального) работодателя, это уже твоё личное право.
Главное тут — адекватность. Если человек адекватен, то он трезво оценит ситуацию и пересмотрит свою оценку, а если не адекватен — то будет гнуть свою линию. И тут уже становится главным вопрос «Кто адекватнее?», соискатель или работодатель? Ведь не всегда соискатели переоценивают свои возможности, бывает и наоборот, что работодатель недооценивает (будущего) работника.
Если второй случай (неадекватный работодатель) лечится рынком, то первый (неадекватный соискатель), лично я, вообще не понимаю как можно вылечить. Разве что только кто-то покажет человеку реальность и поставит его на место.
Мне стал интересен случай, когда соискатели будут массово переоценивать свои возможности. Подогнётся ли под них рынок с работодателями?)
Мы смотрим запросы, которые долго выполняются и оптимизируем их. Обычно это 2-3 самых «тяжёлых» запроса, а вообще их количество для исправления зависит от сложности запроса и выделенного времени. Бывало и по 5-7 запросов в день оптимизировали.
Чуток ИМХО. О наболевшем...
Я пишу на PHP, в качестве СУБД используем PostgreSQL.
ORM — не помощник в оптимизации, скорее наоборот. Не знаю как дела обстоят в других языках, но, если взять пару-тройку популярных фреймворков для PHP с реализованным ORM, то замечаем, что они заставляют нас делать лишние запросы! На сколько я понял, причина — заточенность этих самых ORM в основном под MySQL.
Нет поддержки RETURNING. Иногда работает (не на MySQL) метод аля-getLastInsertId, но работает только в случае если в качестве PK используется счётчик (тип данных INTEGER). Поэтому, если вы используете что-то отличное от счётчика (например, UUID), то прощай getLastInsertId и здравствуй дополнительный запрос перед нужным запросом аля SELECT uuid_generate_v4() и предопределённый id вместо автогенерируемого в запросе с INSERT. А если у вас несколько автогенерируемых полей, которые вам нужно вернуть (RETURNING field1, field2), то понадобится ещё один запрос после INSERT аля-SELECT field1, field2 FROM table WHERE id=:id
Итого 3 запроса вместо 1-го…
Нельзя реализовать непопулярное решение для отличных СУБД от MySQL. В PG при использовании ORM, например, нельзя реализовать запрос: WITH sel AS (SELECT item_id FROM store WHERE category = 'mobile')
SELECT * FROM items WHERE id IN (SELECT item_id FROM sel) AND price BETWEEN 100 AND 200
Я конечно, понимаю, что данный пример не отражает всех нюансов и его можно абсолютно безболезненно заменить на: SELECT * FROM items WHERE id IN (SELECT item_id FROM store WHERE category = 'mobile') AND price BETWEEN 100 AND 200
И даже ещё лучше: SELECT i.* FROM items AS i INNER JOIN store AS s ON s.item_id = i.id AND s.category = 'mobile' AND i.price BETWEEN 100 AND 200
Но всё же бывают случаи, когда тебе приходится делать выборку из таблицы store несколько раз в запросе, тут WITH приходится как нельзя кстати. У нас были очень тяжёлые запросы, которые выполнялись секунд по 10-15, после подобной оптимизации они стали выполняться значительно быстрее.
А заточенных ORM под PG я ещё не встречал, думаю, что иначе в них просто теряется смысл, ибо теряется эта независимость от выбранной СУБД…
Поэтому ORM — это штука только для простых запросов, если вам нужно что-то реально хорошо оптимизировать, то приходится работать с «голыми» запросами, мимо ORM. Либо, есть ещё вариант, инкапуслировать все нужные вам запросы в хранимые процедуры и оптимизировать запросы не со стороны кода и запросов, которые генерирует вам ORM, а со стороны самой СУБД. Но последний вариант, ИМХО, не очень кошерный…
Но и не всегда проблема кроется в том как построен запрос, иногда проблема в отсутствии/не оптимальности какой-то мелочи или индекса.
Например, LIKE работает значительно быстрее, чем ILIKE в PG. Поэтому для полнотекстового поиска лучше использовать LIKE + функциональный индекс: LOWER("name") LIKE LOWER(:name)
И соответствующий функциональный индекс аля-USING btree («name» pg_table.text_pattern_ops).
В итоге видим значительное увеличение скорости выполнения запроса.
Спасибо за внимение.
P.S.: давно не работал с MySQL, поэтому некоторые сравнения могут быть не актуальными… к сожалению…
Меня после Nexus S время жизни Nexus 4 устраивает. Может со временем тоже более привередливым стану к времени жизни)
Мне кажется автору стоит написать отдельный пост с обзором 5-го нексуса. Я бы с удовольствием почитал)
2ГИС-ом пользуюсь на своём телефоне чаще, чем браузером и меня устраивает как всё там выглядит.
Для остального где нужен большой дисплей у меня есть Nexus 10.
Обновить смартфон надо, т.к. некоторыми вещами стало невыносимо пользоваться. Это не критично, конечно, но, например, телефонная книга уже бывает открывается секунд по 5. Такое бывает редко, но метко.
Думал, что когда выйдет новый нексус — куплю его, а он вон 5-ти дюймовый оказался. Придётся остановиться на 4-ом нексусе.
Тоже верно. Буду надеяться, что лет через 5-6 не появится новый тренд с 8-10 дюймовыми телефонами.
Сегодня в метро видел девушку с каким-то гигантским самсунгом. Рост меньше 160, ручки маааленькие. Она его к лицу приложила и тут я еле смех сдержал. Не хочу выглядеть так же)))
Крайне редко запускаю браузер на своём телефоне. Я пробовал 4" аппарат. Моя рука оказалась не очень большой для него. С трудом дотягивался до краёв экрана большим пальцем. С 5" даже пробовать не надо, и так ясно, что уже перебор=(
На сколько я понял, задача заключается в том, чтобы «быстро» записывать статистику. Подобную вещь я бы сделал асинхронной, чтобы не тормозила вывод страницы, а просто складывалась в очередь (например, Gearman). Создал бы воркер, который записывает в БД нужные данные (время, user-agent, url и т.п.) о каждом посещении (в качестве БД я бы выбрал PG, хотя и задумался бы над выбором NoSQL решения).
Ещё можно распаралелить это дело. Для этого делаем master-master репликацию и поднимем на тех же серваках дополнительные воркеры для Gearman.
Задержка записи логов стала большой? Количество задач стало увеличиваться? Добавляем воркеров. Не помогло? Добавляем новый сервак.
Вариант помониторить сначала, побегать по собеседованиям, попытаться продать себя подороже не всегда уместен. Иногда время просто поджимает или встаёт вопрос «Либо сейчас я продаю себя за 30 т.р., либо пробую искать дальше и пытаюсь продать себя подороже», а подороже продать и не получится, а там где 30 предлагали уже поезд уехал… Тут скорее уже встаёт вопрос о том на сколько азартен соискатель=)
Поэтому надо хорошо представлять себе какую пользу ты можешь принести компании и какую прибыль и исходя из этого уже пытаться оценивать себя. Врядли кто-то будет платить вам больше (даже столько же), чем вы зарабатываете для компании (без учёта средней температуры по больнице). Но тут не всегда получается сразу оценить свою пользу в компании. Хотя мне кажется, что за время испытательного срока (от 1 до 3 месяцев) можно уже понять на сколько ты полезен для своей компании и кто ты (баласт или двигатель) и исходя из этого уже назначать себе цену. Вот тогда цена будет справедливой для обоих сторон.
Кстати, на счёт Москвы. Некоторым выгоднее открыть подразделение/филиал в глубинке, как правило они так экономят много времени. А хорошие специалисты встречаются и не в Москве, поэтому шанс сделать качественный продукт на фоне хорошей экономии тоже довольно не плохой. И, как правило, в таких ситуациях в этой самой глубинке появляются дорогие вакансии по меркам той же самой глубинки и дешевые вакансии по меркам Москвы.
Если ты думаешь, что имеешь право оценивать свой труд, то ты должен уметь обосновывать свою оценку наличием определённых навыков и знаний.
Если нет навыков и/или знаний, то ты просто не имеешь права оценивать себя, но можно быть либо согласным, либо не согласным с оценкой (потенциального) работодателя, это уже твоё личное право.
Главное тут — адекватность. Если человек адекватен, то он трезво оценит ситуацию и пересмотрит свою оценку, а если не адекватен — то будет гнуть свою линию. И тут уже становится главным вопрос «Кто адекватнее?», соискатель или работодатель? Ведь не всегда соискатели переоценивают свои возможности, бывает и наоборот, что работодатель недооценивает (будущего) работника.
Если второй случай (неадекватный работодатель) лечится рынком, то первый (неадекватный соискатель), лично я, вообще не понимаю как можно вылечить. Разве что только кто-то покажет человеку реальность и поставит его на место.
Мне стал интересен случай, когда соискатели будут массово переоценивать свои возможности. Подогнётся ли под них рынок с работодателями?)
ORM — не помощник в оптимизации, скорее наоборот. Не знаю как дела обстоят в других языках, но, если взять пару-тройку популярных фреймворков для PHP с реализованным ORM, то замечаем, что они заставляют нас делать лишние запросы! На сколько я понял, причина — заточенность этих самых ORM в основном под MySQL.
Нет поддержки RETURNING. Иногда работает (не на MySQL) метод аля-getLastInsertId, но работает только в случае если в качестве PK используется счётчик (тип данных INTEGER). Поэтому, если вы используете что-то отличное от счётчика (например, UUID), то прощай getLastInsertId и здравствуй дополнительный запрос перед нужным запросом аля SELECT uuid_generate_v4() и предопределённый id вместо автогенерируемого в запросе с INSERT. А если у вас несколько автогенерируемых полей, которые вам нужно вернуть (RETURNING field1, field2), то понадобится ещё один запрос после INSERT аля-SELECT field1, field2 FROM table WHERE id=:id
Итого 3 запроса вместо 1-го…
Нельзя реализовать непопулярное решение для отличных СУБД от MySQL. В PG при использовании ORM, например, нельзя реализовать запрос:
WITH sel AS (SELECT item_id FROM store WHERE category = 'mobile') SELECT * FROM items WHERE id IN (SELECT item_id FROM sel) AND price BETWEEN 100 AND 200Я конечно, понимаю, что данный пример не отражает всех нюансов и его можно абсолютно безболезненно заменить на:
SELECT * FROM items WHERE id IN (SELECT item_id FROM store WHERE category = 'mobile') AND price BETWEEN 100 AND 200И даже ещё лучше:
SELECT i.* FROM items AS i INNER JOIN store AS s ON s.item_id = i.id AND s.category = 'mobile' AND i.price BETWEEN 100 AND 200Но всё же бывают случаи, когда тебе приходится делать выборку из таблицы store несколько раз в запросе, тут WITH приходится как нельзя кстати. У нас были очень тяжёлые запросы, которые выполнялись секунд по 10-15, после подобной оптимизации они стали выполняться значительно быстрее.
А заточенных ORM под PG я ещё не встречал, думаю, что иначе в них просто теряется смысл, ибо теряется эта независимость от выбранной СУБД…
Поэтому ORM — это штука только для простых запросов, если вам нужно что-то реально хорошо оптимизировать, то приходится работать с «голыми» запросами, мимо ORM. Либо, есть ещё вариант, инкапуслировать все нужные вам запросы в хранимые процедуры и оптимизировать запросы не со стороны кода и запросов, которые генерирует вам ORM, а со стороны самой СУБД. Но последний вариант, ИМХО, не очень кошерный…
Но и не всегда проблема кроется в том как построен запрос, иногда проблема в отсутствии/не оптимальности какой-то мелочи или индекса.
Например, LIKE работает значительно быстрее, чем ILIKE в PG. Поэтому для полнотекстового поиска лучше использовать LIKE + функциональный индекс:
LOWER("name") LIKE LOWER(:name)И соответствующий функциональный индекс аля-USING btree («name» pg_table.text_pattern_ops).
В итоге видим значительное увеличение скорости выполнения запроса.
Спасибо за внимение.
P.S.: давно не работал с MySQL, поэтому некоторые сравнения могут быть не актуальными… к сожалению…
А в близкой-близкой Казани?
Регулярно получаю такие сообщения с рекламой. Но телефон ниразу сам не перезагружался и ничего не зависало.
Эти сообщения как-нибудь можно отключить?
Мне кажется автору стоит написать отдельный пост с обзором 5-го нексуса. Я бы с удовольствием почитал)
Это если у нас есть элемент
То выполнив
Мы получим результат foo
Это я так, для справки, т.к. в статье ничего не написано о том что на самом деле делает строчка кода из самого начала статьи.
Или ещё круче — рекурсивная зарядка. Втыкаем оба конца провода в один ноут.
Для остального где нужен большой дисплей у меня есть Nexus 10.
Обновить смартфон надо, т.к. некоторыми вещами стало невыносимо пользоваться. Это не критично, конечно, но, например, телефонная книга уже бывает открывается секунд по 5. Такое бывает редко, но метко.
Думал, что когда выйдет новый нексус — куплю его, а он вон 5-ти дюймовый оказался. Придётся остановиться на 4-ом нексусе.
Сегодня в метро видел девушку с каким-то гигантским самсунгом. Рост меньше 160, ручки маааленькие. Она его к лицу приложила и тут я еле смех сдержал. Не хочу выглядеть так же)))