Случаи использования распределенных баз данных

Question

В настоящее время у меня есть база данных mysql, а сбор данных iam составляет 5 Terrabyte в год. Я сохраню свои данные все время, я не думаю, что хочу удалить что-то очень рано. Я спрашиваю себя, следует ли мне использовать распределенную базу данных, потому что мои данные будут расти с каждым годом. И через 5 лет у меня будет 25 Terrabyte без индекса. (только что подсчитал необработанные данные, которые я сохраняю каждый день)

У меня есть 5 таблиц, и большинство запросов объединяет несколько таблиц. И мне нужно получить доступ в основном к 1-2 столбцам по многим строкам с определенной меткой времени.

Будет ли распределенная база данных предпочтительной базой данных, чем только одна база данных mysql?

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

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

EDIT:

• в среднем у меня будет 1500 клиентов записи данных в секунду, они влияют на все таблицы.

• Мне просто нужен старый набор данных для аналитики. Как машинное обучение и соответствие шаблону.

• также клиент должен иметь возможность увидеть исторические данные

Answer 1

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

«Высокоиндексированный 5ТБ» будет замедлять сканирование. Индекс - это BTree. Чтобы добавить новую строку в индекс, нужно найти блок в том дереве, где находится элемент, а затем прочитать-изменить-записать этот блок. Но...

• Если индекс AUTO_INCREMENT или TIMESTAMP (или подобные вещи), то блоки модифицируются являются «всегда» на «конец» в BTree. Таким образом, практически все чтения и записи можно кэшировать. То есть, обновление такого индекса очень невелико.

• Если индекс «случайный», такой как UUID, GUID, md5 и т. Д., То блок для обновления - редко найден в кеше. То есть, обновление этого одного индекса для этой одной строки может стоить пара IOP. Даже с твердотельными накопителями вы, скорее всего, не справитесь. (Предполагая, что у вас нет нескольких ТБ ОЗУ.)

• Если индекс находится где-то между последовательным и случайным (скажем, каким-то «именем»), тогда могут быть тысячи «горячих точек» в BTree, и они могут быть кэшируемыми.

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

Следующий номер ... Запросы. Если вам нужно сканировать 5TB на SELECT, то будет потребуется время. Если это тип приложения хранилища данных, и вам нужно, скажем, суммировать данные за прошлый месяц, то создание и поддержание сводных таблиц будет очень важным. Более того, это может устранить необходимость в некоторых индексах таблицы «Факт», что, возможно, устраняет мою обеспокоенность по поводу индексов.

«См. Исторические данные» - см. Отдельные строки? Или просто просмотреть сводную информацию? (Опять же, если это похоже на DW, редко приходится видеть старые точки данных.) Если суммирования будет достаточно, тогда большинство из 25TB можно избежать.

У вас есть машина с 25TB онлайн? Если нет, это может заставить вас иметь несколько машин. Но тогда у вас будет сложность выполнения запросов по ним.

5TB оценивается по INT = 4 байта и т. Д.? Если вы используете InnoDB, вам нужно несколько на 2 до 3, чтобы получить фактический след. Кроме того, если вам нужно изменить таблицу в будущем, такое действие, вероятно, должно скопировать таблицу, чтобы удвоить требуемое дисковое пространство. Ваш 25TB становится больше, чем 100TB памяти.

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

"Sharding" (разделение по машинам) возможно, что вы подразумеваете под "распределенным". С несколькими таблицами вам нужно много думать о том, как разделить данные, чтобы JOINs продолжал работать.

5TB огромен. Делайте все возможное, чтобы сжать его. Используйте меньшие типы данных, нормализуйте и т. Д. Но не «чрезмерно нормализуйтесь», вы можете оказаться в ужасном состоянии. (Мы должны видеть запросы!)

Есть много направлений, чтобы взять мульти-TB db. Нам действительно нужна дополнительная информация о ваших таблицах и запросах, прежде чем мы сможем более конкретно.

Answer 2

Это действительно невозможно обеспечить конкретный ответ на такой широкий вопрос.

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

«Может ли MySQL обрабатывать 5 - 25 ТБ данных?» Да. Нет. Зависит. Если, как вы говорите, у вас нет индексов, ваши запросы могут замедляться дольше, чем вы доберетесь до 5 ТБ. Если это 5TB/год сильно индексируемых данных, это может быть хорошо.

Наиболее распространенным решением этого вопроса является сохранение «транзакционной» базы данных для всей «обычной» работы и хранилища данных для отчетности, с использованием регулярного задания Extract/Transform/Load для перемещения данных по и архивирования Это. У хранилища данных обычно есть схема, оптимизированная для запросов, обычно совершенно не похожая на исходную схему.

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

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