Можно ли создать веб приложение без базы данных?

В чём проблема? Сохраняй в текстовых файлах, как раньше делали. А что оно будет делать, если каждый раз с 0 начинает? Можно конечно, осталось придумать зачем это нужно. Ещё можно на сервере положить статичный файл с текстом и выполнять всё в браузере.

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

Зафрендил

Можно, разрешаю.

все данные держит в оперативной памяти

это и есть база данных. Она не обязана быть SQL/реляционной, от этого не так много меняется. Никто не запрещает тебе использовать redis как основную БД.

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

падает приложение иногда и потом восстанавливается

А бэкапы как?

Сохраняй в текстовых файлах

ФС — это база данных.

что мешает ту же бд держать в озу?

Ну тогда память это тоже база данных. И стейт это база данных.

Если хранение данных не важно - можно их даже не держать в памяти. А чё.

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

это как, вечный гон?

А вообще есть ли такая практика?

Есть, например всякие форматтеры json-a, xml. Им БД не нужно.

Где веб приложение вместо оного все данные держит в оперативной памяти?

Тут главное разумность.

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

Вопрос спорный. Сколько времени займет восстановление данных.

https://wiki.tcl-lang.org/page/A tiny Tcl server?R=0

sqlite умеет работать на одной оперативке

для работы в озу уже придумали много всякого:

memcached, redis, sqlite тоже умеет...

база данных это глобальное понятие и означает, примерно, совокупность всякой хрени, в каком-то условном порядке, в котором можно как-то что-то поискать. Map это база данных, даже List можно сказать, что база данных. Так что нет нельзя.

Норм, а теперь придумай под это концепцию и понтовый баззворд, например «NoDB».

И слоган:

No DB, no memory. NoDB!

Не ясно только как писать под это рефересную реализацию.

Map это база данных, даже List можно сказать, что база данных

Надо беречь от тебя сов и глобусы.

Где веб приложение вместо оного все данные держит в оперативной памяти?

Мало того, это всё на стороне клиента - SPA (reactjs + redux).

Ну тогда память это тоже база данных. И стейт это база данных.

И база данных база данных.

Если ты имеешь в виду хранение данных в приложении в виде переменных, то работать это, конечно, будет (например, если ты твое приложение на го реализовано). Но я тебе так делать не советую. Потому что если твой проект потребуется горизонтально масштабировать, то это уже нормально работать не будет, потому что в каждом процессе твоего приложения будет своя версия данных в оперативной памяти. То есть это будет либо дубль, сжирающий в 2 раза больше памяти, либо рассинхронизация, когда один процесс что-то в своих данных поменял, а второй имеет старую версию. Возможно, как-то можно юзать общую память, которую будут видеть несколько процессов, но я не уверен, что так можно сделать. И что это вообще будет хорошим решением - спорный вопрос. То есть то, что ты хочешь (если ты решил хранить данных в переменных), будет работать, но при условии, что у тебя запущен лишь один инстанс твоего приложения.

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

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

либо рассинхронизация

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

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

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

Возможно, как-то можно юзать общую память, которую будут видеть несколько процессов, но я не уверен, что так можно сделать.

Можно.

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

В основном так и делают. Создают изолированные инстансы, которые занимаются своими локальными делами. В этом суть масштабирования.

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

Ведь зачастую данные можно поделить между инстансами. Тут главное создать систему блокировок. Т.е. когда транзакция использует какие-то данные - мы должны запретить вообще какое-либо взаимодействие с ними из других транзакций.

И тут мы вспоминает синхронную архитектуру. Мы имеем список всех операций и мы можем получить то - к каким данным каждая операция будет обращаться. Мы можем выделить все свободные операции и исполнять их как угодно. Все операции с пересечением на одних и тех же данных - можно выполнять последовательно.

Это проверенный способ.

Редис ненеадёжный, непредсказуемый, медленный, требует оверхеда на ipc и много всяких проблем.

Тс по моему не совсем точно понимет что такое бд. Это статический или динамический файл на котором хранится какая то информация. Это может быть как sql так и txt, json, xml или людой другой подключаемый документ в замисимости от реализации, как один большой файл так и множество мелких. Без бд можно создать веб приложение, но оно не будет хранить вообще какую то информацию, а будет генерировать её динамически из введнных данных или брать из других источников.

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

Зафрендил.

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

При чем тут это, если я имею в виду переменные внутри процесса одной из ноды приложения.

В основном так и делают. Создают изолированные инстансы, которые занимаются своими локальными делами. В этом суть масштабирования.

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

Когда-нибудь пользователей станет так много, что задержка станет неприемлимой. В нормальном приложении просто воткнут ещё один сервак рядом, а у тебя... Придётся всё переписывать. А у любого веб-сервиса сложнее лендинга есть данные, которые должны шарится между всеми юзерами (например, у интернет-магазина это список товаров и транзацкий, причём второй ещё и активно обновляется).

А вообще есть ли такая практика? Где веб приложение вместо оного все данные держит в оперативной памяти?

Да. Я думаю все популярные сервисы с не строгим ACID так работают (когда дело не касается денег это почти все), например много где пользуют редис, а это сторадж в оперативке. Наверное все ORM умеют second-level cache, при запросе сущностей по id данные возвращаются из памяти. Просто классическая база выполняет роль single point of truth, т.е. одно место где все состояние хранится, не нужно придумывать как шарить состояние между инстансами, как не допустить чтоб старые данные не затерли новые и т.д.

Можно.

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

При чем тут это, если я имею в виду переменные внутри процесса одной из ноды приложения.

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

Это не так. Для этого есть потоки, никто не мешает выносить туда вычисления.

Но изолированные инстансы не хранят ВСЕ данные.

Могут хранить, а могут не хранить. Если у вас много общих данных - это никак работу с этими данными не масштабирует, а наоборот замедляет.

В любом случае требуется централизованное хранилище данных - хранить все в инстансах не получится.

Центрально хранилище не масштабируется. А если оно требуется - приложение спокойно разносится по нодам.

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

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

В нормальном приложении просто воткнут ещё один сервак рядом

Во-первых нет. Это убогие фантазии, которые дошколята повторяют везде и всюду. Никак твоё убогое приложение не масштабируется добавлением сервака.

К тому же, тебе нужно серваков 20 добавить, что-бы хоть как-то догнать одну ноду.

а у тебя... Придётся всё переписывать.

Маня фантазии.

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

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

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

а вот транзакции да, нужно ACID

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

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

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

К тому же, на уровне «магазинов», которые видели тутошние мамкины срыватели покровов - там вообще никаких проблем нет. Они никогда за рамки одной ноды не выйдут, никогда.

Если твой сервер ребутнется из-за бага в памяти или порванного магистрального кабеля ты откуда брать данные будешь? Не все говнокодят сетевые игрульки.

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

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

Ты это мне?

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

Оттуда вывел, твой сервер выключился, как восстановить работоспособность серыиса

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

Во-вторых, ты там начал кидаться агитками про аватары. Аватары - это ro хранилище медийки. К данным отношения не имеет. Меняй методичку. Аналогично и в других случаях. То, что ты где-то слышал про терабайты - это так же про медийку, а не про данные. Медийку в БД никто не хранит.

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

Так же, узнай разницу между активными и архивными данными.

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

Я тебе сказал - чини методичку. Во-первых здесь вообще никто не говорил про какую-то отказоустойчивость - говорилось о масштабировании.

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

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

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

У фейсбука 2 миллиарда именно активных пользователей, у всяких бесплатных приложений миллионы активных пользователей, если брать прибыль по 1 рублю с каждого то с налогами можно позволить только одного директорабухгалтераразраба с зарплатой в 50к рублей в месяц.
Насчёт аватаров, у него есть сервисная информация и если она будет весить один байт, то уже будет 2 гига. А если взять не аватары а фотки где надо хранить имя файла, то простая строка 255 символов имени файла будет весить 500 гигов для фб если каждый юзер загрузить хотя-бы одну фотку. Если нужно юникод, то умножай на 2. Если нужны комменты к фото, добавь ноль справа.
Насчёт форматов данных, днище типа вконтакта конечно режет всю мету и преобразует в говно, но не все сервисы делают так и не везде это возможно, возьми то же гмыло где к каждому имейлу хранится его исходник.
И на одной ноде это ты про что, ОЗУ? Если это днищеебский сервис то мощного сервера с сотней гигов ОЗУ мб хватит, но для чего-то что приносит деньги без мошенничества этого пп2 как мало.

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

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

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

Как ты можешь подумать далее - эти очереди вообще никак не зависят от данных. Очередь знает то, что она послала сообщение исполнителю. Исполнитель знает - приняла ли очередь отдачи его ответ.

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

Аналогична актуальный фронт, которым является очередь - точно так же может броадкастить всё ещё и на зеркала.

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

Ответы эта система потерять не может. Не может до тех пор, пока пока жив хоть один бек(назовёт это так, чтобы тебе было понятно).

Ты никак и никогда не убьёшь эти систему. И твои фантазии на тему настолько наивны, что просто смешно.

По поводу медийки - медийку вообще никто и никогда не обсуждает - на неё всем насрать и её нету не у контент-сервисов. Да и любая подобная система пишется по такой же схеме, либо используется готовое. Мне это как-то не особо интересно.

Нет. Ответ исчерпывающий, тред закрыт.

И как ты планируешь с помощью этой очереди сделать сраную яндекс аналитику с выборкой отчёта по виндузятникам Бурятии за год? Ты как хранить сами данные то вообще собираешься?

Масштабирование без отказоустойчивости говно.

Пиши свои потуги всем в этой теме, зачем ты начал кукарекать?

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

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

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

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

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

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

Товарищ трепло, терабайт данных это сраные сообщения на реддите за месяц, там к топ постам за день по 5-10 тысяч юникодных комментариев.

И как ты планируешь с помощью этой очереди сделать сраную яндекс аналитику с выборкой отчёта по виндузятникам Бурятии за год?

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

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

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

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

Аналогично засылаются и данные. Есть множество путей. Нода может нахаляву реплецировать снапшоты БД. Ты можешь взять и отлючить любую ноду бека и получить все данные в монопольное пользование.

Ты можешь заатачится на любую ноду и она реплецирует себя.