| |
| 2.3, SunXE (ok), 18:14, 14/03/2014 [^] [^^] [^^^] [ответить]
| +1 +/– |
 Не знаю как XtreemFS, но glusterfs не умеет следить за оставшимся местом на ноде на которую он кидает файл. Она годится только если у тебя все файлы одного размера, тогда место будет заполняться равномерно.
| | |
|
| 1.5, Аноним (-), 18:57, 14/03/2014 [ответить] [﹢﹢﹢] [ · · · ]
| +8 +/– | |
> Серверная часть XtreemFS .. написана на языке Java. Клиент для работы с XtreemFS написан на С++
где эти люди потеряли логику?
| | |
| |
| 2.13, гость (?), 23:10, 14/03/2014 [^] [^^] [^^^] [ответить]
| –1 +/– |
С++ ибо FUSE на клиенте.
Сервер метаданных на Java - так проще писать сложную логику.
| | |
|
| |
| 2.15, anonymous (??), 23:30, 14/03/2014 [^] [^^] [^^^] [ответить]
| –2 +/– |
А то что hadoop и производные, дефакто стандарт для big data, полностью на java написан, вас не смущает?
| | |
| |
| |
| 4.24, anonymous (??), 02:57, 15/03/2014 [^] [^^] [^^^] [ответить]
| +/– | |
> Теплое и мягкое.
Эм.. hadoop/hdfs - распределенная файловая система, XtreemFS - распределенная файловая система. Не объясните - в чем их идеологические/концептуальные различия..?
| | |
|
| 3.19, Аноним (-), 00:03, 15/03/2014 [^] [^^] [^^^] [ответить]
| +5 +/– | |
Если честно, то оочень смущает. И по производительности, и, особенно, по безопасности этих big data.
| | |
| 3.32, all_glory_to_the_hypnotoad (ok), 13:09, 15/03/2014 [^] [^^] [^^^] [ответить]
| +4 +/– |
 нифига не стандарт, это затычка для нищебро. А там где действительно big data хадуп со своими производными сосёт и люди юзают свои локальные поделки на с/с++ и etc.
| | |
| |
| 4.33, registred_anonymous (ok), 14:18, 15/03/2014 [^] [^^] [^^^] [ответить]
| +5 +/– |
 Охтыж, что только не узнаешь на opennet. Facebook, Yahoo, ebay, adobe - нищеброды. А Oracle, IBM и пол дюжины других известных вендоров делают и продают решения на основе затычки для нищебродов. Наверное, тоже начали ориентироваться на рынок нищебродов.
| | |
| |
| |
| 6.60, тигар (ok), 10:09, 17/03/2014 [^] [^^] [^^^] [ответить]
| +/– |
 > Для тебя новость, что деньги делают всегда на нищебродах?
а че, есть примеры контор где для вот этих вот штук используется не ходуп а что-то свое, на "С/С++" ? там же, помимо этой вот хдфс, как бы и матеметеги over дофига. мапят там, редьюсят, прочей фигней занимаются с данными. реально интересно, есть ли те, у кого столько бабла чтобы написать свой задуп.
| | |
| |
| 7.67, all_glory_to_the_hypnotoad (ok), 22:11, 17/03/2014 [^] [^^] [^^^] [ответить]
| +/– |
математика это уже приложение, а не компонент хранилища и кластерного по. Свои С/C++ реализации всего этого добра есть хотя бы у более-менее вменяемых поисковиков, например google и yandex. Не нужно думать, что hdfs/hadoop это такое замечательное отлаженное решенре, на самом деле там довольно много косяков и много чего нужно долго и нудно допиливать напильником.
| | |
| |
| 8.69, тигар (ok), 22:25, 17/03/2014 [^] [^^] [^^^] [ответить] | +/– | а я и не считаю его готовым к использованию как есть но таки пилить его дешев... текст свёрнут, показать | | |
| |
| |
| 10.74, тигар (ok), 23:35, 17/03/2014 [^] [^^] [^^^] [ответить] | +/– | верно так а аналоги-то тому же ходупу где, не на яве в любом случае, не верится... текст свёрнут, показать | | |
|
|
|
|
|
|
|
|
|
| 1.42, Pilat (ok), 10:52, 16/03/2014 [ответить] [﹢﹢﹢] [ · · · ]
| +2 +/– |
 С страницы http://www.rekby.ru/2013/03/xtreemfs.html :
"Итог - очень медленно работает с большим количеством файлов, например распаковка Joomla занимает около 15 минут в режиме синхронной записи в кластер и 20 минут в режиме асинхронной записи (на локальную файловую систему около 2-3 секунд).
Вход на страницу установки joomla занимает 20-40 секунд и так после каждого щелчка (т.е. после чтения файлы не кэшируются), настроек кэширования данных в этой файловой системе нет.
Доступ к большому файлу так же не очень быстр. Запись архива на 70МБ идет со скоростью 140Кб/сек (настроена репликация на 3 сервера), чтение 4-5 МБ/сек."
| | |
| |
| 2.46, AnonymousRex (ok), 20:40, 16/03/2014 [^] [^^] [^^^] [ответить]
| +/– |
 >[оверквотинг удален]
> "Итог - очень медленно работает с большим количеством файлов, например распаковка Joomla
> занимает около 15 минут в режиме синхронной записи в кластер и
> 20 минут в режиме асинхронной записи (на локальную файловую систему около
> 2-3 секунд).
> Вход на страницу установки joomla занимает 20-40 секунд и так после каждого
> щелчка (т.е. после чтения файлы не кэшируются), настроек кэширования данных в
> этой файловой системе нет.
> Доступ к большому файлу так же не очень быстр. Запись архива на
> 70МБ идет со скоростью 140Кб/сек (настроена репликация на 3 сервера), чтение
> 4-5 МБ/сек."
не удивительно, ведь через fuse
| | |
| |
| 3.49, Аноним (-), 02:01, 17/03/2014 [^] [^^] [^^^] [ответить]
| +/– |
Да-да, тормозить может всё что угодно: сеть, ядро, драйвера, память, fuse, чёрт в ступе сглаз наложил, но только не жаба.
| | |
| |
| 4.50, AnonymousRex (ok), 02:27, 17/03/2014 [^] [^^] [^^^] [ответить]
| +/– |
> Да-да, тормозить может всё что угодно: сеть, ядро, драйвера, память, fuse, чёрт
> в ступе сглаз наложил, но только не жаба.
жаба на сервере метаданных, а тормозят операции I/O, которые работают через fuse и написаны на C++. Я конечно понимаю что вы никогда не видели нормальную имплементацию джавы в нормальных масштабах, но это просто потому что вы вообще никакой имплементации не видели, а не потому что таких имплементаций не бывает
| | |
| |
| 5.52, Аноним (-), 03:58, 17/03/2014 [^] [^^] [^^^] [ответить]
| +/– |
Да-да, конечно-конечно, вы не волнуйтесь, поциент, это всё плюсы и fuse виноваты. У-у проклятые!
| | |
| |
| 6.53, AnonymousRex (ok), 05:03, 17/03/2014 [^] [^^] [^^^] [ответить]
| +/– |
> Да-да, конечно-конечно, вы не волнуйтесь, поциент, это всё плюсы и fuse виноваты.
> У-у проклятые!
то есть ответить нечего, ну я так и думал что имею дело с хомячком, спасибо за подтверждение
| | |
| |
| 7.55, Аноним (-), 05:27, 17/03/2014 [^] [^^] [^^^] [ответить]
| +/– | |
Что ж ты так кипишуешь-то болезный? Да, это всё мы, проклятые хомячки, криво пишем на плюсах, не даём светозарной жабе показать свою мощь. Это мы невовремя запускаем gc и калечим технику. От одного нашего взгляда требования к ресурсам у жаба-программ вырастают впятеро! Это мы тормозим прогресс, отчего вам не дают денег на память и железо. Мы смеем что-то возразить против нужности абстрактного генератора синглтонов фабрик фабрик. Еретики! Запретить!
Истинно говорю вам, придёт день, и адепты самого правоверного языка перепишут всё на нём, и тогда наступит мир, покой и в человецах благорастворение. Покайтесь плюсовики! Плачьте ассемблерщики! Ибо близко воскрешение Сана, а оракл - пророк его!
| | |
| |
| |
| |
| 10.61, тигар (ok), 10:13, 17/03/2014 [^] [^^] [^^^] [ответить] | +/– | зачем ты сам себя пародируешь тебе все правильно сказали, жаба там не при делах ... текст свёрнут, показать | | |
|
|
|
|
|
|
|
| 3.51, Pilat (ok), 03:14, 17/03/2014 [^] [^^] [^^^] [ответить]
| +/– |
Не очень важно почему, главное что к реальному использованию, скорее всего, проект не готов. Разве что он идеально работает на медленных соединениях с частыми обрывами.
| | |
| |
| 4.54, AnonymousRex (ok), 05:06, 17/03/2014 [^] [^^] [^^^] [ответить]
| +/– |
> Не очень важно почему, главное что к реальному использованию, скорее всего, проект
> не готов. Разве что он идеально работает на медленных соединениях с
> частыми обрывами.
не готов, хотя swift, ceph, sheepdog и gluster тоже особой скоростью не отличаются. они собственно говоря и не для того придуманы, тут вся идея в масштабируемости и использовании локальных дисков с кучи хостов. если нужна еще и скорость, то надо поднимать инфраструктуру посерьезнее гигабитной сети, как впрочем и с обычным SAN
| | |
| |
| 5.58, Pilat (ok), 09:05, 17/03/2014 [^] [^^] [^^^] [ответить]
| +/– | |
"Запись архива на 70МБ идет со скоростью 140Кб/сек"
Это неоправданно низкая скорость на любой сети.
| | |
| |
| 6.64, AnonymousRex (ok), 15:52, 17/03/2014 [^] [^^] [^^^] [ответить]
| +/– |
> "Запись архива на 70МБ идет со скоростью 140Кб/сек"
> Это неоправданно низкая скорость на любой сети.
несомненно
| | |
|
|
|
|
|
| |
| |
| 3.76, Аноним (-), 16:31, 19/03/2014 [^] [^^] [^^^] [ответить]
| +/– |
пока в проекте "живо" - лишь бодро-написанный/выглядящий веб-сайт, очень любимого амер. правительственными/разведываетльными огранизациями, облика/функциональности.
| | |
|
|
| 1.47, anonimov (?), 21:33, 16/03/2014 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Подскажите, а на чем лучше строить отказоустойчивый бекенд? Скажем, есть 4 сервера с веб-контентом, которые лоадбалансятся. Контент,в основном,мелкие файлы.
Чем лучше синхронизировать такой контент?Gluster?NFS?
| | |
| |
| |
| 3.62, тигар (ok), 10:16, 17/03/2014 [^] [^^] [^^^] [ответить]
| +/– | |
> если контент статический, то лучше rsynс'ать.
как это будет выглядеть при, скажем, 2млн файлов на каждой машине ?
решение с БД и выгрузкой в статику (например по крону) и то выглядит сильно менее корявым.
| | |
| |
| 4.68, all_glory_to_the_hypnotoad (ok), 22:16, 17/03/2014 [^] [^^] [^^^] [ответить]
| +/– |
нужно смотреть по факту, может быть хреново. Вариант с выгрузкой из БД очень даже хорош (~ строим очередь обновлений + на каждой машине докатываем новые файлы), но его же кодить нужно, хоть и не много.
| | |
| |
| 5.70, тигар (ok), 22:28, 17/03/2014 [^] [^^] [^^^] [ответить]
| +/– |
> нужно смотреть по факту, может быть хреново. Вариант с выгрузкой из БД
> очень даже хорош (~ строим очередь обновлений + на каждой машине
> докатываем новые файлы), но его же кодить нужно, хоть и не
> много.
да банальная проверка тем же ngx на наличие файла + обработчик 404 ошибки, который сходит в БД и покладет картинку куда нужно. это даже лучше чем cron, к примеру
| | |
| |
| |
| 7.73, тигар (ok), 23:30, 17/03/2014 [^] [^^] [^^^] [ответить]
| +/– |
> Это уже хуже, будут задержки и из-за внезапного наплыва пользователей может быть
> временами очень плохо.
ну значит AI должен быть чуть лучше, в зав-ти от фазы луны генерить статику и отдавать ее, либо ходить за ней в бд.
в прошлом комменте я затупил про 404, есть же try_files :)
| | |
|
|
|
|
|
| 2.63, Аноним (-), 11:11, 17/03/2014 [^] [^^] [^^^] [ответить]
| +/– |
Gluster генерирует очнь много вспомогательно траффика. На 100 Mb трафика gluster снегерит ещё 200 служебного
| | |
| 2.66, anonymous (??), 20:49, 17/03/2014 [^] [^^] [^^^] [ответить]
| +/– |
Если это чистый вэб, то лучше использовать объектное хранилище (s3 подобное). Вариантов тут много:
dogsheep, ceph, яндекс пиарит свой Elliptics, swift (его многие считают нестабильным).
Если очень нужен posix, то наверное стоит посмотреть на moosefs.
На glaster на продакшене многие ругаются.
| | |
|
|
