3

Позволяет сначала поместить некоторые цифры: Самый большой из них - это 100M записей. (но ожидается, что он вырастет до 500). Другие списки (5-6 из них) составляют миллионы, но в обозримом будущем они будут меньше 100 млн. Это всегда, основанный на одном id. и никогда с другими параметрами. Каков наилучший алгоритм для присоединения к таким спискам?Объединение очень больших списков

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

БД (по крайней мере, MySQL) присоединилось бы с использованием объединения merge (поскольку оно было бы на первичном ключе). Будет ли это более эффективным, чем мой подход?

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

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

+1

Возможно, решение Hadoop, такое как HBase, может быть полезным? –

+2

Все ли списки заказаны? Являются ли небольшие списки заказаны? (Если это так, существуют различные методы нарезки, которые вы могли бы использовать для разделения вашей обработки). Другие важные вопросы: сколько ядер процессора у вас есть, сколько оперативной памяти для каждого узла обработки, сколько оперативной памяти занимает набор данных, и есть ли разделяемое хранилище? Инстинкт - это то, что лучшим вариантом является разделение вашего основного списка на N (где N - количество ядер ЦП), затем присоединяются к соответствующим подспискам других файлов. Я думаю, что вы правы в использовании хэширования - индекс DB и B-tree только окупится, если вам нужно будет повторно извлекать данные позже. – JulesLt

+0

@JulesLt У меня есть выбор. Поэтому, если я хочу, чтобы они были заказаны, мне придется поддерживать порядок, когда новые строки попадают/удаляются. Подумайте о математике процессора, которую вы предложили, и ответьте позже. @ar: спасибо будет искать его! –

ответ

5

Используйте базу данных. Они предназначены для выполнения соединений (с правильными индексами, конечно!)

+0

Но если я не сделаю какой-то осколок. Числа довольно высоки. Поэтому я бы предположил, что мне нужно будет сделать окончательное слияние по внешнему db внешнему –

+0

100 миллионов строк на самом деле не так уж и много. Обычное эмпирическое правило - использовать разбиение таблиц на 50 миллионов строк. –

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