Как организовать хранение MySQL big data (30млн-50млн) и выборку по date range?

Всем доброго времени суток!

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

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

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

Прошу поделиться опытом/своими решениями/ткнуть носом, т.к. в данный момент я даже не знаю в каком направлении может быть верное решение.
  • Вопрос задан
  • 941 просмотр
Решения вопроса 1
Пригласить эксперта
Ответы на вопрос 2
Sanasol
@Sanasol
нельзя просто так взять и загуглить ошибку
30-50 миллионов это не big data. И всё будет летать.

Но вот сервер вовзращал разную частоту данных в зависимости от заданного промежутка времени, при срезе до недели, это 5 минут, при срезе до месяца - 1 час, как это организовать на сервере, для меня вопрос.

Обычная логика, что сложного-то в проверке размера выбранного периода? Если выбрали много то делаем группировку больше.

timestamp должен быть быстрее и удобнее к тому же, особенно в выборках по датам.
Ну и бонусом удобство работы в виде всяких date_sub() date_add() и т.д.
Ответ написан
@thyratr0n
Обычно такие вещи организуются в разных таблицах, типа: stock_5_min, stock_15_min, stock_1_hour. Как правило, в биржевых клиентах временные периоды всегда одни и те же и неизменны.

А на счет временных отрезков - переложите это на приложение, а не на БД.
Ответ написан
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы