Document based databases
How should we use document based databases?
+2
–
–
MarkLogic, MongoDB, couchbase are document databases.
They're often very fast.
But unfortunately compared to relational databases they often do not support efficient joins.
Nėra sub-kategorijų.
+[klausimas]
projektas Document database backed by keyvalue storage
Implement a documentDB backed by keyvalue storage with efficient querying
+[idėją]
+[projektas]
Kaip sukurti dokumentų duomenų bazę, kuri palaiko prisijungimus?
Dažnas dokumentų duomenų bazių trūkumas yra tas, kad jos dažnai nepalaiko veiksmingų sujungimų. Jie vaizduoja dokumentų įrašus kaip nepermatomą dėmę.
Sukūriau pridedamą projektą, kad pakalbėčiau apie tai, kaip planuoju įdiegti dokumentais pagrįstą saugyklą, naudojant raktinių reikšmių saugyklą kaip užpakalinę programą. Kiekvienas dokumento raktas yra atskiras raktas ir jie išdėstyti taip, kad diapazono nuskaitymas būtų efektyvus, kad maišos sujungimai galėtų vykti efektyviai.
How to build a document based database that supports Joins?
A common weakness of document databases is that they often do not support efficient joins. They represent document records as an opaque blob.
I created the attached project to talk of how I plan to implement document based storage using keyvalue storage as the backend. Each key of the document is a separate key and they are arranged so that range scans are efficient so that hash joins can take place efficiently.
Raktinis žodis yra „efektyvus“. Efektyvumas yra atvirkščiai proporcingas skaičiavimo sudėtingumui, todėl manau, kad jūs ieškote naujų sujungimų su nestruktūriniais duomenimis algoritmų.
Pirma, problema jau išspręsta SQL duomenų bazėse, tiesa? Kodėl gi nepažvelgus į įgyvendinimą ir nepaisant jo iš ten?
Tarkime, kad turime neapdorotus duomenis kaip JSON įrašus (arba žodynus, maišus). Tuomet jums rūpi efektyvi užklausa, kuri yra indeksavimo (užklausos optimizavimo arba užklausos algoritmų) objektas. Mes reguliariai indeksuojame SQL duomenų bazes į ElasticSearch, nes SQL duomenų bazės nėra geros arba nėra pakankamai lanksčios ieškant teksto kitais naudotojams svarbiais būdais: naudojame kitus duomenis. sistema, kuri puikiai išmano, ir laikykite ten duomenų kopiją. Vietos nelabai taupo, bet veikia. Tą patį galėtume padaryti ir su NoSQL – jei reikia į prisijungimą panašių užklausų – tiesiog „indeksuokite“ duomenis į SQL duomenų bazes, naudodami specializuotus procesus, kurie interpretuoja ir perkelia SQL duomenų bazę sklandžiai, dirbdami kaip papildomą darbą kartu su NoSQL, nuolat ieško naujų laukų ir kuria tuos laukus papildomoje SQL duomenų bazėje. Žinoma, naudoti daug duomenų bazių vienu metu nėra elegantiškas sprendimas, todėl sutinku, kad reikia tobulinti dokumentais pagrįstas duomenų bazes. Juk schemos neegzistuoja, kiekvienas įrašas implikuoja kažkokią schemą, o kai pakankamai daug įrašų dalijasi tam tikrais laukais, tai gali pateisinti naujo SQL lauko ar išorinio rakto sukūrimą. Pagalvokite apie tai kaip apie smegenis, kurios suvokia naujus „fizikos dėsnius“, kai matome pakankamai daug konkretaus tipo pavyzdžių...
The keyword is "efficient". Efficiency is inversely proportional to computational complexity, and so, I assume, you look for new algorithms for joins with unstructured data.
First, the problem is already solved in SQL databases, right? Why not to take a look at the implementation, and take it from there?
Let's say we have raw data as records of JSON (or dictionaries, hashmaps). What you're concerned about then is efficient querying, which is a subject of indexing (query-optimizing, or query algorithms). We routinely index SQL databases into ElasticSearch, because SQL databases are not good or not flexible enough in text search in other ways that users care about: we use another data system, that is good at it, and keep a copy of data in there. Not very space-saving, but works. We could do the same with NoSQL -- if you need join-like queries -- just "index" data into SQL databases, by specialized processes, that interprets and migrates SQL database on the fly, working as a complementary job in concert with the NoSQL, always looking for new fields, and creating those fields in the complementary SQL database. Sure, using many databases at once is not an elegant solution, so I agree, that we need improvement of document based databases. After all, schemas are not non-existent, every record implies a schema some sort, and when sufficiently many records share certain fields, it may justify creation of new SQL field or foreign key. Think of it like a brain that realizes new "laws of physics" when one sees sufficiently many examples of a specific type...
Sukūriau JSON raktų erdvę, kurią galima greitai iššifruoti atgal į JSON ir greitai nuskaityti naudojant RocksDB raktinių reikšmių duomenų bazės diapazono nuskaitymą.
Tai leidžia mums atlikti įprastą maišos sujungimą, kaip tai daro reliacinė duomenų bazė.
Tai JSON { "vardas": "Samuelis Skvairas",
"darbas": {
"currentJob": {"company": {"darbuotojų skaičius": 2500}}
}
}
{"_id": "1",
"vardas": "Samuelis Skvairas",
"hobis": [
{"vardas": "Dievas"}, {"vardas": "duomenų bazės"}, {"pavadinimas":"kelių kompiuterių sistemos"}
] } Yra paverstas bent šiais raktinių reikšmių objektais
0.0 = "Samuelis Skvairas"
0.1.0.0.0 = "2500"
0.0 = "Samuelis Skvairas"
0.1.0.0 = "Dievas" 0.1.1.0 = "duomenų bazės" 0.1.2.0 = "kelių kompiuterių sistemos"
Iš esmės su raktais suformuokite plokščią dokumento struktūrą.
"tipykite žmones": "objektas",
"type people.*": "sąrašas",
"type people.*.0": "styga",
"type people.*.1": "sąrašas",
"type people..1..0": "eilutė",
"type people..1.": "objektas",
"type people.*.2": "objektas",
"type people.*.2.0": "objektas",
"type people.*.2.0.0": "objektas",
"type people.*.2.0.0.0": "skaičius",
"field people.*": "LIST",
"field people..1.": "LIST",
"field people.*.0": "vardas",
"lauko žmonės.*.1": "hobis",
"field people..1..0": "vardas",
"field people.*.2": "darbas",
"field people.*.2.0": "currentJob",
"field people.*.2.0.0": "company",
"field people.*.2.0.0.0": "employeeCount",
"lauko žmonės": "žmonės",
"field people.*": "LIST",
"field people.*.3": "žodžiai",
"field people..3.": "LIST",
"lauko žmonės..3..*":"SĄRAŠAS",
"field people..3...": "LIST",
"type people.*.3": "sąrašas",
"type people..3.": "sąrašas",
"type people..3..*": "sąrašas",
"type people..3...": "sąrašas",
"type people..3....*": "skaičius"
I've designed a keyspace for JSON that is fast to decode back into JSON and is fast to scan in a RocksDB keyvalue database range scan.
This lets us do a regular hash join as a relational database does.
This JSONs { "name": "Samuel Squire",
"job": {
"currentJob": {"company": {"employeeCount": 2500}}
}
}
{"_id": "1",
"name": "Samuel Squire",
"hobbies": [
{"name": "God"}, {"name": "databases"}, {"name":"multicomputer systems"}
] } Is turned into at least the following keyvalue objects
0.0 = "Samuel Squire"
0.1.0.0.0 = "2500"
0.0 = "Samuel Squire"
0.1.0.0 = "God" 0.1.1.0 = "databases" 0.1.2.0 = "multicomputer systems"
Essentially form a flat structure of the document with keys.
"type people": "object",
"type people.*": "list",
"type people.*.0": "string",
"type people.*.1": "list",
"type people..1..0": "string",
"type people..1.": "object",
"type people.*.2": "object",
"type people.*.2.0": "object",
"type people.*.2.0.0": "object",
"type people.*.2.0.0.0": "number",
"field people.*": "LIST",
"field people..1.": "LIST",
"field people.*.0": "name",
"field people.*.1": "hobbies",
"field people..1..0": "name",
"field people.*.2": "job",
"field people.*.2.0": "currentJob",
"field people.*.2.0.0": "company",
"field people.*.2.0.0.0": "employeeCount",
"field people": "people",
"field people.*": "LIST",
"field people.*.3": "words",
"field people..3.": "LIST",
"field people..3..*":"LIST",
"field people..3...": "LIST",
"type people.*.3": "list",
"type people..3.": "list",
"type people..3..*": "list",
"type people..3...": "list",
"type people..3....*": "number"
Jūsų mintis sinchronizuoti SQL duomenų bazę su dokumentų saugykla yra panaši į mano mintį sinchronizuoti SQL duomenų bazę su dyanamodb, kuri yra greita raktinių reikšmių saugykla.
Noriu geriausio NoSQL našumo, bet SQL galia prisijungia.
Your idea of synchronizing a SQL database with a document store is similar to my thought of synchronizing a SQL database with dyanamodb which is a fast keyvalue store.
I want the best of NoSQL performance but the power of SQL joins.