На самом деле по толковым вебщикам ситуация не сильно лучше. Студентов по быстрому налабать формочку конечно найти можно. А вот если что посерьезней, чтобы не только фронт-енд был. Чтобы адекватно архитектурил — таких тоже нема… Им же как раз проще фрилансить.
Увы не для моего бизнеса… А местный дядя уверен, что «все в рынке», так как честно усреднили и синьора с++ коих единицы и эникейщиков… а то чтовакансии не закрываются — так это HR работает плохо, да руководители групп многого от кандидатов хотят.
Опять путаете программистов и эникейщиков. 150-200 это программисты, которые могут за полгода впятером налабать продукт, который потом продаваны год продавать будут и на яхту владельцу зарабатывать…
А те что формочки и отчетики клепают они так и получают 30-40к
Ну хотя бы слава Богу научили их отличать эникейщиков от сис.админов, а тех в свою очередь от разрабов. Ну а насчет «С++ программисты уже получают где то больше»: «Есть три вида лжи: Ложь, полуправда и статистика.»
Например для меня это вопрос найма людей… Мне HR специалисты утверждают (наверное на основе каких-то исследований), что у нас конкурентная з.п. Тем временем 95% претендентов на роль мидла «с++ разработчик» с окладом 100к брутто срезаются на первом же вопросе «напишите метод, который из std::list data удалит все элементы с четным значением».
Если следовать приведенным выше в комментах аналогиям с электриками это «прикрутите розетку вот к этим 2 проводам»…
А других кандидатов просто нет… Не знаю где они, но на собеседования не приходят.
А ну и конечно в итоге же виноватят меня: «у вас требования завышенные» / «мы вам кандидатов приводим, а вы их не берете» ну и в том же духе.
Хорошая статья — спорная. Около-владельцы / бизнесмены будут утверждать что все брехня, что программеры зажрались…
А по факту: руководство и HR утверждают что з/п «в рынке» (типа 100к это ОК), а тем временем очередной кандидат «забывает» про собеседование на 140к.руб.
Лично я в упор не понимаю, почему программист / айтишник должен отличаться от кого-то ещё — скажем, от бухгалтера или кадровика (при условии, разумеется, что мы говорим о ценных специалистах). Совершенно такой же работник со своими должностными обязанностями.
А и не надо понимать. Речь сейчас идет о дефиците грамотных спецов на Российском IT. Возможно программер даже менее полезен чем бухгалтер… Вот только он может из дома работать на западного дядю получая в разы больше чем мог бы у местного дяди, а бухгалтер — не может (просто в виду другого налогового законодательства например).
Но повторяю — речь тупо о дефиците — нет людей. Я полгода закрываю вакансию C++ програмера (мидл/сеньер). Бюджет 150круб/мес грязными.
Ну Нижний все таки скорее исключение — он слишком далеко от Москвы чтобы имело смысл здесь держать филиалы, но при этом слишком близок чтобы можно было легко перетащить к себе специалиста в Москву. Поэтому в крупных IT компаниях з/п уровня Московских за минусом «неудобств с еженедельным мотанием на ласточке домой, релокацией». Но все это до уровня сеньеров… А дальше — если надо Москва сманивает просто на раз-два.
вы пропустили слова «предполагается» и «должен». Прокси ведь участвует в процедуре обмена сессионными ключами между вами и собеседником. Вы уверены что ключ посланный вам собеседником и присланный вам прокси один и тот же, а прокси не реализует MITM?
Угу именно про ivi. Не спорю — ребята прошареные, только хайлоад бывает сильно по разному хай.
Вы же раньше писали про другой порядок чисел?
25ТБ индекса имелось в виду именно в пересчете на 1 сервер хранения конечно. Т.е. 25ТБ/сервер именно, из за того что Ластик довольно таки неплохо масштабируется. И именно потому что хайлоад. Смысл писать «у нас хайлоад, у нас миллион пользователей в сутки»? Вы пишите, а сколько при этом у вас железа. А то миллион пользователей в сутки на 1 сервер и на 100 серверов — абсолютно разные вещи даже по спектру возникающих задач, проблем и путей их решения.
Ну а то, что при работе с 5 ПЕТАбайтами разработчик системы будет не простой пользователь/потребитель готовой СУБД, а было бы неплохо чтобы и разбирался досканально и проектировали архитектуру под задачу — совершенно естественно, имхо.
На самом деле любая задача которая претендует на хайлоад уже требует «досконально разобраться». Решения «из коробки» типа elastic или postgres годны только так попробовать понюхать… И для более менее серьезного использования требуют анализа и допиливания в лучшем случае конфигов.
Говоря про 25 ТБ/сервер для эластика -я немного лукавлю. Порог был 5-10ТБ/сервер после которого я решил что проще будет «допилить» эластик…
но 10-25ТБ порог «а давайте рискнем с допиленным ластиком» не превзошел «давайте добавим оперативы».
И следующим порогом >25 ТБ/сервер стало — давайте уже напишем собственную «СУБД».
Ребята на Хайлоад не нюхали жизни… Я как раз сейчас говорю про уже размазанную задачу. Я говорю про эээ метакластер на базе elasticsearch на 200+ серверов общим размеров 5 ПЕТАбайт. И кластер на 200 серверов рулится очень плохо, и я бы предпочел чтобы там было только 100 а лучше 50 серверов. Причем из этих 5 ПБ «горячими» являются только 50 ТБ… Т.е. для нормально работы по горячим данным мне хватило бы 500 Гиг ОЗУ на весь кластер, а приходится набивать 25 террабайт озу… только чтобы открыть эти индексы которые не нужны…
Ой, да домохозяйкам и на значек то «безопасный/небезопасный» плевать. Они зачастую и не догадываются о существовании строки для ввода адреса то. А на любимый сайт «одноквасники» попадают через гугление а потом тыке на первой ссылке. И хорошо если только бы они в соцсети так же лазили. А по факту во всякие «зеленый банк онлайн» они также попадают.
Пчелы против меда? Они бы еще с ФСБ России свой алгоритм предложили.
а то как сеансы связи кофеварок с тостером читат станут?
ну как сказать… Вот есть у вас какой нибудь «смарт-датчик» узнающий вас по «фотографии»… что мешает ему сливать фотографии всех кого у вас в комнате узнает…
На самом деле термвектора в постгрессе это «недоэластик» и по сути весь FTS завязанный на обработке этих векторов приходиться писать самостоятельно… Те же токенизаторы, анализаторы. Да и алгоритмы выбора и ранжирования документов тоже… Но с другой это имеет право на жизнь если вам ничего кроме элементарного поиска не нужно, и гораздо более важна например задача целостности данных, или возможность апдейтов.
и намного больше углубился в изучение родных возможностей Postgre.
тоже не бесплатно.
По факту — какие то возможности лучше реализованы «из коробки» в ластике, для этих же фич к Постгресу необходимо ляпать жуткие костыли например партиционирование и федеративные запросы, с другой стороны некоторые банальнейшие задачи для Постгреса типа «проапдейтить поле по уникальному значению doc_id» — это костыли для ластика.
Как правило если у вас возникает выбор между Реляционный PostgreSQL или нереляционный FTS Elastic — вывод — как таковая транзакционность, нормализация и другие плюшки Postgres вам не нужны, а надо вам масштабирование, гибкая документоориентированная модель и полнотекстовый поиск.
А то что вы не можете склониться в сторону Ластика — значит что масштабы у вас так себе и пока еще справляется вертикальная модель, что документы ваши не настолько гибкие и структура понятна, а полнотекстовый поиск довольно ограничен. В итоге вы можете сделать как реализацию на постгресе так и на ластике, при этом в обоих случаях придется писать костыли.
Практически, это предел даже для логов. В ластике by-design есть требование — открытый индекс держит в памяти минимум 0,2% от объема индекса на диске. Причем это тот минимум когда отключены все фичи. Реально на практике меньше 0,5% я не видал.
Это приводит к тому что для 25ТБ индексов надо иметь ОЗУ 125 гиг только чтобы открыть эти индексы. Итого на серваке с 256 Гб ОЗУ все это работает в режиме «еле ворочается» — секунда на запрос. А если учесть насколько JAVA плохо работает с объемом HEAP за 32 гига, то приходиться изгаляться с кучей экземпляров…
И повторюсь, это для достаточно простых операций.
Выгружать/загружать индексы по требованию — тоже не решение: в момент загрузки индекса — кластер краснеет.
Я предлагал для elastic решение по «заморозке» индекса и их прозрачной загрузке выгрузке, но команда его разработки отказалась сказав «вам просто надо больше нод/памяти».
На самом деле странный выбор в пользу Ластика вместо постгресса.
30 тысяч записей для постгресса это не много, впрочем как и для ластика. Но при этом Слон предсказуем и по скорости и по расходу памяти.
Собственно сами когда-то делали выбор:
+ Постгрес предсказуем по расходу ОЗУ, который не зависит от объема БД.
— Ластик — тоже предсказуем — вынь да положь ему от 0,2 — 0,5% от объема индекса на диске даже если выключить все фичи причем это «work as designed» github.com/elastic/elasticsearch/issues/10869 в нашем случае это приводит к пределу 25 ТБ индекса на сервер из которых 24 ТБ — «холодные».
+ Ластик хорошо масштабируется ( раньше я сказал бы что шикарно, но сейчас только хорошо) 5-7 нод — смело. 20-40 нод с осторожностью… Больше 40 только если у вас мало индексов или они редко создаются — уничтожаются. Ибо синхронизация метаинформации между кандидатами в мастера для большого числа индексов (а точнее шардов) может занимать существенное время.
— Постгрес масштабируется от слова никак. Т.е. там есть механизмы master-slave чутка ущербный by-design но работает. Механизм multimaster находится в зачаточном состоянии (я про версию 9 говорю), но с помощью костылей и палок получается заставить работать кластер из 3 узлов в режиме мультимастера… но это хардкор.
+ Постгрес — это хорошая, взрослая, реляционная СУБД MVCC-типа. С транзакциями!
— Ластик в таком режиме — NoSQL система eventualy consistensy, если вам нужен «не точный поиск то оно вам самое то» а вот если вам понадобился поиск точный, да еще и например с сортировкой, да еще и с повторяющимися вариантами — подумайте дважды. Сделать можно, но местами ни разу не тривиально.
Ну и прочее, прочее прочее…
Мое мнение отталкиваться от производительности при выборе elastic/postgre ни разу не правильно.
А те что формочки и отчетики клепают они так и получают 30-40к
Если следовать приведенным выше в комментах аналогиям с электриками это «прикрутите розетку вот к этим 2 проводам»…
А других кандидатов просто нет… Не знаю где они, но на собеседования не приходят.
А ну и конечно в итоге же виноватят меня: «у вас требования завышенные» / «мы вам кандидатов приводим, а вы их не берете» ну и в том же духе.
А по факту: руководство и HR утверждают что з/п «в рынке» (типа 100к это ОК), а тем временем очередной кандидат «забывает» про собеседование на 140к.руб.
А и не надо понимать. Речь сейчас идет о дефиците грамотных спецов на Российском IT. Возможно программер даже менее полезен чем бухгалтер… Вот только он может из дома работать на западного дядю получая в разы больше чем мог бы у местного дяди, а бухгалтер — не может (просто в виду другого налогового законодательства например).
Но повторяю — речь тупо о дефиците — нет людей. Я полгода закрываю вакансию C++ програмера (мидл/сеньер). Бюджет 150круб/мес грязными.
Угу именно про ivi. Не спорю — ребята прошареные, только хайлоад бывает сильно по разному хай.
25ТБ индекса имелось в виду именно в пересчете на 1 сервер хранения конечно. Т.е. 25ТБ/сервер именно, из за того что Ластик довольно таки неплохо масштабируется. И именно потому что хайлоад. Смысл писать «у нас хайлоад, у нас миллион пользователей в сутки»? Вы пишите, а сколько при этом у вас железа. А то миллион пользователей в сутки на 1 сервер и на 100 серверов — абсолютно разные вещи даже по спектру возникающих задач, проблем и путей их решения.
На самом деле любая задача которая претендует на хайлоад уже требует «досконально разобраться». Решения «из коробки» типа elastic или postgres годны только так попробовать понюхать… И для более менее серьезного использования требуют анализа и допиливания в лучшем случае конфигов.
Говоря про 25 ТБ/сервер для эластика -я немного лукавлю. Порог был 5-10ТБ/сервер после которого я решил что проще будет «допилить» эластик…
но 10-25ТБ порог «а давайте рискнем с допиленным ластиком» не превзошел «давайте добавим оперативы».
И следующим порогом >25 ТБ/сервер стало — давайте уже напишем собственную «СУБД».
ну как сказать… Вот есть у вас какой нибудь «смарт-датчик» узнающий вас по «фотографии»… что мешает ему сливать фотографии всех кого у вас в комнате узнает…
По факту — какие то возможности лучше реализованы «из коробки» в ластике, для этих же фич к Постгресу необходимо ляпать жуткие костыли например партиционирование и федеративные запросы, с другой стороны некоторые банальнейшие задачи для Постгреса типа «проапдейтить поле по уникальному значению doc_id» — это костыли для ластика.
Как правило если у вас возникает выбор между Реляционный PostgreSQL или нереляционный FTS Elastic — вывод — как таковая транзакционность, нормализация и другие плюшки Postgres вам не нужны, а надо вам масштабирование, гибкая документоориентированная модель и полнотекстовый поиск.
А то что вы не можете склониться в сторону Ластика — значит что масштабы у вас так себе и пока еще справляется вертикальная модель, что документы ваши не настолько гибкие и структура понятна, а полнотекстовый поиск довольно ограничен. В итоге вы можете сделать как реализацию на постгресе так и на ластике, при этом в обоих случаях придется писать костыли.
Это приводит к тому что для 25ТБ индексов надо иметь ОЗУ 125 гиг только чтобы открыть эти индексы. Итого на серваке с 256 Гб ОЗУ все это работает в режиме «еле ворочается» — секунда на запрос. А если учесть насколько JAVA плохо работает с объемом HEAP за 32 гига, то приходиться изгаляться с кучей экземпляров…
И повторюсь, это для достаточно простых операций.
Выгружать/загружать индексы по требованию — тоже не решение: в момент загрузки индекса — кластер краснеет.
Я предлагал для elastic решение по «заморозке» индекса и их прозрачной загрузке выгрузке, но команда его разработки отказалась сказав «вам просто надо больше нод/памяти».
30 тысяч записей для постгресса это не много, впрочем как и для ластика. Но при этом Слон предсказуем и по скорости и по расходу памяти.
Собственно сами когда-то делали выбор:
+ Постгрес предсказуем по расходу ОЗУ, который не зависит от объема БД.
— Ластик — тоже предсказуем — вынь да положь ему от 0,2 — 0,5% от объема индекса на диске даже если выключить все фичи причем это «work as designed» github.com/elastic/elasticsearch/issues/10869 в нашем случае это приводит к пределу 25 ТБ индекса на сервер из которых 24 ТБ — «холодные».
+ Ластик хорошо масштабируется ( раньше я сказал бы что шикарно, но сейчас только хорошо) 5-7 нод — смело. 20-40 нод с осторожностью… Больше 40 только если у вас мало индексов или они редко создаются — уничтожаются. Ибо синхронизация метаинформации между кандидатами в мастера для большого числа индексов (а точнее шардов) может занимать существенное время.
— Постгрес масштабируется от слова никак. Т.е. там есть механизмы master-slave чутка ущербный by-design но работает. Механизм multimaster находится в зачаточном состоянии (я про версию 9 говорю), но с помощью костылей и палок получается заставить работать кластер из 3 узлов в режиме мультимастера… но это хардкор.
+ Постгрес — это хорошая, взрослая, реляционная СУБД MVCC-типа. С транзакциями!
— Ластик в таком режиме — NoSQL система eventualy consistensy, если вам нужен «не точный поиск то оно вам самое то» а вот если вам понадобился поиск точный, да еще и например с сортировкой, да еще и с повторяющимися вариантами — подумайте дважды. Сделать можно, но местами ни разу не тривиально.
Ну и прочее, прочее прочее…
Мое мнение отталкиваться от производительности при выборе elastic/postgre ни разу не правильно.