Исправление www_linux_org_ru, (текущая версия) :
В моей практике был случай, когда строк было миллиард и тасование занимало больше суток. Сколько будет над такими данными пыхтеть sort? Неделю... месяц..?
бугага!!!
сейчас посчитаю, сколько будет этим заниматься нормально написанный sort -R (гнутый сорт все-таки похоже тормоз)
итак, 1Г строк, каждая, скажем, по 500 байт? допустим даже не рейд-массив, а обычный диск с со скоростью 170 МБ/с
допустим 4Г оперативки на компе, т.е. режем на файлы по 2ГБ за раз
1. прочитать 2ГБ и посчитать хэши его строк — это 12 с
2. отсортировать — это примерно 4М строк, значит 22 прохода по памяти, которой, скажем, 32*4М = 128М — это вообще меньше секунды
3. записать 2ГБ обратно — это опять 12 с
итак 250 рандомно отсортированных файлов это чуть меньше чем 125 минут, т.е 2 часа
теперь делаем (сортирующее) слияние 250 файлов — это опять по времени только прочитать и записать 500 ГБ, само слияние займет ничтожно мало — получаем опять 2 часа, даже меньше (около 3000 секунд)
итого: 4 часа на все про все, при этом именно сортировка будет занимать от силы 20 минут (хэши и то, скорее всего, дольше считаться будут)
почему это куда быстрее, чем у тебя? потому что делается всего лишь 2 (прописью: два) прохода по диску на чтение и столько же на запись, а твоя утилита изъездит диск в незнамо сколько проходов
опять же плюс этого решения в том, что скорость от снижения количества оперативки на компе почти не упадет
э-хе-хех
согласен... эхехех, пейсатели...
Исправление www_linux_org_ru, :
В моей практике был случай, когда строк было миллиард и тасование занимало больше суток. Сколько будет над такими данными пыхтеть sort? Неделю... месяц..?
бугага!!!
сейчас посчитаю, сколько будет этим заниматься нормально написанный sort -R (гнутый сорт все-таки похоже тормоз)
итак, 1Г строк, каждая, скажем, по 500 байт? допустим даже не рейд-массив, а обычный диск с со скоростью 170 МБ/с
допустим 4Г оперативки на компе, т.е. режем на файлы по 2ГБ за раз
1. прочитать 2ГБ и посчитать хэши его строк — это 12 с
2. отсортировать — это примерно 4М строк, значит 22 прохода по памяти, которой, скажем, 32*4М = 128М — это вообще меньше секунды
3. записать 2ГБ обратно — это опять 12 с
итак 250 рандомно отсортированных файлов это чуть меньше чем 125 минут (записываем 2 часа)
теперь делаем (сортирующее) слияние 250 файлов — это опять по времени только прочитать и записать 500 ГБ, само слияние займет ничтожно мало — получаем опять 2 часа, даже меньше (около 3000 секунд)
итого: 4 часа на все про все, при этом именно сортировка будет занимать от силы 20 минут (хэши и то, скорее всего, дольше считаться будут)
почему это куда быстрее, чем у тебя? потому что делается всего лишь 2 (прописью: два) прохода по диску на чтение и столько же на запись, а твоя утилита изъездит диск в незнамо сколько проходов
опять же плюс этого решения в том, что скорость от снижения количества оперативки на компе почти не упадет
э-хе-хех
согласен... эхехех, пейсатели...
Исходная версия www_linux_org_ru, :
В моей практике был случай, когда строк было миллиард и тасование занимало больше суток. Сколько будет над такими данными пыхтеть sort? Неделю... месяц..?
бугага!!!
сейчас посчитаю, сколько будет этим заниматься нормально написанный sort -R (гнутый сорт все-таки похоже тормоз)
итак, 1Г строк, каждая, скажем, по 500 байт? допустим даже не рейд-массив, а обычный диск с со скоростью 170 МБ/с
допустим 4Г оперативки на компе, т.е. режем на файлы по 2ГБ за раз
1. прочитать 2ГБ и посчитать хэши его строк — это 12 с 2. отсортировать — это примерно 4М строк, значит 22 прохода по памяти, которой, скажем, 32*4М = 128М — это вообще меньше секунды 3. записать 2ГБ обратно — это опять 12 с
итак 250 рандомно отсортированных файлов это чуть меньше чем 125 минут (записываем 2 часа)
теперь делаем (сортирующее) слияние 250 файлов — это опять по времени только прочитать и записать 500 ГБ, само слияние займет ничтожно мало — получаем опять 2 часа, даже меньше (около 3000 секунд)
итого: 4 часа на все про все, при этом именно сортировка будет занимать от силы 20 минут (хэши и то, скорее всего, дольше считаться будут)
почему это куда быстрее, чем у тебя? потому что делается всего лишь 2 (прописью: два) прохода по диску на чтение и столько же на запись, а твоя утилита изъездит диск в незнамо сколько проходов
опять же плюс этого решения в том, что скорость от снижения количества оперативки на компе почти не упадет
э-хе-хех
согласен... эхехех, пейсатели...