2010-05-07 3 views
0

Глядя на http://www.nearmap.com/,Nearmap архитектура

Просто интересно, если вы можете приблизиться, сколько памяти требуется для хранения изображений? (Месячные фотоархивы NearMap в месяц снимаются с разрешением 3 см, 5 см, 7,5 см или 10 см)

А какие системы/архитектуры подходят для доставки этих данных/изображений? (скажите, что вы не Google, и хотите реализовать это с нуля, что бы вы сделали?)

т.е. сохраните ли вы изображения в Hadoop и используйте apache/php/memcache для доставки и т. д.?

+0

Почему вы хотели бы их хранить в Hadoop (я думаю, вы имеете в виду HDFS, не так ли?). Это параллельный доступ или что-то вроде: многие небольшие единицы хранения становятся одним большим !? –

+0

Да HDFS имеет параллельный доступ (что означает высокую пропускную способность). – portoalet

ответ

0

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

Но, в интересах математики, мы можем попытаться выяснить, что требуется.

Итак, если каждый пиксель измеряет 3 см на 3 см, они покрывают 9 см^2. Быстрый поиск по Википедии говорит нам о том, что Лондон составляет около 1700 км 2, а при 10 млрд. См2 на км^2 составляет 17 000 000 000 000 см2. Это означает, что нам нужно 1 888 888 888 888 пикселей для покрытия Лондона с разрешением 3 см. Помещение этого в байты с 4 байтами на пиксель составляет около 7000 гигабайт. Если вы получите 50% -ное сжатие, это снизит его до 3500GiB для Лондона. Умножьте это на каждый город, который вы хотите покрыть, чтобы получить представление о том, какое хранилище данных вам понадобится.

Поставка контента проста по сравнению с его сбором. Поскольку это неловкое параллельное решение, кластер с общим доступом с соответствующим интерфейсом для маршрутизации трафика в нужные узлы, вероятно, будет самым простым способом его реализации. Это связано с тем, что узлам не нужно поддерживать состояние или общаться друг с другом. Идеальный метод будет зависеть от того, сколько данных вы проталкиваете, если вы нажимаете достаточно данных, возможно, стоит реализовать собственный веб-сервер, который просто отвечает на HTTP GET.

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

+0

Коэффициент сжатия может составлять до 90% (с потерями) с использованием формата ECW. Хорошо, кластер «ничего общего» имеет смысл, когда каждый узел обрабатывает город или регион, например? Изменение веб-сервера, чтобы просто отвечать на HTTP GET, звучит хорошо, насколько это может улучшить скорость, которую вы считаете? – portoalet

+0

Я думал, что кластер с общим ничем не будет более устойчивым к падениям и даст лучшую производительность. HTTP-сервер, оптимизированный только для GET, может повысить производительность, но насколько я не могу сказать. Даже если вы сократите время обработки на 90%, если в общем времени отклика преобладает просто отправка данных, вы не получите многого. Для Google это может иметь смысл, поскольку они передают огромное количество трафика, но невозможно сказать без контрольных показателей. –

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