Кодирование уникальных идентификаторов до максимального размера документа 100 КБ - PullRequest
2 голосов
/ 07 августа 2011

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

Итак, у меня есть документы в моем индексе поисковой системы. Документы могут иметь несколько полей, однако размер каждого поля должен быть ограничен только 100 КБ.

Я хотел бы хранить идентификаторы определенных сайтов, которые имеют доступ к этому документу. Количество идентификаторов сайта низкое, поэтому он никогда не поднимется до чрезвычайно высоких цифр.

Например, к этому документу могут обращаться сайты с идентификаторами 7 и 10.

Document: {
 docId: "1239"
 text: "Some Cool Document",
 access: "7 10"
}

Теперь, поскольку поле «доступ» ограничено 100 КБ, это означает, что если вы берете последовательные идентификаторы, то могут храниться только 18917 уникальные идентификаторы.

Ссылка: http://codepad.viper -7.com / Qn4N0K

<?php
    $ids = range(1,18917);
    $ids = implode(" ", $ids);
    echo mb_strlen($ids, '8bit') / 1024 . "kb";
?>

// Вывод

99.9951171875kb

В моем приложении пытается выполнить поиск конкретный сайт с идентификатором 7, и он получит доступ к этому «Необыкновенному документу»

Итак, теперь мой вопрос будет, есть ли способ, чтобы я мог как-то вписать больше идентификаторов в это поле? Я думал о правильном кодировании и применении чего-то вроде дерева Хаффмана, но, поскольку каждый документ имеет разные идентификаторы, было бы невозможно применить один набор кодировки к каждому документу.

Возможно, я мог бы использовать что-то вроде римских цифр?

Во всяком случае, я открыт для идей.

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

Edit:

Преобразовать в шестнадцатеричное

<?php
        function hexify(&$item){
             $item = dechex($item);
        }
    $ids = range(1,21353);
    array_walk( $ids, "hexify");
    $ids = implode(" ", $ids);
    echo mb_strlen($ids, '8bit') / 1024 . "kb";

?>

Это дает повышение производительности на 21353 последовательных идентификатора. Так что это как 12,8%

Важная оговорка

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

Ответы [ 2 ]

1 голос
/ 07 августа 2011

Откуда пришел 18917? 100kb - это большое число.

У вас есть около 100 000 байтов. Каждый байт может быть длиной 255, если вы храните его как число.

Если вы закодируете как шестнадцатеричное, вы получите 100000 ^ 16, что является очень большим числом, и это просто шестнадцатеричное кодирование.

А как насчет base64? Вы помещаете 3 байта в 4-байтовое пространство (небольшая потеря), но вы получаете 64 символа на символ. Итак, 100 000 ^ 64. Это большое число.

У тебя не будет проблем. Просто сделайте простое шестнадцатеричное кодирование.

EDIT:

TL; DR

Допустим, вы используете base64. Вы можете разместить в 6,4 раза больше данных в одном месте. Сжатие не требуется.

0 голосов
/ 07 августа 2011

Как насчет использования сжатия данных?

$ids = range(1,18917);
$ids = implode(" ", $ids);
$ids = gzencode($ids);
echo mb_strlen($ids, '8bit') / 1024 . "kb"; // 41.435546875kb
Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...