Назад | Перейти на главную страницу

Очень большая база данных, очень маленькая часть извлекается в основном в реальном времени

У меня интересная проблема с базой данных. У меня есть БД размером 150 ГБ. У меня буфер памяти 8 ГБ.

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

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

Как я могу убедиться, что последний всегда хранится в памяти? (для них места более чем достаточно)

Больше информации: Мы на Рубине по рельсам. База данных - это MYSQL, наши таблицы хранятся с использованием INNODB. Мы разделяем данные на 2 раздела. Поскольку мы разделяем его, мы храним большую часть наших данных с помощью BLOB-объектов JSON, индексируя только первичные ключи.

Здесь много вариантов. Первый, NDB - это механизм кластеризации MySQL, который хранит данные в памяти. NDB имеет некоторые ограничения, тем не мение.

memcached - это популярное решение, которое часто используется, но для его поддержки требуется архитектура приложения.

У вас могут быть таблицы MyISAM, которые вы специально храните на RAM-диске, так как их можно перемещать индивидуально, в отличие от InnoDB. Все табличное пространство InnoDB должно быть сохранено на RAM-диске.

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

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

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

Лучшее, что вы, вероятно, можете сделать, - это изучить планы выполнения ваших длительных запросов и соответствующим образом настроить 1) запрос и 2) базу данных. Вы можете создать индексы для «идентифицируемых частей определенных таблиц», чтобы ускорить запросы. Вы также можете переместить свои наиболее часто используемые данные в отдельную таблицу, а менее часто используемые данные в свою собственную.

Сделать это с помощью больших двоичных объектов JSON будет сложно, потому что, если вам нужен доступ к одному атрибуту большого двоичного объекта JSON, вам придется получить и проанализировать весь большой двоичный объект. Если ваши BLOB-объекты JSON имеют согласованный формат, создайте реальную структуру таблицы, чтобы отразить это, и вы, вероятно, 1) уже улучшили производительность и 2) получите гораздо более гибкую структуру, когда вам потребуется настроить производительность позже.