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.
Нет дочерних категорий.
+[вопрос]
проект Document database backed by keyvalue storage
Implement a documentDB backed by keyvalue storage with efficient querying
+[идея]
+[проект]
Как создать базу данных на основе документов, поддерживающую соединения?
Общим недостатком баз данных документов является то, что они часто не поддерживают эффективные соединения. Они представляют записи документов в виде непрозрачного BLOB-объекта.
Я создал прикрепленный проект, чтобы рассказать о том, как я планирую реализовать хранилище на основе документов, используя хранилище значений ключей в качестве серверной части. Каждый ключ документа является отдельным ключом, и они устроены так, чтобы сканирование диапазона было эффективным, чтобы можно было эффективно выполнять хеш-соединения.
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.
Ключевое слово "эффективный". Эффективность обратно пропорциональна вычислительной сложности, поэтому, я полагаю, вы ищете новые алгоритмы для соединений с неструктурированными данными.
Во-первых, проблема уже решена в базах данных SQL, верно? Почему бы не взглянуть на реализацию и не взять ее оттуда?
Допустим, у нас есть необработанные данные в виде записей JSON (или словарей, хэш-карт). Что вас беспокоит, так это эффективные запросы, которые являются предметом индексации (оптимизация запросов или алгоритмы запросов). Мы регулярно индексируем базы данных SQL в ElasticSearch, потому что базы данных SQL не очень хороши или недостаточно гибки в текстовом поиске другими способами, которые интересуют пользователей: мы используем другие данные система, которая хороша в этом, и храните там копию данных. Не очень экономит место, но работает. Мы могли бы сделать то же самое с NoSQL — если вам нужны запросы, подобные соединению — просто «индексировать» данные в базы данных SQL с помощью специализированных процессов, которые интерпретируют и переносят базу данных SQL на лету, работая как дополнительная работа в сочетании с NoSQL всегда ищет новые поля и создает эти поля в дополнительной базе данных SQL. Конечно, использование многих баз данных одновременно не является элегантным решением, поэтому я согласен с тем, что нам необходимо улучшить базы данных на основе документов. В конце концов, схемы не существуют, каждая запись подразумевает какую-то схему, и когда достаточно много записей имеют общие определенные поля, это может оправдать создание нового поля SQL или внешнего ключа. Думайте об этом как о мозге, который реализует новые «законы физики», когда вы видите достаточно много примеров определенного типа...
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...
Я разработал пространство ключей для JSON, которое быстро декодируется обратно в JSON и быстро сканируется при сканировании диапазона значений ключей RocksDB.
Это позволяет нам выполнять обычное хеш-соединение, как это делает реляционная база данных.
Это JSON { "name": "Сэмюэл Сквайр",
"работа": {
"текущая работа": {"компания": {"employeeCount": 2500}}
}
}
{"_id": "1",
"name": "Сэмюэл Сквайр",
"хобби": [
{"имя": "Бог"}, {"имя": "базы данных"}, {"имя": "многокомпьютерные системы"}
] } Превращается по крайней мере в следующие объекты ключ-значение
0.0 = "Сэмюэл Сквайр"
0.1.0.0.0 = "2500"
0.0 = "Сэмюэл Сквайр"
0.1.0.0 = "Бог" 0.1.1.0 = "базы данных" 0.1.2.0 = "многокомпьютерные системы"
По существу сформируйте плоскую структуру документа с ключами.
"тип людей": "объект",
"введите людей.*": "список",
"тип люди.*.0": "строка",
"введите людей.*.1": "список",
"тип люди..1..0": "строка",
"тип люди..1.": "объект",
"тип люди.*.2": "объект",
"тип люди.*.2.0": "объект",
"тип люди.*.2.0.0": "объект",
"тип люди.*.2.0.0.0": "число",
"полевые люди.*": "СПИСОК",
"полевые люди..1.": "СПИСОК",
"полевые люди.*.0": "имя",
"полевые люди.*.1": "увлечения",
"полевые люди..1..0": "имя",
"полевые люди.*.2": "работа",
"полевые люди.*.2.0": "currentJob",
"полевые люди.*.2.0.0": "компания",
"полевые люди.*.2.0.0.0": "employeeCount",
"полевые люди": "люди",
"полевые люди.*": "СПИСОК",
"полевые люди.*.3": "слова",
"полевые люди..3.": "СПИСОК",
"полевые люди..3..*":"СПИСОК",
"полевые люди..3...": "СПИСОК",
"введите людей.*.3": "список",
"введите людей..3.": "список",
"введите людей..3..*": "список",
"введите людей..3...": "список",
"тип люди..3....*": "число"
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"
Ваша идея синхронизации базы данных SQL с хранилищем документов аналогична моей мысли о синхронизации базы данных SQL с dyanamodb, который является быстрым хранилищем значений ключей.
Я хочу получить максимальную производительность от NoSQL, но мощь SQL присоединяется.
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.