Имя для этого алгоритма оптимизации размещения данных распределенной базы данных?

Допустим, у нас есть большой граф баз данных, связанных друг с другом, фактически одна гигантская распределенная база данных. Любой узел на графе может запрашивать всю базу данных, рекурсивно запрашивая своих соседей, которые берут результаты, полученные от своих соседей, и передают объединенный результат обратно по пути запроса.

Также предположим, что есть возможность остановить рекурсию, если собственная база данных узла содержит результат, который является «достаточно хорошим», так что не нужно опрашивать всю сеть, если поблизости уже есть достойный результат. Это делает то, что я собираюсь сказать, актуальным.

Разве не имеет смысла переносить возвращенные данные на один шаг ближе к узлу, создавшему запрос, каждый раз, когда выполняется запрос? То есть запрошенный узел запрашивает своих соседей и получает X, сам запрашивает и получает Y, передает X + Y обратно узлу, который его запросил, сохраняет X в своей базе данных и удаляет Y из своей базы данных. Разве это в конечном итоге не приведет к тому, что распределенная база данных будет иметь примерно оптимальное распределение данных между ее узлами в отношении количества узлов, к которым в среднем будут обращаться во время запроса?

Есть ли название у этой техники?


person mwhite    schedule 28.06.2011    source источник
comment
Это имеет смысл только в том случае, если у вас есть представление о местонахождении данных, то есть запросам, исходящим от заданного набора узлов, требуются данные определенного типа (например, если ваша гигантская база данных хранит HTML-страницы, запросы, исходящие из Италии, хотят, чтобы страницы были в итальянский). По сути, вы пытаетесь использовать распределенное кеширование. Я не понимаю, где Y будет храниться после всего этого. Вы должны передать Y куда-нибудь на хранение, не удаляя его ...   -  person akappa    schedule 29.06.2011
comment
Я не понимаю, почему узел удалил свою собственную информацию Y?   -  person Tobu    schedule 29.06.2011
comment
Y - часть результата, переданного запрашивающему узлу, который его сохраняет.   -  person mwhite    schedule 29.06.2011
comment
@Tobu, возможно, глобальная база данных огромна и часто запрашивается, поэтому, если вы не удалили Y, вы использовали бы слишком много места в базе данных каждого узла. Но вы правы, если бы это было не так, то действительно не нужно было бы его удалять.   -  person mwhite    schedule 29.06.2011
comment
То, о чем мне напомнил ваш вопрос - кэширование и обучение с подкреплением - работает лучше, когда запрашиваемые вещи становятся более доступными / имеют больший вес. Но это просто аналогия.   -  person Tobu    schedule 29.06.2011
comment
@mwhite: значит, вы реплицируете одну и ту же информацию на всем пути от исходной базы данных к запрашивающей стороне. Кроме того, базы данных рядом с запрашивающей стороной должны будут хранить огромное количество данных. Это нехорошо ... вы должны перемещать данные, а не копировать много раз при каждом запросе. Я думаю, что подход, основанный на кешировании и явных запросах на перемещение данных между двумя узлами, должен быть намного лучше.   -  person akappa    schedule 29.06.2011
comment
Ой, я подумал: всего один шаг. Если запрашивающая сторона повторяет запрос много раз, то в конечном итоге он будет полностью перемещен. Но на самом деле ты прав. Вам понадобится способ различать ваши данные и данные ваших соседей в данных, которые вы передаете. Что ... эээ. И я думаю, что вы, наверное, в целом правы.   -  person mwhite    schedule 29.06.2011


Ответы (2)



Существуют подобные методы, но вы должны знать, что после того, как вы «кешируете» результат, вы должны обновлять его, если при изменении данных ... что означает, что вы должны либо сохранить данные, которые кэшируют его, либо уведомить всех. Реализация чего-то подобного требует большой координации, что отрицательно скажется на производительности ... не так просто, как кажется. Вы также можете ослабить ограничения, которые дает вам база данных, а затем знать в своем приложении, что вы можете получить кешированные результаты, которые не синхронизируются (и, если необходимо, запросить некэшированную версию).

person Karoly Horvath    schedule 28.06.2011