да, 3к максимум

но сейчас докупим посмотрим, 3к это кажется 10% от максимума

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

ок, ну до 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 шард-ключ вообще имеет очень ограниченное применение

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

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

Как я понял

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

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

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

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

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

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