Какая база данных NoSQL лучше всего подходит для финансовых систем OLTP?

Мы разрабатываем финансовую систему OLTP. он должен поддерживать 10 000 транзакций в секунду и иметь функции отчетности.

Итак, мы пришли к идее использования:

  • База данных NoSQL в качестве основного хранилища
  • MySQL DB (фактически Percona-сервер) делает некоторые ETL из базы данных NoSQL для хранения данных отчета

Мы рассматриваем MongoDB и Riak для задания NoSQL. мы читаем, что Riak масштабируется более плавно, чем MongoDB. И мы хотели бы выслушать ваше мнение.

  • Какую базу данных NoSQL вы бы использовали для Финансовая система OLTP?
  • Как было ваш опыт масштабирования MongoDB/Riak?

ОТВЕТЫ

Ответ 1

Нет никаких мыслимых обстоятельств, когда я бы использовал базу данных NOSQl для чего-либо, связанного с финансами. У вас просто нет необходимой целостности данных или внутренних элементов управления. Dow Jones использует SQL Server для выполнения своих транзакций, и если они могут правильно спроектировать высокопроизводительную, высокую транзакционную реляционную базу данных, то можете ли вы. Вам придется инвестировать в некоторых людей, которые знают, что они делают, хотя.

Ответ 2

Базы данных NoSQL, основанные на глобальном хранилище - Cache от InterSystems и GT.M от FIS - широко используются в финансовых услугах и на протяжении многих лет. Кэш, в частности, используется как для базовой базы данных, так и для OLTP.

Ответ 3

Нужно думать о проблеме по-разному. Понятие последовательности транзакций связано с UD (обновление) в CRUD (создание, чтение, обновление, удаление). Базы noSQL представляют собой CRAP (создание, репликация, добавление, процесс), ориентированных на работу, путем аккреции данных с отметкой времени. При правильной модели домена нет причин, по которым невозможность аудита и эквивалент ссылочной целостности не могут быть достигнуты.

Ответ 4

Я могу ответить на мой опыт по масштабированию Riak.

Riak плавно переходит в крайнее. Масштабирование так же просто, как добавление узлов в кластер, что очень простая операция сама по себе. Вы можете добиться почти линейной масштабируемости, просто добавив узлы. Наш опыт работы с Riak в отношении масштабирования был потрясающим.

Откидной стороной является то, что во многих отношениях этого недостает. Некоторые примеры:

  • Вы не можете сделать что-то вроде count(*) или list keys в производственном кластере. Это потребует работы, если вы хотите сделать ETL из Riak в MySQL - или как вы узнаете, что (E) xtract? (Одна возможная работа - поддерживать ведро с известной ключевой последовательностью, которая сопоставляет значения, содержащие ключи, которые вы вставили в свои другие ковши).
  • Бесплатная версия Riak поставляется без консоли управления, которая позволяет вам знать, что происходит, и тот, который включен в версию Enterprise, не является большим улучшением.
  • Вам понадобится версия Enterprise, которую вы хотите реплицировать по WAN (например, для DR/высокой доступности). Это хорошо, если вы не против платить, но имейте в виду, что цены на Башо очень высоки.

Ответ 5

Я работаю с Starcounter (поэтому Im предвзято), но я думаю, что могу с уверенностью сказать, что для обработки финансовых транзакций системы вам нужно беспокоиться о последовательности транзакций. К сожалению, это то, что двигатели, используемые для Facebook и Twitter, должны были отказаться, чтобы их масштабная стратегия обеспечивала производительность. Это связано не с тем, что такие двигатели, как MongoDb или Cassandra, плохо разработаны; скорее, это следует из теоремы CAP (http://en.wikipedia.org/wiki/CAP_theorem). Проще говоря, изменения, внесенные вами в вашу базу данных, будут перезаписаны другими изменениями, если они будут близки по времени. Хорошо для обновлений статуса и новых твитов, но катастрофически, если вы имеете дело с деньгами или другими количествами. Суммы будут просто ошибочными, если многие чтения и записи выполняются параллельно. Таким образом, для необходимой пропускной способности, база данных NoSQL с поддержкой ACID, вероятно, будет способна работать.

Ответ 6

Вы можете использовать некоторые базы данных NoSQL (Cassandra, EventStore) в качестве хранилища для финансового обслуживания, если вы реализуете свое приложение с использованием источников событий и концепций из DDD. Я рекомендую вам прочитать этот мини-альбом http://www.oreilly.com/programming/free/reactive-microservices-architecture.html

Ответ 7

OLTP может быть достигнуто с использованием NoSQL с пользовательской реализацией,

есть две вещи: 1. Как вы собираетесь достичь свойств ACID, которые дает СУРБД. 2. Предоставьте настраиваемый блокирующий или неблокирующий concurrency и механизм обработки транзакций.

Чтобы приблизиться к решению, Apache Phoenix, apache trafodion или машина для сращивания.

Ответ 8

Trafodion имеет полную поддержку ACID над HBase, вы должны взглянуть.

Ответ 9

Cassandra может использоваться как для OLTP, так и для OLAP. Хорошая репликация и согласованная последовательность данных дают вам выбор в ваших руках. Необходимо правильно спроектировать систему. И в конце концов, это бесплатно, но не бесплатно от разработчика, попробуйте