И ты проигнорировал как днище мой вопрос, простая система, как ты соберёшь отчёт за 5 лет, где будешь хранить данные, как будешь обрабатывать перезагрузку сервера при установлении обновлений безопасности.
Ну это естественно не про компуктерную игрулю, а про болееменее серьёзную систему где одна транзакция может быть по паре десятков тысяч условных единиц.

Товарищ трепло, терабайт данных это сраные сообщения на реддите за месяц,

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

К тому же, трепло не сообщает и не пруфцует информацию и не говорит в каком виде её там терабайт.

Ну и да, за месяц. Ну и да - почти все данные архивные т.к. основная аудитория читает только актуальные треды.

Заметим, как быстро клоун съехал с документооборота завода в каком-то там мухосранске до редита. Какое же нелепое трепло.

Клоун хренов, какие снапшоты бд? Как вообще даже в 100 гигов нахалву снапшот отреплицировать без даунтайма? И что за архивные данные, ты как вообще их восстанавливать из архива собираешься и сохранять туда, или ты в гмыде хочешь заблочить просмотр всех писем кроме непрочитанных?

Меня так весилит, какогда запартная балабалока что-то там начинает кукарекать.

как ты соберёшь отчёт за 5 лет,

Как ты меня, секретарша, одалела своей хернёй нелепой. Это же просто ужас.

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

Маня, меня обновления «безопасности» вообще никак не волнуют. Ты перепутал свою птушную реальность и мою.

По поводу как - очень просто. Даже если мы предположим, что у меня нету дампа на энергонезависимую память, то представляешь, маня - я могу в любой момент задампить память. ДА и вообще состояние всей программы, представляешь как магия бывает? Тебе в школе об этом не рассказывали.

Да даже если не дампить - я могу офнуть любую ноду и она восстановится сама. И таким образом по очереди ребутнуть все.

Я тебе сообщаю, трепло, хранение архивных данных никому неинтересно. Никак и никогда. Тебе об этом в школе не рассказывали - иди спроси, создай тему.

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

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

Посчитай налог с зп для завода с 1к людьми с учётом контрольно пропускной системы, больничными, декретами и отпусками. Сделай чтобы это нормально хранились, с учётом того что одна пропавшая запись это потенциально одно уголовное дело. Тоже посмотрим.
П. С.
Если ты основные данные будешь хранить и считать из архивной БД и будешь просто использовать кэш, то ты днище.

Да даже если не дампить - я могу офнуть любую ноду и она восстановится сама. И таким образом по очереди ребутнуть все.

Консистентность быдло.

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

Клоун, это зарплата за три-четыре месяца, а в долине у многих сейчас за один.

Ну с редитом ты обосрался, как и всегда. Ты, дошколёнок, слишком распитушился, но я тебе объясню, ведь тебе интересно.

Клоун хренов, какие снапшоты бд?

Обыкновенные.

Как вообще даже в 100 гигов

Маня, ты даже эти 100гигов в жизни не видел.

нахалву снапшот отреплицировать без даунтайма?

Ну во-первых, почему ты, дошколёнок, игнорируешь всё остальное? Как - очень просто.

Во-первых, откуда ты высрал какой-то даунтайм? Единственное чего стоит реплекация - это канала. Всё остальное - бесплатно.

Во-вторых, тебе уже сообщили, что любую ноду можно отключить и всё будет работать.

И что за архивные данные, ты как вообще их восстанавливать из архива собираешься и сохранять туда, или ты в гмыде хочешь заблочить просмотр всех писем кроме непрочитанных?

О боже, секретарша. Архивные данные - это не то, что там у тебя на маздайке в архивах лежит. Ты всё перепутал.

Архивные данные это те, которые не меняются и те, которым ненужен быстрый доступ.

Гмейл это вообще хелворд, т.к. данные там чисто архивные. Пишешь куда угодно, держишь индекс. Зачастую ты держишь даже часть индекса, т.к. он так же архивный.

Зачем я с тобою, поехавшим, разговариваю? Ты перепутал архивные данные с маздайским архивом(который зип/рар). Это просто ахренеть насколько тупо.

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

Дак вот, сообщаю тебе новость - никакого отношения этот базворд к теме не имеет. В это система не существует неконсистентности вообще.

Дошколёнок, мне абсолютно неважно что там значат твои нелепые потуги. Меня это вообще неволнует. Что там твоя извилина имела ввиду - мне неважно.

Я тебе конкретно спорил - какое отношение ты имеешь к этому, а что «это» мне вообще неважно.

Посчитай налог с зп для завода с 1к людьми с учётом контрольно пропускной системы, больничными, декретами и отпусками. Сделай чтобы это нормально хранились, с учётом того что одна пропавшая запись это потенциально одно уголовное дело. Тоже посмотрим.

А, дак ты у нас полы моешь рядом с 1c, а что же сразу не сказал. С каким гением мысли я имею дело.

Сообщаю тебе новость - вся эта информация - это мегбайты данных, которые считаются левой пяткой. Как быстро дошколёнок с вскукарекав про терабайты пришел с тому, что знает - 1к человек и магабайты. Ну ты молодец.

Если ты основные данные будешь хранить и считать из архивной БД и будешь просто использовать кэш, то ты днище.

Это так смешно, когда поломой тебе что-то вещает.

Школобол, пока ты дампишь память на одной ноде у тебя на другой сопрут денег столько что продажей себя в рабство не отделаешься. Ты либо отключаешь все ноды на время бэкапа, либо хранишь все в файлах и используешь снапшоты. Для памяти снапшотов нормальных сейчас нет.

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

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

Ну, давай, беги рассказывать как.

Ты либо отключаешь все ноды на время бэкапа

На каком основании?

либо хранишь все в файлах и используешь снапшоты.

Опять какая-то шизофрения. Снапшоты и есть файлы.

Для памяти снапшотов нормальных сейчас нет.

Меня прям так волнуют потуги дошколёнка-поломоя. Ты вообще кто такой, что-бы что-то там кукарекать и рассказывать мне - что у меня есть, а чего нет?

К тому же, что значит «нету»? Ты, дошколёнок, не знаешь что память процесса можно читать? Да даже причём тут процесс - просто хип внутри процесса. Ну да пойди проси у дядей, перед тем как кукарекать.

Хотя что я хочу от поломоя, который моет полы рядом с маздайской 1c на консервном заводе в мухосранске.

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

О боже, маня, какую же нелепую херню ты несёшь. Я тебе сообщаю новость - в памяти есть специальные структуры. Так же я тебе сообщаю, что есть такая штука как форк. Хотя в данном случае она ненужна, т.к. на уровне памяти уже есть версинность.

К тому же, даже если там всё совсем плохо и просто данные накиданы в помойку, то нода та не одна. Есть другие ноды.

Вся суть базового снапшотинга - просто перекинуть основную часть данных на новую ноду. Потом инкрементально всё это автоматом добьётся до нужного состояния.

Но всё это проще делать из снапшотов, потому что снапшоты уже являются консистентными срезами БД. Они инкрементальные, с проверкой целостности и всей фигнёй. Иди посмотри мои темы - я когда-то уже писал об этом.

Ты там выше кукарекал про кворум, дак вот что-бы опять не кукарекал. В такой системе уже есть кворум автоматом. Я думаю тебе не нужно объяснять как это работает.

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

Подожди, тут про очередь речь идёт? Распределённая очередь — ок архитектура для современных приложений. Суть: берётся что-нибудь вроде kafka (удачи девопсам это ментейнить в продакшне) или kinesis, любое событие запихивается в эту очередь. Консумеры этой очереди — это, например,

* тупо лог всей очереди — для банального дебага, возможности replay либо добавления новых отчётов по старым данным.

* nosql-база для часто выполняемых запросов

* если нужна бизнес-аналитика и произвольные запросы — данные для этой самой аналитики запихиваются в нужную SQL-базу

* прочие консумеры могут вытаскивать, например, ЛЮБУЮ техническую статистику из этой же очереди для того же анализа загруженности. Не мешая всему остальному.

* бэкапы, снапшоты и прочие радости жизни банальны: (за бесконечное время) ты можешь откатить всю систему на ЛЮБОЕ состояние при наличии лога событий и при желании выкинуть/отменить любые события из лога если сильно нужно.

при этом ты можешь масштабировать ЛЮБОГО из консумеров этой очереди независимо от других. Да, это работает с терабайтами данных. Да, эта архитектура начинается с дублирования данных (каждый консумер держит копию интересных ему данных). Да, консумеры ничерта не консистентны между собой в любой момент времени в общем случае, но они eventually consistant т.е. рано или поздно твой отчёт за 5 лет увидит свежие данные в своей базе, но это может быть чуть позже, чем их учтёт более реалтаймовый микросервис. Хочется, чтобы все данные учитывались одновременно везде и это не просаживало производительность/доступность? Отдел фантастики про distributed transactions — на другом этаже.

Подводные камни — ошибка в классификации событий приведёт к костылям нереального размера либо переписыванию уймы кода, ну и прочие радости event sourcing.

Можно, если осторожно

О чьей памяти идёт речь? Просто есть два принципиально разных подхода к этому вопросу.

1. Snapshot-архитектуры - всё в оперативке, при завале перезапускается из снапшота. 2. Stateless-архитектуры - если что и хранится, то в localStorage и кукисах у клиента. AWS Lambda туда же (в том плане, что сами ничего не хранят).

Архитектура прикольная, но как в ней например смену цены клика после определённого количества кликов в месяц и график выручки без костылей? Получается ведь ещё больше данных надо в бд хранить а это очень далеко от темы топика.

Разбавлю говно на вентиляторе, в компуктерных игрушках так и делают, в браузерных в том числе.
Но если сайт делается не на ворованные гос деньги, то приходится использовать сторонние либы, а они текут и скрипт дольше пары месяцев не проживёт. Хотя на ворованные можно сделать что хочешь, хоть золотые унитазы в офисе.

Я писал такие сервисы. Когда данных мало, инстанс один, запись редкая, то я просто сбрасывал дамп состояния на диск, в какой-то Protobuf/YAML/JSON. Если не критично, то даже асинхронно и даже не каждый раз. После перезапуска вычитывается в память один раз.

Что по-твоему — веб-приложение? Скажем, у меня достаточно много веб-морд есть, и ни у одной нет БД! Потому что им они не нужны!!!

БД на sqlite разве что использую для хранения данных аутентификации (логин и хэш пароля).

А методы - либо REST (сишный демон + html/жабоскрипт под апачем или NGINX), либо вебсокеты (абсолютно аналогично).

Для этого и придумали redis П.С. *сарказм*

Но если ты реально хочешь так сделать, то редис то что надо)

Получается ведь ещё больше данных надо в бд

Ну да, это больше архитектура «как масштабировать распределённую систему» через разделение БД на куски. Баз становится только больше, при желании их можно плодить на каждую задачу (это не значит «нужно»).

Архитектура прикольная

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

но как в ней например смену цены клика после определённого количества кликов в месяц и график выручки без костылей?

Каждая новое потуга архенеть насколько тупее предыдущей.

Получается ведь ещё больше данных надо в бд хранить а это очень далеко от темы топика.

Нет, амёба. Никакой БД тут нету. Абсолютно насрать в каком виде у тебя хранятся данные.

Я тебе уже рассказывал, но расскажу ещё раз - БД это не то, что ты там увидел за своей партой убогой. Весь мир не заканчивается на твоих убогих представлениях.

То, что ты понимаешь(хотя что ты, убогий, можешь понимать) под БД - это лишь какой-то класс БД. БД может не внешняя, а встроенная. БД может быть вообще без привычного тебе интерфейса.

Т.е. любая БД - это такое же приложение без БД, потому что оно само является БД и хранит данные «в переменных». После к нему прикручивается api, сетевой уровень и оно превращается в привычный тебе базворд.

Давай я тебе, трепло запартное, подробнее объясню.

Если брать базовую версию, то у нас есть условная шина. На которую цепляются отдельные сервисы. Для простоты возьмём какую-то базовую задачу, о которой я тебе уже рассказывал, получать запросы от клиента обрабатывать их и возвращать ответ.

Условная шина - это такая херня, в которую какие-то сервисы пишут уловные сообщения. Какие-то сервисы слушают сообщения.

Я тебе уже говорил, что нужен условный фронт. Т.е. то, что будет смотреть в инет, к чему будут подключаться твои пользователи, куда будут посылать запросы и получать ответ.

Т.е. наш условный фронт должен уметь держать соединение с пользователем. Должен принимать запросы. Эти запросы он преобразует в нужную форму и пишет в нашу условную шину. И далее сидит, слушает шину на предмет ответов. Как только там появляется ответ - он его возвращает пользователю.

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

Он запиливается. Как он запиливается - насрать. Но есть фундаментальная вещь - монолит всегда надёжнее. Причины просты - шанс выйти из строя одно тачки - куда меньше, чем 10.

Именно поэтому, когда ламерки кукарекают «я доставлю тачку» - он говорят «снижаю надёжность системы». Потому что для обеспечения тех же шансов на падение системы - тебе нужно на каждую добавленную тачку - добавлять ещё 10, 100, 1000тачек. Всё зависит от того - насколько у тебя раздроблен сервис.

Я уж не говорю о том, что дошколятская «одна бд и все её долбит» - это равно «у меня нет масштабируемости и отказоустойчивости».

Сейчас попсовое решение для домохозяек - это запихать все части сервиса в контейнеры в kubernetes в рамках одной тачки.

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

На этом этапе даже дошколёнку понятно, почему монолит круче. Почему он быстрее, почему он надёжней. Но, основная проблема тут в том, что подобны тебе дошколята никогда монолит ненапишут. Твой потолок - пхп.

Соответственно, каждый из этих сервисов занимается только своей локальной задачей. Задача обработчика запросов - хранить свою данные и отвечать на запросы. Всё остальное - его волновать не должно. Единственное, что он в любом случае должен уметь делать - это делиться данными/статистикой. Но данными, а не выполнять какую-то левую логику.

И тут даже дошколёнку понятно, что подобный обработчик работает точно так же как и любой другой. Поэтому вопросы дошколёнка уровня «а как сделать то-то» - так же сделать.

Далее, всякие вскукареки «как же мне над данными делать то, что мне сказал делать хозяин». Ну это твои локальные проблемы, хотя решаются они так же просто.

Я тебе уже объяснял как. Сервис обработки запросов генерирует какую-то статистику/метрики. Ты можешь к нему(либо через «условную шину») подключится и получать эту статистику/метрики. Далее ты можешь с ними делать что хочешь. Можешь хоть в какое-нибудь скул-дерьмо положить. Меня это волновать не должно.

Аналогично с данными. Этот сервис тебе их так же может посылать. Ты их можешь реплицировать у себя(в чём угодно) и далее что хочешь с ними делать.

Далее, как ты можешь видеть - эта система масштабируется куда угодно.

Ты можешь разделять данные. Делать не один сервис, который хранит всех пользователей, а 10. Каждый из которых хранит десятую часть всех пользователей.

Как хранить мейдику? Так же. Есть какой-то сервис, который её хранит. В него так же форвардятся какие-нибудь птушные картинки, видосики. На них вообще всем насрать.

По поводу «если памяти не хватает» - её всегда хватит. Если ты там начинаешь кукарекаеть «а как же через 10лет» - всём на это так же насрать.

Возьми тот же фейсбук. Сколько читают комменты/посты даже годичной давности? Никто. Поэтому всем насрать.

Есть некие актуальные данные. Они изменяются, постоянно запрашиваются - их мало. Все остальные данные ты можешь спокойно выносить в архивное хранилище. Архивное хранилище может быть попросту ro. Обходятся проблемы вида «а вдруг кто-то там обновит старые данные» - это мало где можно сделать, а даже если можно - это не проблема. Погугли про какое-нибудь кэширование, lsm-tree.

В конечном итоге для твоего сервиса могут выглядеть так: все обновления он пишет себе. Все актуальные обновления - отдаёт. Если чего-то нет - он просит у других.

В данной системе просить у других очень просто. Ты посылаешь «дай мне то-то» и тебе дают. Кто даёт и когда - это насрать. Но где-то оно есть.

монолит всегда надёжнее

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

контейнеры в kubernetes в рамках одной тачки.

OMFG. Царь был интереснее.

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

Ты перепутал методичку. Во-первых ты не обосновал свои потуги, а во-вторых ты всё перепутал. Монолит в контексте моей пасты - это не то, что ты где-то там слышал.

OMFG. Царь был интереснее.

Аргументация пошла. Или я задел твою действительность?

Эх, а что ж будет, когда ты для себя serverless откроешь. Это ж ещё и без сервера можно.

Опа… А открой для меня это. Я пока даже вообразить не могу.