Три решения для хранения 30 миллиардов записей по подбазам данных и подтаблицам
Какую проблему решает подтаблица подбазы данных?
- Подтаблицы: количество записей в одной таблице резко увеличивается, физическое хранилище одной таблицы или запрос к одной таблице сталкиваются с узкими местами;
- Подбаза данных: количество восходящих сервисов увеличивается, а количество подключений к одной базе данных сталкивается с узким местом.В настоящее время необходимо учитывать подбиблиотеку, и пропускная способность будет увеличиваться в геометрической прогрессии после подбиблиотеки;
Сцены
Давайте рассмотрим сценарий онлайн-бронирования отелей.
По статистике, в стране 300 000 отелей с общим количеством номеров 13,47 млн. Если в каждом отеле есть 10 типов торговых номеров (стандартный номер, номер с двуспальной кроватью, номер с двумя односпальными кроватями...), то имеется 3 миллиона торговых номеров. типы.
Нам нужно хранить в общей сложности 2 миллиарда данных о ценах на жилье и объемах номеров для каждого типа номеров в течение следующих 365 дней. Это всего лишь запись доступа дистрибьютора.
Если предположить, что у нас есть доступ к 15 дистрибьюторам, рекорд цен на жилье и объем жилья достигнет 30 миллиардов.
Отсортируйте известные данные: данные об отелях — 300 000, данные о ценах на жилье — 15 миллиардов, данные о жилье — 15 миллиардов; давайте
обсудим, как эти 30 миллиардов записей хранятся в отдельных базах данных и таблицах.
Как хранить 30 миллиардов записей?
Записи об отелях находятся на уровне миллиона, поэтому можно хранить одну таблицу;
записи о ценах на жилье составляют 15 миллиардов, поэтому необходимо учитывать хранение подбаз данных и подтаблиц. Мы используем 16 библиотек и 16 таблиц в каждой библиотеке (256 таблиц). всего) для хранения. В таблице хранится около 58 миллионов записей (аппаратное обеспечение хорошее, а разделение чтения и записи, как правило, без стресса), количество
комнатных записей составляет 15 миллиардов, а хранилище также представляет собой 16 * 16 подбаз данных и подтаблицы, как указано выше,
сводка: база данных разделена на три типа: отели, цены на жилье, база данных количества номеров, база данных отелей 1x1, база данных цен на жилье 16x16, база данных измерений номеров 16x16;
маршрутизация данных?
Учитывая, что информация одного и того же идентификатора отеля должна попасть в один и тот же шард, мы можем использовать хэш по модулю;
здесь мы используем алгоритм BKDRHash, который прост и эффективен (хэш строки Java также использует этот алгоритм);
например, для хранения Информация о ценах отеля: Получите индекс БД через hashHotel (ID отеля)%16 и получите индекс таблицы цен в БД через hashPrice (ID отеля)%16; вы должны найти проблему, то есть использовать тот же
отель Идентификатор для хэширования по модулю, индекс всегда будет одинаковым! ! !
Для решения этой задачи нам необходимо использовать особенность алгоритма BKDRHash.В алгоритм можно добавить коэффициент.Например,фактор площади отеля равен 131, а коэффициент хэш-функции цены — 31.
Таким образом, даже если используется один и тот же идентификатор отеля, будут сгенерированы разные результаты хэширования.
Вы можете обратиться к следующему коду:
'''
Private int patitionCount = 16;
// хеш-функция территории отеля
Private int getBKDRHashByHotel(String key) { intseed = 131; // Значения коэффициентов: 31, 1313, 13131, 131313, … int hash = 0; for (int i = 0; i < key.length(); i++) { hash = (hash *seed) + key.charAt(i); } return hash; } // хэш-функция для ценовой области
частный int getBKDRHashByPrice (строковый ключ) { int семя = 31; // числовые значения: 31, 1313, 13131, 131313, … int hash = 0; for (int i = 0; i <key.length(); i++) { hash = (хэш * семя) + key.charAt(i); } вернуть хеш; } '''
другие схемы маршрутизации
фрагментация генного фактора
Метод подбазы данных генов. Используя идею генов, ген подбазы данных извлекается из одного измерения информации, и вся информация о других измерениях также будет перенесена, так что все измерения информации могут быть заполнены с помощью этого подбазы данных. Ген базы данных.
Что касается метода подбиблиотеки, обратитесь к теории: он имел в виду, что взятие числа по
модулю 2^n эквивалентно удалению всех битов числа, кроме n младших (крайних правых)
. возведя остаток 2 в n-ную степень, тогда остаток — это последние n цифр двоичного числа. Все, что мы можем использовать битовый оператор, чтобы очистить старший бит, чтобы получить остаток.Преимущества
: через идентификатор можно проанализировать область, к которой он принадлежит, чтобы убедиться, что данные попадают в один и тот же сегмент.Недостаток
: идентификатор отеля, цена ID и ID комнаты необходимо заранее указать первичный ключ;
Согласованная фрагментация хеша
Рекомендуется использовать этот алгоритм, который может обеспечить соглашение об именовании исходного идентификатора и в то же время избежать проблемы искажения данных за счет добавления виртуальных узлов; простая модификация
алгоритма BKDRHash может реализовать добавление виртуальных узлов;
вы также можно найти в Интернете готовый алгоритм для его изменения;
О расширении
Разделение базы данных, как правило, представляет собой оптимизацию и реконструкцию после того, как бизнес вырос до определенного масштаба. Чтобы обеспечить быстрый запуск бизнеса, с самого начала сложно разделить базу данных и таблицы. Горизонтальное разделение и очистка данных являются большими проблемами. Для этого мы прошли следующие этапы.
Первый этап
- База данных написана дважды (успех транзакции основан на старой модели), и запрос использует старую модель.
- Ежедневная сверка данных о работе (через DW) и компенсация разницы.
- Импортируйте исторические данные через job.
вторая стадия
- Исторические данные были импортированы, и сверка данных выполнена правильно.
- База данных по-прежнему дважды написана, но успех транзакции зависит от новой модели, а онлайн-запрос режет новую модель.
- Ежедневная сверка данных о работе для компенсации разницы.
Третий этап
- Старая модель больше не пишется синхронно и будет добавлена асинхронно только тогда, когда заказ достигнет конечного состояния.
- На этом этапе только офлайн-данные по-прежнему полагаются на старую модель, и существует множество нисходящих зависимостей.После завершения преобразования хранилища данных старую модель можно полностью отменить.
Подведем итог
Вышеупомянутый план реализации подтаблицы подбазы данных на 30 миллиардов данных. Чтобы обеспечить высокую доступность, необходимо разделить чтение и запись и в то же время сделать хорошую систему мониторинга, включая, помимо прочего: емкость диска сервера, ввод-вывод диска, загрузку ЦП; задержку синхронизации главного-подчиненного, медленную
скорость запрос, частота обновления кэша БД и другие показатели.
В «Руководстве по разработке Java» Alibaba предлагается, чтобы количество строк в одной таблице превышало 5 миллионов строк или емкость одной таблицы превышала 2 ГБ, а также рекомендуется разделить базы данных и таблицы.
Разные аппаратные среды имеют разные пороги для подбаз данных и подтаблиц.Главное — смотреть на кеш БД и дисковый ввод-вывод сервера.
Когда дисковый ввод-вывод сервера хороший, не возникает проблем со 100 миллионами запросов к одной таблице.