Здравствуйте, Shmj, Вы писали:
S>Здравствуйте, gandjustas, Вы писали:
S>>>Но нет же! Делали делали — и ничего не сделали. Все нужно писать в нуля руками. Спорят сейчас в комментах где взять b-tree на C#, чтобы в памяти G>>Ты занимаешься тем же самым, разве нет? S>Критика направлена не на конкретные решения — а на само современное IT и его состояние.
Есть вероятность что ты просто не понимаешь о чем пишешь. Внезапно задача сортировки 100гб файла за разумное время оказалась сложной.
Сложность её не в том, что нет готового решения. Оно как раз есть, и не одно.
Сложность в том, чтобы решение качественно реализовать, а это требует хорошего знания алгоритмов, стандартных и нестандартных библиотек языка, понимания что такое unicode и чем UTF-8 отличается от ASCII, а также что такое collation.
Еще сложность в том, чтобы таки решить задачу до конца, не в теории, а на практике. Всё-таки 100гб это действительно много и медленное решение не даст тебе дождаться результата.
Поэтому попробуй решить задачу до конца тем способом, который ты считаешь лучшим, а потом возвращайся с критикой.
Здравствуйте, Shmj, Вы писали:
S>А что тут за "другой сценарий" — просто отсортировать данные по строке и числу? То что данных 100 Гб — разве СУБД не для того и созданы, чтобы работать с большим количеством данных?
СУБД созданы для сценария, в котором очень большой объем хранения, хранение длительное, а вот процент обновления данных невелик. Кроме того во взрослых БД подразумевается параллельный доступ и необходимость ACID. В этих условиях индексы очень выгодны.
А в тестовом задании сценарий кардинально другой — хранить нужно только на время обработки, обновляется 100% за короткий промежуток времени, и доступ строго монопольный. Если уж искать готовые решения, то смотреть надо в сторону каких нибудь NoSQL движков, заточенных под такое.
Только, опять же, это все имеет смысл когда мы говорим о реальных задачах с кучей дополнительных требований. А абстрактно, в рамках тестового задания, все это лишено смысла, потому что цель — понять твои реальные навыки и умения, а не решить задачу сортировки.
... << RSDN@Home 1.3.17 alpha 5 rev. 62>>
Re: Почему не смогли применить готовое решение для простой задач
). Ну нет никаких особых нестандартных требований. Вроде делали-переделали этих СУБД как собак нерезаных. S>Но нет же — пишут с нуля, причем дело не в десятках процентов выигрыша а в порядках.
Потому что это было тестовое задание.
S>По идее должно быть так — создать таблицу, внести в таблицу пакетом (пусть BULK INSERT), создать индекс. Все! Оно должно само суметь отсортировать быстро — для этого и делаются СУБД, чтобы не писать каждый раз с нуля.
В реальности для решения таких задач будут применять не СУБД, а скорее map-reduce, типа spark (java) или dask (python).
Best regards, Буравчик
Re: Почему не смогли применить готовое решение для простой задач
Здравствуйте, Shmj, Вы писали:
S>Но нет же! Делали делали — и ничего не сделали. Все нужно писать в нуля руками. Спорят сейчас в комментах где взять b-tree на C#, чтобы в памяти
СУБД это универсальная хрень. За универсальность нужно платить, например доп потреблением памяти, меньшим быстродействием, большей сложностью. Потому периодически возникает ситуации, когда обработку данных нужно делать быстрее чем это позволяет СУБД со всеми индексами и т.д.
И в результате хреначишь и сам перпаковываешь данные, чтобы они и занимали места в памяти как можно меньше, и сам хреначишь всякие индексы, и сам думаешь как это распараллелить на кластере. Собственно именно сейчас такой хренью и занимаюсь — имеется жесть какая легаси бизнес логика, и через нее нужно прогнать вообще все данные, если делать стандартными средствами то считаться будет год, нагрузив по максимуму все сервера.
Re: Почему не смогли применить готовое решение для простой задач
). Ну нет никаких особых нестандартных требований. Вроде делали-переделали этих СУБД как собак нерезаных.
Потому что код не имеет смысла вне сценариев. И реальный код пишется не абстрактно, а под конкретные сценарии. И оптимизируется под них. И если ты потом используешь другой сценарий, на который не рассчитывали, то высока вероятность проблем, и с перфомансом, и с юзабилити.
В данном случае СУБД никто не проектирует исходя из одноразовых батч-сценариев. Поэтому такой результат.
... << RSDN@Home 1.3.17 alpha 5 rev. 62>>
Re[3]: Почему не смогли применить готовое решение для просто
Здравствуйте, Shmj, Вы писали:
S>А в чем особенность данного случая — индекс по двум полям?
Индекс гарантированно полезен если ты один раз его пишешь, а потом много раз читаешь. А вот если ты читаешь его тоже один раз — тут могут быть всякие неожиданности.
... << RSDN@Home 1.3.17 alpha 5 rev. 62>>
Re[3]: Почему не смогли применить готовое решение для простой задач
Здравствуйте, Shmj, Вы писали:
НС>>Только, опять же, это все имеет смысл когда мы говорим о реальных задачах с кучей дополнительных требований. А абстрактно, в рамках тестового задания, все это лишено смысла, потому что цель — понять твои реальные навыки и умения, а не решить задачу сортировки. S>Найти готовое решение — это наиболее ценный навык из всех, которые только могут быть.
Для этого есть другие типы интервью, например system design, где тебе дают описание сценариев, упрощенных, но приближенных к боевым. И вот тут от тебя как раз ждут грамотного использования готовых решений. А вот в тестовых заданиях на кодирование и алгоритмы, внезапно, проверяют навыки кодирования и знание алгоритмов, а не навыки архитекта.
... << RSDN@Home 1.3.17 alpha 5 rev. 62>>
Re[6]: Почему не смогли применить готовое решение для просто
S>>Каковы ваши прогнозы — какая скорость будет в сравнении с предложенными вариантами?
НС>В каких условиях? Спарк это не решение для одной машины. Обычно происходит так: где то в дешевом хранилище (s3/azure storage), либо в хранилище другой системы накапливаются первичные данные. Потом нам надо эти данные обработать. Для этого в облаке арендуется на несколько часов/дней кластер из 100500 машин, на котором разворачивается спарк. Потом все это быстро через кластер прогоняется, результат сохраняется и кластер релизится. НС>Говорить о производительности спарка внутри одной машины бессмысленно.
бессмысленно говорить о том о чем не имеешь представления. я показал скорость и все три строчки решения на спарк на одной машине: http://rsdn.org/forum/job/8348407
). Ну нет никаких особых нестандартных требований. Вроде делали-переделали этих СУБД как собак нерезаных.
Но нет же — пишут с нуля, причем дело не в десятках процентов выигрыша а в порядках.
По идее должно быть так — создать таблицу, внести в таблицу пакетом (пусть BULK INSERT), создать индекс. Все! Оно должно само суметь отсортировать быстро — для этого и делаются СУБД, чтобы не писать каждый раз с нуля.
Насоздавали их разных видов — и встраиваемые и кластерные и какие хотите вам.
Но нет же! Делали делали — и ничего не сделали. Все нужно писать в нуля руками. Спорят сейчас в комментах где взять b-tree на C#, чтобы в памяти
Здравствуйте, 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: Почему не смогли применить готовое решение для простой задач
Побуду немного капитаном О. Во-первых, руками делают, чтобы научиться решать такой класс задач, без СУБД. Во-вторых, СУБД не всегда можно применить, и не всегда это оправдано. Например, тебе приносят хард на 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>Во-вторых, СУБД не всегда можно применить, и не всегда это оправдано.
А в чем особенность данного случая — индекс по двум полям?
Здравствуйте, 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
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Только, опять же, это все имеет смысл когда мы говорим о реальных задачах с кучей дополнительных требований. А абстрактно, в рамках тестового задания, все это лишено смысла, потому что цель — понять твои реальные навыки и умения, а не решить задачу сортировки.
Найти готовое решение — это наиболее ценный навык из всех, которые только могут быть. Написано уже миллионы библиотек, фреймворков, решений — мало кто в них ориентируется.
Re[3]: Почему не смогли применить готовое решение для просто
Здравствуйте, Shmj, Вы писали:
Б>>В реальности для решения таких задач будут применять не СУБД, а скорее map-reduce, типа spark (java) или dask (python). S>Там .Net был.
Здравствуйте, Shmj, Вы писали:
S>Каковы ваши прогнозы — какая скорость будет в сравнении с предложенными вариантами?
В каких условиях? Спарк это не решение для одной машины. Обычно происходит так: где то в дешевом хранилище (s3/azure storage), либо в хранилище другой системы накапливаются первичные данные. Потом нам надо эти данные обработать. Для этого в облаке арендуется на несколько часов/дней кластер из 100500 машин, на котором разворачивается спарк. Потом все это быстро через кластер прогоняется, результат сохраняется и кластер релизится.
Говорить о производительности спарка внутри одной машины бессмысленно.
... << RSDN@Home 1.3.17 alpha 5 rev. 62>>
Re[4]: Почему не смогли применить готовое решение для простой задач
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>СУБД созданы для сценария, в котором очень большой объем хранения, хранение длительное, а вот процент обновления данных невелик.
А как же импорт данных? Он может быть и велик.
НС>Если уж искать готовые решения, то смотреть надо в сторону каких нибудь NoSQL движков, заточенных под такое.
А как смотреть? Опишите сколько времени займет и как искать.
Re[6]: Почему не смогли применить готовое решение для просто
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>В каких условиях? Спарк это не решение для одной машины. Обычно происходит так: где то в дешевом хранилище (s3/azure storage), либо в хранилище другой системы накапливаются первичные данные. Потом нам надо эти данные обработать. Для этого в облаке арендуется на несколько часов/дней кластер из 100500 машин, на котором разворачивается спарк. Потом все это быстро через кластер прогоняется, результат сохраняется и кластер релизится. НС>Говорить о производительности спарка внутри одной машины бессмысленно.
А на одной машине он что работать не может? Поможет ли в решении задачи на одной машине?
Re[6]: Почему не смогли применить готовое решение для простой задач
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Для этого есть другие типы интервью, например system design, где тебе дают описание сценариев, упрощенных, но приближенных к боевым. И вот тут от тебя как раз ждут грамотного использования готовых решений. А вот в тестовых заданиях на кодирование и алгоритмы, внезапно, проверяют навыки кодирования и знание алгоритмов, а не навыки архитекта.
И каким было бы решение для данного сценария?
Re[7]: Почему не смогли применить готовое решение для простой задач
Здравствуйте, Shmj, Вы писали:
НС>>СУБД созданы для сценария, в котором очень большой объем хранения, хранение длительное, а вот процент обновления данных невелик. S>А как же импорт данных? Он может быть и велик.
Это крайне редкая операция, под него никто не оптимизирует всерьез.
НС>>Если уж искать готовые решения, то смотреть надо в сторону каких нибудь NoSQL движков, заточенных под такое. S>А как смотреть?
Головой.
S>Опишите сколько времени займет и как искать.
Бессмысленный вопрос.
... << RSDN@Home 1.3.17 alpha 5 rev. 62>>
Re[5]: Почему не смогли применить готовое решение для просто
Здравствуйте, Shmj, Вы писали:
S>Здравствуйте, vaa, Вы писали:
S>>>Там .Net был. vaa>>
vaa>>.NET for Apache® Spark™
vaa>>A free, open-source, and cross-platform big data analytics framework
S>Каковы ваши прогнозы — какая скорость будет в сравнении с предложенными вариантами?
Запомнил спарк по одной статье, там правда на джава было, но вообщем там был выигрыш примерно как у ракеты и 3-х колесного велосипеда.
именно по скорости. так что флаг в руки. штука отличная. правда дотнет тут не причем. софта такого класса на дотнете так и не видно.
а вот java хоть ее и ругают имеет не меньше нативных решений чем плюсы (наверно, я не углублялся сильно, первое впечатление).
которые в большинстве еще и опенсорс и фри.
☭ ✊ В мире нет ничего, кроме движущейся материи.
Re[3]: Почему не смогли применить готовое решение для простой задач
Здравствуйте, Shmj, Вы писали:
scf>>Действительно, было бы интересно заценить производительность решения, которое читало бы файл с диска, форматировало под требования sort (линуксовая утилита), пайпом отправляло в sort, форматировало обратно и сохраняло в целевой файл.
S>А эта sort разве не 100% в памяти работает?
Не-а.
У меня несколько раз было, что переполнялся /tmp его временными файлами. Приходилось переопределять TMPDIR на что-то толстое.
The God is real, unless declared integer.
Re[4]: Почему не смогли применить готовое решение для просто
Здравствуйте, netch80, Вы писали:
N>Не-а. N>У меня несколько раз было, что переполнялся /tmp его временными файлами. Приходилось переопределять TMPDIR на что-то толстое.
Ну это лишь один из примерно 5 тыс. разных вариантов, как решить задачу. Проверить 5 тыс. вариантов, если уделять каждому по 10 минут — это почти 5 месяцев работы. Может какой-то готовый найдете идеальный — но 5 месяцев на поиски...
По сути мы не решили главного — вопрос нахождения базовых реализаций.
Здравствуйте, Shmj, Вы писали: S>Но нет же! Делали делали — и ничего не сделали. Все нужно писать в нуля руками. Спорят сейчас в комментах где взять b-tree на C#, чтобы в памяти
Здравствуйте, Shmj, Вы писали:
S>Ну это лишь один из примерно 5 тыс. разных вариантов, как решить задачу. Проверить 5 тыс. вариантов, если уделять каждому по 10 минут — это почти 5 месяцев работы.
