Выбор базы данных для биржевых данных [закрыто]

Мне интересно, является ли NoSQL вариантом для этого сценария:

Входными данными являются почасовые биржевые данные (sku, сумма, цена и некоторые более конкретные) из нескольких источников. Старые версии будут просто отброшены. Так что мы не получим больше 1 миллиона. наборы данных в ближайшем будущем, и не будет никаких запросов бизнес-аналитики, как в хранилищах данных. Но будут агрегации , по крайней мере для минимальной цены группы статей, которая должна обновляться, если статья с минимальной ценой группы распродается. В дополнение к этим массовым записям на регулярной основе будут иметь место единичные сокращения объема статьи, которые могут произойти в любое время.

База данных будет частью сервиса, который должен давать быстрые ответы на запросы через REST. Поэтому должно быть какое-то кэширование. Нет необходимости в стойкой последовательности, но долговечность.

Далее список желаний:

  • должен хорошо масштабироваться для растущего запроса нагрузка
  • недорогие технологии с точки зрения денег и сложности (нет кластера Oracle)
  • нет проприетарных языков (нет PL/SQL)

MongoDB с егоагрегационной структурой кажется многообещающим. Вы можете думать о alteratives? (Я не придерживаюсь NoSQL!)

2 4
database mongodb nosql rdbms

2 ответа:

Я бы начал с Redis, и вот почему:

  • "должно быть какое-то кэширование" => и это то, в чем Redis лучше всего разбирается. Если по какой-либо причине вы решите, что вам нужно "больше", вы можете добавить" больше", но все равно сохраните все, что вы уже разработали в Redis, в качестве кэша для этого"больше"

  • Один редис-это быстро. Два редиса быстрее. Три редиса-это единица быстрее, чем два, и т. д..

  • Кривая обучения довольно плоская, и весело = > так как набор теория действительно забавна

  • Инкременты / Декременты / мин / макс-это родной язык редиса

  • Интеграция Redis с XYZ (вы упомянули о необходимости REST API) есть во всем google и github

  • Редис честен

MongoDB будет работать сначала , так же как и любой другой крупный NoSQL, но почему!?

Я бы пошел с редисом, и если вы решите позже, вы нужно "больше", я бы сначала посмотрел на " Redis + SQL db (Postgre / MySQL / etc..) ", это даст вам оба из двух миров = > "кэширование / скорость" и "мощность агрегации" в случае, если вам агрегации нужно будет идти выше и выше Min/Max/Incr/Decr.

Тот, кто говорит вам PostgreSQL "недостаточно быстр для написания ", не знает этого.

Тот, кто говорит вам, что MySQL " недостаточно масштабируема", не знает этого (например, Facebook работает на MySQL).

Поскольку я уже нахожусь на ролл :) = > тот, кто говорит вам, что у MongoDB есть "наборы реплик и шардинг", не желает вам добра, так как наборы реплик и шардинг только выглядят сексуально из документов и шумихи. После того, как вам нужно будет пересортировать / переупорядочить наборы реплик, вы узнаете цену неправильного выбора ключа осколка и движений магического куска...

Снова = > Redis FTW!

2

Ну, мне кажется, что MongoDB - это лучший выбор.

Он имеет не только функции агрегации, но и возможности map/reduce запросов для целей расчета статистики. Он может быть масштабирован через replica sets и sharding, имеет атомарные обновления для инкрементов (декременты-это просто отрицательные инкременты).

Альтернативы:

  • CouchDB - недостаточно быстро читает
  • Redis - это ключ / значение db. вам нужно будет запрограммировать статьи логики на приложение уровень
  • MySQL - недостаточно масштабируемо
  • PostgreSQL - может быть хорошей альтернативой, если масштабируется с помощью pgbouncer, но недостаточно быстр при написании
0