Распределить файлы по X серверам [закрыто]

Возможно, посмотрите на распределенную файловую систему как GlusterFS. Это кажется, что будет отвечать всем Вашим требованиям и вероятно будет более надежным, чем что-то, что Вы изрубили сами.

Несмотря на Ваши невозможные требования, я набросаю вниз свои мысли для других людей в будущем, которые не так зажаты в тиски, на основе моих событий, делающих это для GitHub.

Распределительные данные через многие местоположения (быть ими разделы, машины, дата-центры) на основе хеша являются опасным обязательством по двум причинам:

1. Вы никогда не собираетесь получать сбалансированное распределение данных на основе Вашего хеша - не обязательно, потому что хеш не сбалансирован (хотя это - фактор также), но больше потому что объекты, которые Вы храните, не являются равным размером. Таким образом, Вы храните два объекта, один 1 КБ в размере другой 1 ГБ в размере. Уже Вы являетесь в широком масштабе несбалансированными. Попробуйте это несколько раз, и внезапно у Вас есть большая неустойчивость.
2. После того как Ваш алгоритм хеша к серверу существует, Вы не можете изменить количество "блоков" (машины, разделы, безотносительно), чтобы хранить Ваши данные в без значительной суммы боли. Это вызвано тем, что хеш-алгоритм используется и для решения, где сохранить материал, и также где найти его снова. При изменении количества серверов то правило, "где материал является" изменениями, и так некоторые существующие данные, как ожидают, будет где-то в другом месте. Вы заканчиваете любой имеющий долгую офлайновую операцию "восстановления равновесия" (каждый сервер ищет данные, которые, в новой схеме, должны быть где-то в другом месте и перемещают его туда), или необходимо искать данные по всем файловым серверам (мммм, неэффективный).

С другой стороны, наличие справочной таблицы для всех Ваших файлов заставляет эти проблемы уйти. Когда Вы не говорите "базы данных", я держу пари, что Вы вставляете неявный "SQL" перед "базой данных". Однако существует целый другой мир баз данных там, которые не имеют никакого отношения к SQL, и они идеально подходят для этой ситуации. Они известны как "хранилища значения ключа", и если бы Вы мертвы увлеченный продолжением создания этого бесполезного труда сами, затем я настоятельно рекомендовал бы использование одного (у меня есть опыт с Redis, но они все кажутся довольно разумными).

В конечном счете, тем не менее, если Вы продолжаете "все хеши, все время" система и затем бездельничаете проблемы, свойственные от нее (существуют решения, просто не реальные потрясающие), все, что Вы закончите с, в конце дня, half-assed, плохо сделанный, non-feature-complete версия GlusterFS. Если Вам нужна большая сумма устройства хранения данных, growable со временем, распределенного через несколько реальных машин, в едином пространстве имен, я действительно рекомендовал бы это по чему-либо, что можно создать сами.

Если Вы все еще хотите взломать его, сделайте md5sum на каждом файле и затем хешируйте вывод к своим X полям..

Если у Вас есть два поля:

0*-7* идут для упаковки того 8*-f*, идут для упаковки два...

Или если у Вас есть 256 полей: 00*-0f* идут для упаковки того 10*-1f*, идут для упаковки два.. и так далее..

Это работает лучше всего на количества поля полномочий два. (2,4,8,16..)

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

(куда я помещал foo.txt??)

Рассол плоского файла (в Python) работал бы, но он не масштабируется, а также DB для больших объемов данных..

Другие серверы могут также отправить файлы? Вы находитесь в "безопасной" среде?

Горный процесс установки кластеров должен заполнить стойку после того, как стойка вычислит узлы, каждый установленный на лету из первоначального изображения. Выполнение этого линейно или через единственный сервер было бы узким местом. Скалы используют вместо этого немного системы под названием Лавина, где изображения установки вручены с помощью p2p; поскольку узлы подходят, они также становятся серверами, которые будут использоваться для установки новых узлов. Результатом является дерево серверов и каскада изображений установки через стойки очень быстро. Полная задержка является логарифмом количества узлов, умноженный к этому времени для установки одного узла (основа для логарифма зависит от того, сколько другие узлы могут быть поданы от того, который уже установлен, журнал базируются 20, не было бы удивительно...).

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