Можно ли управлять данными 20 ТБ с помощью MySQL?

Я работаю в проекте, и моя работа состоит в том, чтобы создать систему базы данных для управления около 60 000 000 000 записей.

История проекта заключается в том, что мне приходится хранить в режиме реального времени большое количество сообщений, которые читаются примерно 30 000 считывателей RFID каждую секунду. Предположим, что каждый считыватель RFID генерирует 6000 сообщений в день, я должен вставить 180 000 000 записей в базу данных.

Возможный ввод данных выглядит как "time_stamp, Reader_ID, Tag_ID, other_msg_content"

Будут запросы (SELECT) на основе временного диапазона, Reader_ID и Tag_ID. Запросы не будут очень сложными.

Сейчас я занимаюсь проектированием системы баз данных и планирую использовать MySQL. Мои дампы:

  1. Разумно ли использовать MySQL или мне следует прибегнуть к Oracle (который стоит дорого) или к HBase?

  2. Если я должен использовать MySQL, есть идеи, как я могу построить кластер?

  3. Если я вставлю сообщения в таблицу, скоро таблица будет очень длинной. Я хотел бы использовать методы Sharding, чтобы разбить длинный стол на множество коротких столов.

    3.a. Я хочу знать правильную длину для таблицы Myno InnoDB, т. Е. После того, сколько записей данных было вставлено, я начну к шардингу?

    3.b. Есть ли какое-нибудь хорошее решение для шифрования прокси? Я знаю спок прокси и некоторые другие, нужны рекомендации.

  4. Должен ли я использовать MySQL Cluster? ИЛИ Я просто использую главные серверы mysql и sharding slave и использую Replication для достижения высокой доступности?

  5. Предположим, мне нужно обработать 20 ТБ данных в MySQL (на 1 год), я планирую использовать 20 узлов (сервер ПК, дешево) и хранить 1 ТБ данных на узел, возможно ли это? Любые комментарии приветствуются.

Большое спасибо.

1 ответ

Мысли:

  • Если вы задаете этот вопрос на публичном форуме, наймите экспертов, которые сделают это за вас.
  • Рассмотрим Postgres и SQL Server, которые тоже будут масштабироваться до этого объема.
  • Вам нужна КИСЛОТА? Нет = рассмотреть NoSQL
  • Дизайн и оборудование важнее, чем платформа
  • Не виртуализировать и не вырезать другие аппаратные углы
  • Какое у вас RPO/RTO?
  • Окно обслуживания? ака ты действительно 24/7/365? akk 30k строк в секунду все время
  • Архивирование?
  • Вам нужно старше (скажем, 6 месяцев) онлайн?
  • Бюджет?
  • Требуется реалистичное тестирование для проверки архитектуры и дизайна для заявленной нагрузки
  • 20 ТБ, вероятно, слишком мало
  • 6 КБ на RFID в день, но 30 КБ в секунду? Это 86,4 тыс. Секунд в день, поэтому только 1 из 14 RFID записывает в секунду: как насчет возможных пиковых нагрузок в 420 тыс. + Строк в секунду?

в заключение

  • Это не вопрос базы данных, а вопрос архитектуры
  • Вы задаете неправильные вопросы, слишком рано для этого требования
Другие вопросы по тегам