- Køer til at administrere lageropdateringer for hver kanal.
Dette er ikke nødvendigvis et databaseproblem. Du kan være bedre stillet at se på et meddelelsessystem (f.eks. RabbitMQ)
- Beholdningstabel, som har et korrekt øjebliksbillede af allokering på hver kanal.
- Bevaring af sessions-id'er og andre hurtige adgangsdata i en cache.
sessionsdata skal sandsynligvis placeres i en separat database, der er mere egnet til opgaven (f.eks. memcached, redis, osv.) Der er ingen ensartet DB
- Tilbyder et Facebook-like-dashboard (XMPP) for at holde sælgeren opdateret hurtigst muligt.
Mine begrænsninger er:1. Lageropdateringer kan ikke gå tabt.
Der er 3 måder at besvare dette spørgsmål på:
-
Denne funktion skal leveres af din applikation. Databasen kan garantere, at en dårlig registrering afvises og rulles tilbage, men ikke garantere, at hver forespørgsel bliver indtastet. Appen skal være smart nok til at genkende, når der opstår en fejl, og prøve igen.
-
nogle DB'er gemmer poster i hukommelsen og skyller derefter hukommelsen til disken peridokalt, dette kan føre til datatab i tilfælde af strømsvigt. (f.eks. Mongo fungerer på denne måde som standard, medmindre du aktiverer journalføring. CouchDB tilføjer altid til posterne (selv en sletning er et flag tilføjet til posten, så tab af data er ekstremt vanskeligt))
-
Nogle DB'er er designet til at være ekstremt pålidelige, selvom et jordskælv, orkan eller anden naturkatastrofe rammer, forbliver de holdbare. disse omfatter Cassandra, Hbase, Riak, Hadoop osv.
Hvilken type holdbarhed henviser du til?
- Jobkøer skal udføres i rækkefølge og helst aldrig gå tabt.
De fleste noSQL-løsninger foretrækker at køre parallelt. så du har to muligheder her.1. brug en DB, der låser hele tabellen for hver forespørgsel (langsommere)2. byg din app til at være smartere eller begivenhedsrig (sekventiel kø på klientsiden)
- Nem/hurtig udvikling og fremtidig vedligeholdelse.
generelt vil du opdage, at SQL er hurtigere at udvikle i starten, men ændringer kan være sværere at implementerenoSQL kræver måske lidt mere planlægning, men er lettere at lave ad hoc-forespørgsler eller skemaændringer.
De spørgsmål, du sandsynligvis skal stille dig selv, er mere som:
-
"Bliver jeg nødt til at have intense forespørgsler eller dyb analyse, som en kort/reducer er bedre egnet til?"
-
"skal jeg ændre mit skema ofte?
-
"er mine data meget relationelle? På hvilken måde?"
-
"har leverandøren bag min valgte DB erfaring nok til at hjælpe mig, når jeg har brug for det?"
-
"skal jeg bruge en speciel funktion såsom GeoSpatial indeksering, fuldtekstsøgning osv?"
-
"hvor tæt på realtid har jeg brug for mine data? vil det gøre ondt, hvis jeg ikke kan se de seneste registreringer dukke op i mine forespørgsler før 1 sek senere? hvilket niveau af latenstid er acceptabelt?"
-
"hvad har jeg egentlig brug for i form af fail-over"
-
"hvor store er mine data? vil det passe i hukommelsen? vil det passe på én computer? er hver enkelt post stor eller lille?
-
"hvor ofte vil mine data ændre sig? er dette et arkiv?"
Hvis du skal have flere kunder(kanaler?) hver med deres egne lagerskemaer, kan en dokumentbaseret DB have sine fordele. Jeg kan huske, at jeg en gang kiggede på et e-handelssystem med inventar, og det havde næsten 235 tabeller! Så igen, hvis du har visse relationelle data, kan en SQL-løsning virkelig også have nogle fordele.
Jeg kan helt sikkert se, hvordan jeg kunne bygge en løsning ved hjælp af mongo, sofa, riak eller orientdb med de givne begrænsninger. Men hvad er bedst? Jeg ville prøve at tale direkte til DB-leverandører og måske se nosql-båndene