а какой у тебя iowait на такую запись?

не знаю, я не это меряю

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

https://www.youtube.com/watch?v=0vPt7GI-2kc&feature=share

CPU: 48% usr 4% sys 0% nic 46% idle 0% io 0% irq 0% sirq

https://www.youtube.com/watch?v=0vPt7GI-2kc&feature=share

Atlas для ОЧЕНЬ БОГАТЫХ

оно стоит просто ПИЗДЕЦ

0 - io странно как-то стало быть, там памяти вагон?

Mem: 14579448K used, 458084K free, 1444K shrd, 193688K buff, 5627696K cached

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

натурально

я когда счёт за две недели увидел, у меня челюсть упала

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

они мне потом издевательское сообщение прислали: А ЧОЙТЫ ВЫ УШЛИ

А сколько стоит услуги?

https://www.mongodb.com/cloud/atlas/pricing

там есть наёбка, очень обидная

(называется Amazon AWS)

https://yopp.in/13os

Mem: 14579448K used, 458084K free, 1444K shrd, 193688K buff, 5627696K cached

это все рейд или хранилка какая-то модная?

это все рейд или хранилка какая-то модная?

это виртуализация от ovh. это тестовый стол

рейд в монге не нужен

«сдохла нода, ну и хуй с ней, щас новую воткнём»

а если и нужен, исключительно чтоб iops дожать

короче атлас может быть в Калифорнии и нормально, с их зарплатами в 300к/год, но в остльном мире — это эребор

мдаа уж

не, ну серьёзно, ведро на хецнере с 1Tb nmve стоит 170 евро в месяц

256гб рам

510 евро на репликасет

70 центов в час. у монги за такие деньги 8gb ram / 40Gb storage

«сдохла нода, ну и хуй с ней, щас новую воткнём»

главное чтобы ещё пара не сдохла, пока эта заменяется)

главное чтобы ещё пара не сдохла, пока эта заменяется)

так и с рейдом всё тоже самое

ну с рейдом всё-таик дисков в 2 раза больше

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

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

и сколько будет стоит минута простоя если эти данные не будут доступны

и что будет если они безвовратно будут утеряны

ну как всегда)) денег нет, но вы держитесь

увольте CTO

и его зарплату пустите на бекапы

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

тогда зачем бекапы!

да хоть 200 ;) тем не менее. Какое правильное восстановление в этом случе

яж говорю

и сколько будет стоит минута простоя если эти данные не будут доступны

^

и вот это всё

нет правильный стратегии

есть выгодная стратегия

не, ну серьёзно, ведро на хецнере с 1Tb nmve стоит 170 евро в месяц

а я правильно понял это вот оно ? https://www.hetzner.de/en/hosting/produkte_rootserver/px61nvme

https://www.hetzner.de/en/hosting/produkte_rootserver/px121ssd + 2x 512Gb NMVE (42€) + Flexipack

ssd тоже можно заюзать

и да, если не ЕС, то без VAT https://www.hetzner.de/ot/hosting/produkte_rootserver/px121ssd

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

надо сначала определится с моделью угроз

удаление коллекции

тогда да, отложенная реплика

а вообще права нужно оторбать на drop у всех

и вообще, приучится к DENY ALL, ALLOW NONE и выдачей роли конкретного права на конкретную коллекцию

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

то есть фактически восстановление шаред кластера - это дублирование отложенной реплики и сборка второго кластер, чтоб восстановить коллеццию?

и по ключу шардирования все-таки. Правильно ли я понимаю, если совсем просто: date или _id - запись идет все время на один шард из-за монотонно возрастающего ключа client_id - запись на все шарды

то есть фактически восстановление шаред кластера - это дублирование отложенной реплики и сборка второго кластер, чтоб восстановить коллеццию?

dump / restore или application level sync

и по ключу шардирования все-таки. Правильно ли я понимаю, если совсем просто: date или _id - запись идет все время на один шард из-за монотонно возрастающего ключа client_id - запись на все шарды

с client_id это работает только если у тебя вставка таким образом, что вставка вся с разными client_id

ну каждый документ имеет конечно разные client_id

То есть свой, соответственно клиенту

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

если он меньше 512 байт (или сколько там сейчас), то не имеет смысла

у тебя уже даныне есть?

да

ну вот возьми собери себе тестовый стол

и на нём проверь все свои гипотезы

эх

https://yopp.in/13pL

вот так хуёво работает балансер :(

https://yopp.in/13pL

чем рисуется ?

чем рисуется ?

:))))))

убийцей mms

(на самом деле я там забыл сортировочку по min/max, правильный heat map вот такой https://yopp.in/13qO)

но зато видно как чанки бьются

чем рисуется ?

а, что, нравится? :)

Мне тоже нравится.

Фоновый интерес

Warm/hot это шарды по свежести данных?

по скорости стороджа

hot local ssd, warm сетевая хрень с 300 iops

тёпленький ))

видимо чуть тёпленький если там 300иопс )

ребят привет

подскажите тут мне передали парочку баз

и вот пришел момент заресторивать

дамп пищется с ключами —gzip —archive

в итоге на выходе получается один data файл, а не папка dump

как проще всего заресторить из этого файла базу?