). Ну нет никаких особых нестандартных требований. Вроде делали-переделали этих СУБД как собак нерезаных.
Но нет же — пишут с нуля, причем дело не в десятках процентов выигрыша а в порядках.
По идее должно быть так — создать таблицу, внести в таблицу пакетом (пусть BULK INSERT), создать индекс. Все! Оно должно само суметь отсортировать быстро — для этого и делаются СУБД, чтобы не писать каждый раз с нуля.
Насоздавали их разных видов — и встраиваемые и кластерные и какие хотите вам.
Но нет же! Делали делали — и ничего не сделали. Все нужно писать в нуля руками. Спорят сейчас в комментах где взять b-tree на C#, чтобы в памяти
Здравствуйте, Shmj, Вы писали:
S>Но нет же! Делали делали — и ничего не сделали. Все нужно писать в нуля руками. Спорят сейчас в комментах где взять b-tree на C#, чтобы в памяти
СУБД это универсальная хрень. За универсальность нужно платить, например доп потреблением памяти, меньшим быстродействием, большей сложностью. Потому периодически возникает ситуации, когда обработку данных нужно делать быстрее чем это позволяет СУБД со всеми индексами и т.д.
И в результате хреначишь и сам перпаковываешь данные, чтобы они и занимали места в памяти как можно меньше, и сам хреначишь всякие индексы, и сам думаешь как это распараллелить на кластере. Собственно именно сейчас такой хренью и занимаюсь — имеется жесть какая легаси бизнес логика, и через нее нужно прогнать вообще все данные, если делать стандартными средствами то считаться будет год, нагрузив по максимуму все сервера.
Re: Почему не смогли применить готовое решение для простой задач
Здравствуйте, Shmj, Вы писали:
S>Но нет же! Делали делали — и ничего не сделали. Все нужно писать в нуля руками. Спорят сейчас в комментах где взять b-tree на C#, чтобы в памяти
Действительно, было бы интересно заценить производительность решения, которое читало бы файл с диска, форматировало под требования sort (линуксовая утилита), пайпом отправляло в sort, форматировало обратно и сохраняло в целевой файл.
Re: Почему не смогли применить готовое решение для простой задач
). Ну нет никаких особых нестандартных требований. Вроде делали-переделали этих СУБД как собак нерезаных. S>Но нет же — пишут с нуля, причем дело не в десятках процентов выигрыша а в порядках. S>По идее должно быть так — создать таблицу, внести в таблицу пакетом (пусть BULK INSERT), создать индекс. Все! Оно должно само суметь отсортировать быстро — для этого и делаются СУБД, чтобы не писать каждый раз с нуля. S>Насоздавали их разных видов — и встраиваемые и кластерные и какие хотите вам.
Так сделай, покажи как надо. Ну чтобы честно было — сразу 100гб файл. Когда отсортируется — возвращайся.
S>Но нет же! Делали делали — и ничего не сделали. Все нужно писать в нуля руками. Спорят сейчас в комментах где взять b-tree на C#, чтобы в памяти
Ты занимаешься тем же самым, разве нет?
Re[2]: Почему не смогли применить готовое решение для простой задач
Здравствуйте, scf, Вы писали:
scf>Здравствуйте, Shmj, Вы писали:
S>>Но нет же! Делали делали — и ничего не сделали. Все нужно писать в нуля руками. Спорят сейчас в комментах где взять b-tree на C#, чтобы в памяти
scf>Действительно, было бы интересно заценить производительность решения, которое читало бы файл с диска, форматировало под требования sort (линуксовая утилита), пайпом отправляло в sort, форматировало обратно и сохраняло в целевой файл.
Пайпы в винде медленные, увы.
Re: Почему не смогли применить готовое решение для простой задач
). Ну нет никаких особых нестандартных требований. Вроде делали-переделали этих СУБД как собак нерезаных.
Потому что код не имеет смысла вне сценариев. И реальный код пишется не абстрактно, а под конкретные сценарии. И оптимизируется под них. И если ты потом используешь другой сценарий, на который не рассчитывали, то высока вероятность проблем, и с перфомансом, и с юзабилити.
В данном случае СУБД никто не проектирует исходя из одноразовых батч-сценариев. Поэтому такой результат.
... << RSDN@Home 1.3.17 alpha 5 rev. 62>>
Re: Почему не смогли применить готовое решение для простой задач
Побуду немного капитаном О. Во-первых, руками делают, чтобы научиться решать такой класс задач, без СУБД. Во-вторых, СУБД не всегда можно применить, и не всегда это оправдано. Например, тебе приносят хард на 8 Тб, забитый входным файлом под завязку. И второй, пустой, на который нужно записать результат. Давай, сортируй. СУБД в пролете.
В школе до сих пор учат и устному счету, и в уме, и на бумажке, хотя калькуляторы есть любых видов. Догадываешься, почему?
Re[2]: Почему не смогли применить готовое решение для простой задач
Здравствуйте, scf, Вы писали:
scf>Действительно, было бы интересно заценить производительность решения, которое читало бы файл с диска, форматировало под требования sort (линуксовая утилита), пайпом отправляло в sort, форматировало обратно и сохраняло в целевой файл.
А эта sort разве не 100% в памяти работает?
Re[2]: Почему не смогли применить готовое решение для простой задач
Здравствуйте, gandjustas, Вы писали:
S>>Но нет же! Делали делали — и ничего не сделали. Все нужно писать в нуля руками. Спорят сейчас в комментах где взять b-tree на C#, чтобы в памяти G>Ты занимаешься тем же самым, разве нет?
Критика направлена не на конкретные решения — а на само современное IT и его состояние.
Re[2]: Почему не смогли применить готовое решение для простой задач
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Потому что код не имеет смысла вне сценариев. И реальный код пишется не абстрактно, а под конкретные сценарии. И оптимизируется под них. И если ты потом используешь другой сценарий, на который не рассчитывали, то высока вероятность проблем, и с перфомансом, и с юзабилити. НС>В данном случае СУБД никто не проектирует исходя из одноразовых батч-сценариев. Поэтому такой результат.
А что тут за "другой сценарий" — просто отсортировать данные по строке и числу? То что данных 100 Гб — разве СУБД не для того и созданы, чтобы работать с большим количеством данных?
Re[2]: Почему не смогли применить готовое решение для просто
Здравствуйте, wildwind, Вы писали:
W>Побуду немного капитаном О. Во-первых, руками делают, чтобы научиться решать такой класс задач, без СУБД.
Это могло бы быть оправданием — типа можно легко решить с помощью СУБД, но просто нужно проверить как вы ту же задачу решите врукопашную. Но нет — СУБД не помогают решить это задачу — вот в чем беда
Т.з. не запрещало применить СУБД, особенно встраиваемую. Но это ничем не поможет — вот в чем печаль.
W>Во-вторых, СУБД не всегда можно применить, и не всегда это оправдано.
А в чем особенность данного случая — индекс по двум полям?
). Ну нет никаких особых нестандартных требований. Вроде делали-переделали этих СУБД как собак нерезаных. S>Но нет же — пишут с нуля, причем дело не в десятках процентов выигрыша а в порядках.
Потому что это было тестовое задание.
S>По идее должно быть так — создать таблицу, внести в таблицу пакетом (пусть BULK INSERT), создать индекс. Все! Оно должно само суметь отсортировать быстро — для этого и делаются СУБД, чтобы не писать каждый раз с нуля.
В реальности для решения таких задач будут применять не СУБД, а скорее map-reduce, типа spark (java) или dask (python).
Best regards, Буравчик
Re[3]: Почему не смогли применить готовое решение для просто
Здравствуйте, Shmj, Вы писали:
S>А в чем особенность данного случая — индекс по двум полям?
Думаю, в этом:
>Важный момент, файл может быть очень большой.
Решение с помощью СУБД будет проигрывать по времени, и возможно, даже упадет из-за нехватки места под индекс.
Думаю, это сделали специально, чтобы отсечь такие решения и заставить поработать мозгами.
). Ну нет никаких особых нестандартных требований. Вроде делали-переделали этих СУБД как собак нерезаных. S>>Но нет же — пишут с нуля, причем дело не в десятках процентов выигрыша а в порядках.
Б>Потому что это было тестовое задание.
Там не было условия — не применять готовых решений. Скорее наоборот — умение применить решения — это большой плюс. Бросаться сразу писать все с нуля — расточительно.
S>>По идее должно быть так — создать таблицу, внести в таблицу пакетом (пусть BULK INSERT), создать индекс. Все! Оно должно само суметь отсортировать быстро — для этого и делаются СУБД, чтобы не писать каждый раз с нуля.
Б>В реальности для решения таких задач будут применять не СУБД, а скорее map-reduce, типа spark (java) или dask (python).
Там .Net был.
Интересно было бы посмотреть именно на промышленное решение данной задачи, а не на студенчески-самопальное. И сравнить скорость работы/потребление памяти. ПО памяти вроде как сошлись — использовать 2-3 Гб.
Для .Net, похоже, готовых решений просто нет. Ну и для сравнения на Java — spark — какую скорость обеспечит. В комментах предлагали решение, однако сам написавший не понимал как оно работает, сортирует ли целиком в памяти или нет.
Здравствуйте, Shmj, Вы писали:
Б>>В реальности для решения таких задач будут применять не СУБД, а скорее map-reduce, типа spark (java) или dask (python).
S>Там .Net был.
.NET for Apache® Spark™
A free, open-source, and cross-platform big data analytics framework
Здравствуйте, Shmj, Вы писали:
S>А что тут за "другой сценарий" — просто отсортировать данные по строке и числу? То что данных 100 Гб — разве СУБД не для того и созданы, чтобы работать с большим количеством данных?
СУБД созданы для сценария, в котором очень большой объем хранения, хранение длительное, а вот процент обновления данных невелик. Кроме того во взрослых БД подразумевается параллельный доступ и необходимость ACID. В этих условиях индексы очень выгодны.
А в тестовом задании сценарий кардинально другой — хранить нужно только на время обработки, обновляется 100% за короткий промежуток времени, и доступ строго монопольный. Если уж искать готовые решения, то смотреть надо в сторону каких нибудь NoSQL движков, заточенных под такое.
Только, опять же, это все имеет смысл когда мы говорим о реальных задачах с кучей дополнительных требований. А абстрактно, в рамках тестового задания, все это лишено смысла, потому что цель — понять твои реальные навыки и умения, а не решить задачу сортировки.
... << RSDN@Home 1.3.17 alpha 5 rev. 62>>
Re[3]: Почему не смогли применить готовое решение для просто
Здравствуйте, Shmj, Вы писали:
S>Здравствуйте, gandjustas, Вы писали:
S>>>Но нет же! Делали делали — и ничего не сделали. Все нужно писать в нуля руками. Спорят сейчас в комментах где взять b-tree на C#, чтобы в памяти G>>Ты занимаешься тем же самым, разве нет? S>Критика направлена не на конкретные решения — а на само современное IT и его состояние.
Есть вероятность что ты просто не понимаешь о чем пишешь. Внезапно задача сортировки 100гб файла за разумное время оказалась сложной.
Сложность её не в том, что нет готового решения. Оно как раз есть, и не одно.
Сложность в том, чтобы решение качественно реализовать, а это требует хорошего знания алгоритмов, стандартных и нестандартных библиотек языка, понимания что такое unicode и чем UTF-8 отличается от ASCII, а также что такое collation.
Еще сложность в том, чтобы таки решить задачу до конца, не в теории, а на практике. Всё-таки 100гб это действительно много и медленное решение не даст тебе дождаться результата.
Поэтому попробуй решить задачу до конца тем способом, который ты считаешь лучшим, а потом возвращайся с критикой.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Только, опять же, это все имеет смысл когда мы говорим о реальных задачах с кучей дополнительных требований. А абстрактно, в рамках тестового задания, все это лишено смысла, потому что цель — понять твои реальные навыки и умения, а не решить задачу сортировки.
Найти готовое решение — это наиболее ценный навык из всех, которые только могут быть. Написано уже миллионы библиотек, фреймворков, решений — мало кто в них ориентируется.
Re[3]: Почему не смогли применить готовое решение для простой задач
