Работать (фильтровать, искать и т. Д.) Непосредственно над хешем из API или сначала хранить в БД?

Question

Я начинаю работать с большими данными, возвращенными из API. API возвращает тысячи строк в одном запросе, например:

"2000-01-06": {
        "1. open": "112.1900",
        "2. high": "113.8700",
        "3. low": "108.3700",
        "4. close": "110.0000",
        "5. volume": "27488300"
    },
    "2000-01-05": {
        "1. open": "111.1200",
        "2. high": "116.3700",
        "3. low": "109.3700",
        "4. close": "113.8100",
        "5. volume": "32029800"
    },
    "2000-01-04": {
        "1. open": "113.5600",
        "2. high": "117.1200",
        "3. low": "112.2500",
        "4. close": "112.6200",
        "5. volume": "27059500"
    },
    "2000-01-03": {
        "1. open": "117.3700",
        "2. high": "118.6200",
        "3. low": "112.0000",
        "4. close": "116.5600",
        "5. volume": "26614200"
    }

На следующем шаге я хочу работать с данными, фильтровать, искать, строить средние и т. Д. Было бы разумно сначала сохранить данные в моей БД и работать с ними или использовать непосредственно хэш из API? Я использую RoR и Postgres.

Моя идея - хранить данные в реляционной БД со столбцами для даты, открытия, максимума и т. Д.

Answer 1

Это зависит от того, что именно вы делаете с данными.

1. Если данные часто меняются между запросами и вам нужно всего лишь один раз запустить алгоритмы, просто сделайте это в памяти: Он уже находится в памяти в эффективном формате (JSON), когда вы берете его из API. Разобрать его в ActiveRecord и сохранить на диск будет намного медленнее.

2. Если вы хотите запустить аналитику асинхронно или по каким-то причинам вам необходимо нормализовать данные, вам нужно будет объективировать данные. Это будет медленнее, но часто легче рассуждать (и использовать Ruby или SQL, естественно, вместо того, чтобы сбивать с толку управление хешем)

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