Какую БД и стек технологий выбрать для графического редактора?

Есть онлайн графический редактор. Для него будем разрабатывать базу данных для хранения user-generated контента и REST API серверной части.

Детали проектирования такие

docs.google.com/...​jKxRMibpQMRW63tpt6lU/edit

https://lucid.app/lucidchart/518d1ce3-1e6d-40b4-a89d-26c48277fb5f/view?page=0_0#

Похожие графические редакторы (типа canva.com, crello.com) используют такие технологии: AWS (S3, CloudFront, ELB, SQS, SNS, SES, SWF), ZooKeeper, Cassandra, MongoDB. Возможно NodeJS.

В оценке стека нам нужно было учитывать такие факторы:

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

— Несмотря на веру в успешность проекта, мы не можем позволить себе аналогичные затраты на сервера как у конкурентов так как у нас заложена другая бизнес-модель (free + реклама) и у нас нет инвесторов. То есть если при количестве например в 37 млн дизайнов у нас будет 200-300 серверов — мы просто уйдём в жёсткий минус.

product.canva.com/csesoc-site-visit

cassandra.apache.org/...​t/operating/hardware.html

Our users upload more than 1.5 million image uploads every day, and create more than 14 designs every second. That means petabytes of media data on Amazon S3 and hundreds of gigabytes of design data in our MongoDb cluster. We also have a large Cassandra cluster (tracking comments on designs, likes, and followers), several large Solr clusters (media and design search), and many more traditional relational stores (e.g. for billing, profile and subscription data). The backend infrastructure consists of between 200-300 servers keeping the whole show going.

— В связи с этим напрашивается больше подход вертикального масштабирования (увеличение мощности сервера), которое гораздо эффективнее горизонтального(увеличение количества серверов).

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

👍НравитсяПонравилось0
В избранноеВ избранном0
LinkedIn

Лучшие комментарии пропустить

Похожие графические редакторы (типа canva.com, crello.com) используют такие технологии: AWS (S3, CloudFront, ELB, SQS, SNS, SES, SWF), ZooKeeper, Cassandra, MongoDB

Это просто набор хайповых базвордов а не «список необходимых технологий»

Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Лучший проект в этом классе — figma.
Но там самое основное — frontend, написанный на С++ и компилируемый в WASM с использованием WebGL. Писался «подорванным» основателем — программистом.

В первых версиях все грузилось из одного файла, который апдейтился последовательностью CDRT операций одним экземпляром процесса на каждый такой файл (www.figma.com/...​iplayer-technology-works).
Бек-энд в первой версии typescript, потом переписывался на Rust.
База данных — на одной вертикально-масштабируемой машинке AWS с монго памяти и монго процесором (я надеюсь я установил раппорт с вашим подсознанием ;)).
На такой машинке и взлетели и жили долго и счастливо, пока не пришли большие компании с корпоративными хотелками (www.figma.com/...​of-figmas-infrastructure)
Сейчас только перешли к усложнению и думают оверинжинерить, надеюсь ничего не поломают...

монго памяти

Чому таке решення є якість поясненя від розробника?

Є дуже змістовне поясненя — „Я великий фан принціпу Тримай його простим, дурню”! :)
One of things people are most shocked to learn about Figma’s infrastructure is that it’s backed by a single database instance running on one of the beefiest machine in AWS. Surprising, right? We are a big fan of the KISS design principle and this simple approach has gotten us pretty far.

Це не пояснення

Твердження про KISS — ще більше заплутує ситуацію

Чому не використана ФС як БД?

В посиланнях є LinkedIn автора — запитуйте там. У мене лише припущення, що якийсь параметр файлової системи не влаштовує — або пошук файла довше, або швидкість послідовного читання, або кількість файлів/нод обмежена.

або пошук файла довше, або швидкість послідовного читання, або кількість файлів/нод обмежена.

точно не це

LinkedIn автора — запитуйте там

не треба так далеко мене посилати
xD

по другой версии там так же руби пробегал на бек-енде.
news.ycombinator.com/item?id=23047495
Our front-end tech stack: TypeScript, React, C++, WebAssembly, WebGL
Our back-end tech stack: Ruby, Sinatra, Go, Rust

Похожие графические редакторы (типа canva.com, crello.com) используют такие технологии: AWS (S3, CloudFront, ELB, SQS, SNS, SES, SWF), ZooKeeper, Cassandra, MongoDB

Это просто набор хайповых базвордов а не «список необходимых технологий»

В Google Cloud можно настроить динамическое подключение/отключение ресурсов (процессоров, памяти и т.д.) в зависимости от нагрузки. Причем платите только за использованные ресурсы. И цены у них нормальные.

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

Новому пользователю дают $300. Деньги можно тратить на оплату сервисов. Этого более чем достаточно для пробного использования.

Підлаштовуіання власної архітектури під гугл клауд коштує значно дорожче тих 300 дол.

Этого более чем достаточно для пробного использования.

если планируется потом закрыть проект, да, чего б нет :)

а если будет жить и усложняться...

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

или как уже реальных что знаю, история, с AWS, тоже, еще на этапе разработки.
пришли счета кастомеру он и охренел.

и пришлось серьезно менять сам процесс разработки и подходы к отладке.

клауды — классная вещь
когда деньги есть.

а когда, как уже другой реальный, приходится выкручивать код чтобы он меньше запросов делал, потому что тарифицируется каждый запрос... и выкручивать — используя другой сервис, который не бесплатный, но дешевле, и ..., и ...,
они потом ушли с Google Cloud, слишком много дурной работы приходилось делать программистам, ради этой «экономии». слишком много инфраструрного кода получается, с неочевидным функционалом, совсем далеким от бизнес задачи приложения

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

когда как конечно.
считать надо.

Коротше єдиного рішення під всі випадки як завжди не знайдено. І лише фанатики наводять шуму.

Что думаете о DigitalOcean Managed Databases? Этот вариант привлекает. Или Hetzner + devop интереснее?

Плюс під кожен вендор потрібен окремий девопс, який на ньому спеціалізується.

думаю что начать стоит с просто хорошего VPSника. Обычного, на KVM.
на убунте или centos

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

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

есть такое дело.
но тут — пусть платит
платит — отчего б не прокачаться :)

но как то клауд провайдеры подмяли под себя существенную долю рынка. И сегодня полностью он-премис деплоймент скорее исключение чем правило, а 20 лет назад клаудов вообще не было :)))
Злые языки говорят что 30% этих ваших интернетов хостятся в амазоне. Наверное исключительно из-за удачного маркетинга. :)))

Злые языки говорят что 30% этих ваших интернетов хостятся в амазоне

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

для таких проектов клауд — фактически незаменим

но вот тут и отвт про деньги
проекты которые столкнулись с такой разницей как правило имеют деньги оплачивать клауд

а когда «пицерия» пытается разместить сайтик свой в клауде, потому что скоро скоро мы станем сетью пицерий города. Не, страны! НЕ, мы так круты — целого мира!!

не вопрос.
деньги дайте, на клауд :)

а когда «пицерия» пытается разместить сайтик свой в клауде, потому что скоро скоро мы станем сетью пицерий города.

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

тогда клауды в разы дешевле получаются.

Можно конкретные цифры по сравнению с тем же Hetzner?:)

Чисто виртуалки конечно у хетзнера дешевле, без вариантов. Но наверное клауды потому и называются «клаудами», что предлагают несколько бОльший сервис чем просто виртуалки? У хетзнера есть аналог RDS, S3, SQS?

RDS, S3, SQS?

я и даром бы на текущий проект не взял :)

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

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

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

Это зависит от. Ни одно наколенное решение и рядом не даст надежности и SLA клаудов. Оно правда не всем нужно, это да. До первого эпичного фейла.

вы и правда перепутали место страшилки рассказывать, и про надежность уровня «для атомной станции»

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

и 30% интернета — мне и правда интересно что и как считали. верю что вы не выдумали эту цифру.

вы и правда перепутали место страшилки рассказывать, и про надежность уровня «для атомной станции»

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

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

Можете сами загуглить цены на SQS/S3.

и 30% интернета — мне и правда интересно что и как считали. верю что вы не выдумали эту цифру.

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

Если в вашем проекте даунтайм в пару дней ни на что не влияет

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

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

но чтобы пару дней...

Можете сами загуглить цены на SQS/S3.

вы глухой? мне и даром он не нужен, накой мне гуглить?

еглый гугл не помогает, цифру я помню с амазоновской презентахи.

а, с «амозоновской презентахи». ну да, ну да, объективней источника не найти.

Но считайте что я выдумал,

не считал, и не считаю что выдумали.

просто, как оно как бухгалтерская шутка
— а какая цифра нужна? сейчас, сделаем!

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

Давайте начнем со списком хостингов, которые вообще дают SLA на виртуалки.

вы глухой? мне и даром он не нужен, накой мне гуглить?

Дык вы же говорите что они дорогие. Эти сервисы вам не нужны, вы не в курсе их стоимости а также стоимости аналогов, но вы утверждаете что они дорогие. Прекрасно.
Если что, я в этом топике раза 3 написал что цена на виртуалки, с учетом их использования 24/7 в любом клаудном провайдере выше чем в хостинге.

Давайте начнем со списком хостингов, которые вообще дают SLA на виртуалки.

начинайте.

я пока даже не интересовался этим параметром :)

Дык вы же говорите что они дорогие.

да. и ладно я слаб в арифметике :)
другие миллионы мух, не с вашего поля в этом глубоко уверены.

но вы утверждаете что они дорогие

потому что подобный функционал я даже не заметил как у нас появился в пару тасок в джире объемом работ.
кажется даже я лично что-то там поднимал, и настраивал. «великий спец» в командной строке линуха, аха.

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

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

нас пока такое — устраивает.

вы похоже никак понять не можете что я тоже умею щеки надувать.

но я вам как фокусник фокуснику и говорю — мы не на сцене, чтобы удивлять друг дружку чудесами

а вы похоже как перед менеджерами кастомера выступаете.

нас пока такое — устраивает.

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

только отмечу что зачастую бывает не так как у вас

я же вам сразу и написал — что зачастую бывает совсем не так как у вас.

Засим предлагаю дискуссию свернуть

ее и не было.
был какой-то монолог — образец впаривателя чудес.

который оказалось невозможным оборвать :)
но было интересно, спасибо.

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

помнится был скандальчик, как Интел душили АМД откатами

Берите пример :)

был какой-то монолог — образец впаривателя чудес.

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

эм, у вас несколько искаженное понимание действительности

конечно у меня искаженное.
у вас вот да — кристально объективный. признаю :)

Во первых мне не платят за посты на доу

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

Вы мне на посты отвечали?

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

а отвечал я на расхожее мнение и типичный «дебют».
ну знаете, может, увлекались, проигрываешь партию на доске, и — а я бы так сходил
а-а-а, «противник» Капабланка — да и пес с ним, кто там противник.
а так глупо сходил Ласкер. Ну дык, ёп, того и проиграл!

нет, не на ваши. мы не знакомы чтобы я отвечал на ваши посты.

Рыдаль :))))

от чего, что не можете деперсонализировать текст в интернете, и как следствие обобщать информацию?

ну, это вполне приобретаемый навык.
если нужен такой.

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

кто что ищет в инете — то себе и найдет.

цифру я помню с амазоновской презентахи

...3 billions devices running Java

SLA клаудов

Молодь
Вже не пам’ятають, як амазон валився цілими дц і зонами

Вже не пам’ятають, як амазон валився цілими дц і зонами

тоесть это было давно и единично. Что и требовалось доказать.

если верить инету, то самый устойчивый это
Digital Ocean, а не AWS

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

единично

Тобто не пам’ятаєте чи не були в той час в іт

Пошукайте — там багато цікавого, особливо для вашого тайтлу, якщо він реальний

эм, с чего вы взяли что я не помню или меня эти факапы не цепляли в смысле работы?

с чего вы взяли что я не помню или меня эти факапы

Не знаю. Коли мене щось підводить сильно декілька разів, то я не буду так висловлюватись

это было давно и единично

Навіть коли будуть співати про sla 99.(9)

Ни одно наколенное решение и рядом не даст надежности и SLA клаудов.

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

У чела тайт — Solution Architect

Его задача, утрировано, собирать из лего функционал.
С минимумом привлечения персонала.

«Программисты скоро станут не нужны:
Коробочные продукты покроют основную часть потребностей — и кастомизировать их будут бизнес-консультанты.
а то на что не будет коробочных продуктов — будет реализовано сервисами, и работами специалистов сервиса по кастомизации»

«Wordpress скоро умрет, сервисы типа Wixx и Shopify избавят от необходимости»

и т.п.

Так что ваш вопрос — не тому специалисту :)

а программистов скоро ждет — массовая безработица.
GPT-надцать закроет оставшиеся потребности.

у професии программиста — нет перспектив...

Его задача, утрировано, собирать из лего функционал.
С минимумом привлечения персонала.

Рыдал. Задача архитектора — решить бизнес проблему клиента с учетом функциональных и нефункциональных требований, ограничений, имеющейся ситуации, финансов, времени и тд и тп. Ваш капитан очевидность, точней адмирал ясин хуй.
И внезапно получается что зачастую «собрать лего» банально быстрей, надежней, секурней, дешевле чем пилить уникальные решения конкретно под данный проект.
Ваши тезисы даже не буду комментировать, я хз откуда вы их взяли и зачем приписываете мне.

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

да?
а остальные чем тогда заняты?
кофе решателю носят? ноги массируют?

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

я то и написал, что программисты скоро станут не нужны.
потому что банально быстрее взять коробочный продукт, Shopify, лего от AWS и доверить дело решения проблем клиента тому кто ее решает, а не программистам, тестировщкам, пиэмам с скрам мастерами и прочим, которые не решают проблем клиента, а заняты непонятно чем.

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

так вот же пост который написан после моих тезисов, как будто был бы написан до них :D

думаю дело в лейтенси. рассинхрон случился, и порядок получения сообщений не соответствует порядку их создания.

Ничто не мешает. Кроме стоимости решения, с хождением по всем граблям в процессе его имплементации.

ай ладно, про грабли то.
не надо нас маленьких стращать то так :)

серваки если и лежат и сервисы падают, то потому что «вечный цикл» в коде блокирует выборку задач из очереди.

но верю, верю, на клауде «вечный цикл» выполняется намного быстрее.
бытенько, прозрачно поднимет еще очередей, и будет счастье безотказности

Лет несколько назад столкнулся с перфоманс тестами распределенного кластера монги в разных регионах амазона. И внезапно оказалось, что лейтенси репликации из сша в ирландию — больше минуты. Это, на секунду, один и тот же клаудный провайдер. Уверен, что при построении кластера между разными провайдерами, таких внезапных удивлений будет куда больше.

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

распиливайте приложение по другому, с учетом :)
архитектурой поиграйтесь
клауды вот использовать — тоже никто не запрещает.

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

старею, факт.

спросите в Дия, Хелси и других — что им помешало?
itc.ua/...​-stavsya-tehnichnij-zbij

Дурноватая стоимость поддержки всего этого добра самому, например?)

и тогда клауды в разы дешевле получаются

«а мужики то и не знали» и выбирают для ворпдессов с вукомерсами — вообще шаред хостинги.

это сознательный путь большого бизнеса

а очень большой и свои датацентры строит

считать надо :)
что выгоднее.

бесплатных «Не надо париться про» не бывает.

выгоды лексуса перед ланосом — понятны.
но даже ТО — разной стоимости :)

бесплатных «Не надо париться про» не бывает.

Беспалтных — не бывает. Но обычно на масштабе получается сильно лучше и сильно дешевле. Т.е. какой нить SQS стоит копейки потому что им пользуются миллионы и тем самым окупают затраты. А построить аналогичное решение «для себя» будет стоить не дешевле чем SQS но из-за совершенно других масштабов это банально невыгодно, не окупится.

Но обычно на масштабе получается сильно лучше и сильно дешевле

именно — на масштабе.
до которого бОльшая часть айти проектов не доросла, и никогда не дорастет

Т.е. какой нить SQS

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

А построить аналогичное решение «для себя» будет стоить не дешевле чем SQS

Да, Цукерберг с того и начал — с аренды дата центра.
упомянутая пицерийка тоже должна с этого начать, аха.

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

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

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

деньги есть — конечно купите.

именно — на масштабе.

На масштабе — это в смысле пролдавать решение миллионам кастомеров, что и делают клаудные провайдеры. За счет количества цены копеечные. Ваш капитан очевидность.

Да, Цукерберг с того и начал — с аренды дата центра.

20 лет назад наверное все технологически было немного не так как сейчас.

В действительности

Действительность бывает совсем разная.

вот и хайп — ах как круто, жить низя без этого.

Именно поэтому 30% инета хостится в амазоне. Потому что хайп, а они тупые, не понимают как надо :))))

это в смысле пролдавать решение миллионам кастомеров

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

За счет количества цены копеечные.

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

20 лет назад наверное все технологически было немного не так как сейчас.

у «цукерберга» и сейчас — в кармане пусто, и «джобс» и сейчас в гараже в «деревянный корпус» микросхемы впихивает.

Действительность бывает совсем разная.

зато в счетах на оплату — используются числа одинаковые для цивилизованного мира

Именно поэтому 30% инета хостится в амазоне.

ссылочку — можно?
интересно как и что мерялось, чтобы прийти к уверенному выводу о копеечных ценах.

Потому что хайп, а они тупые,

кто — они? Амазон или миллионы мух?
уточните субъекта.

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

Если что то не нужно вам, то эьто не значит, что это не нужно кому-то другому. Вас же не заставляют покупать. Но да, очень редко кому нужные сервисы тоже есть: aws.amazon.com/...​ion/?hp=tile&so-exp=below

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

я несколько тоже причастен к бюджетам ИТ проектов, и с уверенностью утверждаю, что SQS стоит копейки. Дешевле него наверное только S3.

у «цукерберга» и сейчас — в кармане пусто, и «джобс» и сейчас в гараже в «деревянный корпус» микросхемы впихивает.

Опять придумали за меня херню какую то. Вы предложили просто взять и перенести реалии 20летней давности на современность. Это глупо.

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

Усталым голосом: копеечные цены на КОНКРЕТНЫЕ сервисы. Да. там есть и дорогие тоже.

кто — они? Амазон или миллионы мух?
уточните субъекта.

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

Если что то не нужно вам, то эьто не значит

а обратное что, уже неверно?
Если это нужно вам, то это не значит что это нужно — миллионам других

SQS стоит копейки. Дешевле него наверное только S3.

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

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

Усталым голосом: копеечные цены на КОНКРЕТНЫЕ сервисы

усталым голосом:
а мужики то и не знали что это все дешевле «индонезийского шареда Hostinger»

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

вы что ли платите? свои?

в третий раз — вы не в том месте рассказываете о том кто принимает решения об оплате.

или путаете два понятия
выбить бюджет и — подписать бюджет.

я сам первый раз выбивал еще в 2000ом.
цену росказням от технарей поэтому знаю.
про то как космические корабли будут бороздить просторы галактик, если вот эту штучку купить.
тогда еще было действенным ввернуть циферки с потолка, насколько улучшится «экономическая эффективность предприятия»
сейчас вроде все, фин отделы подросли, поумнели, и это вышло из употребления.

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

вопросов больше не имею, реально посмешили :)))

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

Гдле я говорил что клауды нужны вообще всем всегда?

цену росказням от технарей поэтому знаю.

Все с вами понятно :)))))

Именно поэтому 30% инета хостится в амазоне

Пруф?

2017 год, но всё же. dou.ua/...​a/articles/moving-to-aws «Минус миграции с железа в облако может быть только один — это дорого. С нашими масштабами эти затраты оправданы. Но если идет речь о небольшом стартапе, то, возможно, будет проще купить VPS.»

и так и будет — за все надо платить.
есть деньги — платите :)

в том числе и за стоимость ребят с «опыт работы с AWS» в резюме.
Если реальный — они «почему-то» тоже стоят дороже :)

Это очень сильно зависит от требований. Тот же dropbox сначала хостился в амазоне и только после того как нарастил масштаб, пр икотором дешевле построить свой датацентр, начал его строить.
Еще один классический пример: быстрый рост нагрузки на ресурсы, которые готовы к горизонтальнйо масштабируемости. В клаудах есть(почти) бесконечные сервераЮ, просто бери и плати. В локальных датацентрах существует временной лаг между закупкой железа и ростом нагрузки. В результате ет приводит или к простою(закупили много наперед, но неугадали и железо стоит), либо к невозможности обслужить кастомеров(закупили слишком мало, не хватает, следующая партия приедет через месяц и это невозможно ускорить).
В ту же степь — пиковые нагрузки, если они есть. В клаудах ресурсы просто масштабируются на время пиковых нагрузок и платишь только за это время. Со своим железом либо купить много, чтобы обработать пики(а все остальное время простаивать), либо просто не обрабатывать пиковые нагрузки.
В общим тема выбора клауда и он премис хостинга — боянистый боян.

ну звичайно кожен проект росте так що нові сервери треба камазами завозити.

WordPress в Google Cloud на виртуальной машине.
Operating System: Debian 10
Package contents: Ghostscript 9.05 , Apache 2.4.46 , ImageMagick 6.9.8 , lego 4.3.1 , MySQL 8.0.23 , OpenSSL 1.1.1k , PHP 7.4.16 , phpMyAdmin 5.1.0 , SQLite 3.35.2 , Varnish 6.0.7 , WordPress 5.7 , WP-CLI 2.4.1
VM instance: 1 shared vCPU + 1.7 GB memory (g1-small)
Standard Persistent Disk: 10GB

$13.61 в месяц.

Вам показати де можна це отримати за менше ніж 5 чи не треба?

www.a2hosting.com/wordpress-hosting
Unlimited Websites
Unlimited NVMe Storage
Free & Easy Site Migration
Free Automatic Backups
Turbo (Up To 20X Faster)
$9.99

21 per mo

Meh

Ніде нема тестів швидкості тих nvme

A2 один з найдорожчих хостингів такого типу.
а тестів на швидкодію nvme я й на поточному хостингу не шукав. Тупити будуть не ssd, зазвичай.

тупити будуть не ssd

Ну рам не резиновий, тому тупити буде саме дискова підсистема

Як нижче писали — той хто писав такє і для 64MB — знає що і хто буде тупити

Никакого

Unlimited

там нет. Это чисто рекламный ход.

Ессно его нигде нет где он звучит.
Но 10 гиг, одно ядро, и 2г ОЗУ — это как-то непонятно о чем. Для бложика, или лендинга — дорого.
для Эл магазина — мало.
Даже если он не маженте.

Потестить? А что тут тестить то?

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

Одному разработчику php показал решение с wordpress, сказал что это полуграмотный бред . WP для для высоконагруженного проекта не годится. И что его предлагают только потому что есть готовые модули для WP и API.

WP вам не подойдет.
Даже без учета нагрузки.
Никаких выгод в разработке не даст, а вот минусов — огребете.

чисто по виртуалкам, повторюсь клауд дороже без вариантов. А вот если ест ьпиковые нагрузки, 3 раза в неделю, то ситуация начинает играть совсем другими красками :))

Сделайте прототип на коленке, проверите идею, если дальше будет финансирование — выкинете прототип и сделаете нормально, нет — быстро и без больших потерь закроетесь. Поэтому я бы рекомендовал брать то что знаете и вперед.

Брати технології, які не знаєте, бо вони по словам в інтернеті чимось кращі/популярніші — місяці викинутого часу на опанування технологій, а результат однаково буде гіршим, ніж коли б цим займалися досвідчені розробники на даних технологіях. Це в гуглах можуть собі дозволити розпилювати бюджети на перенавчання девів. Та й деви там вище середнього, тому можуть швидше світчатися між технологіями.

Моя нубська думка — ключове тут це архітектура і розуміння вимог бізнесу. Щоб воно почало працювати добре хай і не витягує серйозне навантаження, допоки його нема. Займатись передчасною оптимізацією — зло. Це як купувати спортивний мотоцикл, коли вперше отримали права, і ще не поїздили нормально на скутері, з аргументацією, що в майбутньому плануєте стати гонщиком.

Я дуже сумніваюся, що ви не можете затюнити наявний у вас стьок, щоб він вижирав менше цпу/оперативи/пам’яті. Від ре-дизайну коду, до налаштувань самих тулзів.

Плюс, будь-яка код бейз з часом перетворюється в купу з неприємним запахом. Можливо коли зтикнетеся з проблемами на горизонті — почнете писати з нуля вже розуміючи, що має вийти, і якісь написаного буде кращою?

З іншої сторони, якби я був вашим девом, і хотів світчнутися на нову популярну технологію — я б був всіма руками за те, щоб змінювати стьок в проекті. Що може бути кращим навчання за гроші роботодавця?

Ну або ж, коли в наявному проекті вже такий гівнокод, що переписувати в будь-якому разі треба, то тут може вийти виграш усім: розробники заапдейтять свій інструментарій(будуть щасливими, надої підуть вверх), а проект дістане нове дихання. Але це знову ж — серйозний розпил проектного бабла і серйозний тормоз росту бізнесу на місяці, якщо не роки.

— Go существует больше 12 лет, должно было появиться много всего. Но оно все превращается в мусор почти с такой же скоростью как и появляется.

Какой ещё мусор, о чём вообще речь? Если надо, есть официальные драйвера под базы данных на Go, и нормальные библиотеки под любые распространённые темы.

Вот уже давно есть аналог фотошопа онлайн www.photopea.com
Можете пользоваться без регистрации и смс.

Vertx + kotlin + jooq + postgres + redis остальное по ситуации

Есть онлайн графический редактор.

То есть главная сложность будет — на фронтенде, при разработке UI

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

Я бы все что вы написали о бекенде «выбросил». В этом проекте главные будут фронтендеры

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

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

Наш изначальный бек писался на Ruby on rails + PostgreSQL. Вы советуете продолжать?
С фронтендом нам повезло, вроде всё движется как надо.

Часть АПИ уже есть на

Ruby on rails + PostgreSQL.

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

А у Шустера уже были? Как аудитория реагирует на предложение?

Не могу ничего советовать, даже ссылки не открывал :)

Просто опыт. Технологии — дело вторичное для проектов которые можно назвать стартапами.

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

Хотите успеха проекту — ищите, выделите из своих — продакта.
Из фронтендеров — «вице продакта» с визионерскими задатками

А бек подтянется. Когда надо будет.
Тут бек — ведомый.
В отличие скажем от финтех проектов, где бек главный.

Пока у вас на проде(!) не возникли проблемы с бекендом — незачем им особо и заморачиваться.

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

рассчитав все шаги наперёд

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

IMHO здесь заморачиваться нет смысла, тем более архитектурить. Структурируемые данные — в SQL, неструктурируемые (но не используемые для частого поиска) — в полнотекстовое поле SQL, а в нём JSON или что-то подобное. Всё остальное часто спрашиваемое дерьмо — на файловую систему (имена файлов хранить в SQL, но сущности лучше по разным папкам, это облегчит бэкап.
И если контент редко меняется, то сразу и архивировать (кроме манифеста).

Почему так: файловый кеш на операционках за время эволюции просто сказочно эффективен. Он занимает свободную память, и память остаётся свободной. Кроме того, частично можно файловый контент тупо перебросить на CDN, и делать так сколько угодно раз, арендуя ресурсы по мере необходимости — в каждый конкретный момент ничего не переплачивая.

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

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

неструктурируемые (но не используемые для частого поиска) — в полнотекстовое поле SQL, а в нём JSON или что-то подобное.

Джейсон дизайна целиком в базе — это огромные размеры базы уже через пару месяцев работы приложения.

json будет состоять из свалки несвязанных между собой файлов:

список дизайнов юзера (ссылки на json)
список последних поисков
список аплоудов (ссылки на файлы аплоудов)
список аплоуд шрифтов (ссылки на файлы шрифтов)
список бренд шрифтов
список лайков
файловая структура
список палитр
возможно другие списки (все не упомню)

Хранить всё это в postresql будет напряжно.

Один джсон будет весить где-то 30кб, при 5млн дизайнов — это не много?

дело не в количестве данных.
а в проценте потребности горячих данных.
и в типичных алгоритмах их обработки

Тупые примеры:
нам надо отсортировать данные и выдать срез с 20той позиции по 30ую.
надо надо выдать 10 последних позиций

В первом случае если размер данных превышает размер ОЗУ, может быть ой больно
Во втором — да на порядки пусть размер всех данных больше ОЗУ.

А можна частину даних тримати на дорогих SSD, а частину на дешевих HDD? Провайдери серверів дозволяють таке?

та якщо задешево — просто купується «два» сервери у одного ж і того ж провайдера, з різними дисковими системами. так можна навіть економити коли береться частина на OVZ а частина з KVM. рахувати треба, для кожного конкретного проекту, та кількості необхідних серверів.
звісно, будуть тоді вимоги до архітектури самої системи.

а можливо й пропозиція, яку часто бачу:
HDD+SSD кеш
допоможе.
але, навряд чи гарантовано. Статіка то переїде на SSD, а от частина данних БД... невідомо.

А хто їх питає, якщо це хмара? Що треба де треба та й підняв. Проблема лише в дешевих HDD. Хостери за копійку удавляться, але поставлять ненависний сігейт. З черепичним записом, Карл!

Обращение будет постоянным к разным json, фактически при каждом входе юзера в редактор.

надо вникать...

но так — «не бывает» чтобы пользователю нужны был вот сразу все данные.
это как:
— а ваш грид с какой скоростью отрисует миллион строк?
— а кто в здравом уме будет работать сразу с миллионом строк?

но, надо вникать конечно, всякое бывает. даже то что «не бывает»

наверное и правда вам двоих надо
продакта и архитекта.

Пока решили, что один юзер — один джсон. Во время работы этот джсон обновляется. Обращение будет к этому джсону в основном при входе юзера в редактор, то есть особо нагрузка минимальная. Предполагаю что нам Postresql должен хватить с головой в работе с этими джсон. То есть пока обойдёмся без Монго. Если нужно будет попробуем партицирование postresql из коробки для шардинга. По поводу стека на чём писать. Да, я понял что любой подойдёт на котором пишет разработчик. Хоть php.

не проверял, но встречал неоднократно пробовавших в разработке и то и то, что:
CouchDB для быстрого разворачивания, простоты настроек, и некоторых возможностей имеет преимущества перед Монго. И тем более Касандры, та вообще — очень уникальная вещь, и если не знать как ее готовить, можно получить больше боли, чем ее плюшек.
когда сплошь json

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

Да, я понял что любой подойдёт на котором пишет разработчик. Хоть php.

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

а вот фронт там, у-у-у... Могуч. Крут и сложен. Как в разработке так и в развитии.

Графический редакор — аналогично.
Он и во времена GUI считался самым сложным в разработке. Сложней даже многих игр.

какой шардинг, о чем вы. В обозримом будущем ваша аудитория — 3 калеки, вам просто файла на диске хватит с головой :)))

Я бы с ходу выбирал что-то серилизуемое и сжимаемое.
Можно и json+zip, можно protofuf+zip, messagepack+zip.
Хранить меньше, передавать быстрее. Если девелоперы на фронте и беке умеют — делайте. На анализ много времени главное не тратьте — нет так нет, да — берем то с чем работали — вы не убер ;)
eng.uber.com/...​son-encoding-compression

храните данные для пользователя в реляционном виде, собирайте функцией, грубо говоря:

create or replace function get_userinfo
			( user_id bigint
			)
returns JSON as $$
select json_build_object (<your json format>) 
from (
<here your join user table with other tables having details>
) t;
$$ language sql;
Это условный код, можно идентифицировать пользователя токеном и передавать в функцию токен, а оттуда уже айди пользователя выбирать. Формат в этом случае может быть гибким, с минимумом зависимостей.

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

но так — «не бывает» чтобы пользователю нужны был вот сразу все данные

Когда запилили говноархитектуру — бывает :)

Это да...
Как там, у кого-то из классиков

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

Но тут, думаю достаточно будет на этом этапе просто пресекать самодеятельность, моднявость и фантазии «завтра у нас будет навала пользователей, мы рекламу запустили! миллионы придут!!!» и делать по книжке. «по заветам дидов» :)

А что из всего этого используется для поиска? Что-то сомневаюсь, что все 30 килобайт. Остальной мусор тупо кидай в файл.

Список лайков — и вовсе хранить бредово, если ты не фейсбук. Но никто не запрещает попробовать, разумеется отдельной таблицей в SQL.

И потом, 30 000 * 5 000 000 = 150 гигабайт диска. Это условно, разумеется база сожрёт в 4 раза больше, если данные часто удаляются, и ещё на индексы что-то будет. Но в целом даже без оптимизаций у тебя в 0.7 терабайта запрос.

Ты только что расписал структурированные данные.
Для этого достаточно обычных ООП классов + SQL + JOIN.
NoSQL здесь не нужен, как и хранение в JSON.
NoSQL базу для хранения классифицируемых данных втащит или наркоман или хайповод-смузихлеб или человек который за чужие деньги хочет поделать резюме-драйвен-девелопмент.

Хранить всё это в postresql будет напряжно.

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

Да ну? И насколько огромные? Базы данных в принципе не особо боятся объёма. Они боятся промаха по индексам, потому что базы данных — это в первую очередь про индексы.

Если действительно огромные, ничто не мешает поднять две базы, разные. Или как я говорил, кучу хлама, который НЕ ИСПОЛЬЗУЕТСЯ как поля поиска, тупо ложить в файлы и всё. Json же нужен чтобы хранить слабо структурируемые данные, которые всё же можно кешировать и для поиска использовать, но они не могут быть единственными полями поиска.

ок, есть вариант ещё максимально упростить и делать без json. Все данные юзера — в одной таблице postresql. Одно поле — один юзер. В ячейках поля:
-имя юзера,
-данные авторизации,
-дата регистрации,
-дата последнего входа,
-список дизайнов юзера (ссылки на файлы)
-список последних поисков
-список аплоудов (ссылки на файлы аплоудов)
-список аплоуд шрифтов (ссылки на файлы шрифтов)
-список бренд шрифтов
-список лайков
-файловая структура
-список палитр и тд.

Всё остальное в файлы.

то что просится к нормализации у реляционки — лучше нормализовать.

дайте БД возможность соптимизировать, разделив данные :)
они умные, современные БД.

таблица
-имя юзера,
-данные авторизации,
-дата регистрации,
-дата последнего входа,

таблица
список дизайнов юзера (ссылки на файлы)

таблица
-список последних поисков

таблица
-список аплоудов (ссылки на файлы аплоудов)
-список аплоуд шрифтов (ссылки на файлы шрифтов) — может и отдельная тоже

таблица
-список бренд шрифтов

таблица
-список лайков

таблица
-файловая структура

таблица
-список палитр и тд.

ужасы про джойны пересказываются с лохматых времен первых версий MySQL

денормализировать будете когда возникнет проблема
обычно это проще, чем наоборот — из всего «в одной куче» — перейти к «порядку»

ну и, вдруг захочется — избегайте IDшников строк. UUID и прочая.
целое число!

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

вобщем — так как бек вторичен, делайте по «правильным книжкам». без творчества.
я называю это — главное избежать грубых архитектурных ошибок.
а те 20% функционала что потребуют творчества и отхода от канонов — предсказать сложно, и лучше делать когда начнет припекать.

вот когда сразу сложная функциональность.
но у вас это не бек :)

избегайте IDшников строк. UUID и прочая

Или я тебя не понял, или ты думаешь, что UUID хранится в базе как строка? 0.о Это ж BINARY(16) / RAW

смотря в какой.

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

и когда возникает необходимость в UUID завожу просто еще таблицу соответствия ID данных этого узла-кластера, и глобального UUID

бывает редко. у кого-то — обязательно.
потому и — не нужен UUID явно, сразу, по спеке, или по опыту в домене? ну так и не делай. 4 байта, ну ок, 8 байт биг инта — и вперед.

не готов холиварить, это выяснять для митинг рума имеет смысл, для конкретного проекта

смотря в какой.

Ого. Я даже не подозревал что есть базы, которые хранят ууид как варчар. Это же абсурдно.
Просто для информации — скажи, что это за базы?
Насколько я знаю — везде ууид это байты. Только у мускуля традиционные проблемы с представлением ууида и маппингом колонка -> uuid

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

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

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

Поэтому для себя я решил, что по-дефолту ууид предпочтительнее.

Насколько я знаю — везде ууид это байты. Только у мускуля традиционные проблемы с представлением ууида и маппингом колонка -> uuid

и до версии емнип 8 там uuid хранились как строки.
Но с uuid другая проблема: при построении индекса по нему заполненность страниц очень фрагментарная из-за рандомности значений uuid, что приводит к необходимости держать сразу много страниц в памяти, кеширование ломается. Идет постоянный своп на диск при поиске и тормоза.
Чтобы ето побороть в ms sql придумали docs.microsoft.com/...​sql?view=sql-server-ver15
И вот с этим в остальных субд может быть печалька.

при построении индекса по нему заполненность страниц очень фрагментарная из-за рандомности значений uuid

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

ms sql придумали docs.microsoft.com/...​sql?view=sql-server-ver15

Sequential uuid generation есть в оракле. Однажды давно когда не знал этого и открыл таблицу, даже подумал «стопе а почему ууиды одинаковые»

Естественно ет проявляется под приличной нагрузкой в таблицах в десятки-сотни млн записей. И да, зачастую дешевле проапдейтить железо и не париться.
Но стрельнуть может очень неприятно и очень внезапно :)

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

последовательные гуиды вполне могли помочь, они для этого и предназначены. Описанная проблема — не самый частый кейс, согласен и не причина не использовать гуиды :)

Насколько я знаю — везде ууид это байты

да как бы только байты и существуют
варчар — тоже байты.

Только у мускуля

да. моя любимая БД.

Но в проектах с хоть какой-то нагрузкой использовать ПК инт стремновато изза ограниченности и сиквенсов.

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

а какое у вас соотношение чтения и записи?

у «веб проекта» считай никто не пишет, все читают :)
у энтерпрайз — о, один оператор пишет тьму, а «читает» мало.

А лонг проигрывает ууиду в читабельности имхо.

ну не знаю, не знаю :)
по моему как раз наоборот

На практике, имея колонки на десятки-сотни миллионов записей c пк/фк ууид, я с такими проблемами не сталкивался.

может и нет проблем, не проверял
с точки зрения разработки — разницы никакой. а потенциальный риск поиметь проблемы — есть.

поэтому у меня дефолтно — обратное правило :)
даже 3 байтные целые использую.
разницы в разработке никакой, а

«дай БД возможность соптимизировать» соблюдается.

Я бы дату последнего входа вынес в отдельную таблицу входов. А в таблицу юзера просто ячейку с ид с форейн кеем на последнюю запись по юзеру в таблице входов.
Аргументы:
1) если дата входа важна — 99% важны и другие даты
2) статистика посещений — получаем легкий способ отделить одно-двух-разовых юзеров от постоянных.

то уже подробности.

у меня нередко ситуация — есть статусы у сущностей.

и у бОльшей части статус — «completed»
в итоге индексище по этому полю — а смысл, если в 99% случаев интересны акутальные?

тогда, по ситуации — либо две таблицы, для «completed» и горячих статусов и перенос между ними
либо индекс таблица, id status

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

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

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

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

Структурируемые данные — в SQL, неструктурируемые (но не используемые для частого поиска) — в полнотекстовое поле SQL, а в нём JSON или что-то подобное. Всё остальное часто спрашиваемое дерьмо — на файловую систему (имена файлов хранить в SQL, но сущности лучше по разным папкам

Этот простой и рабочий концепт делит на ноль все архитетурное творчество мамкиных архитекторов в сторону хайпа про бигдату носкль кафку и т.д., поэтому никому не зайдет :)

Эти мамкин архитекторы просто не видели все эти задачи рабочими на 64Мб оперативы. Задача-то вообще не на архитектуру, а типичная для безобразия на построение нормальных форм. Всё.

Я-то с тобой согласен.
Но вокруг бродят целые толпы бекендеров, для которых default silver bullet DB — это монга

Я на них посмотрю, когда эта монга посыпется. А она умеет.

Найміть архітектора 8-)

Неправильно ищите. Надо сесть на скамейку, достать кулечек с баксами, посыпать и сказать «гули-гули». Они и прилетят.

то в архитектуру можно добавить MongoDB

Щоб застопорити все?

В Mongodb шардинг более-менее автоматический, администрирование в теории проще чем Postgres.

Пфффф
У вас якась дивна інфобульбашка — в моїй монгу поховали для всього, що більше хелловорлд

Напишіть перелік інструментів, на яких ви написали більше одного проекта
Це ваш стек

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

Але саме бомбезне

Есть онлайн графический редактор

Ви ж розумієте, що вам іноді треба буде повторювати, те що зробив юзер на фронті на серверах?

То есть Монго — это плохо, в тоже время любой стек подойдёт в котором шарит разработчик. Правильно?
А если разработчик шарит в Монго?

"

Ви ж розумієте, що вам іноді треба буде повторювати, те що зробив юзер на фронті на серверах?

"
не понял

Монга — це коли ви перевірили її на навантаженням і точно знаєте який важіль тягнути в якому випадку. І ви не боїтесь втратити дані

У вас вже є постгрес

не понял

браузер має суттєві обмеження
Вам треба буде робити частину роботи на серверах
В залежності від напрямку розвитку — ви можете опинитись в ситуації, коли ви будете догоняти фічі, що треба на фронті, замість оптимізувати бек

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

Якщо редагуються векторні зображення, то текст в бд
Растр
superuser.com/...​ersion-control-for-images
stackoverflow.com/...​ontrol-systems-for-images

It will be pain in the ass

Сумісне редагування — це race condition і тут нема (я не знаю) простого рішення

Сам контент и не надо хранить в бд. На бд хранится ссылка на контент и метаданные

Подписаться на комментарии