Не живіть в ілюзіях, розробка це не мішки вигрузити

Якщо проводити аналогію із мішками, то це як вантажити мішки, але про те що мішках вже дізнаєшся лише взявши його на руки.
У першому мішку цукор, у другому чавунні чушки, у третьому сирі курячі яйця, у червертому їжачки... і так далі.
І вантажники також мають свою спеціалізацію — один вміє працювати з цукром, інший з зерном ячменю, ще один з зерном пшениці, а ще один із любим вмістом зеленого кольору :)

Пане Славік. Питання ж було зовсім не про два тижні...
Ви маєте ідею.
Бюджет.
Уявлення про кінцеву якість.
А також орієнтовний час на реалізацію.

Чи є у вас який план дій, якщо щось піде не так?
Якщо у вас обмежений бюджет (наприклад 1000 на усе) то чи готові ви до збільшення часу розробки (ну щоб програміст працював не по 8 годин вдень, а по дві години ввечері) або до відповідного обмеження фунціонали продукту?
Коли ж вам це потрібно зробити якнайшвидше за 2-4 тижні — чи готові ви збільшити бюджет у 3-4 рази щоб винайняти більш классного спеціаліста. І так далі.

Проектний трикутник = кошти + час + якість.
Який показник для вас, як постановника задачі, найбільш пріорітений ?
Ви виставляєте термін — 2 тижні (за правило приймається звичайний КЗпП 5-ти денний 8-годинний робочий тиждень, тобто 2*5*8 = 80 годин).

Якщо виявиться, що ваша задача не реалізується за пару тижнів (тобто у данному випадку це помилка РМ визначення термінів виконання) то чим ви готові пожертвувати ? Зменшити якість? Збільшити час? Збільшити кошти (наприклад підняти ставку з 10 до 20)?

Влад, зачем вы вот это вот здесь делаете?

Пане Александр.
Я б із задоволенням би відповів на це ваше питання, але довго думав, і до мене так і не дійшов таємний зміст, що вкладений у ці слова :’(

Прошу мене вибачить, але а заглянув до вашого профілю, і побачив там Oracle, MS SQL та ше купу різних страшних термінів. Порівняно із вами, якщо можна так сказати, гуру в кубі — то я зелений джархед... Але ви погоджуєтесь зі мною у тому, що DBMS потрібні, та кількість памяті для роботи з БД може бути у декілька разів менша за обєм даних.

Щодо ваших інших питань, як ви чудово знаєте (пробачте, що нагадую такі банальні речі) розрахунковий обєм ОЗУ це фунція від частоти та обєму звернень. І не можна так однозначно сказати чи це 30% чи інший процент. Для деяких баз потрібен подвійний обєм ОЗУ, і тоді стає правий автор статті.
Трохи вище вашого посту я навів інший пристрій для зберігання даних. Для P3520 виробник заявляє 375000 IOPS на читання та 26000 IOPS на запис. Як ви вважаєете, чи достатньо буде 375 тисяч IOPS для нормальной проізводітєльності?

Але ж звичайний HDD і є окремим прикладом

non-volatile memory

Можу навіть спростити для вас умови — і замість SAS взяти Intel DC P3520 2TB який зараз коштує по 35 тисяч гривень за штуку. Навіть якщо взяти 2 штуки, то кінцева ціна буде у 4,5 рази менша порвіняно з ОЗУ.
А у явімо, що ваша система працюватиме не з 2TB даних, а з 120TB... тут навіть Постгре не врятує :)
Тому використання сучасних СУБД = питання суто економічне.

В то время, когда Amazon запускает сервера с 2 ТБ RAM

Простий економічний розрахунок (на рівні математики 2-го класу).
Для того щоб зберегти 2 терабайти даних нам потрібно:
2048/32 = 64 планки памяті по 32 GB
Заходимо на хотлайн і бачимо, що сама дешевенька планка на 32 вартує близько 5 тисяч гривень, тобто нам потрібно 320 тисяч гривень для зберігання 2TB певних даних.
Далі переходимо у розділ HDD і підбираємо дешевенький диск за такими параметрами:
Назначение (для внутренних) для серверов Внутренний интерфейс SAS Размер буфера, МБ
128 и более
І бачимо, що самий дешевий коштує також близько 5 тисяч гривень (Hitachi Ultrastar 7K6000).
Нам потрібно буде таких 2 штуки для дзеркала (5 * 2 = 10 тисяч гривень).
Тобто для зберігання тих самих 2TB певних даних нам потрібно витратити у 320/10 = 32 рази менше коштів.

Який критерій «здоровості» їдла?

PS: Зразу згадується: Цей смажений кабанчик на столі ще зранку був здоровий :)