Необходимо хранить 128 * бит * Первичный ключ: я должен использовать SQL Azure или Azure Table? Или просто используйте связанный список в Azure Blob

Question

Мне нужно хранить большой (128-битный) ПК. Каждому int будет соответствовать несколько столбцов ... схема не определена сейчас ... и я хочу, чтобы схема была гибкой в ​​будущем. (Мне нужна только консервативная гибкость, например, добавление новых столбцов время от времени)

На данный момент я не слишком обеспокоен способностью делать соединения и тому подобное. Я в основном хочу выбрать случайный ПК и искать вверх или вниз по следующим 10 записям. Поскольку в поиске может быть много пустого пространства, стоимость поиска вверх и вниз может варьироваться.

Какова лучшая технология для обработки этого запроса? Меня интересует то, что сэкономит мне деньги (на транзакцию) и место для хранения. Я также заинтересован в производительности.

Что вы рекомендуете?

Обновление

ОК, так для чего это нужно? Я хочу создать историю данных для адресов IPv6. Конечно, это будет очень скудная таблица ... но мне нужно отследить определенные вещи, касающиеся увиденных IP-адресов.

Answer 1

Чтобы уточнить, я думаю, вам нужен ключ 128 бит (не 2 ^ 128 бит).

Я воспринимаю это как вопрос о выборе типа Db Key, я не уверен, какие последствия имеет угол Azure.AFAIK он построен на основе MS-SQL.

128 бит или 16 байт имеют тот же размер, что и Guid (UniqueIdentifier), но я не думаю, что вы хотите использовать это.Хотя есть поддержка для его использования в качестве ключа.

Прямой выбор - это что-то вроде двоичного (16), но я не знаю, насколько хорошо он подходит в качестве PK.

Вы можете закодировать его как шестнадцатеричную строку char (32)Это не чрезмерно.

Для практических оценок ключевым фактором является то, насколько разреженными являются ваши данные, или лучше: сколько адресов вы ожидаете хранить?

Answer 2

Таблицы Windows Azure были бы моей рекомендацией, но определен только один порядок сортировки, поэтому будет трудно искать как вперед, так и назад. Возможно, вам придется хранить каждую клавишу дважды, один раз в обычном порядке и один раз в обратном порядке (клавиша 0xFFF ... F) для эффективной поддержки обоих направлений сканирования.

Answer 3

Прежде всего, ваше предположение о 2 ^ 128 целочисленных ключах неверно, так как вы упомянули, что хотите хранить IP V6-адреса. Адрес IP V6 имеет длину 128 бит. Чтобы сохранить его как целое число, вам нужно 128/32 или 4 32-битных целых числа на адрес. Таким образом, правильная оценка составляет 2 ^ 128 возможных адресов * 4 целых числа для общего количества 2 ^ 128 * 4 ключей 32-битных целых чисел ....

В любом случае я хочу, чтобы это было в байтах, поэтому мы просто перейдем на 2 ^ 128 возможных адресов * 4 целых числа * 4 байта на целое число = 5,44 * 10 ^ 39 байтов. После этого просто следуйте расчетам Андреаса, и вы получите больше ...

Как говорится, идея IP V6 заключается в том, что у нас больше адресов, чем нам когда-либо понадобится. Поэтому я очень сомневаюсь, что где-то около 2 ^ 128 будет назначено на многие годы. Самое большее, если мы перейдем к IP V6 прямо сейчас, у нас будет назначено адресное пространство IP V4 и ничего больше, и хотя число IP-адресов увеличивается с каждым годом не так сильно.

В любом случае кажется, что вы не знаете, что храните, поскольку схема не определена, поэтому таблица Azure может быть тем, что вам нужно. В основном это ключ / значение. Для каждого IP-адреса вы можете хранить совершенно разные свойства. И действительно легко добавить другое свойство / удалить другое свойство, используя операции обновления / вставки / слияния. Но если вы хотите, чтобы к вашим данным применялась некоторая единообразие, используйте SQL. Это правда, что вам придется изменять схему по мере их изменения, но это приведет к тому, что каждая строка (и, следовательно, IP-адрес) будет иметь одинаковые данные. В противном случае легко пропустить «обязательные» столбцы / свойства или ввести их с ошибкой, если у вас несколько приложений. Но это действительно зависит от того, что вы хотите сделать. Больше вы цените целостность данных или гибкость свойств? Даже если схему нужно изменить, есть команды для добавления / удаления столбцов из схемы. Более того, вы хотите, чтобы на каждом IP-адресе хранились одинаковые свойства или каждый из них имел разные свойства. Я считаю, что способ таблицы Azure, вероятно, занимает меньше памяти на адрес, чем способ SQL, если вы не используете большинство свойств для данного IP-адреса. Так что все зависит от того, что вы ищете.