Уверен, что все резко стало бы возможным, появись правильный закон или прецендент в суде против скотов. Вспомнилось, как американские авиапроизводители обещали космические удорожания и утяжеления самолётов при добавлении регулировок в сидения и органы управления в истребители, чтобы удобно было большинству пилотов. Но, когда минобороны безальтернативно потребовало это, как условие для контракта, вдруг, все производители нашли способ решить вопрос дешево и без особого доп веса.
Технически реально сделать достаточно точный биллинг, если резервировать деньги чуть с запасом. Условно, есть глобальный сервис, который резервирует деньги, попутно проверяя лимит + даёт грубый прогноз по использованию на, например, минуту вперед.
Каждый сервис синхронно берет себе среднеминутный лимит, локально его уменьшает, и при окончании берет ещё. Тогда нетфликс будет откусывать на свои S3 по $1000 за раз, а стартапер Вася по $0.001
Как я понимаю, чтобы реализовать один и тот же высоконагруженный сценарий, то для кассандры потребуется в разы меньше дисков и памяти. Условно, есть база на 10ТБ постгресс, требующая 10 реплик для чтения, чтобы выдержали процы. То есть, нам надо иметь 110ТБ NVMe дисков + память под это все дело. И мы в итоге получаем систему с репликейшн лагом и нетривиальными процедурами восстановления работы при падении мастера. В случае кассандры же, нам достаточно 30ТБ NVMe, сильно меньше памяти (да, в 2 раза больше камней, увы), но, зато, система практически неопрокидываема от отказа железа и нет репликейшн лага
>Реляционка, например постгрес, на дешевой виртуалке за 5$ легко потянет 1000 рек-сек без особых проблем
Охотно верю. В моем опыте были проекты с миллиардами событий в день как на постгресе, так и на MS Sql Server. Правда, понятно, что оборудование там было близкое к описанному в статье)
>Почему? Реляционки дадут фору многим но-скл решениям
Потому, что 1) они отвратительно масштабируются. В примере в посте разрабы не хотят головняка с независимыми шардами, поэтому держат всю базу одним куском и реплицируют ее целиком. Это очень плохой паттерн, ибо 1.1) производительность системы ограничена скоростью записи мастера и скоростью воспроизведения WAL на самом медленном слейве, а ограничение по объему = объем самого маленького слейва 1.2) слейвы делают огромный объем работы впустую. К примеру, по нагрузке на процы, надо 10 слейвов. В случае no-sql решений можно шардировать данные так, чтобы каждая из 10 машин содержала лишь 1/10 всех данных. Тут же так не выйдет. Каждый слейв вынужден оперировать объемом данных в 10 раз большим, чем минимально возможный. Сюда еще в 10 раз большее время восстановления из бекапа и прочие радости 1.3) шардинг реляционок возможен, но он лишает их практически всех плюсов перед no-sql собратьями 2) они делают много работы впустую. Огромная инфраструктура, связанная с WAL, транзакциями, консистентностью, MVCC, корректной инвалидацией кешей тратит процессорное время, IO, память. Если это обусловлено задачей (к примеру, клиент А перевел клиенту Б деньги, и ситуация, когда деньги задвоятся или обнуляться, недопустима для бизнеса), то это оправданная цена, но для управления сертификатами непонятно, зачем
Как и швейцарским ножом можно провести операцию... Но идея, вцелом, не очень хорошая для таких нагрузок и таких задач. Реляционки тратят слишком много ресурса и требуют слишком много от железа, давая взамен фичи, ненужные продукту. Когда 3 калеки пользователей, то, да, можно забить.
Жаль, что не написали, сколько именно серверов
Но, вцелом, интересно, зачем вообще использовать реляционную базу для подобных задач? Как я понимаю, скоуп запросов жестко фиксирован, запросы от разных клиентов независимы. Соответственно, возникают вопросы, нужен ли там b-tree, или хватит хеш таблиц, нужен ли синхронизированный по всем клиентам WAL, и так далее. Реляционные СУБД, все же, швейцарский нож. Может, тут скальпель нужен?
Each Graviton2 has 64 cores, and an AWS virtual CPU (vCPU) uses an entire core rather than the simultaneous multithreading (SMT) core sharing that’s applied to x86 vCPUs.
On the surface, these would seem like hugely impressive claims: Graviton2 both has higher core-count and higher performance per virtual core. However, it should be noted that Intel’s CPUs have HyperThreading, resulting in two vCPUs per core. That means these tests only use one thread of Intel's available two threads per core.
Если мне не изменяет память, то в AWS одно ядро ARM виртуалки соответствует одному физическому ядру камня (ибо в Graviton нет HT), а вот одно ядро x86 виртуалки соответствует одной половинке физического ядра (одному, когда повезло, и сосед не нагружает свое логическое ядро), ибо AWS продает логические ядра.
Таким образом, t4g.micro подразумевает в 4 раза больше ядер (2 физических ARM ядра), чем более дорогой t2.micro (0.5 физических x86 ядер).
Возможно, и не лукавил автор книги о Безосе, говоря, что он всегда продает инновации дешево, чтобы не создать сверхмаржи для привлечения конкурентов, и приводит, как антипример, Apple, который, с первых дней начал жестко доить айфон, и, тем самым, привлек много сильных конкурентов, поманив их гигантской маржей
Зря вы так о стоматологах и общепите хорошо думаете. У них багов не меньше, чем в программных продуктах. Просто тестирование сложнее организовать и баг воспроизвести.
Первые часто кариес оставляют под пломбой, или зуб могут вырвать, который подлежит лечению. У знакомых были случаи, когда, не поверив одному стоматологу, они шли к другому, и слышали совершенно другой диагноз и рекомендуемое лечение. И это я не говорю о заведомо нечистоплотных врачах, которые намеренно лечат здоровые зубы с, например, пятнышком, ибо, время уже забронировано, а цена только лишь консультации так себе заработок.
Из-за вторых же люди постоянно понос получают, но, снова таки, а ты докажи, что заработал понос в ресторане, а не съел чего дома
Может быть, тогда мое Вам почтение)
Из моего опыта, — для списывания или экстренной подготовки к вопросу, пока препод объявил вопрос и водит глазами по аудитории, ища, кого бы дернуть, — вообще маст хев.
Для подготовки к экзамену по списку вопросов не так сильно надо, но лишним не будет
Лично меня у, будучи студентом, взрыв пукана вызывали pdf без возможности поиска. И, как я понимаю, именно такие файлы на выходе и выходят (надеюсь, что неправ, и библиотека Synapse это комбайн, делающий все и сразу).
Есть ли идеи, как туда OCR прикрутить, который, пусть и коряво, но, все же, файл в текст превратит и сформирует PDF, в котором будет и картинка (чтобы видеть глазами первоисточник), и текст для поиска одновременно?
Может, когда-то подобное будет в AWS с прайсом в $5000 в час…
Тогда представляю стартаперов, которые будут рассуждать «что-то пока наша модель, которая должна сделать прорыв в ИИ не фитится, но ничего, чуток инвестиций поднимем, часов 100 возьмем машинного времени, и тогда стартап точно взлетит»
Интересно, почему столь скучным заказчикам достается такая мощь. Неужели обладание подобным чипом не может дать буст Гуглу в улучшении поиска, Тесле в улучшении автопилота, или, Фейсбуку в оптимизации рекламы?
Так а кто сказал, что отношение к пьяным за рулем не нормализовано уже?) Если бы проблема была прям сильно критичной, то давно были бы обязательные датчики алкоголя в каждой машине,
У нас был очень показательный кейс: компания среднего размера искала замдиректора. На эту вакансию откликнулось 600 человек. Если бы рекрутер тратил только по 5 минут на каждого кандидата, ему потребовалось бы 50 часов, больше недели чистого рабочего времени, только для того, чтобы прочитать и вникнуть, что же прислали претенденты.
Серьезно, предлагаете замдиректоров при помощи ИИ искать? Тут два противоречия:
1) Где вы выборку на замдиректоров возьмете? Их ведь не сажают в помещение, пободное школьному спортзалу в 4 ряда, как операторов коллцентра
2) Так ли важны 50 часов рекрутера при поиске человека, полномочия которого позволяют легко сэкономить, или, наоборот, угробить результаты работы 10000 часов его подчиненных
теме оформления результатов создания ИТ-продуктов для органов государственной власти и крупных корпораций
Вот скажите, а что вы там ловите и на что надеетесь?) Даже эта фраза уже звучит настолько зашкварно, что сразу понятно, что никакого проф развития, адекватных вызовов или интересной работы в этой сфере не будет.
Тут скорее вопрос не к тем, кто это все требует, а к Вам, автор. Зачем пошли в такую сферу, если монотонная размеренная и бесполезная работа Вам не по душе? Возможно, кто-то другой, был бы счастлив. Я сам офигеваю, но общался с людьми, которым в кайф делать монотонную бюрократическую работу, находить свой ритм, и чуть ли не медитировать при этом
При чем тут это? Гугл полез в красный океан отжимать рынок у ФБ и получил по лбу. Точно так же по лбу получил М$ со своими жалкими попытками отжать рынок у Гугла. Как в случае G+, так и в случае Bing инноваций там не было.
В случае Безоса, он не шёл отжимать рынок у производителя конвееров (ибо зачем) и не шёл отжимать рынок у облачных провайдеров (ибо рынка не существовало). А находил оригинальные решения проблем своего основного бизнеса, но эти решения выходили настолько крутыми, что уделывали вендоров, для которых это ключевая компетенция
Уверен, что все резко стало бы возможным, появись правильный закон или прецендент в суде против скотов. Вспомнилось, как американские авиапроизводители обещали космические удорожания и утяжеления самолётов при добавлении регулировок в сидения и органы управления в истребители, чтобы удобно было большинству пилотов. Но, когда минобороны безальтернативно потребовало это, как условие для контракта, вдруг, все производители нашли способ решить вопрос дешево и без особого доп веса.
Технически реально сделать достаточно точный биллинг, если резервировать деньги чуть с запасом. Условно, есть глобальный сервис, который резервирует деньги, попутно проверяя лимит + даёт грубый прогноз по использованию на, например, минуту вперед.
Каждый сервис синхронно берет себе среднеминутный лимит, локально его уменьшает, и при окончании берет ещё. Тогда нетфликс будет откусывать на свои S3 по $1000 за раз, а стартапер Вася по $0.001
Как я понимаю, чтобы реализовать один и тот же высоконагруженный сценарий, то для кассандры потребуется в разы меньше дисков и памяти.
Условно, есть база на 10ТБ постгресс, требующая 10 реплик для чтения, чтобы выдержали процы. То есть, нам надо иметь 110ТБ NVMe дисков + память под это все дело. И мы в итоге получаем систему с репликейшн лагом и нетривиальными процедурами восстановления работы при падении мастера.
В случае кассандры же, нам достаточно 30ТБ NVMe, сильно меньше памяти (да, в 2 раза больше камней, увы), но, зато, система практически неопрокидываема от отказа железа и нет репликейшн лага
>Реляционка, например постгрес, на дешевой виртуалке за 5$ легко потянет 1000 рек-сек без особых проблем
Охотно верю. В моем опыте были проекты с миллиардами событий в день как на постгресе, так и на MS Sql Server. Правда, понятно, что оборудование там было близкое к описанному в статье)
>Почему? Реляционки дадут фору многим но-скл решениям
Потому, что
1) они отвратительно масштабируются. В примере в посте разрабы не хотят головняка с независимыми шардами, поэтому держат всю базу одним куском и реплицируют ее целиком. Это очень плохой паттерн, ибо
1.1) производительность системы ограничена скоростью записи мастера и скоростью воспроизведения WAL на самом медленном слейве, а ограничение по объему = объем самого маленького слейва
1.2) слейвы делают огромный объем работы впустую. К примеру, по нагрузке на процы, надо 10 слейвов. В случае no-sql решений можно шардировать данные так, чтобы каждая из 10 машин содержала лишь 1/10 всех данных. Тут же так не выйдет. Каждый слейв вынужден оперировать объемом данных в 10 раз большим, чем минимально возможный. Сюда еще в 10 раз большее время восстановления из бекапа и прочие радости
1.3) шардинг реляционок возможен, но он лишает их практически всех плюсов перед no-sql собратьями
2) они делают много работы впустую. Огромная инфраструктура, связанная с WAL, транзакциями, консистентностью, MVCC, корректной инвалидацией кешей тратит процессорное время, IO, память. Если это обусловлено задачей (к примеру, клиент А перевел клиенту Б деньги, и ситуация, когда деньги задвоятся или обнуляться, недопустима для бизнеса), то это оправданная цена, но для управления сертификатами непонятно, зачем
Как и швейцарским ножом можно провести операцию... Но идея, вцелом, не очень хорошая для таких нагрузок и таких задач. Реляционки тратят слишком много ресурса и требуют слишком много от железа, давая взамен фичи, ненужные продукту. Когда 3 калеки пользователей, то, да, можно забить.
Но, вцелом, интересно, зачем вообще использовать реляционную базу для подобных задач? Как я понимаю, скоуп запросов жестко фиксирован, запросы от разных клиентов независимы. Соответственно, возникают вопросы, нужен ли там b-tree, или хватит хеш таблиц, нужен ли синхронизированный по всем клиентам WAL, и так далее. Реляционные СУБД, все же, швейцарский нож. Может, тут скальпель нужен?
Видимо, пропитанная трупным смрадом гадость, вроде ABAP или APL, не набрала кворума по количеству ответов, чтобы попасть в список)
Ок, чуток погуглю за Вас)
https://www.infoq.com/news/2020/03/Graviton2-benchmarks/
https://www.tomshardware.com/news/amazon-web-services-takes-on-intel-with-64-core-arm-graviton2
Таким образом, t4g.micro подразумевает в 4 раза больше ядер (2 физических ARM ядра), чем более дорогой t2.micro (0.5 физических x86 ядер).
Возможно, и не лукавил автор книги о Безосе, говоря, что он всегда продает инновации дешево, чтобы не создать сверхмаржи для привлечения конкурентов, и приводит, как антипример, Apple, который, с первых дней начал жестко доить айфон, и, тем самым, привлек много сильных конкурентов, поманив их гигантской маржей
Зря вы так о стоматологах и общепите хорошо думаете. У них багов не меньше, чем в программных продуктах. Просто тестирование сложнее организовать и баг воспроизвести.
Первые часто кариес оставляют под пломбой, или зуб могут вырвать, который подлежит лечению. У знакомых были случаи, когда, не поверив одному стоматологу, они шли к другому, и слышали совершенно другой диагноз и рекомендуемое лечение. И это я не говорю о заведомо нечистоплотных врачах, которые намеренно лечат здоровые зубы с, например, пятнышком, ибо, время уже забронировано, а цена только лишь консультации так себе заработок.
Из-за вторых же люди постоянно понос получают, но, снова таки, а ты докажи, что заработал понос в ресторане, а не съел чего дома
5000 контактов мало, как по мне.
Но тема интересная.
Может быть, тогда мое Вам почтение)
Из моего опыта, — для списывания или экстренной подготовки к вопросу, пока препод объявил вопрос и водит глазами по аудитории, ища, кого бы дернуть, — вообще маст хев.
Для подготовки к экзамену по списку вопросов не так сильно надо, но лишним не будет
Есть ли идеи, как туда OCR прикрутить, который, пусть и коряво, но, все же, файл в текст превратит и сформирует PDF, в котором будет и картинка (чтобы видеть глазами первоисточник), и текст для поиска одновременно?
Так и на тех, кто свое делает, управа найдётся. Яша ещё свой Amazon.basics запустит. Просто время не пришло
Тогда представляю стартаперов, которые будут рассуждать «что-то пока наша модель, которая должна сделать прорыв в ИИ не фитится, но ничего, чуток инвестиций поднимем, часов 100 возьмем машинного времени, и тогда стартап точно взлетит»
Серьезно, предлагаете замдиректоров при помощи ИИ искать? Тут два противоречия:
1) Где вы выборку на замдиректоров возьмете? Их ведь не сажают в помещение, пободное школьному спортзалу в 4 ряда, как операторов коллцентра
2) Так ли важны 50 часов рекрутера при поиске человека, полномочия которого позволяют легко сэкономить, или, наоборот, угробить результаты работы 10000 часов его подчиненных
Вот скажите, а что вы там ловите и на что надеетесь?) Даже эта фраза уже звучит настолько зашкварно, что сразу понятно, что никакого проф развития, адекватных вызовов или интересной работы в этой сфере не будет.
Тут скорее вопрос не к тем, кто это все требует, а к Вам, автор. Зачем пошли в такую сферу, если монотонная размеренная и бесполезная работа Вам не по душе? Возможно, кто-то другой, был бы счастлив. Я сам офигеваю, но общался с людьми, которым в кайф делать монотонную бюрократическую работу, находить свой ритм, и чуть ли не медитировать при этом
Поможет от чего?
Если это делать из под статического ип, то по фингерпринту+ip и так отлично рекламные сети все отследят и поймут, что им надо.
При чем тут это? Гугл полез в красный океан отжимать рынок у ФБ и получил по лбу. Точно так же по лбу получил М$ со своими жалкими попытками отжать рынок у Гугла. Как в случае G+, так и в случае Bing инноваций там не было.
В случае Безоса, он не шёл отжимать рынок у производителя конвееров (ибо зачем) и не шёл отжимать рынок у облачных провайдеров (ибо рынка не существовало). А находил оригинальные решения проблем своего основного бизнеса, но эти решения выходили настолько крутыми, что уделывали вендоров, для которых это ключевая компетенция