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

Question

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

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

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

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

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

Answer 1

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

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

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

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

Но с учетом всего сказанного, хорошо, вы говорите о 300 Кбайт / с и 2500 TPS (если предположить, что это действительно последовательность несвязанных семплов). * * * * * * * * * * * * * * * * * * * * * * По крайней мере, этот набор тестов указывает на то, что он не вне пределов возможности.

Answer 2

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

Answer 3

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

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

Answer 4

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