SQL срещу NoSQL за система за управление на инвентара

1. Опашки за управление на актуализации на инвентара за всеки канал.

Това не е непременно проблем с базата данни. Може би е по-добре да погледнете система за съобщения (напр. RabbitMQ)

1. Таблица с инвентара, която има правилна моментна снимка на разпределението на всеки канал.
2. Запазване на идентификатори на сесии и други данни за бърз достъп в кеш.

данните за сесията вероятно трябва да бъдат поставени в отделна база данни, по-подходяща за задачата (например memcached, redis и т.н.) Няма универсална база данни за всички

1. Предоставяне на табло за управление като Facebook (XMPP), за да поддържа продавача актуализиран възможно най-скоро.

Моите ограничения са:1. Актуализациите на инвентара не могат да бъдат загубени.

Има 3 начина да отговорите на този въпрос:

1. Тази функция трябва да бъде предоставена от вашето приложение. Базата данни може да гарантира, че лош запис ще бъде отхвърлен и върнат обратно, но не гарантира, че ще бъде въведена всяка заявка. Приложението ще трябва да бъде достатъчно интелигентно, за да разпознае кога възникне грешка и да опита отново.

2. някои DB съхраняват записи в паметта и след това изхвърлят паметта на диска периодично, това може да доведе до загуба на данни в случай на прекъсване на захранването. (напр. Mongo работи по този начин по подразбиране, освен ако не активирате дневник. CouchDB винаги се добавя към записите (дори изтриването е флаг, добавен към записа, така че загубата на данни е изключително трудна))

3. Някои DB са проектирани да бъдат изключително надеждни, дори ако удари земетресение, ураган или друго природно бедствие, те остават издръжливи. те включват Cassandra, Hbase, Riak, Hadoop и др.

За какъв тип издръжливост имате предвид?

1. Опашките за задания трябва да се изпълняват в ред и за предпочитане никога да не се губят.

Повечето noSQL решения предпочитат да работят паралелно. така че тук имате две възможности.1. използвайте DB, която заключва цялата таблица за всяка заявка (по-бавна)2. изградете приложението си, за да бъде по-интелигентно или организирано (последователно опашка от страна на клиента)

1. Лесна/Бърза разработка и бъдеща поддръжка.

Като цяло ще откриете, че SQL се развива по-бързо в началото, но промените могат да бъдат по-трудни за прилагане.noSQL може да изисква малко повече планиране, но е по-лесно да се правят ad hoc заявки или промени в схемата.

Въпросите, които вероятно трябва да си зададете, са по-скоро:

1. „Ще трябва ли да имам интензивни запитвания или задълбочен анализ, за ​​който Map/Reduce е по-подходящ?

2. „ще трябва ли да променям схемата си често?

3. "силно релационни ли са моите данни? по какъв начин?"

4. "продавачът зад избраната от мен БД има ли достатъчно опит, за да ми помогне, когато имам нужда?"

5. „ще имам ли нужда от специална функция като GeoSpatial индексиране, пълно текстово търсене и т.н.?“

6. "колко близо до реалното време ще имам нужда от данните си? Ще ме боли ли, ако не видя последните записи да се показват в заявките ми до 1 секунда по-късно? какво ниво на латентност е приемливо?"

7. "какво наистина ми трябва по отношение на отказ"

8. "колко големи са моите данни? Ще се поберат ли в паметта? Ще се поберат ли на един компютър? Всеки отделен запис голям ли е или малък?

9. "колко често ще се променят данните ми? това архив ли е?"

Ако ще имате множество клиенти (канали?), всеки със свои собствени схеми на инвентаризация, базираната на документи DB може да има своите предимства. Спомням си, че веднъж разгледах система за електронна търговия с инвентар и тя имаше почти 235 таблици! От друга страна, ако имате определени релационни данни, SQL решението наистина може да има и някои предимства.

Със сигурност мога да видя как мога да създам решение, използвайки mongo, couch, riak или orientdb с дадените ограничения. Но що се отнася до кое е най-доброто? Бих се опитал да говоря директно с доставчиците на DB и може би да гледам касетите на nosql