MySQL - рейтинг с миллионами записей

Question

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

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

Структура лидеров каждой строки следующий:
• рейтинге позиция
• название команды
• значение команды
• Всего игр команда выиграла
• общее количество игр команды побежденный
• всего игр, в которые вничью команда
• Сумма забитых голов
• сумма целей команда уступила
• 4 последних результатов игры команды

Ниже таблица моей базы данных

проблем табличных

CREATE TABLE `challenges` (
    id` int(10) unsigned NOT NULL AUTO_INCREMENT, 
    'challenge_date` datetime NOT NULL, 
    `status` varchar(20) COLLATE utf8_unicode_ci NOT NULL, 
    `created_at` timestamp NULL DEFAULT NULL, 
    `updated_at` timestamp NULL DEFAULT NULL, 
    PRIMARY KEY (`id`), 
    KEY `challanges_id_index` (`id`), 
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci; 

вызовов Результатов

CREATE TABLE `challenges_results` (
    `id` int(11) unsigned NOT NULL AUTO_INCREMENT, 
    `challenge_id` int(11) NOT NULL, 
    `team_id` int(11) NOT NULL, 
    `goals` int(11) NOT NULL, 
    `result` char(1) DEFAULT NULL, 
    `challenge_date` datetime NOT NULL, 
    PRIMARY KEY (`id`) 
) ENGINE=InnoDB DEFAULT CHARSET=utf8; 

На вызовы результатов в результате столбец может быть W для победы, D для ничьи и L для поражений

команда значения

CREATE TABLE `team_values` (
    `id` int(11) unsigned NOT NULL AUTO_INCREMENT, 
    `team_id` int(11) DEFAULT NULL, 
    `value` double(15,8) DEFAULT '1500.00000000', 
    `created_at` datetime DEFAULT NULL, 
    PRIMARY KEY (`id`) 
) ENGINE=InnoDB DEFAULT CHARSET=utf8; 

команда

CREATE TABLE `teams` (
    `id` int(10) unsigned NOT NULL AUTO_INCREMENT, 
    `name` varchar(255) COLLATE utf8_unicode_ci NOT NULL, 
    `avatar` varchar(255) COLLATE utf8_unicode_ci NOT NULL, 
    `founded` date NOT NULL, 
    `residense_city_id` int(10) unsigned NOT NULL, 
    `slug` varchar(255) COLLATE utf8_unicode_ci NOT NULL, 
    `primary_color` char(10) COLLATE utf8_unicode_ci NOT NULL, 
    `secondary_color` char(10) COLLATE utf8_unicode_ci NOT NULL, 
    `status` varchar(20) COLLATE utf8_unicode_ci NOT NULL, 
    `created_at` timestamp NULL DEFAULT NULL, 
    `updated_at` timestamp NULL DEFAULT NULL, 
    PRIMARY KEY (`id`), 
    UNIQUE KEY `teams_slug_unique` (`slug`), 
    KEY `teams_id_index` (`id`) 
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci; 

Одна команда может иметь много значений (teams_values), но будет отображаться только последнее. У одной команды может быть много проблем. У одной команды может быть много результатов от разных задач.

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

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

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

Первый вариант, который я использую, например, как internal join, union и т. Д. Для сбора информации из таблиц и применения правил в одном и том же запросе SQL. Поэтому каждый раз, когда я хочу просмотреть таблицу лидеров, я буду выполнять этот SQL. Проблема с этим решением заключается в том, что я не знаю, насколько эффективным будет то, что мы хотим, чтобы таблица лидеров всегда была в курсе последних результатов. Потому что изображение с 10 тыс. Посетителей в день и каждый, выполняющий этот запрос.

Второй вариант заключается в сборе информации, и в случае дублирования значений я буду использовать PHP для получения дубликатов команд, применения правил, а затем на основе результатов правил проведите пальцами команды в массиве. С сайта производительности я не знаю, насколько эффективен этот вариант.

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

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

Какой из них является лучшим решением и почему и в случае лучшего решения я открыт для предложений. Спасибо

Answer 1

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

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

Вы можете использовать PHP для создания веб-страницы, которая просматривается в браузере, каждый раз, когда обновляется таблица лидеров. Таким образом, вы выполняете вычисления только один раз каждый раз, когда таблица лидеров должна обновляться.

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

Для чего стоит, если сервер настроен правильно, вы не должны беспокоиться о том, чтобы получать 10 тыс. Пользовательских запросов в день, если ваш код действительно ужасно не написан.

EDIT: В качестве запоздалой мысли вы можете установить программу, такую ​​как https://memcached.org/, которая кэширует ваши данные SQL в ОЗУ. Сайты, такие как LiveJournal и Wordpress, используют его, но вам нужно настроить его таким образом, который будет работать для остальных пользователей vps, если поле не является действительно высокой спецификацией.