«И тут я понял, что решать задачи бизнеса — думать о том, как принести работодателю больше прибыли.» — главный, и абсолютно ошибочный, тезис статьи.
Прибыль и работа с ней это задача продаванов и продукт-овнеров, но они, конечно же, будут пытаться на инженеров её переложить настолько, насколько смогут. Не надо на них обижаться, они смотрят со своей колокольни и им кажется, что их цели это цели всех… не надо обижаться хотя бы потому, что вы — программисты — делаете абсолютно тоже самое — создавая удобные, нужные и интересные… вам! а не им и клиентам, вещи, а потом смеясь какие все «тупые», что не понимают как «это всё круто», хотя ваша задача как профи в чём-то как раз и состоит в том, чтобы это что-то было для остальных непонимающих, если не понятно, то хотя бы удобно.
Да, синьёр действительно должен уметь решать именно «бизнес-задачи», только тут термин «бизнес-задача» (как и термин «бизнес-логика») не относится напрямую к монетизации, а относится к большой законченной системе, а не конкретному модулю/сервису. Именно такие, комплексные задачи, и называются «бизнес задачи» и тут нет ничего про деньги, только про техническую сложность комплексной системы, про оценку времени (то есть опять же сложности) и технических рисков предположений в архитектуре (опять же тех.сложность). Потому ими и занимаются синьёры, для них надо уметь не только кодить (джун), а ещё и решать сложные части системы основываясь на знаниях и опыте (мидл) и главное вести разработку всех этих компонентов вместе постоянно корректируя для максимально эффективного достижения _конечной_ цели, общего результата системы и таки выдавать _законченный_ результат с приемлемым техническим долгом (синьёр). Именно потому синьёры и ценны — они решают задачи, а не просто играются в технологии.
А зовут их на бизнес-встречи (в правильных компаниях) по двум причинам:
1. когда хотят обговорить конечные цели (а без них он не сможет эффективно разрабатывать) и, соответственно, хотят узнать можно ли вообще и, если да, то за сколько времени что-то сделать
2. синьёры и тимлиды разрабатывающие системы ближе всех к проекту и потому у них самих могут быть идеи в какую сторону с их точки зрения стоит развиваться и что можно сделать крутого (а хорошие продаваны потом продадут всё)
Если что, это было мнение не бизнес-аналитика-овнера-менеджера, а человека так же с детства (9ти лет) и до своих 39 всё ещё пишущего программки и не потерявшего к этому интерес. К тому же в моей компании вообще все продукты придумывали и продолжают придумывать технари (все продуктовнеры это бывшие разработчики, которые иногда всё ещё кодят), а наши продаваны каким-то гениальным образом их неплохо продают…
p.s.
не хочу судить автора, быть может у него реально странные работодатели и заставляют его заниматься предпродажными делами, но если это не так… то это может быть простая боязнь решать сложные технические задачи и нести за это ответственность, к сожалению я регулярно вижу это среди знакомых программистов и, частенько, всё списывается на «тупых» менеджеров которые вот ничего не понимают, а они, бедные, должны делать невозможное…
У вас есть реальный опыт работы со scylla? А до этого была с cassandra? Если можно — кратко минусы (плюсы у них на сайте разрекламированы) и вообще какова реальность? И что насчёт лицензионной политики?
Как долго после падения регион сервера кластер это понимает и как долго переезжает регион мастер?
Как об этом узнают клиенты?
Насколько это автоматически?
(Как вообще это выглядит для клиентов, если не секрет, интересно узнать)
Если так же поштучно (без батчей) работать с HB во много (100+) потоков насколько она у вас получилась быстрее? И на запись и на чтение интересует… Раз уж тестите, может и мой кейс на hb потестите )
Да, я вас понял, просто придрался :) к фразе, что может работать в режиме допускающем потерю данных, она может работать с любым количеством реалик и если копия только одна, то как бы вы ж сами выбрали, то есть это не минус это плюс, есть выбор, возможно вам для определённых таблиц не нужно лишнее дублирование и данные там если что не жалко.
Да, у нас тоже прилично данных, а главное куча изменений и ssd диски регулярно сыпятся, потому очень удобно иметь возможность в любой момент просто вытащить ноду из кластера (просто выключить) и что-то с ней поделать без пенальти.
"CS может использоваться в режиме допускающем потерю данных. Т.е. это когда только один сервер (нода) отвечает за данные некоего ключа и если он по какой-то причине отвалился, то значение этого ключа будет потеряно."
Если он отвалится, то данные не будут потеряны, они просто не будут доступны пока вы не поднимите эту ноду, а до тех пор вы получите ошибку чтения/записи, логично, ведь… вы сами задали хранение на одной ноде (rf=1).
Cs позволяет делать разные настройки для кейспейса (группы таблиц) и из коробки имеет понятие датацентра и настраиваемой политики реплик между дц. Так же можно задавать разную политику консистенции для каждого отдельного запроса. Так что вы сами настраиваете консистенси и авайлабилити считайте чуть ли не на каждый запрос, естественно, если вы хотите выстрелить себе в ногу, то cs даст вам массу возможностей, однако если вы знаете, что вы делаете, всё можно использовать в соответствующих юзкейсах.
Так же у cs присоединяются (и отсоединяются) ноды без дауниайма и какой-либо латенси.
Наш юзкейс это большое кол-во key=value записей (в основном) и чтений (~10:1) (рандомных по ключу), но все по одно и латенси критично (так что никаких батчей не получится собрать), но благодаря вашей статье я попробую посмотреть в сторону hbase ещё раз (5ть лет назад уже смотрел и тогда выбрал cs).
arheops писал про задержки в 500мс, это не cs, это java gc, если правильно под вашу нагрузку настроить и долгих gc, а тем более stw не будет (а 500мс это возможно оно), то вы даже 5мс никогда не увидите.
(Про scylladb знаю, но с ней были непонятки/проблемы год назад, может тоже посмотрю ещё раз)
Честно скажу, опыт только с кассандрой, с hbase нет.
Сравнение очень странное…
Вы сравниваете cassandra, базу, целью которой является высокая доступность, которая вообще без каких-либо латенси переживает вылет rf/2-1 ноду (то есть при rf=3 и rw=quorum (классика), вылет одной ноды вообще не влияет на работу кластера от слова совсем), с Hbase, которая, насколько мне известно работает через мастера и соответственно в случае его падения… не работает. То есть для high available бд не подходит…
Естественно база пишушая через один мастер всегда будет по умолчанию в выигрышной ситуации, хотя бы потому что у неё локализован весь кэш и индексы…
Но даже при этом вы используете кассандру совсем не по назначению, она по сути key-value база с группировкой колонок по pk. Классическое её использование это read/write (в основном второе) по конкретному ключу, по одной записи (high available риал тайм процессинг), батчи антипаттерн для неё, тем более (и это прям написано в доке) батчи содержащие ключи в разных нодах (что вы и сделали).
Как тут уже заметили кассандра работает с одним диском и ей нужен raid0, плюс она непосредственно через wal + sync заботится о гарантии записи, в то время как hdfs имеет свой мемори кэш.
В общем — сравнивать высокодоступную базу с базой имеющей мастера (point of failure) некорректно иначе надо сравнивать одну ноду cs с одной нодой hb, тогда честнее будет.
А если сравнивать — пишите в большое кол-во потоков (write workers в кассандре) с rf=3, но rw=quorum (классика) при этом по одной записи (один pk) в запросе, либо, чтобы все батчи уходили в одну партицию, иначе вы опять же сравниваете ha базу размазывающую с базой с одним мастером...
P.s.
Hb может и быстрее, но она ж для другого...
P.p.s.
Кстати, что это за кейс такой где нужна high availability и low latency и при этом батч операции? Зачем вы сравниваете cs и hb...
Сначала надо принять, что идеального решения нет вообще, никогда. Мы ищем лучшее решение в текущих условиях, а не идеальное.
Надо научиться оценивать (чувствовать?) «стоимость» решения в смысле профита от него относительно затрат сил и ресурсов. Тут много на уровне чувств, посчитать сложно или невозможно. Автор совершенно верно подобрал слово — гармония.
Выбирайте не более гибкие и крутые решения, а более гармоничные — когда чувствуете, что решение тут достаточное и оно ест столько ресурсов, которые стоят профита от него.
p.s.
в итоге «фигак-фигак и в продакшн, и так сойдёт» => возможно это решение и есть максимально близкое к гармоничному? просто вы хотели ненужной гибкости/крутости и не выслушали ваши чувства, которые вам подсказывали, что то, что вы делаете, слишком и ненужно сложно…
если же реально постоянно невозможно найти оптимально в «быстро-дёшево-качественно», то возможно и правда стоит сменить работу…
Прибыль и работа с ней это задача продаванов и продукт-овнеров, но они, конечно же, будут пытаться на инженеров её переложить настолько, насколько смогут. Не надо на них обижаться, они смотрят со своей колокольни и им кажется, что их цели это цели всех… не надо обижаться хотя бы потому, что вы — программисты — делаете абсолютно тоже самое — создавая удобные, нужные и интересные… вам! а не им и клиентам, вещи, а потом смеясь какие все «тупые», что не понимают как «это всё круто», хотя ваша задача как профи в чём-то как раз и состоит в том, чтобы это что-то было для остальных непонимающих, если не понятно, то хотя бы удобно.
Да, синьёр действительно должен уметь решать именно «бизнес-задачи», только тут термин «бизнес-задача» (как и термин «бизнес-логика») не относится напрямую к монетизации, а относится к большой законченной системе, а не конкретному модулю/сервису. Именно такие, комплексные задачи, и называются «бизнес задачи» и тут нет ничего про деньги, только про техническую сложность комплексной системы, про оценку времени (то есть опять же сложности) и технических рисков предположений в архитектуре (опять же тех.сложность). Потому ими и занимаются синьёры, для них надо уметь не только кодить (джун), а ещё и решать сложные части системы основываясь на знаниях и опыте (мидл) и главное вести разработку всех этих компонентов вместе постоянно корректируя для максимально эффективного достижения _конечной_ цели, общего результата системы и таки выдавать _законченный_ результат с приемлемым техническим долгом (синьёр). Именно потому синьёры и ценны — они решают задачи, а не просто играются в технологии.
А зовут их на бизнес-встречи (в правильных компаниях) по двум причинам:
1. когда хотят обговорить конечные цели (а без них он не сможет эффективно разрабатывать) и, соответственно, хотят узнать можно ли вообще и, если да, то за сколько времени что-то сделать
2. синьёры и тимлиды разрабатывающие системы ближе всех к проекту и потому у них самих могут быть идеи в какую сторону с их точки зрения стоит развиваться и что можно сделать крутого (а хорошие продаваны потом продадут всё)
Если что, это было мнение не бизнес-аналитика-овнера-менеджера, а человека так же с детства (9ти лет) и до своих 39 всё ещё пишущего программки и не потерявшего к этому интерес. К тому же в моей компании вообще все продукты придумывали и продолжают придумывать технари (все продуктовнеры это бывшие разработчики, которые иногда всё ещё кодят), а наши продаваны каким-то гениальным образом их неплохо продают…
p.s.
не хочу судить автора, быть может у него реально странные работодатели и заставляют его заниматься предпродажными делами, но если это не так… то это может быть простая боязнь решать сложные технические задачи и нести за это ответственность, к сожалению я регулярно вижу это среди знакомых программистов и, частенько, всё списывается на «тупых» менеджеров которые вот ничего не понимают, а они, бедные, должны делать невозможное…
Как долго после падения регион сервера кластер это понимает и как долго переезжает регион мастер?
Как об этом узнают клиенты?
Насколько это автоматически?
(Как вообще это выглядит для клиентов, если не секрет, интересно узнать)
Если так же поштучно (без батчей) работать с HB во много (100+) потоков насколько она у вас получилась быстрее? И на запись и на чтение интересует… Раз уж тестите, может и мой кейс на hb потестите )
Да, я вас понял, просто придрался :) к фразе, что может работать в режиме допускающем потерю данных, она может работать с любым количеством реалик и если копия только одна, то как бы вы ж сами выбрали, то есть это не минус это плюс, есть выбор, возможно вам для определённых таблиц не нужно лишнее дублирование и данные там если что не жалко.
Да, у нас тоже прилично данных, а главное куча изменений и ssd диски регулярно сыпятся, потому очень удобно иметь возможность в любой момент просто вытащить ноду из кластера (просто выключить) и что-то с ней поделать без пенальти.
"CS может использоваться в режиме допускающем потерю данных. Т.е. это когда только один сервер (нода) отвечает за данные некоего ключа и если он по какой-то причине отвалился, то значение этого ключа будет потеряно."
Если он отвалится, то данные не будут потеряны, они просто не будут доступны пока вы не поднимите эту ноду, а до тех пор вы получите ошибку чтения/записи, логично, ведь… вы сами задали хранение на одной ноде (rf=1).
Cs позволяет делать разные настройки для кейспейса (группы таблиц) и из коробки имеет понятие датацентра и настраиваемой политики реплик между дц. Так же можно задавать разную политику консистенции для каждого отдельного запроса. Так что вы сами настраиваете консистенси и авайлабилити считайте чуть ли не на каждый запрос, естественно, если вы хотите выстрелить себе в ногу, то cs даст вам массу возможностей, однако если вы знаете, что вы делаете, всё можно использовать в соответствующих юзкейсах.
Так же у cs присоединяются (и отсоединяются) ноды без дауниайма и какой-либо латенси.
Наш юзкейс это большое кол-во key=value записей (в основном) и чтений (~10:1) (рандомных по ключу), но все по одно и латенси критично (так что никаких батчей не получится собрать), но благодаря вашей статье я попробую посмотреть в сторону hbase ещё раз (5ть лет назад уже смотрел и тогда выбрал cs).
arheops писал про задержки в 500мс, это не cs, это java gc, если правильно под вашу нагрузку настроить и долгих gc, а тем более stw не будет (а 500мс это возможно оно), то вы даже 5мс никогда не увидите.
(Про scylladb знаю, но с ней были непонятки/проблемы год назад, может тоже посмотрю ещё раз)
Честно скажу, опыт только с кассандрой, с hbase нет.
Сравнение очень странное…
Вы сравниваете cassandra, базу, целью которой является высокая доступность, которая вообще без каких-либо латенси переживает вылет rf/2-1 ноду (то есть при rf=3 и rw=quorum (классика), вылет одной ноды вообще не влияет на работу кластера от слова совсем), с Hbase, которая, насколько мне известно работает через мастера и соответственно в случае его падения… не работает. То есть для high available бд не подходит…
Естественно база пишушая через один мастер всегда будет по умолчанию в выигрышной ситуации, хотя бы потому что у неё локализован весь кэш и индексы…
Но даже при этом вы используете кассандру совсем не по назначению, она по сути key-value база с группировкой колонок по pk. Классическое её использование это read/write (в основном второе) по конкретному ключу, по одной записи (high available риал тайм процессинг), батчи антипаттерн для неё, тем более (и это прям написано в доке) батчи содержащие ключи в разных нодах (что вы и сделали).
Как тут уже заметили кассандра работает с одним диском и ей нужен raid0, плюс она непосредственно через wal + sync заботится о гарантии записи, в то время как hdfs имеет свой мемори кэш.
В общем — сравнивать высокодоступную базу с базой имеющей мастера (point of failure) некорректно иначе надо сравнивать одну ноду cs с одной нодой hb, тогда честнее будет.
А если сравнивать — пишите в большое кол-во потоков (write workers в кассандре) с rf=3, но rw=quorum (классика) при этом по одной записи (один pk) в запросе, либо, чтобы все батчи уходили в одну партицию, иначе вы опять же сравниваете ha базу размазывающую с базой с одним мастером...
P.s.
Hb может и быстрее, но она ж для другого...
P.p.s.
Кстати, что это за кейс такой где нужна high availability и low latency и при этом батч операции? Зачем вы сравниваете cs и hb...
Надо научиться оценивать (чувствовать?) «стоимость» решения в смысле профита от него относительно затрат сил и ресурсов. Тут много на уровне чувств, посчитать сложно или невозможно. Автор совершенно верно подобрал слово — гармония.
Выбирайте не более гибкие и крутые решения, а более гармоничные — когда чувствуете, что решение тут достаточное и оно ест столько ресурсов, которые стоят профита от него.
p.s.
в итоге «фигак-фигак и в продакшн, и так сойдёт» => возможно это решение и есть максимально близкое к гармоничному? просто вы хотели ненужной гибкости/крутости и не выслушали ваши чувства, которые вам подсказывали, что то, что вы делаете, слишком и ненужно сложно…
если же реально постоянно невозможно найти оптимально в «быстро-дёшево-качественно», то возможно и правда стоит сменить работу…