База данных NoSQL для электронной коммерции

Я буду строить сайт электронной коммерции и хотел бы использовать базу данных no-sql, которая будет хорошо соответствовать планам приложения. Но когда дело доходит до того, какая база данных будет соответствовать заданию, я не уверен. После сравнения различных БД, те, которые кажутся лучшими, могут быть mongo, couch или даже orientdb. Я видел аргументы для всех из них, которые будут использоваться или не использоваться по сравнению с чем-то вроде MySQL. Но между собой (базы данных nosql), которые хорошо подходят для электронной коммерции решение?

Примечание, для случая использования у меня не будет тысяч транзакций в секунду. Или аналогично высокие скорости записи. они будут умеренными, но на уровне, который может обрабатывать любая установленная база данных.

CouchDB: имеет master для master репликации, которую я действительно мог бы использовать. Если нет, мне все равно придется реализовать ту же функциональность в коде. Мне нужно иметь базу данных пользователей, синхронизировать с материнским кораблем. (пользователи будут иметь свои собственные, потенциально база данных localhost, которая может синхронизироваться с основным сервером доменов). Couch также быстро, как только ваши запросы будут сохранены в БД.Поскольку у меня, вероятно, будет более высокая потребность в производительности чтения. Хотя и не очень.

MongoDB: запросы очень просты и удобны для пользователя. Кроме того, с тем фактом, что конечным пользователям может потребоваться запросить определенные вещи в данный момент времени, которые я не могу учесть заранее, это кажется более подходящим. Мне не нужно предварительно хранить мои запросы в БД. Поддерживает атомарные транзакции, хотя только при записи в один документ за раз.

OrientDB: база данных графиков. сильно отличается от того, к чему привыкло большинство людей, но с потребностями он тоже может очень хорошо подойти. Ориент имеет преимущества быть schemaless, так же, как иметь поддержку для кислотных сделок. Существует много отношений с клиентами и продуктами, с которыми база данных graph может быть отличной. Orient также поддерживает master to master репликацию, аналогичную в CouchDB.

Не поймите меня неправильно, я вижу, как построить это традиционно с чем-то вроде MySQL, но простота и простота решения nosql очень привлекательны. Хотя, в моем случае, нуждаясь в решении без схем, было бы намного проще в nosql, а не mysql. данный продукт может иметь больше или меньше элементов, чем другое. и избежать воссоздания таблицы при добавлении нового поля предпочтительнее.

Итак, между этими 3 (или даже другими, которые вы думаете, могут быть лучше), какие функции в каждом из них могут потенциально работать для или против меня в отношении сайта электронной коммерции при работе с транзакциями клиентов?

Edit: причина, по которой я не использую существующее решение, заключается в том, что с интегрированными функциями, которые мне нужны, нет доступных решений. Мы также направляем использовать это как полный продукт для нашей компании. Будет несколько других интеграций, кроме продаж. Он также будет работать с POS магазина система.

11
couchdb e-commerce mongodb nosql orientdb

3 ответов

с электронная коммерция может охватывать все, от торговых тележек до членства и повторяющихся подписок, трудно точно угадать, какие требования и сложность вы представляете.

при создании сайта электронной коммерции одним из первых соображений должно быть изучение того, существует ли уже установленный продукт электронной коммерции или инструментарий, который мог бы удовлетворить ваши требования. Есть много тонкостей в таких процессах, как упорядочивание, выставление счетов, платежи, продукты и отношения с клиентами, даже если ваш вариант использования кажется простым. Также может быть возможно разделить ваше приложение на аспекты " управление каталогом "(возможно, более пользовательские) и" выставление счетов " (потенциально третья сторона, возможно, даже через размещенный API выставления счетов/платежей).

другим соображением должно быть то, для кого вы разрабатываете сайт электронной коммерции: это поцарапать свой собственный зуд или для клиента? Время, бюджет и возможности для выборочной сборки может быть трудно оценить и графику .. и нишевый выбор технологии может затруднить поиск / наем дополнительного опыта в области развития.

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

тем не менее, написание системы электронной коммерции, по-видимому, является обрядом перехода для многие разработчики.)-;

для MongoDB в частности, вы можете посмотреть:

репликация Master-Master (MVCC) вы упомянули, что это не похоже на соответствующую функцию для электронной коммерции, где вам обычно нужна сильная согласованность, а не возможная согласованность. Вы упоминаете синхронизацию пользовательских баз данных, поэтому, возможно, это конкретное требование может быть лучше рассмотрено с помощью единого решения для входа, такого как OpenID.

13

Проверьте сравнение различных доступных баз данных NoSql здесь. Удовлетворить ваши требования по.

2

в MongoDB 4 Теперь мульти-документ ACID-транзакций! Это делает его подходящим для электронной коммерции!

Проверьте:https://www.mongodb.com/transactions

0