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

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

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

Спасибо

Arfon

ОТВЕТЫ

Ответ 1

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

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

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

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

Ответ 2

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

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

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

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

Ответ 3

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

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