Какая база данных NoSQL лучше всего подходит для финансовых систем OLTP? - PullRequest
14 голосов
/ 02 июня 2011

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

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

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

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

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

Ответы [ 9 ]

17 голосов
/ 03 июня 2011

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

7 голосов
/ 16 сентября 2013

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

6 голосов
/ 06 июня 2011

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

4 голосов
/ 02 июня 2011

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

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

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

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

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

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

Чтобы приблизить вас к решению, Apache Phoenix, Apache Trafodion или Splice machine.

1 голос
/ 19 июня 2016

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

1 голос
/ 22 июня 2011

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

0 голосов
/ 21 октября 2017

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

0 голосов
/ 20 сентября 2014

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

...