Спецы ассемблера
Неужели эта очевидная оптимизация не встроена давно во все популярные СУБД? "Ну тупые!"
ооо, даже не верится, я когда то потратил денег на оптимизации баз, но ни на одном форуме никто не сказал да о возможности относительно быстрой сортировки базы в миллиард записей )) и пришлось тупо сесть и придумать решение самому, что я и успешно сделал. Но никому не скажу как ))
Кстати есть оказывается тулза которая поддерживает таки миллиард строчек, но я еще не тестировал ее
Power BI от Microsoft – что это?
ооо, даже не верится, я когда то потратил денег на оптимизации баз, но ни на одном форуме никто не сказал да о возможности относительно быстрой сортировки базы в миллиард записей )) и пришлось тупо сесть и придумать решение самому, что я и успешно сделал. Но никому не скажу как ))
Это только я не понял задачу, которую хотел решить 
Muenchausen? :) Зачем сортировать лярд записей? В БД для быстрой сортировки придумали индексы...
Кстати есть оказывается тулза которая поддерживает таки миллиард строчек, но я еще не тестировал ее
Любая БД поддерживает лярд строчек. Даже есть все строчки пронумеровать обычным 32 разрядным интом, будет больше 4 лярдов строк...
Зачем сортировать лярд записей? В БД для быстрой сортировки придумали индексы...
Кстати, да - сортируют обычно результат запроса.
Зачем сортировать лярд записей?
-----
В свете постановки задачи ТС некоторый смысл имеется.
В БД для быстрой сортировки придумали индексы...
-----
Угу... Вот только смысл в индексе по одноколоночной табличке? 
Я сказал "обычно". Что там ДБАшники со своими индексами-оптимизациями делают меня не очень касается. Я всё равно потом результат пересортирую как мне надо.
Тоесть имеем текстовый файл например 90 гиг, где база из двух столбцов, в первом 30 значный код , во втором дата , и таких строчек по моему 870 млн штук, сколько времени нужно чтобы просто отсортировать по тридцатизначному коду в порядке возрастания ?
В свете постановки задачи ТС некоторый смысл имеется.
Да? :) Какой?
Вот только смысл в индексе по одноколоночной табличке?
Отсортированная одноколоночная табличка - это фактически и есть индекс.
Тоесть имеем текстовый файл например 90 гиг, где база из двух столбцов, в первом 30 значный код , во втором дата , и таких строчек по моему 870 млн штук, сколько времени нужно чтобы просто отсортировать по тридцатизначному коду в порядке возрастания ?
Еще раз, все зависит от того, что тебе нужно иметь на выходе.
Самое простое и быстрое решение:
1) создать БД
2) сделать табличку из 2- колонок (id и дата)
3) добавить индекс по колонке код
4) дальше просто считываешь все эти 870млн строк и добавляешь в БД.
Отсортированные данные готовы. Осталось их только выбрать: select * from <table> order by <id>. Ну очевидно, что 870млн строк за раз никому не надо, поэтому имеет смысл сделать вывод по частям: select * from <table> order by <id> offset X rows fetch next Y rows only (для MSSQL).
Сколько на это уйдет времени сказать не могу, но это будет не то, чтобы очень долго.
Другой способ - создать индекс самостоятельно. Т.е. рядом с текстовым файлом появится еще один файл, в котором будет сохранен двухсвяхный список.
Если нужен совсем хардкор, то различные алгоритмы сортировки гуглятся на раз. Если в исходном файле данные одинковой длины, то жизнь несколько упрощается.
2й и 3й способы будут гарантированно медленнее и геморройнее в реализации. Зато 100% свое :D
Выбирай любое подходящее тебе решение :)
А почему играет роль одинаковая длина ? По идее я могу в текстовом исходном файле сделать автозамену 1 на 01 , 2 на 02 .. и тогда все однозначные станут двузначными и длига кода станет везде одинаковой. Я читал что при сортировке оно берет например первую строку и сравнивает со всеми следующими снизу, тоесть 870 млн сравниваний. Итого имеем прогрессию как бы ( 1+870млн)/2 × 870 млн что грубо равно 900 млн х 400 млн = 36000000 млн млн или 36 млн млн млн операций , это же куча времени !
А почему играет роль одинаковая длина ?
Потому что
1) в строках одинаковой длины легче навигация
2) строки одинаковой длины проще менять местами
Пример:
AAAA
DDDD
CCCC
BBBB
против
AA
DDD
BBBB
C
Очевидно, что в 1-ом случае для того, чтобы узнать начало какой-либо строки надо знать просто номер этой строки. Во втором случае для того, чтобы узнать начало 3-й строки нужно прочитать первые две (ну или построить индексный файл и хранить там начало и длину каждой строки).
С сортировкой все еще забавнее. Если для перестановки 2-й и 4-й строк понадобится всего 2 операции записи, то во стором случае понадобится 3 операции записи, при этом 3-я операция - это все, что между 2-й и 4-й строчкой.
Т.е. если у тебя 1млн строк и ты хочешь поменять местами 2-ю и предпоследнюю строки, то ты перезапишешь практически весь файл. А чтение и запись - это очень медленные операции.
Я читал что при сортировке оно берет например первую строку и сравнивает со всеми следующими снизу, тоесть 870 млн сравниваний. Итого имеем прогрессию как бы ( 1+870млн)/2 × 870 млн что грубо равно 900 млн х 400 млн = 36000000 млн млн или 36 млн млн млн операций , это же куча времени !
Это не самый быстрый алгоритм :)
Есть более эффективные сортировки: https://www.toptal.com/developers/sorting-algorithms
Тоесть имеем текстовый файл например 90 гиг, где база из двух столбцов, в первом 30 значный код , во втором дата , и таких строчек по моему 870 млн штук, сколько времени нужно чтобы просто отсортировать по тридцатизначному коду в порядке возрастания ?
Зачем текстовый файл на 90 гиг? Зачем 30-значный код для миллиарда (10 знаков) записей? Зачем сортировать без смысла, без запроса? Разве что предварительная сортировка, но она делается один раз.
ну как бы анализ событий случившихся за многие годы, а результат кодирован тридцатизнаком, причем там тысячи за день, просто скидывалось в текстовик годами, но формат соблюден. Задача найти топ 10 например повторяющихся, но мне хватит даже если все их просто отсортировать по возрастанию а там я уже макросом пройдусь по текстовику. А текстовик потому что я ексцелем иногда балуюсь, с текста легче вынимать и там нет ограничения на 90 гб файлразмер.
Отсортированные данные готовы.
-----
Ээээ... каким образом?
гуглятся на раз
-----
Ээээ... а зачем? для файлового варианта все есть в системе...
но это будет не то, чтобы очень долго
------
Исходная задача говорит что - в сопоставлении с другими решениями - долго - нужно будет читать последовательно два списка, при этом один перечитывать сначала.
А почему играет роль одинаковая длина ?
-----
Ты хоть немножко программируешь?
Напиши простую программку - прочитать эн-ную строку из файла.
Один вариант - для равнодлинных строк, другой - для переменной длинны.
И погоняй на своих 870 млн строк.
Все поймешь...
ну я составляю Produktionsprogramm на месяц )) а так в вижуалбейсике в ексцеле балуюсь.
мне хватит
-----
Потому что у тебя есть полдня, а то и неделя, чтобы найти этот десяток...
А мне - не хватит - потому что у меня от сотни до десятка тысяч запросов в минуту и каждый ожидает ответа не более полсекунды.
Да без разницы на чем - лишь бы умел прочитать заданную строку в обоих случаях...