Структура MySQL для БД размером более 10 мм

Question

Я работаю с приложением, которое имеет 3 таблицы, каждая с записями более 10 мм и размером более 2 ГБ.

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

Каков наилучший способ разделения БД на более мелкие единицы и на разные серверы, чтобы нагрузка для каждого сервера была управляемой?

Примечания:
1. Количество операций вставки превышает 10 в секунду, и, следовательно, сценарий агрегирования выполняется одинаковое количество раз.
2. Сценарий агрегации ресурсоемкий
3. Сценарий агрегирования должен быть запущен для всех данных, чтобы определить, какой из них относится к последней вставке
4. Я не нашел способа как-то разделить БД на более мелкие единицы
5. Я очень мало знаю о распределенных БД, поэтому, пожалуйста, используйте основную терминологию и предоставьте ссылки для дальнейшего чтения, если это возможно

Answer 1

Есть два ответа на это с точки зрения базы данных.

1. Найдите способ разбить базу данных на более мелкие единицы. Это очень зависит от использования вашей базы данных. Это действительно ваш лучший выбор, потому что это единственный способ заставить базу данных взглянуть на меньшее количество материала одновременно. Это называется шардингом:
   http://en.wikipedia.org/wiki/Shard_(database_architecture)

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

С точки зрения программирования у вас уже есть почти вся ваша информация (кроме идентификаторов). Вы можете попытаться найти способ использовать эту информацию для всех ваших нужд, а не запрашивать базу данных после вставки. Вы можете иметь некоторый процесс, который только создает идентификаторы, которые вы запрашиваете в первую очередь. Представьте, что у вас есть таблицы A, B, C. У вас будут другие таблицы, в которых есть только первичные ключи A_ids, B_ids, C_ids. Шаг первый, получите новые идентификаторы из таблиц идентификаторов. Шаг второй, вставьте в A, B, C и делайте все, что вы хотите сделать одновременно.

Кроме того, следует проверить общую эффективность / производительность всех запросов. Убедитесь, что у вас есть индексы на все, что вы запрашиваете. Выполните explain для всех выполняемых запросов, чтобы убедиться, что они используют индексы.

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