2012-01-09 2 views
3

Я пишу автономное приложение javascript со Spine, Node.js и т. Д. (Here is an earlier incarnation его, если вам интересно). По сути, приложение является интерактивным исследователем «номер свойства». Идея состоит в том, что вы можете выбрать любое число и посмотреть, какие свойства он обладает. Это простое, треугольное и т. Д.? Где другие номера, которые имеют одни и те же свойства? Такого рода вещи.Лучший способ кодирования/декодирования большого количества данных для клиента JavaScript?

На данный момент я могу довольно легко показать цифры 1-10k, но я хотел бы показать свойства для чисел 1 миллион или даже лучше 1 миллиард.

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

В настоящее время я использую JSON для файлов данных. Для некоторых данных я знаю простой алгоритм для получения информации, которую я ищу на стороне клиента, и я использую это (т. Е. Это даже?). Для более сложных номеров я предварительно их вычисляю, а затем сохраняю значения в файлах синтаксического анализа JSON. Я немного зашел за борт со всем этим: I implemented чистый javascript bloom filter, и когда это не масштабировалось до 1 миллиона для простых чисел, я попытался использовать CONCISE bitmaps внизу (что не помогло). В конце концов я понял, что это не имеет большого значения, как «сжатый» я получаю свои данные, если я представляю его как JSON.

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

Какие варианты у меня есть для эффективной отправки эти большие наборы данных в мое решение только для javascript?

Можно ли преобразовать в двоичный код, а затем прочитать двоичный код на стороне клиента? Примеры, пожалуйста!

+0

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

ответ

4

Как насчет только вычисление этих точек данных на клиенте?

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

Для свойств выставленных на номер. Чистый JavaScript на современных настольных компьютерах ослепляет быстро (если вы держитесь подальше от DOM), я думаю, вы обнаружите, что различия в скорости обработки незначительны между алгоритмическим и предварительно вычисленным решением JSON, и вы будете экономить себе много боли и ненужных использование полосы пропускания.

Что касается начального индекса диаграммы, это показывает только ряд свойств на число и может быть передана в виде массива:

'[18,12,9,11,9,7,8,2,6,1,4, ...]' 

или в JSON:

{"i": [18,12,9,11,9,7,8,2,6,1,4, ...]} 

Заметим, что это работает одинаково для логарифмической шкалы, так как в любом случае вы можете одновременно привязывать значение до 1 точки на экране. Вы просто должны удовлетворять содержимому массива (возвращая логарифмические значения последовательно на массив размером 1-2 КБ).

Вы можете использовать алгоритм DEFLATE, чтобы сжать его дальше, но поскольку вы можете отображать только ограниченное количество чисел на экране (< 1-2K пикселей на рабочем столе), я бы рекомендовал вам создать свое решение вокруг этого факта, например, проверяя, можете ли вы вычислить свойства 2K * 30 = 60K на ходу с минимальным воздействием, что, вероятно, будет быстрее, чем попросить сервер в этот момент дать вам некоторый JSON.

UPDATE 10-Jan-2012

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

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

{ 
    "n": [18,12,9,11,9,7,8,2,6,1,4, ...] // number of properties x 1-2K 
    "p": [1,2,3,5,7,13,...] // prime numbers x 1-2K 
    "f": [1,2,6, ...] // factorials x 1-2K 
} 

Я думаю, что объект JSON, как это будет около 30-60K, но вы можете дополнительно уменьшить, убрав свойства которых алгоритмы не рекурсивная и позволить клиенту рассчитать те локально.

Если вы хотите альтернативный способ сжать эти массивы, когда вы получаете большое количество, вы можете форматировать массив как VECTOR вместо списка чисел, хранение различия между одним номером и следующим, это будет держать пространство вниз, когда вы имеете дело с большими числами (> 1000). Пример использования JSON с использованием векторов будет следующим:

{ 
    "n": [18,-6,-3,2,-2,-2,1,-6,4,-5,-1, ...] // vectorised no of properties x 1-2K 
    "p": [1,1,2,2,2,6,...] // vectorised prime numbers x 1-2K 
    "f": [1,1,4, ...] // vectorised factorials x 1-2K 
} 
+0

Я определенно вижу вашу мысль, и за значительную информацию я думаю, что могу сделать что, все еще поражая все цели, которые я хочу поразить.Но, остается точка - есть значительный объем данных, которые мне нужно иметь. Когда это так, что мне делать? – dsummersl

+0

Сколько чисел вы намерены показывать на экране одновременно? –

+0

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

3

Я бы сказал, что самым простым способом было бы разбить набор данных на несколько файлов данных. Затем «клиент» может загружать файлы по мере необходимости, исходя из числа, которое пользователь ищет.

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

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

+0

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

+0

Два основных варианта, которые я могу видеть, это либо загрузить его «по требованию», либо рассчитать его «на лету» ». В любом случае, если просто _needs_ будет много данных, перемещаемых клиенту, тогда не так уж и много. Сжатие Gzip, скорее всего, поможет _a lot_ в этом случае, так как все данные являются текстовыми, поэтому вам может не понадобиться беспокоиться, как вы думаете. Попробуйте это в одну сторону, посмотрите, как это работает, и если это не достаточно, попробуйте еще раз. – cdeszaq

+0

Да, я предполагаю, что без потерь * что-то имеет смысл. Я вижу ... https://github.com/nmrugg/LZMA-JS Мне нужно будет немного поработать ... – dsummersl

Смежные вопросы