Distributed join
To join data together you need the data to be colocated - this idea is to colocate a subset of joined data on each node so that the data can be split up
If you've got lots of data - more than can fit in memory you need a way to split the data up between machines. This idea is to prejoin data at insert time and distribute the records that join together to the same machine
this way the overall dataset can be split between machines. But the join can be executed on every node and then aggregated for the total joined data.
In more detail, we decide which machine stores the data by consistently hashing it with the join keys. So the matching records always get stored on the same machine.
+[проект]
Разве это не то, что делает распределенный nft. Мы собираем проект из многих аккаунтов. Я люблю называть это композицией. Я думаю, что композицию нужно решить не только для хранения, но и для управления сложностью.
Is it not what a distributed nft does. We agregating a project from many accounts. I like to call it composition. I do think composition is the problem to solve, not just for storage concerns, but to manage complexity
Я не знаю, как NFT хранят собственность в цепочке блоков. Но, по сути, эта идея касается деталей реализации среднего уровня распределенного механизма хранения базы данных SQL.
Я считаю идею распределенной базы данных P2P очень полезной У меня есть проект, в котором я реализую очень простую базу данных SQL, и она поддерживает распределенные соединения, распределяя ключи соединения на каждый узел в кластере. В этой идее я использую другой подход и хэширую ключ соединения и использую ключи соединения для размещения узла.
Таким образом, каждый в кластере получает подмножество данных. Вам нужно, чтобы все были в сети, чтобы сделать запрос
I don't know how NFTs store ownership in the block chain. But essentially this idea is about the mid level implementation detail of a distributed SQL database storage engine.
I find the idea of a distributed P2P database very useful I have a project where I implement a very simple SQL database and it supports distributed joins by distributing join keys to every node in the cluster. In this idea I take a different approach and hash the join key and use the join keys to do the node placement.
So everybody in the cluster gets a subset of the data. You need everybody to be online to do a query
// предварительное соединение данных во время вставки //
Думаю, это разумная идея, но как это сделать? На самом деле существует много возможных объединений, предположим, что количество таблиц в базе данных равно %%n%%, тогда количество всех пар таблиц, которые могут потребоваться объединить, равно количеству %%k=2%%. подмножества:
$${\binom{n}{2}}={\frac{n!}{2!(n-2)!}}={\frac{n^2-n}{2}}$$
Например, если в базе данных 15 таблиц, это число равно 105, а если есть 42 таблицы, это число равно 861. Добавьте возможность того, что вам нужно выполнять объединения в разных полях - и количество предварительно вычисленных объединений может быть даже выше. Тем не менее, кажется разумным делать это во время вставки, поскольку соединения будут меняться и их нужно будет пересчитывать или изменять при каждой вставке.
// prejoin data at insert time //
I think it's a reasonable idea, but how would this be done? There are many possible joins, in fact, suppose that the number of tables is the database is %%n%%, then the number of all table pairs that may need to be joined, is the number of %%k=2%% subsets:
$${\binom {n}{2}} = {\frac {n!}{2!(n-2)!}} = {\frac {n^2-n}{2}} $$
For example, if the database has 15 tables, this number is 105, and if there's 42 tables, this number is 861. Add the possibility that you need to do joins on different fields -- and the number of pre-computed joins may be even higher. Still, it seems reasonable to do it at insert time, as the joins would change and need to be recomputed or modified to on every insert.
В моей базе данных SQL я ввел оператор под названием create join.
Вы заранее сообщаете базе данных, какие поля могут быть объединены.
создать соединение внутреннее присоединение к людям на people.id = items.people продукты внутреннего соединения на items.search = products.name
Затем база данных проверяет каждую вставку и выполняет соответствующее согласованное хеширование и размещение узлов.
In my SQL database I introduced a statement called create join.
You tell the database ahead of time what fields are joinable fields.
create join inner join people on people.id = items.people inner join products on items.search = products.name
The database then checked on every insert and does the associated consistent hashing and node placement.
Я должен указать, что некоторые данные могут быть перемещены после выполнения оператора create join.
Если существовало соединение для products.id и search.product_id и во время вставки были вставлены товары. Запрос на соответствие поисков будет запускать select Id из поиска, где product_id = X
search.product_ID зависит от products.id. они имеют одинаковую ценность. Согласованный хэш для продуктов может иметь следующий вид: id. Согласованный хэш для поиска может игнорировать собственный идентификатор и использовать product_id. Это распределит эти данные на один и тот же компьютер, потому что хеши идентичны.
Если имеется несколько соединений, эта схема может быть более сложной. Я думаю, что поля можно объединить и хешировать. Q
I should point out that some data may be movable once the create join statement has ran.
If a join existed for products.id and search.product_id and at insert time of products was inserted. A query for matching searches would run select Id from search where product_id = X
search.product_ID depends on products.id. they have the same value. The consistent hash for products can be: id. The consistent hash for search can ignore its own id and use the product_id. This would distribute this data to the same machine because the hashes are identical.
If there is multiple joins the this scheme might need to be more complicated. I think the fields can be concatenated and hashed.q
Предоставление поисковой системы для Интернета возмутительно дорого, потому что объем данных слишком велик и не умещается в памяти. Мы могли бы использовать этот подход, чтобы разделить требования к хранилищу для выполнения поиска.
Если у всех есть часть поискового индекса, то все запросы отправляются всем до того, как будут возвращены.
Если имеется 1000 узлов хранения, то каждый поисковый запрос производит 1000 подзапросов по одному на каждый узел хранения. Каждый возвращает то, о чем он знает.
Providing a search engine for the internet is outrageously expensive because the data is so large and doesn't fit in memory. We could use this approach to split up the storage requirements of doing search.
If everybody hosts a fraction of the search index then all queries go to everybody before being returned.
If there is 1000 storage nodes then every search query produces 1000 subqueries one to every storage node. Each returns what they know about.