Как сэкономить миллион: Как сэкономить миллион на процентах по ипотеке и найти скрытые дыры в бюджете

Содержание

HighLoad Junior Блог

Продолжаем изучение практического использования Tarantool. Отличный доклад Дениса Аникина с HighLoad++ 2015 про то, как правильный инструмент помог сэкономить миллион долларов 🙂

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

Для начала вопрос: почему чаще используют именно базы данных, а не файлики?

Базы данных – это хранилище, более структурированное, чем файл, и обладающее рядом некоторых фич, которых у файла нет.

Там можно делать запросы, там есть транзакции, индексирование, таблицы, устойчивые, более-менее надежные хранилища. На самом деле, базы данных – это более удобно, чем файлы.

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

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

Что обычно в таких случаях делают? Еще один сервер. Это репликация. Т.е., по сути, вы доставляете реплики ровно в таком количестве, чтобы они держали вашу нагрузку.

Вы всю нагрузку на чтение уводите на реплики. Соответственно, нагрузку на запись вы оставляете на мастере. Эта схема может, в принципе, масштабировать нагрузку на чтение практически до бесконечности.

Дальше у нас происходит нагрузка на запись.

И нагрузка на запись, опять же, достигает какого-то предела, когда база данных уже не может ее держать. Поможет в данном случае репликация? Нет. Какая бы не была репликация – мастер-слейв или мастер-мастер – она не поможет нагрузке на записи, потому что каждая запись должна пройти на все сервера. Даже если там мастер-мастер, значит, сколько у вас идет суммарно запросов на весь ваш кластер, ровно столько же пойдет на каждый из серверов, т.е. вы этим ничего не выиграете.

Какие есть еще идеи?

Шардинг.

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

Есть много разных способов шардинга – можно резать по базам данных, можно резать по таблицам, можно резать внутри одной таблицы. Способов – миллион. Каждый использует тот способ, который ему удобней.

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

Но дальше у вас происходит проблема. Ваша следующая проблема – это ваш босс. Что ему в этом может не нравиться? Вроде как, все работает, все шардируется, реплицируется, но что ему не нравится? Деньги. Ему все нравится, кроме того, что это стоит очень дорого, потому что вы доставляете, доставляете, доставляете сервера, и он за это платит.

Вы ему говорите: «Чувак, ты не понимаешь, у меня тут технология, у меня тут шардинг, репликация. .. Оно масштабируется бесконечно – это очень крутая система».

Он вам говорит: «Да-да, но мы теряем деньги, если так пойдет дальше, у нас просто не будет денег, чтобы покупать сервера баз данных. Нам придется закрыться».

Что же делать?

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

Кэширование – это то, что частично решает нашу проблему.

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

Но… какая есть проблема? Проблема несогласованности – одна из самых больших проблем, которая есть с кэшем.

Это самая первая проблема, которая тут же видна.

Смотрите, у вас приложение отдельно пишет в кэш, например, в Memcached и отдельно пишет в базу. Т.е. кэш не является репликой базы, кэш является отдельной сущностью. Тут нарисованы стрелочки между кэшем и базой, которые на самом деле виртуальны, т.е. никакой репликации между ними нет. Все делается на уровне приложения. Соответственно, это приводит к несогласованности данных.

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

Тут картинка, чтоб показать вам, что вы можете писать сначала в базу, потом в кэш, или сначала в кэш, потом в базу. В обоих случаях у вас будет несогласованность. Смотрите: вы пишете данные в кэш, после этого ваше приложение благополучно падает и в базу их записать не успевает. Приложение поднимается и работает с теми данными, которые уже в кэше, а в базе данных их нет, но никто про это не знает. Когда кэш перезагружается (а он когда-нибудь перезагружается), вы получаете из базы данных при пустом кэше устаревшие данные.

Как ни странно, если писать в обратном порядке – сначала в базу, потом в кэш, будет ровно такая же проблема: записали в базу, приложение упало, в кэше старые данные, все работает со старыми данными, кэш перезагрузился, потянул из базы новые данные, как бы другую ветку данных, которые не целостные, которые не соответствуют тем изменениям, которые были сделаны поверх другой копии…

Т.е. с кэшем есть как минимум две проблемы: нет целостности данных, и вам все еще нужен шардинг.

Какие есть еще проблемы с кэшем? Какие вы кэшем внесли проблемы в тот момент, когда ваш босс начал сердиться? Проблема такая: кэш – это не база данных.

У вас до кэша была база данных, там были запросы, транзакции, и все эти штуки из кэша почти все пропадают, у вас приложение работает уже с кэшем. Индексы и таблицы остаются, не во всех кэшах есть вторичные индексы, не во всех кэшах есть таблицы, но как-то криво-косо поверх key-value и то и другое можно поддержать, поэтому мы считаем, что эти свойства соблюдены, а остального всего нет.

Теперь по поводу проблемы нецелостности данных. Что с ней сделать? Как сделать так, чтобы данные обновлялись и в кэше и в базе целостно? Умный кэш.

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

Это решает проблему нецелостности, потому что кэш сначала пишет в базу, а потом пишет в себя. Если он в базу не записал, отдал ошибку – все хорошо. Это конечно не хорошо, но данные целостные. После того, как кэш записал в базу, он в себя запишет данные обязательно, потому что он пишет в память, такого, чтобы данные не записались в память практически никогда не бывает. Вернее, бывает, когда на сервере бьется память и в этот момент все падает, и все равно вы теряете весь кэш, по крайней мере, целостность данных не теряется.

Но есть один кейс, когда даже при таком умном кэше данные можно потерять.

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

Это редкий кейс, но такое тоже бывает. Т.е. умный кэш не решает до конца проблему нецелостности данных. И вам все еще нужен шардинг.

Шардинг – это когда у вас есть база данных, которая на одном сервере, и вы ее просто режете. Вы ее режете на кусочки и эти кусочки укладываете по разным серверам, физическим серверам. Это уменьшает нагрузку на запись, потому что нагрузка на запись идет на конкретный кусочек. Т.е. у вас, по сути, все CPU, например, всех серверов участвуют в обработке этой нагрузки, а не CPU только одного сервера.

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

Итак, нецелостность данных, к сожалению, остается с кэшем, шардинг все еще нужен, свойств баз данных нет.

Какая еще очень неприятная проблема с кэшем есть? Холодный старт.

Это супер неприятная проблема, когда кэш поднимается с нуля, чистый, голый, без данных… Он бесполезен, также как машина, полностью заваленная снегом – в нее вначале нужно залезть, а еще ее нужно завести. Холодный старт полностью убивает кэш, все запросы напрямую летят в базу данных.

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

Четыре проблемы с кэшем:

Вопрос: как прогреть кэш? Кэш всегда должен быть прогрет, чтобы он имел смысл. Через базу данных его прогревать как-то не аккуратненько, потому что много-много реплик, и они все его греют-греют – слишком дорого они его греют.

Персистенс – правильное слово. Кэш лучше просто не охлаждать, его нужно персистить, потому что кэш – хорошее и быстрое решение, за исключением нескольких проблем, включая проблему холодного старта, включая то, что он иногда недогрет, так пусть он будет всегда согрет. Как, например, в Сибири некоторые люди не глушат машины, чтобы они были всегда заведенные, потому что иначе ты ее потом не заведешь – примерно из той же оперы.

Какой самый простой способ персистента для кэша?

Это просто dump данных. Т.е., на самом деле, мы каждый раз, может быть, в минуту, или, например, раз в 5 минут дампим весь кэш полностью на диск, прямо целиком. Как вам это решение? Отстой, потому что теряется консистентность. Вы раз в 5 минут дампите, у вас как бы сервер поднимается, и он теряет свое изменение за 5 минут. Через базу данных их прогревать нельзя, и даже непонятно, откуда эти изменения взять. И это не единственная проблема.

Вторая проблема – это то, что по IOPS’ам будет плохо, т.е. постоянно будете нагружать диск. Дампами, дампами и еще раз дампами, постоянными. Чем вы хотите иметь более целостные данные, тем чаще будете дампить. Какой-то не очень приятный путь.

Как лучше персистить кэш?

Лог. Нужно просто вести лог.

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

Если вы думаете, что это медленно (всегда есть мнение, что кэш – это что-то такое быстрое, а когда там появляется диск, то это становится как-то медленно), так вот, на самом деле, это не медленно, потому что даже самый обычный крутящийся магнитный диск, не SSD, пишет со скоростью 100 Мб/с, последовательно пишет. Если размер транзакции, скажем, 100 байт, то это 1 млн транзакций в секунду. Это неимоверная скорость, которая удовлетворит почти всех присутствующих в этой аудитории, может быть даже меня. Поэтому даже один диск с этой задачей вполне справляется, но есть другая проблема, что этот лог разрастается очень сильно, потому что, например, идет 10 инсертов, потом 10 делитов тех же самых данных, они должны все схлопнуться, а в логе они не схлопываются. Или идет 100 апдейтов одного и того же элемента данных, опять же нужен только последний, а в логе хранятся все. Как эту проблему решить? Сшепшоты делать.

Нужно соединить два этих метода – Dump и Log воедино. Т.е. мы раз в неделю дампим, или когда нам этого хочется, а все остальное время только пишем лог. В дамп мы еще запоминаем id последней примененной записи из лога или последней записи из лога, которая в этом снепшоте еще есть. И когда у нас сервер перезагружается, мы поднимаем с диска dump, восстанавливаем его в памяти и сверху накатываем тот кусок лога, который после этой записи. Все, кэш восстановлен и прогрет сразу.

Кстати, этот прогрев происходит быстрее, чем из базы данных. Вот такого рода прогрев при перезагрузке потом полностью попадет в диск, потому что это линейное чтение файла – 100 Мб/с. Даже на магнитных дисках это очень быстро.

Все, проблема холодного старта решена, но это только одна проблема, к сожалению. Хотя кэш прогрет, есть еще 3 проблемы.

Давайте подумаем, как решить первые две – проблемы неконсистентности и шардинга?

Идея использовать кэш как базу данных – это очень правильное направление. Действительно, зачем нам в этом месте наша основная база данных? MySQL или Oracle – зачем она нам нужна? Давайте подумаем.

Нужна, наверное, для 2-х вещей:

мы считаем, что база данных надежно хранит данные, не как кэш, а надежно, т.е. там, наверное, есть какая-то магия;
то, что в базе данных есть репликация. У кэшей обычно репликации нет. Соответственно, кэш сервера вышел из строя или просто перезагрузился, и пока он не поднимет все с диска, это быстрее, чем прогрев, но все равно будет down time – это тоже плохо, а репликации там нет.

По первому пункту – надежное хранение. Если разобраться, то что хранит база данных? База данных хранит горячие и холодные данные – это по сути все, что она хранит. Горячие данные – это обычно маленькие-маленькие и очень-очень горячие, которым 10-100 тысяч RPS, а холодные данные – это такие большие и холодные, к ним очень мало обращений.

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

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

Зачем мы делаем все это копирование? Мы можем, наверное, копировать только горячие данные?

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

И ваш босс все еще злой, потому что у вас все еще есть шардинг.

На самом деле, мы говорим, что базы данных надежно хранят данные, но наш кэш сейчас тоже надежно хранит данные, потому что у него есть транзакшн лог – файл, в который пишутся все изменения. Это не что иное, как лог транзакции, это то же самое, что есть у любой базы данных, это ровно то, за счет чего обеспечивается надежное хранение в любой базе данных, никакой магии, и у кэша есть то же самое.

Репликации нет. Это, конечно, плохо, но давайте подумаем, почему кэш не может быть первичным источником данных? Потому что нет репликации? Хорошо, мы ее сделаем.

Почему еще кэш не может быть первичным источником данных? Потому что он не обладает свойствами баз данных? Мы тоже можем это сделать, мы можем все эти свойства баз данных поддержать, и кэш будет ими обладать. Помните картинку «Кэш – это не база данных»?

Кэш может быть базой данных. Он может всеми этими свойствами обладать.

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

Собственно, что мы и сделали, и назвали эту базу данных Tarantool.

Мы разработали специальную базу данных для горячих данных, которая является кэшем, но при этом у него есть персистенс, транзакции (такие же, как у взрослых баз данных), репликация, у него даже есть хранимые процедуры. Т.е. все основные свойства базы данных у Tarantool’а есть. И поэтому мы его используем как первичный источник для горячих данных. Мы эти данные не дублируем нигде. У нас Tarantool, у него есть реплика, эти данные бэкапятся, как и для любой базы данных, но они не дублируются нигде, ни в каких других базах данных. Это такой всегда горячий кэш с персистентом и со свойствами баз данных, т.е. он все эти проблемы решает.

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

Мы просто используем правильный инструмент для правильной задачи, т.е. холодные данные хранятся в хранилище. Например, в SQL хранилищах, которые были созданы десятки лет назад именно для холодных данных, потому что тогда не было такого количества запросов в секунду на данные, никто про это не думал. А горячие данные хранятся в том хранилище, которые специально задизайнено для горячих данных в Tarantool.

Тут, в принципе, на слайде все написано – наш путь, через который мы прошли, но факт в том, что для большинства задач были достаточны 2 инстанса всего Tarantool – один мастер, второй – реплика, потому что нагрузка, которая идет на одну из баз данных, на один инстанс, она, скорее всего, обеспечит всю вашу полосу нагрузки, которая шла раньше на весь ваш кластер SQL серверов.

И еще тут один психологический момент – не очень хочется уходить из уютного мира баз данных в неуютный новый мир кэшей. В базе данных транзакции и т.д. Тогда, когда ваш босс злой, вы доставили кэш и как-то сразу стало неуютно. И как раз Tarantool возвращает этот уют, т.е. он, мало того, что решает проблемы неконсистанси и холодного старта. Он, как бы, возвращает вас в мир баз данных для горячих данных.

Теперь кейс в почте Mail.ru.

Кейс был такой: нам нужно было хранить профили пользователей. Профили пользователей – это такие маленькие кусочки информации – от 500 байт до 1 Кб на пользователя. Мы изначально стали для этого дела использовать MySQL. И стали дублировать всю нагрузку на профили, которые у нас до этого лежали в старом хранилище, на чтение и на запись на ферму из MySQL. Мы поставили ферму из 16-ти MySQL, все пошардили заранее и туда пустили нагрузку. И оказалось, что на 1/8 от всей нашей нагрузки эти 16 серверов уперлись в полки. В основном, они уперлись в полку по процессору.

Мы пытались их тюнить так и сяк, но по факту, все, что мы достигли – это 16 серверов на 1/8 нагрузки, т.е. на весь кластер, на всю нагрузку потребовалось бы 128 MySQL серверов. Мы подумали, что это дороговато – это больше 1 млн. долларов. И мы просто поставили несколько серверов с Tarantool и туда пустили всю нагрузку. В тестовых целях, дублировали. И оказалось, что они без проблем ее тянут целиком. Даже одного сервера было достаточно. Поставили просто 4, потому что мастер, реплика + еще пара, на всякий случай. Мы обычно перезакладываемся всегда по нагрузке.

Собственно, вот она экономия миллиона долларов – просто мы в 60 раз снизили количество серверов, которое нам нужно. При этом даже пользователю стало лучше, потому что кэши обычно работают с лучшим лэйтенси.

У нас суммарно в облаке и почте больше 120 инстансов Tarantool, серверов прямо с Tarantool, которые используются для разных фич, для очень большого количества фич. Если бы мы все это хранили в MySQL или в любом другом SQL, то это были бы сотни миллионов долларов, просто, если экстраполировать имеющиеся цифры.

Мораль моего всего выступления: нужно использовать правильный инструмент, для правильной работы, т.е. нужно использовать базы данных для холодных данных и кэши с персистентом, как Tarantool, для горячих данных. И сэкономить на этом 1 млн. долларов.

Тут краткое Summary о том, что мы сделали. Мы шардировали, реплицировали, уперлись в деньги, стали кэшировать, потеряли консистенси и еще кое-что… Сделали персистент кэш, это не база данных, но он может быть базой данных, отделили горячие от холодных данных, холодные – в MySQL, горячие – в Tarantool, спасли 1 млн. долларов и, как бонус, получили лучший юзер експириенс, потому что все стало быстрее.

← Строим сервисы на базе Nginx и Tarantool

Принципы и приёмы обработки очередей →

Как сэкономить миллион долларов с помощью Tarantool / Хабр

Для чего используются базы данных, ведь есть старые добрые файлы? Чем они хуже базы данных или чем база данных лучше файлов? БД — более структурированное хранилище. Она позволяет делать транзакции, запросы и так далее. Самый простой случай: есть сервер с базой данных и несколько приложений, которые делают запросы к серверу. База данных отвечает, меняет что-то внутри себя, и всё хорошо ровно до того момента, пока нагрузка на неё не вырастает настолько, что база данных перестаёт справляться.

Если допустить, что это только нагрузка на чтение, то проблема решается репликацией. Вы можете ставить к базе данных столько реплик, сколько нужно, и все чтения пускать на реплику, а все записи — на мастер. Если же на базу данных идёт нагрузка на запись, то репликация эту проблему не решает, ведь запись должна осуществляться на все реплики. Таким образом, сколько бы вы их ни ставили, вы не уменьшите нагрузку на запись из расчёта на одну машину. Тут на помощь приходит шардинг.

Если база не держит нагрузку на запись, то шарды можно добавлять до бесконечности. Шард устроен сложнее, чем реплика, потому что нужно как-то распределить данные по таблицам или внутри таблицы, по хэшу, по range — есть множество разных вариантов. Таким образом, добавляя реплики и шарды, вы можете делить любую нагрузку на базу данных. Казалось бы, больше желать нечего, о чём дальше говорить?

…которая лежит уже не в плоскости технологий. Ваш босс, видя постоянно растущий парк серверов, начинает негодовать, потому что на это уходит много денег. Нагрузка растёт, количество запросов от пользователей растёт, и вы всё добавляете и добавляете серверы. Вы же технарь, про деньги не думаете — пусть этим занимаются финансисты. И вы говорите своему боссу: «Всё нормально. У нас бесконечно масштабируемая система. Мы добавляем серверы, и всё круто работает». А босс отвечает: «Отлично, но мы теряем деньги. Нужно что-то с этим сделать. И если мы не решим проблему, то придётся закрыть весь бизнес. Поскольку, несмотря на рост бизнеса, по базам данных и серверам мы растём с опережающей скоростью». И эту проблему должны решить именно вы, а не финансисты, потому что она лежит, возможно, в технологической плоскости. Что делать дальше? Amazon гораздо дороже. Оптимизировать? Вы уже оптимизировали все запросы.

Выходом может стать кэширование данных, которые часто селектятся. Их можно держать в каком-то кэше и постоянно возвращать оттуда, не обращаясь к многочисленным репликам и шардам.

Отлично, проблема решена: один memcached заменяет нам целую стойку серверов-реплик. Но за всё приходится платить.

Приложение пишет и в кэш, и в базу, которые между собой никак не реплицируются. Таким образом возникает несогласованность данных. Например, вы пишете сначала в кэш, потом в базу. По какой-то причине запись в базу не получилась: приложение упало, сеть моргнула. Затем приложение вернуло пользователю ошибку, но в кэше уже находятся другие данные. То есть в кэше одни данные, а в базе другие. Про это никто не знает, приложение продолжает работать с кэшем. И когда он перезагружается, данные теряются, потому что в базе находится другая копия.
Самое смешное, что если писать в обратном порядке, то будет происходить то же самое. В базу записали, а в кэш запись не прошла. Мы работаем со старыми данными из кэша, в базе новые данные, но про это никто не знает. Кэш перезагрузился — опять данные потеряны. То есть в обоих случаях теряется апдейт. А это говорит о том, что вы теряете некое свойство базы данных, а именно — гарантию, что записанные данные сохранены в ней навсегда, то есть коммит уже не коммит. Справиться с несогласованностью данных можно, написав умный кэш, чтобы приложение работало только с ним. Он может быть и write through, лишь бы приложение не работало с базой. Сначала кэш должен записывать полученные данные в базу, а потом в себя. Если по каким-то причинам данные в базу не записались, то и в кэш они не должны записываться. Таким образом данные будут всегда синхронны. Данные не могут не записаться в кэш, потому что кэш — это память, а в память запись всегда проходит, кроме ситуации, когда память побилась, но и в этом случае умный кэш «свалится», унеся все закэшированные данные в небытие, что плохо, но не приведет к рассинхрону данных.
Но всё равно остаётся один редкий случай, при котором данные оказываются несинхронны: приложение пишет в кэш, кэш пишет в базу, база внутри себя сделала коммит. Дальше она подтверждает кэшу успешное завершение операции, но в этот момент рвётся сеть, и кэш этого подтверждения не получает. Он считает, что данные в базу не записались, и не применяет их у себя. Но в базе они всё-таки применились. Приложение работает со старыми данными, потом кэш перезагружается — данные опять другие. Это очень редкий случай, но он возможен.
И самое главное — умный кэш никак не решает проблему шардинга. А ваш босс не любит шардинг, потому что это очень дорого, ведь нужно покупать много-много серверов.
Помимо прочего, внедрение кэша не избавляет нас от шардинга, потому что запись не ускоряется. Каждый коммит должен куда-то коммититься, причём не в кэш.
Следующая проблема: кэш — это не база данных, а обычное key/value-хранилище. У вас теряются запросы и транзакции. Индексы и таблицы тоже теряются, но их можно с грехом пополам соорудить поверх key-value кэша. Поэтому приложение приходится упрощать и кардинально переделывать.
Четвёртая проблема — «холодный старт». Когда кэш только поднимается, он пустой, в нём нет данных. Далее все селекты идут напрямую в базу мимо кэша, потому что в нём ещё ничего нет. Соответственно, приходится снова добавлять реплики, хотя бы не в полном объёме. Нам же нужно как-то прогревать кэш. А когда он прогревается, то в базу идёт много селектов. Соответственно, приходится держать целый ряд реплик только для прогрева кэша. Не правда ли, это выглядит достаточно расточительно? Но без этих реплик вы не сможете нормально стартовать. Рассмотрим подробнее решение этой проблемы.

В своё время возникла такая идея: чтобы данные были всегда «теплыми», нужно просто не «охлаждать» их. Для этого кэш должен быть персистентным (persistence), то есть нужно хранить данные где-то на диске, и тогда всё будет нормально. Кэш будет стартовать и подгружать данные. Но тут возникло сомнение: кэш — это ОЗУ, он должен быть быстрым, а когда ему в пару даётся диск, то не будет ли он таким же медленным, как база данных? На самом деле — не будет.

Проще всего «персистить» кэш раз в N минут, целиком дампить его на диск. Этот дамп можно делать асинхронно, в фоне. Он не замедляет никакие операции, не нагружает процессор. Это позволяет многократно ускорить прогрев: когда кэш поднимается, у него уже под рукой собственный дамп с данными, он их читает линейно и очень быстро. Получается быстрее, чем с любым количеством реплик баз данных. Но не может же быть всё так легко, верно? Допустим, мы делаем дамп каждые пять минут. А если в промежутке происходит сбой, то накопившиеся с момента предыдущего дампа изменения будут потеряны. Для каких-то приложений это неважно, например для статистики, а для каких-то важно.

Вторая проблема — мы хорошо нагружаем диск, который, возможно, требуется для чего-то ещё, например для логов. Во время дампа диск будет тормозить, и происходить это будет бесконечно. Избежать этого можно, если вместо регулярных сбросов дампа вести журнал. Сразу должен возникнуть вопрос: «Как же так? Это кэш, он быстрый, а мы тут всё журналируем». На самом деле это не проблема. Если писать журнал в файл последовательно, на обычном винчестере, то скорость записи будет достигать 100 Мб/с. Допустим, средний размер транзакции 100 байт — это миллион транзакций в секунду. Очевидно, что мы никогда не упрёмся в производительность диска при журналировании кэша. Благодаря этому решается и проблема IOPS: мы нагружаем диск ровно настолько, насколько это необходимо, чтобы все данные персистились. Данные всегда свежие, мы их не теряем, при этом прогрев осуществляется быстро.

Но у журналирования есть свои недостатки. При ведении лога апдейты, которые обновляют один и тот же элемент, не группируются в одну запись. Их получается много, и при старте кэшу приходится «проигрывать» все эти записи, что может занять больше времени, чем старт с дампа. Кроме того, сам по себе лог может занимать очень много места, даже не уместиться на диск.

Для решения проблемы можно объединить оба подхода — сброс дампа и ведение лога. Почему бы нет? Мы можем дампить, то есть создавать снапшот, раз в сутки, и при этом всегда писать в лог. В снапшоте мы сохраняем ID последнего изменения. А когда нужно запустить кэш, читаем снапшот, сразу применяем его в память, дальше читаем лог, начиная с последнего изменения в снапшоте, и применяем его поверх снапшота. Всё, кэш прогрет. Это делается так же быстро, как если бы мы читали из дампа. Итак, с холодным стартом мы разобрались, давайте теперь решать остальные проблемы в нашем списке.

У базы данных есть такое свойство, как durability, которое обеспечивается с помощью транзакций. В БД обычно хранятся горячие и холодные данные. По крайней мере, раз мы дошли до кэша, то у нас данные точно делятся на горячие и холодные. Обычно холодных данных очень много, а горячих очень мало. Так устроена жизнь. Мы реплицируем и шардируем базу данных на много-много копий и шардов только для того, чтобы обслуживать горячие данные. Мы можем сказать себе: «Зачем мы всё это копируем? Давайте шардировать только горячие данные». Но это никак не поможет, потому что мы должны использовать ровно такое же количество серверов, ибо шардируем и реплицируем не из-за того, что данные не помещаются в память или на диск, а из-за того, что мы упираемся в CPU. То есть база не успевает обрабатывать. Таким образом, шардинг и репликация только горячих данных не решает эту проблему. И босс всё ещё злится, потому что нужно платить за всё новые серверы.

Что можно сделать? У нас есть кэш, но горячие данные в базе не дают спокойно жить, мы доставляем их реплики и шарды. Однако кэш тоже хранит данные, как и база. При желании можно сделать в нём репликацию. Что нам мешает использовать кэш как первичный источник данных? Отсутствие такой фичи, как транзакции? Можем сделать и транзакции. Тем самым мы решаем остальные три проблемы, поскольку горячие данные можно будет вообще не хранить в базе, только в кэше. Шардинг тоже становится не нужен, ведь нам не придётся резать базу данных на много серверов, кэш успешно справляется с нагрузкой, в том числе и на запись. А на запись он справляется потому, что у кэша запись работает с журналом так же быстро, как и без журнала.

Итак, в кэш можно внедрить все свойства, которые присущи базе данных. Мы так и сделали, а получившееся в результате детище назвали Tarantool. По скорости работы на чтение и запись он сопоставим с кэшем, при этом имеет все свойства базы данных, которые нам необходимы. Таким образом, мы можем отказаться от базы для хранения горячих данных. Все проблемы решены.

Итак, эти многочисленные холодные данные мы реплицировали и шардировали только для того, чтобы обрабатывать малочисленные горячие. Теперь холодные данные, редко запрашиваемые и изменяемые, лежат в SQL, а горячие отправляются в Tarantool. То есть Tarantool — это база для горячих данных. В итоге для большинства задач двух инстансов (мастера и реплики) более чем достаточно. Хотя можно обойтись и одним, потому что паттерн доступа к нему и RPS такой же, как у обычного кэша, несмотря на то что это база данных. Для кого-то это проблема психологического свойства: как можно отказаться от базы как от авторитетного источника хранения данных с её уютным durable с транзакциями и уйти в кэш? На самом деле, начав использовать memcached или любой другой кэш, вы уже отказались от преимуществ базы данных. Вспомните про inconsistency и потерю апдейтов. И с этой точки зрения Tarantool не только ускоряет работу и позволяет экономить деньги, он возвращает вас обратно в мир баз данных с транзакциями, запросами, индексами и прочим.

Пара слов про параллельную работу транзакций. Когда в Tarantool используется Lua, он это рассматривает как одну транзакцию: все чтения делает из памяти, а все записи передаёт во временный буфер и в самом конце одним куском пишет на диск. И пока данные пишутся, другая транзакция уже может читать из памяти старые, незакомиченные данные без всяких блокировок! Очередь из транзакций может возникнуть лишь в том случае, если будет превышена пропускная способность последовательной записи на диск.

Этот процесс у нас пока не автоматизирован. Анализируем логи и определяем, что данные с таким-то паттерном можно считать горячими. Например, профили пользователей — горячие, значит, мы их перекладываем в Tarantool. Понятно, что попутно зацепим и холодные, потому что часть юзеров, например, на Почту уже не ходит. Но, несмотря на перерасход, это получается эффективнее, чем при использовании MySQL. Хотя бы потому, что у Tarantool очень сильно оптимизирован memory footprint. Очень интересный факт: БД SQL всё хранит на диске, но 10–20% должно кэшироваться в памяти. Но при этом у традиционных SQL БД footprint в три-пять раз хуже чем у Tarantool, поэтому эти 20% превращаются в 100%. Получается, что при аналогичной нагрузке SQL-сервер не выигрывает даже по памяти, хотя и нагрузку эту он не держит.

С нашей точки зрения, есть два ключевых отличия между Tarantool и Redis.

По нашим тестам, Tarantool быстрее процентов на 30%. Результаты тестирования представлены на сайте Tarantool и в этой статье.
Tarantool — это база данных. Там можно писать server side скрипты на Lua. У Redis тоже есть Lua, но он однопоточный, блокирующийся, писать свои скрипты можно, но область применения их весьма ограниченна. К тому же Lua в Redis не транзакционен. В этом смысле Tarantool идеален. Он и быстрее, и позволяет использовать транзакции везде, где нужно. Нет необходимости доставать key из кэша, апдейтить и класть обратно, когда параллельно кто-то ещё может менять.

Эта сумма — не выдумка для привлекательного заголовка, а реально сэкономленные деньги в одном из проектов Mail.Ru Group. Нам нужно было где-то хранить профили пользователей. До этого они лежали в старом хранилище, и мы размышляли, куда бы их перенести. Изначально мы рассматривали MySQL. Развернули 16 реплик и шардов MySQL, начали потихоньку дублировать в них нагрузку от профилей на чтение и запись. Профили — это маленькие порции информации (от 500 байт до килобайта), хранящие ФИО, количество отправленных писем, различные флаги и сервисные данные, которые обычно нужны на каждой странице. Эти данные часто запрашиваются и обновляются. При 1/8 от всей нашей нагрузки ферма из 16 MySQL сломалась. И это после всех оптимизаций, которые мы там сделали. После этого мы решили попробовать Tarantool. Оказалось, что он на четырёх серверах спокойно держал нагрузку, которая до этого была распределена по 128 серверам. На самом деле даже на одном сервере держал, мы поставили четыре для подстраховки. А экономия в виде 128 серверов и снижения расходов на хостинг оказалась эквивалентна миллиону долларов.

И это лишь один случай. Tarantool нашёл применение во многих наших проектах. Например, в Почте и Облаке трудится 120 инстансов Tarantool. Если бы при имеющемся уровне нагрузок там использовался MySQL, то пришлось бы ставить десятки тысяч серверов или других SQL — PostgreSQL, Oracle, чего угодно. Даже трудно оценить, в какие миллионы долларов это бы вылилось. Мораль сей басни такова — для каждой задачи нужно подбирать правильный инструмент, это позволяет экономить огромные деньги на простейшей фиче. Холодные данные надо хранить в предназначенной для этого базе данных SQL, а горячие данные, которые часто запрашиваются и часто обновляются, нужно хранить в хранилище, адаптированном для этого, коим является Tarantool.

В версии 1.7, которая сейчас находится в разработке, мы хотим сделать полностью автоматическое кластерное решение с шардингом и с репликацией типа RAFT. Следите за обновлениями!

Как накопить миллион долларов до выхода на пенсию

В этой статье:

1. Автоматизируйте свои сбережения
2. Начните раньше
3. Составьте бюджет и придерживайтесь его
4. Избавьтесь от долгов по кредитным картам с высокими процентами
5. Подумайте о дополнительной работе
6. Не используйте свои сбережения раньше времени
Постоянство – ключ к успеху

вам нужно экономить на основе вашего дохода и пенсионных планов образа жизни. Если ваша цифра — 1 миллион долларов, вам может быть интересно, достижима ли эта цель.

Сможете ли вы накопить миллион долларов к пенсии? Это возможно, но требует тяжелой работы, времени и дисциплины. Читайте советы, как достичь цели уйти на пенсию с 1 миллионом долларов.

1.

Автоматизируйте свои сбережения

Автоматическое отчисление части вашей зарплаты на ваш пенсионный счет каждый день выплаты зарплаты поможет вам регулярно вносить вклады и не отклоняться от поставленных целей сбережений. «Заплатив себе в первую очередь» — другими словами, автоматически откладывая на будущее каждый день выплаты жалованья, — у вас не возникнет соблазна потратить деньги, которые принесли бы вам больше пользы, если бы вы отложили их на пенсию.

Один из самых простых и эффективных способов инвестировать средства для выхода на пенсию — настроить автоматические депозиты на ваш счет 401(k) или IRA. 401 (k) и традиционные IRA позволяют вам инвестировать свои деньги на основе до налогообложения, что означает, что со временем они будут расти (и накапливаться) без уплаты налогов. Он будет облагаться налогом как доход, когда вы будете использовать его на пенсии, когда ваш заработок, скорее всего, поставит вас в более низкую налоговую категорию.

Некоторые работодатели перечисляют хотя бы часть взносов своих сотрудников на свои счета 401(k). Всегда стремитесь вкладывать по крайней мере столько же, сколько ваш работодатель может дать.

Если вы достигли лимита взносов на пенсионный счет или хотите рассмотреть другие способы инвестирования, у вас есть варианты. Вы можете настроить автоматические переводы на высокодоходный сберегательный счет или напрямую инвестировать свои деньги в недвижимость, акции, облигации или биржевые фонды. Вы также можете инвестировать в индексный фонд, например, в фонд S&P 500. Согласно данным Goldman Sachs, акции, включенные в этот индекс, достигли высокой среднегодовой доходности в 13,6% в период с 2010 по 2020 год.

Имейте в виду, что инвестирование напрямую в рынок может потребовать немало усилий для управления, а также сопряжено с риском, но вы имеете преимущество, если между вами и выходом на пенсию проходит несколько десятилетий. Таким образом, у вас будет достаточно времени на рынке, чтобы переждать взлеты и падения.

2. Начните раньше

Если вы еще не начали откладывать на пенсию, вы не одиноки. Согласно отчету Федеральной резервной системы об экономическом благополучии домохозяйств США за 2020 год, каждый четвертый взрослый человек вообще не имеет пенсионных сбережений. В то время как у большинства непенсионеров есть сбережения в той или иной форме, только 36% заявили, что чувствуют себя на пути к финансовой свободе на пенсии.

Лучшее время, чтобы начать работать над достижением цели пенсионных сбережений, — прямо сейчас, даже если вы работаете неполный рабочий день. Чем моложе вы будете, когда начнете экономить, тем лучше. И хотя 1 миллион долларов — амбициозная сумма, она вполне может быть достигнута, если ваши взносы успеют вырасти.

Время имеет решающее значение, когда речь идет о пенсионных накоплениях. Ожидание даже пяти или 10 лет может иметь огромное значение в том, сколько вы будете иметь к тому времени, когда достигнете пенсионного возраста. Чтобы определить, сколько вы должны откладывать, чтобы достичь своей личной пенсионной цели, вы можете использовать онлайн-калькулятор сбережений, чтобы подсчитать, сколько лет вам осталось до выхода на пенсию, вашу предполагаемую норму прибыли и вашу пенсионную цель.

Используя 8,7% годовой доходности (среднее значение для пенсионного счета, равномерно распределенного между акциями и облигациями, согласно данным Vanguard), вот сколько вам нужно откладывать в месяц, чтобы достичь 1 миллиона долларов к выходу на пенсию:

3. Составьте бюджет и придерживайтесь его

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

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

Затем добавьте свои цели сбережений и постройте свой образ жизни на том, что осталось. Вы можете обнаружить, что несколько потоковых сервисов, еженедельные изысканные рестораны или регулярные походы в маникюрный салон работают против вашей цели заработать 1 миллион долларов к пенсии, и это нормально. Хотя вам не нужно отказываться от всех удобств, чтобы достичь своей цели, вам, вероятно, придется пойти на жертвы, если вы хотите дойти до 1 миллиона долларов.

Установив свой бюджет, постарайтесь его придерживаться. Если вы обнаружите, что испытываете искушение перерасходовать деньги без необходимости, сравните немедленное удовлетворение от совершения покупки с вашими целями финансовой свободы на пенсии. С другой стороны, вы можете пересмотреть свои пенсионные цели, если новый бюджет покажется вам слишком строгим.

4. Избавьтесь от долгов по кредитным картам с высокой процентной ставкой

Хотя долги сами по себе не так уж плохи, долги с высокими процентными ставками могут помешать вам накопить богатство. Если у вас есть остаток на кредитной карте с годовой процентной ставкой (APR) выше примерно 8%, одна из лучших инвестиций, которую вы можете сделать, это погасить ее как можно скорее. Это потому, что маловероятно, что любые инвестиции окупятся так же высоко, как проценты, которые вы платите своему кредитору.

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

Но как только вы отметите эти галочки, сделайте приоритетной выплату долга с высокими процентами. Вы также можете консолидировать задолженность по кредитной карте с помощью личного кредита с низкой годовой процентной ставкой или использовать кредитную карту с переводом остатка с вводным периодом 0% годовых.

5. Подумайте о подработке

Благодаря сегодняшней бурной экономике подработок существует больше способов преуспеть, чем когда-либо, чтобы заработать немного денег на стороне. И если вы ищете способы увеличить свои сбережения до 1 миллиона долларов, подработка и вложение дополнительного дохода в пенсионный период — отличный способ пополнить свои сбережения.

Например, если у вас есть машина, поездка в службу такси может стать гибким способом добавить деньги к вашим сбережениям. Если вам нравится заниматься рукоделием, попробуйте выставить свою работу на продажу на Etsy. Переворачивание мебели, стрижка газонов, выгул собак — возможности почти безграничны. Вы также можете найти внештатную работу, в которой используются навыки, которые вы уже используете на работе, такие как программирование или дизайн. Храните заработанные деньги на своих пенсионных счетах.

6. Не используйте свои сбережения раньше

Несмотря на то, что может возникнуть соблазн воспользоваться 401(k) или IRA в момент финансовых трудностей, использование вашего пенсионного счета может иметь долгосрочные финансовые трудности, которые могут быть серьезными.

Мало того, что преждевременное изъятие средств из ваших пенсионных сбережений препятствует вашим усилиям по накоплению, но и суровые штрафы за досрочное снятие могут сделать доступ к вашим наличным до выхода на пенсию еще более разрушительным. Если вы обналичите свои средства из 401 (k) или традиционной IRA до достижения возраста 59,5 лет, вам может грозить штраф в размере 10%. Кроме того, вам также придется платить подоходный налог с денег, которые вы снимаете.

Чтобы не брать взаймы на пенсию, создайте резервный фонд. Стремитесь к чрезвычайным сбережениям, чтобы покрыть как минимум три-шесть месяцев необходимых расходов.

Ключ к постоянству

Достичь 1 миллиона долларов к выходу на пенсию — большая цель, требующая немалой работы. Если вы планируете жить по средствам, регулярно инвестируете и позволяете сложным процентам творить чудеса, создание здоровой пенсионной сбережения может стать достижимой целью.

Сколько бы времени ни осталось до пенсии, сейчас самое время составить план. Если вам нужна помощь в определении того, какие стратегии вам подходят и как достичь цели, обратитесь к специалисту по финансовому планированию за индивидуальным советом.

Как сэкономить 1 миллион долларов, шаг за шагом

Чем раньше вы начнете, тем легче будет сэкономить 1 миллион долларов. Вот пошаговое руководство, которое покажет вам, сколько вы должны откладывать каждый месяц, чтобы достичь семизначной суммы.

Вы когда-нибудь задумывались, как накопить миллион долларов?

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

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

Что впереди:

Во-первых, решите, когда вы хотите накопить 1 миллион долларов

Хотите ли вы накопить 1 миллион долларов раньше, позже или к обычному пенсионному возрасту 65 лет, количество оставшихся лет будет определять сколько вам нужно откладывать каждый месяц, чтобы достичь миллиона долларов.

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

Просто возьмите желаемый возраст миллионера (если вы хотите накопить 1 миллион долларов) и вычтите текущий возраст.

Итак, если вы хотите заработать 1 миллион долларов в 65 лет, а сейчас вам 30 лет, у вас есть 35 лет на накопления.

Затем решите, какую прибыль вы ожидаете от своих инвестиций

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

Прежде чем мы начнем говорить о том, насколько окупились различные инвестиции с течением времени, вы должны знать следующее: то, как инвестиция работала в прошлом, не обязательно означает, что она будет такой же в будущем.

Тем не менее, чем длиннее ваш инвестиционный горизонт (количество времени, в течение которого вы будете инвестировать свои деньги), тем выше ваши шансы на получение общего дохода, который ближе к среднему историческому долгосрочному значению.

Давайте посмотрим, как несколько различных инвестиций работали за последние 20 лет (включая так называемое «потерянное десятилетие», первый зарегистрированный 10-летний период, когда доходность акций была неизменной).

Акции

За последние 20 лет средняя годовая доходность фондового рынка, измеренная индексом S&P 500 и представленная Школой бизнеса Стерна Нью-Йоркского университета, составляла 7,60%. Для ясности: были годы, когда рынок падал (ужасные -36,55% в 2008 г.), но были и годы, когда он рос (колоссальные 32,15% в 2013 г.).

Стоит также упомянуть, что средние показатели фондового рынка были исторически низкими за последние 20 лет (это «потерянное десятилетие» было весьма непростым). Средняя годовая доходность за последние 50 лет составляла 11,23% .

Облигации

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

Используя 10-летние казначейские облигации в качестве косвенного показателя и снова используя данные, представленные Школой бизнеса Стерна при Нью-Йоркском университете, средний годовой доход за последние 20 лет составил 5,31% . За последние 50 лет она составляла 7,11%.

Наличные

Хотя деньги в вашем кошельке определенно считаются наличными, то же можно сказать и об инвестициях, таких как ваш счет денежного рынка, которые обычно состоят из краткосрочных инвестиций, таких как трехмесячные казначейские векселя.

Это самые безопасные инвестиции с самой низкой волатильностью (количество колебаний цены инвестиции с течением времени). В то же время они также предлагают самую низкую доходность.

Хотя очень маловероятно, что вы потеряете деньги, вложив свой капитал в наличные, существует также высокая вероятность того, что ваши инвестиции не опередят инфляцию, что со временем означает, что ваши деньги будут медленно терять ценность.

Тем не менее, за последние 20 лет трехмесячные казначейские векселя в среднем составляли 1,44% (опять же с использованием данных, представленных Школой бизнеса Стерна при Нью-Йоркском университете). За последние 50 лет они составляли в среднем 5,04%.

Большинство инвестиционных портфелей включают в себя комбинацию инвестиций из этих трех сегментов. Те, кто готов пойти на больший риск, в надежде на более высокую доходность, создают портфель с более высокой концентрацией акций. Те, кто более не склонен к риску, нагружаются облигациями и денежными вложениями.

Связанный: Хотите узнать больше о том, как работает ваш портфель? Попробуйте Personal Capital, бесплатное приложение для анализа ваших инвестиций

Наконец, найдите свой волшебный номер ежемесячных сбережений

шансы на получение более высокой прибыли с течением времени. В противном случае вам придется каждый месяц искать способ сэкономить кучу денег.

Ознакомьтесь с кратким описанием на рисунке в начале этой статьи.

Если до выхода на пенсию осталось 40 лет

Те, у кого самый длинный инвестиционный горизонт, находятся в лучшей форме благодаря магии сложных процентов.

Если вы начнете рано и выйдете на пенсию поздно, вы можете выйти на пенсию миллионером, сэкономив всего 179 долларов в месяц , при условии 10%-й нормы прибыли. Используя более консервативную норму прибыли 6%, вам нужно будет экономить 522 доллара в месяц.

По теме: Все еще не верите в силу сложных процентов? Вы должны это увидеть

Если до выхода на пенсию осталось 30 лет

Ожидание всего 10 лет сильно повлияет на сумму, которую вам придется накопить, чтобы достичь своей цели. Даже при среднем годовом доходе в 10% вам придется откладывать 481 доллар в месяц , чтобы получить 1 миллион долларов до выхода на пенсию. При 6% вам нужно будет экономить 1021 доллар в месяц.

Если до выхода на пенсию осталось 20 лет

Чем дольше вы откладываете накопления, тем больше денег вам придется откладывать каждый месяц для достижения цели. Если вы подождете до выхода на пенсию через 20 лет, вам нужно будет накопить 1382 доллара в месяц чтобы достичь отметки в миллион долларов, предполагая 10-процентную прибыль. При 6% вам нужно будет экономить 2195 долларов США в месяц!

Если до выхода на пенсию осталось 10 лет

Как видите, ждать последние 10 лет до выхода на пенсию — рискованная стратегия. При доходности 10% вам придется откладывать 4964 доллара в месяц , чтобы заработать миллион долларов. Это довольно сложно сделать, особенно если вы не выработали привычку постоянно откладывать деньги на протяжении всей жизни.

Если бы доходы были ниже, это кажется еще более невозможным: при 6% вам нужно было бы откладывать 6 125 долларов в месяц, чтобы получить миллион.

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

Суть в том, что чем дольше у вас осталось и чем выше ваш среднегодовой доход, тем выше ваши шансы на достижение цели.

Хорошей новостью для вкладчиков и инвесторов является то, что если вы откладываете по пенсионному плану 401(k) или другому пенсионному плану, спонсируемому работодателем, ваш работодатель может компенсировать часть ваших сбережений. Эти совпадения могут оказать огромное влияние на пенсионный портфель, независимо от того, на какой стадии сберегательного цикла вы находитесь.

Резюме

Неважно, через 10 или 40 лет вы выйдете на пенсию, откладывая столько, сколько вы можете сейчас, вы повысите свою финансовую безопасность в будущем.

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

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

Подробнее:

Как вкладывая всего 50 долларов в месяц, можно выйти на пенсию
Лучшие инвестиционные счета для молодых инвесторов