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

Question

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

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

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

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

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

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

Обновление 3 Некоторые люди комментируют, что 8Gb это игрушка в эти дни. Я согласен, но увеличение размера БД - это чистая ЛЕННОСТЬ, если есть более разумное и эффективное решение

Answer 1

Вот почему у нас есть хранилища данных. Разделите две вещи на (а) отдельные базы данных или (б) отдельную схему в одной базе данных.

1. Данные, которые являются текущими, для немедленного доступа, обновляются.

2. Данные, являющиеся историческим фактом, для анализа не обновляются.

150 ГБ не очень велик, и одна база данных может обрабатывать ваши небольшие данные в реальном времени и большую часть истории.

Используйте «периодический» процесс ETL, чтобы вывести вещи из активной базы данных, денормализовать в звездообразную схему и загрузить в хранилище исторических данных.

Answer 2

Это вызывает memcached! Я бы рекомендовал использовать cache-money, отличную библиотеку ActiveRecord для сквозного кэширования. В ветви ngmoco есть поддержка включения кеширования для каждой модели, поэтому вы можете кэшировать только те вещи, которые, как вы знали, вы хотите сохранить в памяти.

Вы также можете выполнить кэширование вручную, используя вызовы $ cache.set / get / expire в действиях контроллера или хуках модели.

Answer 3

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

Answer 4

В MySQL правильное использование Query Cache сохранит часто запрашиваемые данные в памяти. Вы можете дать подсказку MySQL не кэшировать определенные запросы (например, из внутренних процессов) с помощью ключевого слова SQL_NO_CACHE.

Если внутренние процессы обращаются к историческим данным или к данным для целей отчетности, обязательно следуйте предложению С. Лотта создать отдельное хранилище данных и запросить его вместо этого. Если хранилище данных слишком много для достижения в краткосрочной перспективе, вы можете реплицировать свою транзакционную базу данных на другой сервер и выполнять там запросы (хранилище данных дает вам НАМНОГО больше гибкости и возможностей, поэтому, если возможно, пройдите этот путь)

UPDATE:

• См. Документацию SELECT и прокрутите вниз до SQL_NO_CACHE.
• Читать о Кэше запросов
• Убедитесь, что query_cache_type установлен в соответствии с вашими потребностями.

ОБНОВЛЕНИЕ 2:

Я подтвердил поддержку MySQL, что нет механизма выборочного кэширования определенных таблиц и т. Д. В пуле буферов innodb.

Answer 5

Итак, в чем проблема?

Во-первых, 150 ГБ сегодня не очень велико. Это было 10 лет назад.

Во-вторых, любая система баз данных, не относящаяся к полному дерьму, будет использовать вашу память в качестве кэша. Если кэш достаточно большой (по сравнению с объемом используемых данных), он будет эффективен. Если нет, единственное, что вы МОЖЕТЕ сделать, это получить больше памяти (потому что, извините, 8 ГБ памяти ОЧЕНЬ мало для современного сервера - это было мало 2 года назад).

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