Вся база в оперативке

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

Согласен, просто интересны реальные цифры и какое железо брали

Ну так зачем везде использовать rdbms ? Вводите данные в rdbms, а отдавайте в плоской структуре nosql

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

250 гигов было пару лет назад, просто интересен опыт.

Согласен , но для этого нужны немало качественных людских ресурсов

на хабре у них неплохой блог, с описанием технических моментов, поищи в нем.
вариант2Ж спросить «случайно невпопад» про начинку серверов.

Заносили постгрес в оперативку, стало быстрее на 2 порядка (ну все что не блокировалось), начали в сетку упираться.

А поподробней что за железо и тд и тп ?

Не, все настраивали админы. Из всего что знаю - 160gb оперативки. Я как разраб только нагрузкой в развернутую базу тыкал.

Так а в чем проблема указать величину кэша для БД?

Не проблема мы это сделаем , у нас в команде даже эксперт DBA по базам есть , интересно что за железо и у кого как получилось на обьемах от 512 г

Насколько я знаю, больше 384гб серверов нету. Большие базы либо шардированы, либо со временем часть таблиц просто уезжает в новую базу, либо работают с диска (в памяти в первую очередь индексы). В общем, рокет саенса никакого нет.

Хреновый спец, если решение - база в оперативе. Есть же быстрые ssd. В комплекте в redis можно получить максимум скорости с сохранением на диск.

Ssd redis mysql в правильной конфигурации наверняка решат проблему, но для этого надо переписать софт

Да вот уже даже 3 ТБ держит https://www.supermicro.com/products/motherboard/Xeon/C600/X10DRC-LN4_.cfm

Согласен можно и на clickhouse переехать, но затраты будут на порядки дороже чем просто накупить 3терабайт оперативки https://www.supermicro.com/products/motherboard/Xeon/C600/X10DRC-LN4_.cfm

Это все равно временное решение. Вы только отсрачиваете час Икс.

Что у вас там в Бд ? Какие нить блобы ? Или куча текста ?

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

Ну плотность рамок растет быстрее чем размер бд

Вот я и хочу поднять оперативку

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

Те куча мелких данных которые изменяются во времени активно ? А по этим данным потом агрегация ? В одной БД ? Уволить бы вашего архитектора дешевле выйдет

Я имею в виду серваки, которые у вг стоят. Хотя тут напрягся, вспомнил: вроде есть какое-то количество по полтерабайта памяти.

А потом редис рестартовался и привет на час-другой, угу

непонял про вг ? виртуализационная группа ?

агрегация - отчеты понятное дело периодически делаються

На живой бд ? Т е на бд куда данные пишутся в реальном времени ?

нет конечно, с одного из slave .

Нет, компания из ОП

может стоит почитать первичную документацию на оракел, мс сиквель?

попадались какие-то видео по такому поводу, но там каскадно было всё устроенно^W нарисовано от горячих данных к холодным.

а может такое проскакивало у iwalker2000...
ощем слышал я звон, да не понял откуда он.

Много хайлоад проектов отправляют все в оперативку, как простой способ оптимизации.

Как-то работал в одной соц. сеточке(не втентакли, не ок, но не лучше) - так вот там была мода пилить миллион in-memory хранилищ, которые для обеспечения какой-никакой персистентности писали бинлог, который разматывался в случае падения.

Вот все здорово. Работает все достаточно быстро и т.д., но есть но.

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

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

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

Читанно, просто интересны реальные примеры

Примеры есть ?

Если хранение в раме ускоряет работу более чем в 2 раза, значит как-то неправильно потюнили sql.

ну там просто могут сторонние люди не юзать индексы по нормальному и делать full scan !!

https://ya-nenavizhu.ru/wp-content/uploads/2015/07/picard-facepalm.jpg

Не очень смешно