Почему вы не должны использовать nosql для финансовых транзакций
Я слышал от спикера о мероприятии, организованном банком в Хакатоне, что вы не должны использовать nosql для финансовых транзакций из-за соображений безопасности. Но я понятия не имею о том, что он говорит. Я искал ответ, почему я не должен использовать базу данных nosql в моем приложении.
В чем плюсы и минусы nosql, а в чем плюсы и минусы базы данных sql для финансовых транзакций?
Сейчас я создаю приложение для кассира магазина, где кассир использует это приложение для хранения транзакций, получения заказа и оплаты наличными или кредитной картой.
Каков наилучший возможный подход для API этого проекта? SQL или NoSQL и почему
4 ответа
Как объясняется @A2H, SQL и NoSQL зависят от ваших требований, говоря, что NoSQL небезопасен, не является точным, это все равно, что сказать, что SQL не масштабируем... что тоже не так.
Теперь для финансового приложения у вас будут некоторые нефункциональные требования, которые я могу перечислить ниже:
- Безопасность на уровне файлов: если у кого-то есть доступ к файлу базы данных, сможет ли он использовать его для загрузки информации в другое место? например, в SQL Server информация о входе в базу данных включена в файлы, поэтому копирование файлов без пароля затруднит хакерам кражу информации.
- Масштабируемость: о чем мы говорим? несколько миллионов записей? Масштабируемость. В каком смысле требуется выполнять распределенные запросы или просто локализованные базы данных в зависимости от региона и центральных таблиц для информации об учетных записях? или вы планируете создать приложение, которое будет получать тонны записей в секунду (например, информацию о форексе), и, следовательно, вам нужно что-то, чтобы получать тонны записей и анализировать результаты? в этом случае, возможно, NoSQL для вас.
- Жалоба на транзакцию (ACID): обрабатываете ли вы транзакции (например, тип дебетования этого кредита?), Тогда вам может понадобиться что-то вроде Djondb или традиционной RDBMS, обе из которых поддерживают транзакции.
- Гибкие схемы: вам нужна гибкая схема, которая может адаптироваться к вашим частым изменениям без необходимости перепроектирования базы данных и обновления предыдущих записей? NoSQL хорош в этом.
список будет продолжен... но я думаю, вы поняли...
Утверждение, что NoSQL небезопасен, является преувеличением, как и любое другое обобщение.
Базы данных SQL и NoSQL не являются взаимозаменяемыми. Там нет технологии базы данных серебряной пули. При выборе технологии баз данных, которую вы хотите использовать для своего проекта, вы должны учитывать плюсы и минусы.
Краткий ответ: если вам нужно обрабатывать транзакции, ваши данные могут быть упорядочены в реляционные сущности, тогда используйте SQL. Если вам нужно обрабатывать большие объемы полуструктурированных или неструктурированных данных и вам нужна горизонтальная масштабируемость, используйте NoSQL.
Если вы хотите узнать больше о различиях между SQL и NoSQL, нажмите здесь или здесь.
Некоторое понимание того, когда использовать SQL или NoSQL, можно найти здесь.
В сценарии совершения платежей, перевода денег между счетами, операций на фондовом рынке нам нужна строгая ACID. Даже такие простые вещи, как, я хочу прочитать баланс своего счета (100 долларов) и снять 90 долларов, но прежде чем я смогу снять, моя жена снимает 80 долларов. Таким образом, банк получает отрицательный баланс на моем счете, что, вероятно, нарушает какое-то правило, запрещающее отрицательный баланс.
Так что нам с этим делать? Реляционные базы данных предоставляют отличные инструменты ACID и блокировки базы данных. В MongoDB тоже можно взломать, но взлом - это все равно взлом.MongoDB предлагает ACID и т. Д., Но в системе, основанной на распределенных шардах, без строгой согласованности, я бы держался от нее подальше.
Наконец, в эпоху архитектуры микросервисов в серверных приложениях у нас есть база данных для каждой службы (я имею в виду не выделенный физический, а логически db на службу). Так что иметь две базы данных просто; MongoDB и реляционный. Используйте реляционные данные для транзакций, которые составляют лишь 10% случаев использования. Используйте MongoDB для остальных вариантов использования, таких как просмотр данных, изображений, чтение обзоров, контента, истории учетных записей и т.д.
Может быть, я думаю, что одна из причин заключается в том, что "nosql не поддерживает ACID"
Это то же самое, что нет транзакции.
Может быть, это может объяснить, почему не использовать nosql для "финансового перехода".