Назад | Перейти на главную страницу

Mysql: Работа со 192 триллионами записей… (Да, 192 триллиона)

Вот вопрос ...

Учитывая 192 триллиона записей, что я должен учитывать?

Моя главная забота - скорость.

Вот таблица ...

    CREATE TABLE `ref` (
  `id` INTEGER(13) AUTO_INCREMENT DEFAULT NOT NULL,
  `rel_id` INTEGER(13) NOT NULL,
  `p1` INTEGER(13) NOT NULL,
  `p2` INTEGER(13) DEFAULT NULL,
  `p3` INTEGER(13) DEFAULT NULL,
  `s` INTEGER(13) NOT NULL,
  `p4` INTEGER(13) DEFAULT NULL,
  `p5` INTEGER(13) DEFAULT NULL,
  `p6` INTEGER(13) DEFAULT NULL,
  PRIMARY KEY (`id`),
  KEY (`s`),
  KEY (`rel_id`),
  KEY (`p3`),
  KEY (`p4`)
    );

Вот вопросы ...

SELECT id, s FROM ref WHERE red_id="$rel_id" AND p3="$p3" AND p4="$p4"

SELECT rel_id, p1, p2, p3, p4, p5, p6 FROM ref WHERE id="$id"

INSERT INTO rel (rel_id, p1, p2, p3, s, p4, p5, p6)
VALUES ("$rel_id", "$p1", "$p2", "$p3", "$s", "$p4", "$p5", "$p6")

Вот несколько заметок ...

ОБНОВЛЕНИЕ (11.08.2010)

Интересно, что мне дали второй вариант ...

Вместо 192 триллионов я мог бы хранить 2,6 * 10 ^ 16 (15 нулей, что означает 26 квадриллионов) ...

Но во втором варианте мне нужно было бы сохранить только один bigint (18) в качестве индекса в таблице. Вот и все - всего одна колонка. Поэтому я бы просто проверял наличие значения. Иногда добавляю записи, но не удаляю их.

Это заставляет меня думать, что должно быть лучшее решение, чем mysql, для простого хранения чисел ...

Учитывая этот второй вариант, следует ли мне брать его или придерживаться первого ...

[редактировать] Только что получил новости о проведенном тестировании - 100 миллионов строк с этой настройкой возвращают запрос за 0,0004 секунды. [/редактировать]

Оценка pQd в 7 ПБ кажется разумным, а это большой объем данных для СУБД. Я не уверен, что когда-либо слышал о том, чтобы кто-то делал 7 ПБ с любой совместно используемой дисковой системой, не говоря уже о MySQL. Запрос этого объема данных с любой совместно используемой дисковой системой будет необычно медленным. Самое быстрое оборудование SAN обеспечивает максимальную скорость 20 ГБ / сек даже при настройке на большие потоковые запросы. Если вы можете позволить себе оборудование SAN этой спецификации, вы можете позволить себе использовать что-то более подходящее для этой работы, чем MySQL.

Фактически, я изо всех сил пытаюсь представить сценарий, при котором у вас может быть бюджет на дисковую подсистему этой спецификации, но не на лучшую платформу СУБД. Даже при использовании дисков емкостью 600 ГБ (самый большой из имеющихся на рынке «корпоративных» дисков объемом 15 КБ) у вас будет примерно 12 000 физических дисков для хранения 7 ПБ. Диски SATA будут дешевле (а с дисками 2 ТБ вам понадобится около 1/3 их количества), но немного медленнее.

SAN этой спецификации от крупного поставщика, такого как EMC или Hitachi, обойдется в многие миллионы долларов. В прошлый раз, когда я работал с оборудованием SAN от крупного поставщика, стоимость передачи места на IBM DS8000 составляла более 10 тыс. Фунтов стерлингов за ТБ, не включая капитальные затраты на контроллеры.

Для такого большого количества данных вам действительно нужна система без общего доступа, такая как Teradata или Netezza. Разделение базы данных MySQL может работать, но я бы рекомендовал специально созданную платформу VLDB. Система без общего доступа также позволяет вам использовать гораздо более дешевый диск с прямым подключением к узлам - посмотрите на платформу Sun X4550 (thumper) для одной возможности.

Вам также необходимо подумать о ваших требованиях к производительности.

  • Какое приемлемое время выполнения запроса?
  • Как часто вы будете запрашивать свой набор данных?
  • Можно ли разрешить большинство запросов с помощью индекса (т.е. собираются ли они просматривать небольшую часть - скажем, менее 1% - данных) или им нужно выполнить полное сканирование таблицы?
  • Как быстро данные будут загружены в базу данных?
  • Требуются ли для ваших запросов актуальные данные или вы могли бы жить с периодически обновляемой таблицей отчетов?

Короче говоря, самым сильным аргументом против MySQL является то, что вы будете делать обратное сальто, чтобы получить приличную производительность запроса более 7 ПБ данных, если это вообще возможно. Этот объем данных действительно помещает вас на территорию без совместного использования, чтобы создать что-то, что будет запрашивать его достаточно быстро, и вам, вероятно, понадобится платформа, которая с самого начала была разработана для работы без совместного использования. Сами по себе диски могут превзойти стоимость любой разумной платформы СУБД.

Примечание: Если вы разделяете операционную базу данных и базу данных отчетности, вам необязательно использовать одну и ту же платформу СУБД для обеих. Получение быстрых вставок и отчетов за доли секунды из одной и той же таблицы 7 ПБ будет как минимум технической проблемой.

Судя по вашим комментариям, вы можете жить с некоторой задержкой в ​​отчетности, вы можете подумать о раздельных системах сбора и отчетности, и вам, возможно, не потребуется хранить все 7 ПБ данных в вашей операционной системе сбора данных. Рассмотрим операционную платформу, такую ​​как Oracle (MySQL может делать это с InnoDB) для сбора данных (опять же, стоимость одних дисков значительно превзойдет стоимость СУБД, если у вас нет много пользователей) и платформу VLDB, например Терадата, Sybase IQ, Красного кирпича, Netezza (примечание: проприетарное оборудование) или Greenplum для отчетности

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

простые вычисления в конверте - предполагая 32-битные целые числа для всех столбцов, кроме 64-битного идентификатора; без индексов:

8 * 4Б + 8Б = 40Б на строку [и это очень оптимистично]

192 триллиона строк по 40 байт каждая дают нам почти 7 Пбайт

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

вопросы для ответа:

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

случайные ссылки - скорость вставок:

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

Изменить: на самом деле, если это просто наличие или отсутствие «записи» в местоположении X в диапазоне целых чисел, вы можете удалить хранилище данных и просто использовать растровое изображение ... Итак, 10 или около того машин с 100 ТБ дискового пространства (так что у вас есть 10 копий вашего растрового изображения для производительности и резервного копирования), и если вы сделали 128 ГБ ОЗУ на сервер, вы могли бы разместить в памяти индекс группы блоков верхнего уровня с высоким разрешением, чтобы выполнить первую проверку перед тем, как попасть на диск для бита X, равного 26 квадриллионам .

Я бы выбрал вариант №2. Если взять:

375 машин по 64 ТБ (32 диска по 2 ТБ) каждая (реально 400 машин на наличие сбоев), а затем просто отображают записи на ZVOL размером 2 ТБ каждая. Затем на одном или нескольких индексных серверах сохраните в массиве Judy, массиве критических битов или просто растровом изображении отображение того, добавили ли вы запись в это 1 из 26 квадриллионов местоположений. Индекс будет от 50 до 100 ТБ, и вы даже можете иметь индекс второго уровня, указывающий, есть ли какие-либо записи, записанные в определенный блок адресов размером 64 КБ, которые уместились бы менее чем в 64 ГБ ОЗУ и обеспечили бы быстрый уровень начальной проверки. был ли некий «квартал» пуст или нет.

Затем, чтобы прочитать эту запись, вы сначала должны проверить, есть ли запись, которую нужно найти, просмотрев индекс. Если есть, перейдите к машине # (X) / ZOL # (Y) на этой машине / расположению записи # (Z) в этом большом двоичном объекте 2 ТБ на основе простого расчета индекса. Поиск отдельных записей будет чрезвычайно быстрым, и вы можете протестировать загрузку некоторых частей хранилища данных в разные базы данных (в то время как хранилище данных используется для реальной работы) и провести тестирование производительности, чтобы увидеть, способны ли они поддерживать всю вашу базу данных - или нет, просто используйте хранилище данных таким образом.

ZOL - это вещь ZFS, которую можно рассматривать как разреженный файл в других файловых системах, поэтому применимы аналогичные вещи. Или вы можете просто проиндексировать до определенного числа байтов на диске, но это становится сложно, если диски имеют разные размеры, если вы не ограничиваете количество байтов, используемых на диск, на уровне, который работает для всех дисков, то есть 1,75 ТБ на диск 2 ТБ . Или создайте метаустройства фиксированного размера и т. Д.

Помимо сумасшедшей настройки параметров вашей БД (используйте mysqltuner, чтобы помочь), чтобы попытаться сохранить ваши SELECT в кэше настолько, насколько это возможно, вы можете исследовать одну вещь, которую вы можете исследовать, - это START TRANSACTION / CoMMIT (при условии InnoDB) при вставке нескольких сотен записей, чтобы избежать накладные расходы на построчную блокировку и во много раз сокращают время вставки. Я бы также создал таблицу как MyISAM, так и InnoDB и запустил бы на ней тесты, чтобы увидеть, что действительно быстрее, когда вы усилите кеширование - не всегда MyISAM будет быстрее читать - проверьте это:

http://www.mysqlperformanceblog.com/2007/01/08/innodb-vs-myisam-vs-falcon-benchmarks-part-1/

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

Кроме того, если вы используете MyISAM и / или InnoDB file-per-table, вы можете исследовать создание другой точки монтирования файловой системы для / var / lib / mysql, которая была настроена на меньший размер блока и настроила параметры типа fs - т.е. ext3 / ext4 / resiserfs, вы можете использовать data = writeback для журнала и отключить обновление времени доступа в файловой системе для скорости ввода-вывода.

Для второго варианта, сколько цифр будет фактически размещено?

Если будет только один из тысячи или 10K, 100K и т. Д., То сохранение диапазонов используемых (или неиспользуемых) номеров может сэкономить триллионы записей. например: хранение ('бесплатно', 0,100000), ('принято', 100000,100003), ('бесплатно', 100004,584234) - разделение строк на две или три строки по мере необходимости и индексация по первому числу, поиск x <= {игла}, чтобы увидеть, занят ли диапазон, содержащий искомое число, или свободен.

Возможно, вам даже не понадобятся оба статуса. Просто сохраните наименее вероятный статус.