SQL vs NoSQL pro systém řízení zásob

1. Fronty pro správu aktualizací inventáře pro každý kanál.

Nejedná se nutně o problém databáze. Možná by bylo lepší podívat se na systém zasílání zpráv (např. RabbitMQ)

1. Tabulka inventáře, která obsahuje správný snímek alokace na každém kanálu.
2. Uchovávání ID relací a dalších dat s rychlým přístupem v mezipaměti.

data relace by pravděpodobně měla být umístěna do samostatné databáze, která je pro daný úkol vhodnější (např. memcached, redis atd.) Neexistuje žádná univerzální databáze

1. Poskytování řídicího panelu podobného facebooku (XMPP), aby byl prodejce co nejdříve informován.

Moje omezení jsou:1. Aktualizace inventáře nelze ztratit.

Na tuto otázku lze odpovědět 3 způsoby:

1. Tuto funkci musí poskytovat vaše aplikace. Databáze může zaručit, že špatný záznam bude odmítnut a vrácen zpět, ale nezaručuje, že bude zadán každý dotaz. Aplikace bude muset být dostatečně chytrá, aby rozpoznala, kdy dojde k chybě, a zkusila to znovu.

2. některé DB ukládají záznamy do paměti a poté paměť periodicky vyprázdní na disk, což by mohlo vést ke ztrátě dat v případě výpadku napájení. (např. Mongo funguje tímto způsobem ve výchozím nastavení, pokud nepovolíte žurnálování. CouchDB se k záznamům vždy připojí (i smazání je příznak připojený k záznamu, takže ztráta dat je extrémně obtížná))

3. Některé DB jsou navrženy tak, aby byly extrémně spolehlivé, i když udeří zemětřesení, hurikán nebo jiná přírodní katastrofa, zůstávají odolné. mezi ně patří Cassandra, Hbase, Riak, Hadoop atd

Jaký typ trvanlivosti máte na mysli?

1. Fronty úloh by měly být prováděny v daném pořadí a pokud možno nikdy neztrácet.

Většina řešení noSQL preferuje paralelní běh. takže zde máte dvě možnosti.1. použijte databázi, která uzamkne celou tabulku pro každý dotaz (pomalejší)2. sestavte svou aplikaci tak, aby byla chytřejší nebo uspořádanější (sekvenční řazení na straně klienta)

1. Snadný/rychlý vývoj a budoucí údržba.

obecně zjistíte, že vývoj SQL je zpočátku rychlejší, ale implementace změn může být obtížnějšínoSQL může vyžadovat trochu více plánování, ale je snazší provádět ad hoc dotazy nebo změny schématu.

Otázky, které si pravděpodobně budete muset položit, jsou spíše:

1. "Budu potřebovat intenzivní dotazy nebo hloubkovou analýzu, pro kterou je Map/Reduce vhodnější?"

2. "Budu muset často měnit schéma?"

3. "jsou moje data vysoce relační? jakým způsobem?"

4. "má dodavatel za mnou vybranou DB dostatek zkušeností, aby mi pomohl, když to potřebuji?"

5. "Budu potřebovat speciální funkce, jako je indexování GeoSpatial, fulltextové vyhledávání atd.?"

6. "Jak blízko reálnému času budu potřebovat svá data? Bude to bolet, když se v dotazech neuvidím nejnovější záznamy až o 1 sekundu později? Jaká úroveň latence je přijatelná?"

7. "co skutečně potřebuji z hlediska převzetí služeb při selhání"

8. "jak velká jsou moje data? vejdou se do paměti? vejdou se na jeden počítač? je každý jednotlivý záznam velký nebo malý?"

9. "jak často se budou moje data měnit? je to archiv?"

Pokud budete mít více zákazníků (kanálů?), z nichž každý má svá vlastní schémata zásob, může mít databáze založená na dokumentech své výhody. Vzpomínám si, jak jsem se jednou díval na systém elektronického obchodování s inventářem a ten měl téměř 235 tabulek! Pak znovu, pokud máte určitá relační data, řešení SQL může mít opravdu také určité výhody.

Určitě vidím, jak bych mohl vytvořit řešení pomocí mongo, gauč, riak nebo orientdb s danými omezeními. Ale jaká je ta nejlepší? Zkusil bych mluvit přímo s prodejci DB a možná se podívat na kazety nosql