Может ли MySQL Cluster обрабатывать базу данных терабайта

Question

Мне нужно изучить решения для предоставления базы данных MySQL, которые могут обрабатывать объемы данных в диапазоне терабайт и быть высокодоступными (пять девяток). Каждой строке базы данных, вероятно, будет отметка времени и до 30 значений с плавающей запятой. Ожидаемая рабочая нагрузка составляет до 2500 вставок в секунду. Запросы, вероятно, будут менее частыми, но могут быть большими (возможно, с использованием 100 Гб данных), хотя, вероятно, только с участием отдельных таблиц.

Я изучал MySQL Cluster, учитывая, что это их предложение HA. Из-за объема данных мне нужно будет использовать дисковое хранилище. Реально я думаю, что только временные метки могут храниться в памяти, и все остальные данные должны храниться на диске.

Есть ли у кого-нибудь опыт использования MySQL Cluster в базе данных этого масштаба? Это даже жизнеспособно? Как дисковое хранилище влияет на производительность?

Я также открыт для других предложений о том, как достичь желаемой доступности для этого объема данных. Например, было бы лучше использовать стороннюю библиотеку, например Sequoia, для обработки кластеризации стандартных экземпляров MySQL? Или более прямое решение на основе репликации MySQL?

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

Answer 1

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

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

Answer 2

Хорошо, я сделал прочитал часть о том, что mySQL является жестким требованием.

Итак, позвольте мне вначале указать, что рабочая нагрузка, о которой вы говорите, - 2500 вставок/сек, редкие запросы, запросы, которые могут иметь наборы результатов до 10 процентов от всего набора данных - является почти pessimal для любой реляционной базы данных.

(Это скорее напоминает мне проект, давно, когда у меня было жесткое требование загрузить 100 мегабайт программных данных по линии RS-422 по бокам 9600 бод (также жесткое требование) менее чем за 300 секунд (также жесткое требование.) Тот факт, что 1KByte/сек × 300 секунд = 300kbytes, похоже, не общаться.)

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

Но все сказанное, хорошо, вы говорите о 300Kbytes/sec и 2500 TPS (предполагая, что это действительно последовательность несвязанных образцов). Это set of benchmarks, по крайней мере, предполагает, что это не выход из сферы возможностей.

Answer 3

This article действительно полезен при определении того, что может замедлить большую базу данных MySQL.

Answer 4

Возможно, попробуйте спящие спячки и запустите MySQL на 10 узлах с 1 терабайтом каждый, чтобы вы могли обрабатывать 5 терабайт, тогда;) хорошо над вашим пределом, я думаю?