с этого надо начинать всегда

а jombo чанк уже никуда не поедет? он не балансируется?

в чем как бы проблема jombo чанка?

нет, не поедет

во всём

понятно. то есть их не должно быть...

да, потому что они всю идею шардинга на нет сводят

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

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

не бывает идеального поля для всех

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

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

вот например как выглядит неравномерное распредление чанков при записи. сначала всё шло хорошо (слева ровно) и данные равномерно попадали на разные шарды. а потом вылезло говно, которое называется «алгоритм балансировки» и из-за того что балансировщик тупой, данные начали попадать чаще на одни шарды, чем на другие https://yopp.in/13lg

и вот так вот просела производительность кластера на вставку https://yopp.in/13mZ

на графике сети пики это примерно 300мбит/с

кстати, можно иначе посмотреть

а у меня на каждый инсерт еще четыре апдейта приходит

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

во, наглядно: https://yopp.in/13nq

а какой у тебя 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