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

Ты на цену посмотри. Там за iops были какие-то совершенно конские цены

ну клиенту показал, он сказал ок

там 0.075 в час

ток я не понял еще за что конкретно лол

За iops?

хм...чет ваще дорого тогда

типа один iops?

за 1?

Ты уточни. :)

Хз, может за 1 или за 100 или за 1000

Но я помню что было очень дорого

ну дорого да

но тут выбор или я работаю дня 3-4 и разворачиваю все, мигрирую, меняю код

или платим за iops

Мигрировать не надо. Нужно только реплику поднять (и арбитра)

Это можно тупо снепшотом сделать.

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

Ну и connection string

For example, if you provision a volume with 1000 IOPS, and keep this volume for 15 days in a 30 day month, then in a Region that charges $0.10 per provisioned IOPS-month, you would be charged $50 for the IOPS that you provision ($0.10 per provisioned IOPS-month * 1000 IOPS provisioned * 15 days/30). You will be charged for the IOPS provisioned on a volume even when the volume is detached from an instance.

короче может быть норм если это решит вопрос с IO

я как раз купил 1000

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

ок, гляну на будущее пригодится

а, блин

там 15 дней

получается за 30 выходит 100 баксов

чет дофига

прям ваще...

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

а, стопэ у нас цена 0.07

короче 74 бакса где-то

за 1000 iops в месяц

там на амазоне еще влияет размер ноды,на которой это крутится

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

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

Я тут прикинул

Наверное будет проще купить для реплики instance с ephemeral storage

У которого все дофига быстро и только с него и читать

если время экспорта не критично, то надо идти по пути «медленная реплика»

тупо дешевле будет

да но не забывать, что это эфемерал и я не тестил его на нагрузку @dd_bb поделишься своим мнением оп этому поводу?

Кстати документация говорит что реплики особо не увеличивают скорость

гхм

Ну оно и понятно - что там что там один объём будет данных

Кстати документация говорит что реплики особо не увеличивают скорость

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

и камни подводные, но вставка идет быстрее

Ну я так и думаю в принципе. Вижу смысл в реплике только если делать на ephemeral...

добавление нод в replica set, при использовании readPreference: secondaryPreffered или secondary увеличиют пропускную способность, то только на чтение

если хочется скейлить нагрузку на запись, то только шардинг

А если нет то как то хз. Какая разница какой сервер затупит - primary/secondary

большая

Ну по сути у меня нет фронтенда

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

Ну это да, но зачем все мутить если в итоге все запросы все-равно будут идти на одну ноду

почему на одну ноду?

Ну preference выставлю на одну ноду

Ну ок. Будет 80/20%

Я на самом деле не знаю :) Просто с шардингом я так понимаю можно увеличить на 70%-90% с каждой новой нодой

нельзя

А с репликой ну будет +40% прироста на чтение

почему?

Я ж не знаю. Поэтому и пишу :) Это мои догадки по документации.

надо понимать что шардинг это не волшебная таблетка,

шардинг это адовый геморой с дизайном данных, потому что если данные не дизайнились под шардинг, всё будет _очень плохо_

а hashed это не шардинг

я боюсь по шардингу что это навсегда раз и что могу терять на бродкастах много два

шардинг это адовый геморой с дизайном данных, потому что если данные не дизайнились под шардинг, всё будет _очень плохо_

А вот например hashed + _id как ключ хреново?

конечно

hashed шард-ключ вообще имеет очень ограниченное применение

Хм...а почему?

Ну оно разбросает равномерно

Как я понял

равномерно != оптимально

Но будем много терять чтобы потом собрать на запросах

по этому он и говно

Ну там вроде если нет запросов по интервалам то ок пишут

если у тебя есть «широкие» выборки без явного указания шард-ключа, то это ничего не меняет

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

у тебя любая выбока в которой не известен точно шард-ключ будет броадкастится на весь кластер

Угу

и это убивает весь смысл шардинга

И это сильно будет медленно по сравнению с одной нодой?

это работает для всяких приблуд типа gridfs и прочих

И это сильно будет медленно по сравнению с одной нодой?

я не знаю что такое «медленно» или «быстро» :)

Ок. Запросы будут быстрее или медленнее выполнятся при использовании hashed и __id чем если бы они работали на одной ноде?

И на сколько быстрее/медленнее? Хотя бы примерно на глаз :)

потому что правильный вопрос: для данных X, испольуемых через выборки Z и Y, как изменится производительность при изменении топологии с Foo на Bar

И на сколько быстрее/медленнее? Хотя бы примерно на глаз :)

¯\_(ツ)_/¯

Я тут думал за часик все поменяю и буду на коне. А тут такие философские вопросы :)

Кстати купили iops

1000

Мало:)

По цене как ещё один сервак :)

это от того что почти все думают про данные самым неэффективным образом

В общем ты считаешь что лучше реплика с чтением с secondary?

В принципе если использовать ephemeral...

Возникает вопрос насколько это хреново если бутнуть потом этот сервер

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

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