Распространение файлов на X серверов

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

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

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

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

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

Однако в конечном итоге, если вы воспользуетесь системой «все хэши, все время», а затем обойдете присущие ей проблемы (есть решения, но не очень крутые), все, что у вас получится, в конце the day, это недоработанная, дрянная, неполнофункциональная версия GlusterFS. Если вам нужен большой объем хранилища, расширяемый со временем, распределенный по нескольким физическим машинам в одном пространстве имен, я бы действительно рекомендовал его вместо всего, что вы можете создать самостоятельно.

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

Если у вас две коробки:

0 * -7 * перейти к первой ячейке 8 * -f * перейти к второй ячейке ...

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

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

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

(куда я положил foo.txt ??)

Плоский файл pickle (на Python) будет работать, но он не будет масштабироваться так же хорошо, как БД для больших объемов данных.

Могут ли другие серверы также отправлять файлы? Вы находитесь в «безопасной» среде?

Процесс установки кластеров Rocks должен заполнять стойку за стойкой вычислительных узлов, каждый из которых устанавливается «на лету» из исходного образа. Выполнение этого линейно или через один сервер будет узким местом. Вместо этого Rocks использует небольшую систему под названием Avalanche, в которой установочные образы обслуживаются с помощью p2p; по мере появления узлов они также становятся серверами, которые будут использоваться для установки новых узлов. В результате получается дерево серверов, и установочные образы очень быстро проходят каскадом по стойкам. Общая задержка - это логарифм количества узлов, умноженный на время установки одного узла (основание для логарифма зависит от того, сколько других узлов может обслуживаться из уже установленного, логарифм базы 20 не удивит ...).

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