Существует ли кластерная база данных, которая позволяет группировать данные по двум измерениям? - PullRequest
Новая
       3

Существует ли кластерная база данных, которая позволяет группировать данные по двум измерениям?

1 голос
/ 29 июня 2011

Скажем, у меня есть объекты для хранения. В банкомате было бы достаточно рассмотреть их как капли. Я хочу, чтобы сущности были сохранены в кластере. Ключ / ID объекта является (x, y) целочисленной координатой. Таким образом, они в основном расположены в двумерной сетке. Обновление любого объекта требует блокировки его 4-х соседей. Поскольку я хочу избыточности, я подумал, что лучше всего использовать избыточность, чтобы гарантировать, что соседи всегда доступны. Вот как может выглядеть дистрибутив: 

   1  2  3  4  5  6
1 [F][F][E][E][G][G]
2 [F][F][E][E][G][G]
3 [D][D][A][A][B][B]
4 [D][D][A][A][B][B]
5 [H][H][C][C][I][I]
6 [H][H][C][C][I][I]

Если A, B, C, D, E, F, G, H, I являются серверами, то A владеет (3,3) объектом, и ему необходимо знать (2,3) и (3,2) ) которые принадлежат другим серверам. Расположенный в блоках по 4, это всегда оставляет две стороны, принадлежащие другим серверам. Используя тройную избыточность, я хочу форсировать локальную копию всех соседей. Это даст мне эффект линейной масштабируемости.

Существует ли база данных, которая позволяет мне определить ключ шардинга / репликации, чтобы я мог указать такое распределение, или есть способ объединить x и y в одно значение, которое можно использовать для достижения этого?

Что мне нужно, так это низкая задержка и избыточность, а не экономия места на диске. Мои объекты имеют свойство «месторасположение ссылки»; транзакции только когда-либо обращаются к соседям, но использование одного и того же ключа для объекта и его соседей приведет к тому, что у всех будет один и тот же ключ.

1 Ответ

1 голос
/ 29 июня 2011

Я понимаю, что дублирование BLOB-данных может стоить дорого, поэтому мы хотим ограничить избыточность.Преимущество разделения данных состоит в том, что ненормализованным образом вы можете значительно ускорить возможности и производительность поиска.

Это всего лишь мысль, но, возможно, вы могли бы подойти к этому нормализованным способом вместо создания трех таблиц:

Координаты - столбец (ID), столбец (Xcor), столбец (Ycor)

Данные - столбец - (ID), столбец (контрольная сумма?),

CoordinateData - Столбец (CoordinateID), Столбец (DataID)

С CoordinateData в качестве таблицы сопоставления.Это обычно не идеально для индексов или поиска, однако, если вы сохранили, возможно, строку контрольной суммы, вы могли бы использовать какой-то другой носитель для хранения и поиска необработанных данных.

Как я уже сказал, просто идея.

...