Стратегия для работы с большими таблицами БД

Question

Я смотрю на создание приложения Rails, которое будет иметь довольно большие таблицы с числом строк более 500 миллионов. Чтобы все было быстро В настоящее время я смотрю на то, как большой стол можно разделить на более управляемые куски. Я вижу, что с MySQL 5.1 есть разделение вариант, и это возможный вариант, но мне не нравится, как столбец который определяет, что разделение должно быть частью первичного ключа на стол.

Что я действительно хотел бы сделать, так это разделить таблицу, в которую пишет модель AR основанный на написанных значениях, но насколько я знаю, нет никакого способа чтобы сделать это - кто-нибудь есть какие-либо предложения относительно того, как я мог бы реализовать эту или любые альтернативные стратегии?

Спасибо

Arfon

Answer 1

Столбцы разделов в MySQL не ограничены первичными ключами. На самом деле столбец раздела не обязательно должен быть ключом (хотя для него будет создан прозрачный ключ). Вы можете разделить по RANGE, HASH, KEY и LIST (что аналогично RANGE только в том, что это набор дискретных значений). Прочтите руководство по MySQL для , обзор типов разбиения.

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

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

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

Answer 2

Вы можете полностью справиться с этим в Active Record, используя DataFabric .

Не так сложно самостоятельно реализовать подобное поведение, если оно не подходит. В Google было много дискуссий об архитектуре обработки таблиц на уровне приложений. Он имеет то преимущество, что избегает промежуточного программного обеспечения или зависит от специфики DB Vender С другой стороны, за ваше приложение отвечает больше кода.

Answer 3

Если вы хотите разделить данные по времени, приведенное ниже решение может соответствовать вашим потребностям. Вы, вероятно, можете использовать MERGE таблицы;

Давайте предположим, что ваша таблица называется MyTable и вам нужна одна таблица в неделю

1. Ваше приложение всегда регистрируется в одной и той же таблице
2. Еженедельное задание атомарно переименовывает вашу таблицу и воссоздает пустую: MyTable переименовывается в MyTable-Year-WeekNumber, и создается новая пустая MyTable
3. Таблицы слияния удаляются и воссоздаются.

Если вы хотите получить все данные за последние три месяца, вы создаете таблицу слияния, которая будет включать в себя только таблицы за последние 3 месяца. Создайте столько таблиц слияния, сколько вам нужно для разных периодов. Если вы можете не включить таблицу, в которую в данный момент вставлены данные (MyTable в нашем примере), вы будете еще более счастливы, поскольку у вас не будет параллелизма чтения / записи