Вы обновили библиотеку HTTP запросов до самой последней версии в последнем релизе.
Нда? А к «элегантной программе», «с точно требуемым количеством абстракций», «безупречны модулям» — тестирования не прилагалось?
И «самый почтенный по годам специалист компании» не станет произносить эту мудрую, но бессмысленную в данной ситуации фразу выделенную курсивом (ради которой, очевидно, и писался рассказ). А бросит коротко — «ну, что ж откатывайся, а потом действуй по своему плану». Еще может быть, для одобрения, пошутит вроде: «в этим мире нельзя никому доверять,… мне можно».
Вы в общем то правы, это нормальное поведение для обычного «рабочего» (слесаря к примеру). Только вот проблема в том, что программисты в IT это не слесаря, это инженеры. В ваших терминах скорее всего подойдет аббревиатура ИТР (как в общем любом производстве). Я сомневаюсь что хорошие ИТР на производстве слепо следуют указаниям начальства.
В свое время я работал в металлургии и помню как инженеры и директора матом друг друга крыли на планерках обсуждая какую то проблему, при этом ни кто тупым приказам сверху почему то слепо не следовал. После конечно, приходили к какому то консенсусу, и производство не вставало, или возвращалось в нормальный режим работы. От части только потому, что есть ИТР работники которые думают головой.
Если начальник сойдет с ума и прикажет вместо перфоратора пробивать стену головой, то до приезда санитаров следует безоговорочно биться головой о стену — это будет единственный ПРАВИЛЬНЫЙ поступок любого работника.
Вы описали обычное армейское слепое повиновение.
Правильный поступок — это ПОЛОЖИТЬ БОЛТ на неадекватный приказ.
Процитирую военного гения Сунь-Цзы, написавшего «Искусство войны»:
Бывают дороги, по которым не идут; бывают армии, на которые не нападают; бывают крепости, из-за которых не борются; бывают местности, из-за которых не сражаются; бывают повеления государя, которых не выполняют.
>> начальство прикажет вам разбить, это следует немедля сделать
>Дело в том, что ИТ — вещь очень специфичная. Далеко не каждый начальник вообще понимает, чем вы заняты.
Согласен с предыдущим ораторам. Я при возникновении проблем прихожу к начальнику с несколькими решениями, объясняю о плюсах и минусах, и просто, предлагаю ему выбор
Не совсем так. Например, если Вы выполняете приказ более вышестоящего начальника (в нашем случае требований качества ПО), то Вы обязаны доложить об этом отдавающему приказ, и после этого он принимает решение — повторить приказ и тогда Вы обязаны его выполнять или не повторять.
А когда речь идет о производстве, то служебная (докладная) записка с перечнем возможных проблем и Ваша совесть чиста и через месяц на вопрос начальника «А Вы не предупреждали, что так нельзя» чпокойно демонстрируете копию с его подписью.
В армии, в уставе есть пункты:
1. про то что надо выполнять приказ, а потом оспаривать
2. если приказ унижает личное достоинство подчинённого, его можно НЕ ВЫПОЛНЯТЬ.
Так что там тоже не всё так плохо и головой биться об стены не обязательно.
Это касается всего инженерного состава. Они же все либо придумывают детальки, либо собирают из деталей убермашины. Да и программисты, если так подумать, тоже инженеры. Куча непонятных терминов, постоянно витают в облаках, результат труда не ясен до завершения, требуются навыки а гуманитарных областях, и вишенка на торте — 100500 ошибок на выходе.
Вы описали обычное армейское слепое повиновение.
> Биться головой об стену
Кажется, голова не хозяйская, а своя. Если только тебя не продали в рабство
> начальство прикажет вам разбить, это следует немедля сделать
Дело в том, что ИТ — вещь очень специфичная. Далеко не каждый начальник вообще понимает, чем вы заняты. И если он скажет убрать не нужный сервер, и вы удалите по слепому приказу сервак менеджеров(продавцов. Ведь сервак вам не нужен?), то выкручиваться в стиле «мне приказали, я сделал» не получится. Начальник покрутит у виска, спросит зачем тебе голова и попросит увольняться, и будет прав в целом.
На заводах люди совсем по-другому работают, чем в бизнесе. Одно ваше слово «ХОЗЯЙСКОЕ» о многом говорит. И к воровству там относятся проще, мол хозяин жадничает, вот я и утащил. Возможно, приказы на заводе и дело вынужденное, но не могу говорить за другие места.
И манагер и девелопер — зелень. Манагер был бы крутым, если бы не орал, а девелоперу надо понимать как можно «похачить» чтобы и система не «взорвалась» и пользователь остался доволен. Цель работающее ПО, какие хаки внутри — проблема компании. Конечному пользователю абсолютно до лампочки.
очень интересно, но не оставляет впечатление «каши из топора».
В том смысле, что берем кэш, прикручиваем к нему фичи БД, выкидываем девяносто процентов данных в другую «медленную» базу, и он показывает чудеса производительности в качестве БД. И не понятно, толи выигрыш за счёт замечательной архитектуры, толи за счёт выигрыша по объему. Правда используют хранение данных в памяти, а не на диске, что может дать выигрыш в скорости.
И как отметили, интересно было бы почитать, как происходит разбивка данных на горячие и холодные.
Спасибо, прочитал. Понял, что все ~100GB хранятся в RAM. Если честно, то очень сомневаюсь в таком подходе. Ну — во всяком случае не понимаю зачем для этого отдельная БД. У всех современных БД есть подсистема кэширования. Я уж не говорю о том, что на серверах приложения так же можно создавать кэши с репликацией. + не понятно что значит что транзакции выполняются в одном потоке… Если сервер приложения создает пул из ~50 тредов и они будут формировать транзакции, то со стороны БД что будет происходить? Они будут в очередь выстраиваться? Т.е. если в обработке сейчас одна транзакция, то вторая будет в ожидании в любом случае? А если это распределенные транзакции?
Посмотрите например вот это или можете сами поискать доклады Константина Осипова он архитектор этой БД и уже есть достаточно много записей его докладов, где он достаточно подробно и на понятном языке рассказывает как устроен tarantool, для каких задач оптимизирован и какие есть плюсы и минусы у этой БД.
Могу пригласить мейлрушных админов в чат. С точки зрения эксплуатации — одна из самых простых СУБД в мире. Бэкапить можно прямо на горячюю, копированием файлов из под базы. Либо через встроенный инструмент создания реплики (по сути — создается реплика и тут же отключается от мастера — вот и бэкап). В обоих случаях бэкап всегда целостный и производительность СУБД во время создания бэкапа не приседает. Целостность гарантируется. Можно включить в настройках fsync, можно выключить — тут ничем от других классических СУБД не отличается. Сломаться — я такого не припомню. Извлечь можно все из логов и из снэпшотов. Более того, если из-за бага в коде в базу пришел плохой коммит, то его можно выкусить из середины. Делается это так — берется старый снэпшот (до коммита) и на него накатываются все логи, с исключением из них плохого коммита. Деградация возможна, если запустить долгоиграющие хранимые процедуры (с пустыми циклами, например). Не делайте так :-)
Не понятно кто и как управляет распределением холодных и горячих данных, это какой-то внешний процесс или тарантул сам скидывает редко используемые данные в «холодное хранилище»?
Не совсем понимаю. Если вы сделали кэш а-ля свою кэширующую БД на 100GB, то какое основное отличие от обычной БД, благодаря которому обращение к данным происходит быстрее? Принцип хранения данных? По итоговой схеме становится понятно, что к MySQL обращения происходят более редко за счет того, что ко всем горячим данным они идут в tarantool. Но ведь т.о. большая часть нагрузки теперь падает на него. Цитирую: «Мы разработали специальную базу данных для горячих данных» — из этого понятно только то, что большая часть обращений будет падать на вашу новую бд, которую также придется маштабировать. Можете как-то уточнить?
И «самый почтенный по годам специалист компании» не станет произносить эту мудрую, но бессмысленную в данной ситуации фразу выделенную курсивом (ради которой, очевидно, и писался рассказ). А бросит коротко — «ну, что ж откатывайся, а потом действуй по своему плану». Еще может быть, для одобрения, пошутит вроде: «в этим мире нельзя никому доверять,… мне можно».
В свое время я работал в металлургии и помню как инженеры и директора матом друг друга крыли на планерках обсуждая какую то проблему, при этом ни кто тупым приказам сверху почему то слепо не следовал. После конечно, приходили к какому то консенсусу, и производство не вставало, или возвращалось в нормальный режим работы. От части только потому, что есть ИТР работники которые думают головой.
Правильный поступок — это ПОЛОЖИТЬ БОЛТ на неадекватный приказ.
Процитирую военного гения Сунь-Цзы, написавшего «Искусство войны»:
>Дело в том, что ИТ — вещь очень специфичная. Далеко не каждый начальник вообще понимает, чем вы заняты.
Согласен с предыдущим ораторам. Я при возникновении проблем прихожу к начальнику с несколькими решениями, объясняю о плюсах и минусах, и просто, предлагаю ему выбор
А когда речь идет о производстве, то служебная (докладная) записка с перечнем возможных проблем и Ваша совесть чиста и через месяц на вопрос начальника «А Вы не предупреждали, что так нельзя» чпокойно демонстрируете копию с его подписью.
1. про то что надо выполнять приказ, а потом оспаривать
2. если приказ унижает личное достоинство подчинённого, его можно НЕ ВЫПОЛНЯТЬ.
Так что там тоже не всё так плохо и головой биться об стены не обязательно.
> Биться головой об стену
Кажется, голова не хозяйская, а своя. Если только тебя не продали в рабство
> начальство прикажет вам разбить, это следует немедля сделать
Дело в том, что ИТ — вещь очень специфичная. Далеко не каждый начальник вообще понимает, чем вы заняты. И если он скажет убрать не нужный сервер, и вы удалите по слепому приказу сервак менеджеров(продавцов. Ведь сервак вам не нужен?), то выкручиваться в стиле «мне приказали, я сделал» не получится. Начальник покрутит у виска, спросит зачем тебе голова и попросит увольняться, и будет прав в целом.
На заводах люди совсем по-другому работают, чем в бизнесе. Одно ваше слово «ХОЗЯЙСКОЕ» о многом говорит. И к воровству там относятся проще, мол хозяин жадничает, вот я и утащил. Возможно, приказы на заводе и дело вынужденное, но не могу говорить за другие места.
В том смысле, что берем кэш, прикручиваем к нему фичи БД, выкидываем девяносто процентов данных в другую «медленную» базу, и он показывает чудеса производительности в качестве БД. И не понятно, толи выигрыш за счёт замечательной архитектуры, толи за счёт выигрыша по объему. Правда используют хранение данных в памяти, а не на диске, что может дать выигрыш в скорости.
И как отметили, интересно было бы почитать, как происходит разбивка данных на горячие и холодные.
Его 3 раза об этом спрашивали, но он так толком и не ответил… Видимо, в их кейсе не учитывается остывание данных.
Хорошо бы вспомнить еще один очень важный параметр — надежность в широком смысле этого слова.
Классические СУБД отличаются еще и тем, что им можно доверить важные данные, а что касается NoSQL и прочих хранилищ новой формации...
И прочие неприятные моменты, которые выясняются только при эксплуатации.
Мне вспоминается притча Мастер Фу и десять тысяч строк кода.
На bash это можно сделать вот так: