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

я еще знаю девопса психолога

Теперь у этого быдла открытые редисы и монги наружу торчат (тысячи их), но админы этому быдлу не нужны. Они ж программисты. Инфраструктура как код. А код они писать умеют :)))

знатный у тебя багет

а я скажу что деплои это сложна

Ты про телеграмовский девопс_ру? Да там просто активны те, что из админов :) одни и те же лица и Чистяков

ну вот :)

чистякова знают все

А я скажу, если ты ещё новичок тут и не понял, что я то как раз админ, бггг :))

ну всех не запомнишь

и я наверное не задержусь

What is девопс?

набор практик. типа паттернов проектирования и аджайл.

я не могу не агриться

Скатертью дорога, к девочкам в чатик :))

О, тогда тебе сюда. Тут весь чатик про агриться :)))

Теперь у этого быдла открытые редисы и монги наружу торчат (тысячи их), но админы этому быдлу не нужны. Они ж программисты. Инфраструктура как код. А код они писать умеют :)))

это быдлы, у которых, извините, хеллоу ворлд начинает содержать 17 паттернов сразу после прочтения книжки про паттерны

им что не дай, всё запоганят.

ну девопс это когда пытаешься писать деплой скрипт и вроде все просто но понимаешь что это работа на фултайм

нет тут никаких аджайлов и практик

оно просто требует времени и все

ну девопс это когда пытаешься писать деплой скрипт и вроде все просто но понимаешь что это работа на фултайм

нет, это не так.

Нам в чатике питона девочки не давали агриться и мы устроили вот этот бордель, свой собственный

ну у кого то может и не так

это быдлы, у которых, извините, хеллоу ворлд начинает содержать 17 паттернов сразу после прочтения книжки про паттерны

Дай пять!

Деплой скрипт, щас каждый пацан с fabric - девопс, ибо хорошо в резюме смотрится :) ясен хрен это скучно, если на фуллтайм

ну у кого то может и не так

ну, у авторов это не так. я стараюсь внедрять девопс-практики у себя в команде. для этого я пинаю админа, чтобы он пояснял девелоперам что нужно от приложения (метрики-хуетрики, как логи писать), чтобы админ ночью мог быстро разобраться, и пинаю программистов, чтобы они поясняли админу, что идёт нахер, а не логи в сислог. И пинаю менеджмент, что ну его нахер, а не релиз раз в месяц. Т.е. раз в день надо. Ну и feature toggles, чтобы бизнес управлял релизами фич.

ну фабрик все хейтят

ну, у авторов это не так. я стараюсь внедрять девопс-практики у себя в команде. для этого я пинаю админа, чтобы он пояснял девелоперам что нужно от приложения (метрики-хуетрики, как логи писать), чтобы админ ночью мог быстро разобраться, и пинаю программистов, чтобы они поясняли админу, что идёт нахер, а не логи в сислог. И пинаю менеджмент, что ну его нахер, а не релиз раз в месяц. Т.е. раз в день надо. Ну и feature toggles, чтобы бизнес управлял релизами фич.

Вот так я 15 лет и работал, когда ещё не было не то что мейестримом, а и слова девопс не было :) Только назывался "админом" :)

Вот так я 15 лет и работал, когда ещё не было не то что мейестримом, а и слова девопс не было :) Только назывался "админом" :)

ну у меня это называется "server team lead"

просто уже как то стерлась грань между админством и программированием

кодерок щас больше конфиги нжинкса пишет, хранимки, крон скрипты

Вообще забавно мир устроен. Нынче программисты жалуются, что скучно и лезут админить. Я в своё время скучал админить и писал бэкенд со своими программистами :))

кодерок щас больше конфиги нжинкса пишет, хранимки, крон скрипты

ну, "больше" - это большой вопрос.

просто уже как то стерлась грань между админством и программированием

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

кодерок щас больше конфиги нжинкса пишет, хранимки, крон скрипты

Я писал выше, откуда это началось. Просто "мы не похаебы, мы умнее, знаем про крон, нам админы не нужны. И DBA не нужны" :) ну вот теперь и пишут, как могут.

У них и железо не нужно, есть облака. Кого там мониторить? Это каменный век, есть ньюрелик! :)))

ну, дба в целом не нужны.

у бизнес спрашивать не будет

Говорили они

а дба думают наверное иначе

дба нужны, но не всем

ну я - дба, я считаю, что это очень нишевая вещь и должна быть совмещена с чем-то. чистый дба не нужен.

нужны не только лишь всем, мало кому (с) :) Но их и мало настоящих, так что они без работы не сидят и никогда сидеть не будут

та чего не будут. легко

я бы все писал на скуэлях

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

та чего не будут. легко

Я про дба, а не про программиста, который уже научился индекс создавать, поэтому теперь дба :)

ох у каждого своя боль

Я про дба, а не про программиста, который уже научился индекс создавать, поэтому теперь дба :)

это примерно как девопс, ага. я всех, у кого в навыках написана какая-то субдшечка спрашиваю одну штуку.

"у вас есть индекс по числовому полю и ваш запрос выбирает по нему 30% большой (миллионы строк) таблицы. Будет ли использоваться индекс?"

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

Мало у кого просто есть базы такие, где нужен дба, ну правда. Поэтому все с удовольствием говорят про дба, хотя даже не представляют, что это :)

"у вас есть индекс по числовому полю и ваш запрос выбирает по нему 30% большой (миллионы строк) таблицы. Будет ли использоваться индекс?"

Не будет

"у вас есть индекс по числовому полю и ваш запрос выбирает по нему 30% большой (миллионы строк) таблицы. Будет ли использоваться индекс?"

какая разница будет или нет если весь ботлнек в ио ?

Не будет

В большей части случаев, да. В sql server иногда будет даже по дефолту, и можно сделать почти всегда. Но это надо написать "Sql Server 2012 хорошо знаю"

как разработчики базы написали планировщик кверь так и будет. к.о.

какая разница будет или нет если весь ботлнек в ио ?

у тебя все данные в памяти. нет io.

Это просто тот самый случай, когда "проще полный перебор"

у тебя все данные в памяти. нет io.

значит она не большая :)

или я не так прочитал

ну как обычно вопросы которые проще проверить чем знать

И Анатолий прав, знает это только тот, кто хоть раз видел explain на миллионах строк, а не прочёл на хабре статью про создание индексов в MySQL и теперь пишет в своём резюме баззворды :)

значит она не большая :)

https://pbs.twimg.com/media/C3vkZz8WIAAulOX.jpg:large

Ну функциональная неграмотность "прочёл то, что хотел, а не то, о чем спрашивали" нынче тоже распространена :))

картинка - это сервер stack overflow, на котором крутится SQL Server 2016, в котором лежит весь контент Stack Overflow.

да они хвастались как круто они отмасштабировались

Это просто тот самый случай, когда "проще полный перебор"

в sql server можно сделать create index (field) include(col1, col2), тогда, может быть, key lookups будут не нужны.

Анатолий, грубо говоря, спросил просто про таблицу в миллионы строк. Эта таблица может быть из двух столбцов. В одном число с индексом, в другом ещё одно небольшое поле. Ну и схуя ли оно все это даже на ноуте в память то не войдёт? С миллионами строк :)

но это такие, очень тонкие нюансы.

Я даже не сильно стебусь сейчас. Дата и вольтаж, дата и градусы, да мало ли.

Я даже не сильно стебусь сейчас. Дата и вольтаж, дата и градусы, да мало ли.

да просто табличка для многие-ко-многим отношения

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

Конечно. Там вообще два числа.

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

rule of thumb: если данных больше процента выбирается, индекс почти никогда не используется. потому что потом по индексу надо делать key lookup, чтобы достать данные. только и всего. io там не сильно важен.

ну проще обойти последовательно память чем дрочить деревья и всеравно обходить память с кучей промахов кеша

Это Анатолий ещё тонко спросил про 30%. Я спрашивал вообще святую толстоту, если в запрос попадут 90%, почему эксплайн без индекса? Ты что его создать забыл? У некоторых руки потели.

А в резюме "уверенное знание" конечно

индустрия основанная на кошмариньи

А в эксплайн смотрит и правда без индекса. В индексы смотрит, а он там есть. Мокрые ладошки и заикание.

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

ну проще обойти последовательно память чем дрочить деревья и всеравно обходить память с кучей промахов кеша

ну, тут надо знать конкретную СУБД. Например, SQL Server никогда не работает с данными на диске. Т.е. он все необходимые данные грузит в память всегда. Это и плюс, и минус. mysql и postgresql не знаю, их не курил никогда.

Но как? На хабре ведь писали .... :))

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

нельзя эффективный трёхэтажный вопрос построить, не зная вот этот вот ответ про индексы.

ну, тут надо знать конкретную СУБД. Например, SQL Server никогда не работает с данными на диске. Т.е. он все необходимые данные грузит в память всегда. Это и плюс, и минус. mysql и postgresql не знаю, их не курил никогда.

это странно. что это за база которая все грузит в память

это странно. что это за база которая все грузит в память

ну, вот такая база. быстро делать рандомное IO с 200 IOPS очень затруднительно.

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

У нас в этой херне круто рубит вы не поверьте кто из команды. Изоляции, сложные запросы, хинты.

нельзя эффективный трёхэтажный вопрос построить, не зная вот этот вот ответ про индексы.

может ему не нужен был эффективный может он пару лет писал аналитику которую оставляешь на ночь а оа тебе считает окна через with рекурсив

это все приходящее

может ему не нужен был эффективный может он пару лет писал аналитику которую оставляешь на ночь а оа тебе считает окна через with рекурсив

для аналитики свои базы, на колонках основаны. там надо знать другие нюансы. Вон, рекомендую посмотреть на clickhouse. и многие СУБД умеют некоторые рекурсивные with оптимизировать в обычные запросы.

для аналитики свои базы, на колонках основаны. там надо знать другие нюансы. Вон, рекомендую посмотреть на clickhouse. и многие СУБД умеют некоторые рекурсивные with оптимизировать в обычные запросы.

свои но их попробуй выбери. есть истории успеза когда просто брали постгре

и есть redshift кажется

и ктото прикрутил колумнар сторадж

свои но их попробуй выбери. есть истории успеза когда просто брали постгре

ну, для аналитики есть vertica, есть columnstore в sql server, clickhouse и ещё что-то.

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

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

аналитика это та еще предметка

monetdb есть а mixpanel вообще психанули и написали свою бд

об остальном не слышал даже странно почему

об остальном не слышал даже странно почему

ну, вот кликхаус уверенно держит 4.3 петабайта и запросы быстро работают