Как организовать хранение MySQL big data (30млн-50млн) и выборку по date range?
Всем доброго времени суток!
Столкнулся с проблемой хранения больших данных, боюсь накосячить, поэтому нуждаюсь в совете более опытных разработчиков.
Задача такова, необохдимо хранить данные котировок валют со временем и делать выборку по ним по промжутку времени. Встречал реализации таковые, каждое значение котировки хранится в отдельной таблице а условно связываются по INT TIMESTAMP. Но вот сервер вовзращал разную частоту данных в зависимости от заданного промежутка времени, при срезе до недели, это 5 минут, при срезе до месяца - 1 час, как это организовать на сервере, для меня вопрос. Какой оператор для выборки по промежутку самый производительный? Какой тип данны в данном случае лучше использовать для даты INT или DATE?
Я с такими большими данными прежде не работал, как я полагаю одними индексами я не разгребусь, а партиции и вовсе не помогут, тк промежутки могут совершенно разными.
Прошу поделиться опытом/своими решениями/ткнуть носом, т.к. в данный момент я даже не знаю в каком направлении может быть верное решение.
Использую Influx DB оказалась очень удобной под мои задачи, котировки мигрировали на эту СУБД, струтуры ответов API аналогов дают понять что они так же используют подобные решения, спасибо за совет.
30-50 миллионов это не big data. И всё будет летать.
Но вот сервер вовзращал разную частоту данных в зависимости от заданного промежутка времени, при срезе до недели, это 5 минут, при срезе до месяца - 1 час, как это организовать на сервере, для меня вопрос.
Обычная логика, что сложного-то в проверке размера выбранного периода? Если выбрали много то делаем группировку больше.
timestamp должен быть быстрее и удобнее к тому же, особенно в выборках по датам.
Ну и бонусом удобство работы в виде всяких date_sub() date_add() и т.д.
Обычно такие вещи организуются в разных таблицах, типа: stock_5_min, stock_15_min, stock_1_hour. Как правило, в биржевых клиентах временные периоды всегда одни и те же и неизменны.
А на счет временных отрезков - переложите это на приложение, а не на БД.
Простой
Простой
Простой
