В рейтинге участвует:

групп:

каналов:

Виртуальный сервер на SSD - недорого!

Аренда выделенных и виртуальных серверов (VDS/VPS), хостинг, аренда IP-адресов, администрирование, круглосуточная поддержка

qwarta.ru подробнее

Резервное копирование с проверкой на вирусы!!!

Удобный сервис создания резервных копий на любой сервер сети интернет. Отслеживайте изменения, проверяйте на вирусы. Надежно защитите свой бизнес!

go.backupland.com

Выбираете сервер? Любая конфигурация на заказ!

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

qwarta.ru подробнее

Size: a a a

Архитектура данных

430 membersпожаловаться на группу
2020 August 25

CO

Chern Oleksander in Архитектура данных
и доп вопрос, а если разработчики будут работать в облаке AWS (EC2/3, VMS, Instance, S3), а вот аналитика в Google Cloud (Google CLoud Storage, BigQuery)
и данные для аналитики дергать с S3/Instance в CloudStorage
источник
16:52пожаловаться#1

CO

Chern Oleksander in Архитектура данных
Paul Golubev
на какой железке делать пофиг, если тебе iops и остальных мощей хватит. Вопросы параллельных процессов наполнения и вопросы железа разные темы
просто понимать, это реально критично?
просто я за последние два года привык к облакам где, любая потребность по увеличение любых параметров сервака - не есть проблема, ползунок вправо ))
источник
16:53пожаловаться#2

CO

Chern Oleksander in Архитектура данных
"Вопросы параллельных процессов наполнения и вопросы железа разные темы"
Якобы если сервак 8CPU/1Tb SSD/42Gb Ram
в момент когда на этом серваке будет крутится две отдельные БД, они будут жрать намного больше, что может в конечном итоге сильно влиять на работу сайта
источник
16:58пожаловаться#3

PG

Paul Golubev in Архитектура данных
Критично если одна база начнет жрать диски, тогда всем на этой хранилке несладко придется. Не админ, поэтому не особо понимаю, насколько там можно менеджить именно iops
источник
16:59пожаловаться#4

PG

Paul Golubev in Архитектура данных
так ты хочешь урезать то, что сейчас выделено под основную базу сайта? Или поставить 2 базы без разделения?
источник
17:01пожаловаться#5

CO

Chern Oleksander in Архитектура данных
Paul Golubev
Критично если одна база начнет жрать диски, тогда всем на этой хранилке несладко придется. Не админ, поэтому не особо понимаю, насколько там можно менеджить именно iops
Вооо, вот за этот момент больше всего и горит
источник
17:01пожаловаться#6

CO

Chern Oleksander in Архитектура данных
Paul Golubev
так ты хочешь урезать то, что сейчас выделено под основную базу сайта? Или поставить 2 базы без разделения?
Две БД
источник
17:01пожаловаться#7

CO

Chern Oleksander in Архитектура данных
два мастера
источник
17:01пожаловаться#8

PG

Paul Golubev in Архитектура данных
не совсем понятно, зачем такое делать, реалтайм нужен в хранилище?
источник
17:03пожаловаться#9

PG

Paul Golubev in Архитектура данных
само по себе 2 мастера не сильно накладно, вставка - из самых дешевых операций. Но вот потом использование. На моем опыте было по нескольку баз на одной железяке + хранилище. Иногда админ писал ай яй яй кушай поменьше
источник
17:05пожаловаться#10

PG

Paul Golubev in Архитектура данных
но это редко было. Только железка там очень мощная была, поэтому у тебя может другой случай
источник
17:06пожаловаться#11

CO

Chern Oleksander in Архитектура данных
Paul Golubev
не совсем понятно, зачем такое делать, реалтайм нужен в хранилище?
со стримом, планировал делать из мастера-прод, а с DWH еще не решил, будет или (
источник
17:08пожаловаться#12

CO

Chern Oleksander in Архитектура данных
Paul Golubev
но это редко было. Только железка там очень мощная была, поэтому у тебя может другой случай
а вот тут я не уверен что мне такой бюджет дадут
источник
17:08пожаловаться#13

VS

Vladislav 👻 Shishkov... in Архитектура данных
С точки зрения архитектуры строительства хранилища, по хорошему, надо разделять все и делать отдельные трансформации. А то после развития продукта есть большой шанс нарваться на лютый ахтунг в лице монолита между продуктом и хранилищем
источник
17:08пожаловаться#14

CO

Chern Oleksander in Архитектура данных
Vladislav 👻 Shishkov
С точки зрения архитектуры строительства хранилища, по хорошему, надо разделять все и делать отдельные трансформации. А то после развития продукта есть большой шанс нарваться на лютый ахтунг в лице монолита между продуктом и хранилищем
вот тоже больше хочется отдельно прям всё, но пока что есть небольшие ограничения по бюджетам.
источник
17:15пожаловаться#15

CO

Chern Oleksander in Архитектура данных
Всем спасибо, короче лучше всё отдельно делать - где-то так в голове и было )
источник
17:15пожаловаться#16

VS

Vladislav 👻 Shishkov... in Архитектура данных
если есть ограничение по бюджетам - значит хранилище не нужно
источник
17:16пожаловаться#17

CO

Chern Oleksander in Архитектура данных
Chern Oleksander
и доп вопрос, а если разработчики будут работать в облаке AWS (EC2/3, VMS, Instance, S3), а вот аналитика в Google Cloud (Google CLoud Storage, BigQuery)
и данные для аналитики дергать с S3/Instance в CloudStorage
и может кто-то с такой херней сталкивался
источник
17:16пожаловаться#18

CO

Chern Oleksander in Архитектура данных
Vladislav 👻 Shishkov
если есть ограничение по бюджетам - значит хранилище не нужно
там нужно просто подождать, они будут но попозже, а работать нужно сейчас
источник
17:16пожаловаться#19

VS

Vladislav 👻 Shishkov... in Архитектура данных
Петров и Ильф писали "утром деньги - вечером стулья"
источник
17:17пожаловаться#20