Как хранить 7,3 миллиарда строк рыночных данных (оптимизированных для чтения)?

Question

У меня есть набор данных за 1 минуту с данными о 1000 акциях с 1998 года, всего около 1001 * строк.

В большинстве случаев (99,9%) я буду выполнять только чтения запросов.

Каков наилучший способ сохранить эти данные в БД?

• 1 большая таблица с 7,3B строками?
• 1000 таблиц (по одной на каждый символ акции) с 7,3M строками в каждой?
• какие-либо рекомендации по движку базы данных? (Я планирую использовать Amazon RDS MySQL)

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

Edit:

Это пример строки:

'XX', 20041208, 938, 43.7444, 43.7541, 43.735, 43.7444, 35116.7, 1, 0, 0

Столбец 1 - символ акций, столбец 2 - дата, столбец 3 - минуты, остальные - столбцы цены открытия, максимума и минимума закрытия, объема и трех целочисленных столбцов.

Большинство запросов будут выглядеть как «Дайте мне цены на AAPL в период с 12 апреля 2012 года 12:15 до 13 апреля 2012 года 12:52»

Об аппаратном обеспечении: я планирую использовать Amazon RDS, так что я настроен на это

Answer 1

Если у вас есть оборудование, я рекомендую MySQL Cluster .Вы получаете интерфейс MySQL / RDBMS, с которым вы так хорошо знакомы, и получаете быстрые и параллельные записи.Чтение будет медленнее, чем обычное MySQL из-за задержки в сети, но у вас есть преимущество, заключающееся в возможности распараллеливать запросы и чтения благодаря тому, как работает MySQL Cluster и механизм хранения NDB.

Убедитесь, что у вас достаточноКомпьютеры MySQL Cluster и достаточно памяти / RAM для каждого из них - MySQL Cluster - это архитектура базы данных, в значительной степени ориентированная на память.

или Redis , если вы не возражаете против значения ключа/ NoSQL интерфейс для чтения / записи.Убедитесь, что у Redis достаточно памяти - он очень быстрый для чтения и записи, вы можете выполнять с ним базовые запросы (хотя и не в RDBMS), но он также является базой данных в памяти.

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

Answer 2

Я думаю, что любая основная СУБД справится с этим.На атомарном уровне единственная таблица с правильным разделением кажется разумной (разделение, основанное на использовании ваших данных, если фиксировано - это просто символ или дата).

Вы также можете изучить создание агрегированных таблиц для более быстрогодоступ выше атомного уровня.Например, если ваши данные представлены в дневное время, но вы часто возвращаете данные на уровне недели или даже месяца, это можно предварительно рассчитать в сводной таблице.В некоторых базах данных это можно сделать с помощью кэшированного представления (различные имена для разных решений БД, но в основном это представление атомарных данных, но после запуска представление кэшируется / закрепляется в фиксированной временной таблице), которая запрашивается для последующих запросов сопоставления.. Это может быть сброшено с интервалом, чтобы освободить память / дисковое пространство.)

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

Answer 3

Если вы используете простой способ чтения строк без агрегирования, вы можете использовать кластер Aerospike.Он находится в базе данных памяти с поддержкой файловой системы для сохранения.Он также оптимизирован для SSD.

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