grup kanal est

#вакансия #backend #yii https://phpclub.ru/talk/threads/php-%D1%80%D0%B0%D0%B7%D1%80%D0%B0%D0%B1%D0%BE%D1%82%D1%87%D0%B8%D0%BA-%D0%9C%D0%BE%D1%81%D0%BA%D0%B2%D0%B0-%D0%BC-%D0%A7%D0%B8%D1%81%D1%82%D1%8B%D0%B5-%D0%BF%D1%80%D1%83%D0%B4%D1%8B.84204/

Что-то Yii староват у вас ?

grup kanal est

Кто кого должен сьесть?

“до 180 000 руб. до вычета НДФЛ” Цифра кажется внушительнее, но когда большинство работодателей указывают NET — я бы к вам даже не обратился за хитрожопость)

т.е. 156к потолок для синьера

ну такое. Зависит от того, кого понимать под сеньором. В целом, может и найдут.

т.е. 156к потолок для синьера

160 у нас была средняя цифра для синьора, цифра для ориентира:)

?

160 у нас была средняя цифра для синьора, цифра для ориентира:)

Да надо было писать прям “до вычета налогов”, подразумевая вообще все налоги :) Можно было бы и 200+ впендюрить.

Вообще да, разрабы обычно всегда так странно реагируют, как будто это для них констрейнт какой-то. Понятно же что приходишь на собеседование, устраиваешь фееричный мастер-класс, а дальше можешь торговаться, хоть 200 попроси. Если реальный профессионал то и на такие деньги возьмут.

Далеко не всегда компании готовы предложить больше по деньгам. Не всегда готовы и по разивитию предложить хороших условий. Так что это не относится к продаже собственных услуг.

ну если пишут до 160, то предполагается констрейнт... а иначе странный какой-то программсит, с условиями проблема ;)

Вообще да, разрабы обычно всегда так странно реагируют, как будто это для них констрейнт какой-то. Понятно же что приходишь на собеседование, устраиваешь фееричный мастер-класс, а дальше можешь торговаться, хоть 200 попроси. Если реальный профессионал то и на такие деньги возьмут.

Как будто такие профессионалы табунами ходят во все компании на собеседования.

))

А мест для работы на самом деле не так уж много

Иногда в резюме без слёз не взглянешь-то, а тут про мастер-классы уже речь)

сеньору за 150 дофига мест

Я когда искал работу, себе в мск отфильтровал едва 10 мест куда я бы хотел пойти. Ну у меня правда и вилка по зп была 190+

А джуны пхп

Ныне какая зп

В среднем

Не все те, что хочет 150 — сеньоры) Потому и мест много :D

о том и речь, да... 190 сложнее

А джуны пхп

У джунов другая картина немного, там наоборот конкурс людей на место. Стартовая вилка где-то от 40-50к

Ппц)

И работаешь как ишачок

Все нудное писанина на тебе

а по другому никак. Не пописав нудятины не обретешь опыт

С джунами хуже ещё и то, что мест не так много, которые могут себе позволить таковых.

Как выжить джуну))

Живешь с мамкой пока сениором не станешь ))

Ящитаю что норм вариант к выпуску из универа уже быть мидлом (т.е. 21-22 года). На двух последних курсах активно роешь все технологии, алгоритмы и фреймворки, контрибутишь в опенсорс проекты по возможности, пилишь свои велосипеды и выкладываешь на гитхаб.

Плюсую

так и первоночальное утверждение абстрактоне - >90 млн. начинает умирать, отсюда и абстрактный вопрос кто-нибудь наблюдал такой эффект или нет, я при своих 50млн. такого не наблюдаю

основная проблема при таком количестве строк добавление, если оно не часто, то не будет больших проблем. Ну и конечно все зависит от конкретных индексов. Вот что точно будет тупить так это импорт всей этой таблицы из дампа, т.к. построение нескольких btree индесов с нуля учитывая кластерный первичный индекс - это жесть, тут по любому нужен будет очень быстрый ssd винт в рейде и объем памяти + скорость проца почти не играет роли

XDXF - как считать этот xml-подобный формат для словарных записей на js?

основная проблема при таком количестве строк добавление, если оно не часто, то не будет больших проблем. Ну и конечно все зависит от конкретных индексов. Вот что точно будет тупить так это импорт всей этой таблицы из дампа, т.к. построение нескольких btree индесов с нуля учитывая кластерный первичный индекс - это жесть, тут по любому нужен будет очень быстрый ssd винт в рейде и объем памяти + скорость проца почти не играет роли

очень частое, данные о посещаемых ресурсах пльзователей на провайдере, само собой используется шардинг, ssd

мы подобную стату в монгу собираем, в целом проблем нет. данных конечно много, но шардинг/реплики/map-reduce/агригация в общем и в целом терпимо

да хотя и мускуль гдето был с innodb... медленно. неудобно с индеками, но тоже живет. пока неуперлись в лимит INT... был autoincrement

мы подобную стату в монгу собираем, в целом проблем нет. данных конечно много, но шардинг/реплики/map-reduce/агригация в общем и в целом терпимо

я подумываю о mariadb и columnstorage, но пугает отсутствие индексов (ну точнее ограниченность LIKE '...%')

но с мускулем мы не собираем всю входящую стату в одно место... 10+ бэкендов со своим мускулем. и раз в час агригируется в report db, где дополнительно агрегируется в несколько дополнительных таблиц - такчто может по этому проблем не наблюдаем. и report db нормально работает, там сейчас 500+ млн записей innodb >100 гигов данных и > 200 индексов в самой большой таблице а вот в монгу - много где пишем все в одну дб (точнее репликасет или шард)

очень частое, данные о посещаемых ресурсах пльзователей на провайдере, само собой используется шардинг, ssd

Очень частое это сколько? Просто у всех разное понимание часто

и мускуль без шардинга... мастер и 2 реплики

в сек. 10-15 записей, часы пик больше

это вообще не о чем нагрузка с такой без проблем и один hdd справится без рейда.

Если есть свободное железо, то самый простой вариант проверить импорт дампа такой большой таблицы - в зависимости от списка индексов веселуха может затянуться на несколько часов

это на 1 сервер, всего 7, т.е. порядка 100 з.с. (но в целом на один сервер пока такая)

ну т.е. я правильно понимаю, чо innodb в состоянии выдержать фигову тучу записей (ну и bigint в качестве autoincrement)

выдержать да, но тупит добавление/изменение индекса если записей дофига.

ну у нас таблица юзеров больше 100 миллионов. инсертится порядка 10-30 в секунду. держит уж.

но это тупление на каких-то задачах не будет заметно

10-30 в сек- это же вообще не нагрузка

ну.. так то да :)

на своем опыте - должна поидее... но всегда есть нюансы :)

у нас только поля добавлять не хотела новые :)

и я вполне по человечески ее понимаю :)

хм. успокоили :) если что, сошлюсь на вас :))

хотя да будет тупить и на 10-30 в сек, если первичный индекс составной из 20 полеу + 20 отдельных индексов по этим полям + еще 20 ра0зличных их комбинаций

ну че успокоили - там же в самом начале написали - все от индексов зависит

ну и к требованиям по допустимому уровню 'тупления' :)

нет уж, все , как только докатит до 90 млн. я вас вспомню добрым словом :)

был около месяца назад или чуть более товарищ на форуме у которого был первичный индекс по всем полям таблицы + куча других бесполезных составнызх индексов, удивлялся что самые простые запросы тупят

нужно бООльше индексов!!

и не стоит забывать что при таком количестве записей любой альтер связанный с индексами может выполняться неожиданно дофига времени

именно - чем больше тем будет быстрее! :))))

мускуль в этом плане мне не нравится, именно для big data... изза сложности alterов

универсальное решение!

окей, так а есть другое что? ну вот про монго - ок, я думаю в сторону columnstorage mariadb

не юзал )

ну у нас таблица юзеров больше 100 миллионов. инсертится порядка 10-30 в секунду. держит уж.

а по железу что? всякие там ssd? шардинги?

окей, так а есть другое что? ну вот про монго - ок, я думаю в сторону columnstorage mariadb

postgres )

postgres )

кирпич мне в рот - вот это поворт. я так кординально не думал :) а есть опыт?

Ну у нас объемы были относительно не большие, порядка 5 млн. записей в таблице, но выборки были по ней очень сложные.

Насчет альтера схемы надо смотреть каждый кейс, но там в целом все намного лучше чем у мускуля

У нас в постгре таблица на запись ~1 ярда строк, до того как партицирование реализовали

Например колонку он дропает мгновенно, т.к. просто удаляет запись о ней в системной таблице.

А данные меняются или только добавляются?

Там в нем проблема в операции VACUUM - это такой аналог сборщика мусора в постгресе

добавляются only - timeseries

Редкие изменения

А clickhouse смотрел?

Да, смотрим в сторону колоночных.

Правда кликхаус с отсутствующим комьюнити вряд ли в прод возьмём.

А clickhouse смотрел?

нет, вот и я боюсь сомтреть в сторону решений которые не саппортятся или камьюнити ни какое

Почему не саппортятся - нужен платный саппорь?

конечно. яндекс ведь шарашкина контора :)

Нет сообщества вокруг решения. Инструмент не обкатан. А платного суппорта в случае необходимой поддержки — нет.

:) ну да - одина доку чего стоит - "столбцовых СУБД"

мне казалось есть устоявшияся термин - "колоночные БД"

Комбюнити есть https://t.me/clickhouse_ru

Почему не саппортятся - нужен платный саппорь?

да хотя-бы какой-нибудь, по моему последнему обращению в яндекс, до сих пор ответа нет

Ну почему тогда в MySQL не написал что тормозит ?

эээ, у меня еще не тормозит, я "зрю" дальше и лучше сейчас поменяю коней на переправе, чем потом сутками ждать разворачивание дампа

А clickhouse смотрел?

обязательно гляну

Комбюнити есть https://t.me/clickhouse_ru

Для меня это пока выглядит как группа евангелистов-экспериментаторов.

Но за ссылку спасибо, послежу внимательнее, а то вдруг сильно ошибаюсь)

Я вот не могу могу понять, чего есть такой тип людей смеющихся с пхп?