Как создать базу данных / таблицу, которая каждую минуту добавляет много строк - PullRequest
Новая
       11

Как создать базу данных / таблицу, которая каждую минуту добавляет много строк

0 голосов
/ 01 сентября 2018

Я нахожусь в ситуации, когда мне нужно хранить данные для 1900+ криптовалют каждую минуту, я использую MySQL innoDB.

В настоящее время таблица выглядит так 

coins_minute_id | coins_minute_coin_fk | coins_minute_usd | coins_minute_btc | coins_minute_datetime | coins_minute_timestamp

coins_minute_id = autoincrement id
coins_minute_coin_fk  = medium int unsigned
coins_minute_usd  = decimal 20,6
coins_minute_btc = decimal 20,8
coins_minute_datetime = datetime
coins_minute_timestamp = timestamp

Таблица невероятно быстро росла за считанные минуты, каждую минуту в нее добавлялось 1900+ строк.

Данные будут использоваться для исторического отображения цены в виде линейного графика D3.js для каждой криптовалюты.

У меня вопрос: как лучше оптимизировать эту базу данных, я думал только о том, что собираю данные каждые 5 минут вместо 1, но это все равно добавит много данных за короткое время, я также подумал, что если Лучше было создать уникальную таблицу для каждой криптовалюты. Кто-нибудь из вас, кто любит проектировать базы данных, знает какой-нибудь другой очень умный и умный способ делать подобные вещи?

С наилучшими пожеланиями

(из комментария) 

SELECT  coins_minute_coin_fk, coins_minute_usd
    FROM  coins_minutes
    WHERE  coins_minute_datetime >= DATE_ADD(NOW(),INTERVAL -1 DAY)
      AND  coins_minute_coin_fk <= 1000
    ORDER BY  coins_minute_coin_fk ASC

1 Ответ

0 голосов
/ 20 сентября 2018
  • Избавиться от префикса coins_minute_; он загромождает SQL, не предоставляя никакой полезной информации.
  • Не указывайте время дважды - существуют простые функции для преобразования между DATETIME и TIMESTAMP. Почему у вас есть «созданные» и «обновленные» временные метки? Вы делаете UPDATE заявления? Если так, то код сложнее, чем просто «вставка». И вам нужен уникальный ключ, чтобы узнать, какую строку нужно обновить.
  • Обеспечить SHOW CREATE TABLE; это более наглядно, чем то, что вы предоставили.
  • 30 вставок в секунду легко обрабатывается. 300 / сек может иметь проблемы.
  • Не PARTITION таблица без какой-либо реальной причины для этого. Общая действительная причина в том, что вы хотите периодически удалять «старые» данные. Если вы удаляете через 3 месяца, я бы построил таблицу с PARTITION BY RANGE(TO_DAYS(...)) и использовал еженедельные разделы. Больше обсуждения: http://mysql.rjweb.org/doc.php/partitionmaint
  • Покажите нам запросы. Схема не может быть оптимизирована, не зная, как к ней будут обращаться.
  • «Пакетные» вставки выполняются намного быстрее, чем однорядные операторы INSERT. Это может быть в форме INSERT INTO x (a,b) VALUES (1,2), (11,22), ... или LOAD DATA INFILE. Последнее очень хорошо, если у вас уже есть файл CSV.
  • Ваши данные поступают из одного источника? Или 1900 разных источников?
  • MySQL и MariaDB, вероятно, идентичны для вашей задачи. (Опять же, нужно видеть запросы.) PDO хорошо для любого; перекодировка не требуется.
  • После просмотра запросов мы можем обсудить, что PRIMARY KEY иметь, а какое дополнительное INDEX(es).
  • 1 минута против 5 минут? Вы имеете в виду, что в последнем случае вы соберете только одну пятую числа строк? Мы можем обсудить это после того, как будут раскрыты остальные детали.
  • Этот запрос не имеет смысла несколькими способами. Зачем останавливаться на "1000"? Выход довольно большой; какой клиент заботится об этом большом количестве данных? Порядок не ограничен - дата и время не гарантируются. Зачем указывать usd без указания даты и времени? Пожалуйста, предоставьте обоснование запроса; тогда я могу помочь вам с INDEX(es).
...