Комментарии 35
а будет поддержка s3 api?
Интересно, кому может понадобится использовать подобное специфическое хранилище? Разве что большим компаниям, но у них и так уже есть свои аналоги.
Расскажите, пожалуйста, чем Elliptics+Rift лучше/хуже, чем LeoFS.
А расскажите, пожалуйста, что такое LeoFS. Вы им пользовались?
Я им не пользовался (как и эллиптиксом). Но в публичные описания архитектур (DHT, свой способ хранения чанков) весьма схожи.
При том, что слабые места кластера — диск и сеть, хотелось бы узнать, почему для реализации использованы столь многословные языки как C и C++.
При том, что слабые места кластера — диск и сеть, хотелось бы узнать, почему для реализации использованы столь многословные языки как C и C++.
Когда данных становится действительно много, то слабыми местами становятся так же оперативная память и процессор, как раз на таких случаях C++ и позволяет получить серьезный выигрыш по сравнению с Erlang (если уж сравнивать в контексте LeoFS).
Следующим пунктом является распространенность языка, найти толкового C или C++ разработчика в разы проще (но все равно невероятно трудно), чем аналогичного специалиста по Erlang.
Следующим пунктом является распространенность языка, найти толкового C или C++ разработчика в разы проще (но все равно невероятно трудно), чем аналогичного специалиста по Erlang.
Ну, то есть, «нам сказали, что эрланг жрет много памяти и процессора, поэтому мы найдем 10 крутых плюсовиков, а не двух эрлангистов». Ок.
А ява вам чем не угодила с ее, например, уже давно написанным и работающим HDFS?
С++, значит, многословный, а Java не многословная. Ну-ну :)
Java при той же многословности и схожей производительности дает еще и защиту от сегфолтов. Ну, не считая того, что под нее уже три горы релевантных библиотек написано.
Как жаль, что вы в Яндексе не руководитель отдела, вы бы их научили сразу, на чем надо писать!
Вы еще забыли предложить Go и Rust, подсказываю :)
Вы еще забыли предложить Go и Rust, подсказываю :)
GC, чёртов GC испортит вам жизнь…
Segfault не страшен, Ну будет кора и что? Потом это починят, когда разбереут. Упавшее приложение естественно поднимут автоматом. А вот историй про то, что" Java течет и я ее перезапущу, а если опять потекла, то в cron поставлю" — хоть отбавляй. И Outofmemory никто не отменял, да
Segfault не страшен, Ну будет кора и что? Потом это починят, когда разбереут. Упавшее приложение естественно поднимут автоматом. А вот историй про то, что" Java течет и я ее перезапущу, а если опять потекла, то в cron поставлю" — хоть отбавляй. И Outofmemory никто не отменял, да
> найти толкового C или C++ разработчика в разы проще, чем по Erlang
Это либо злонамеренная ложь, либо нехватка информации. Надеюсь, что второе.
Что касается скорости, то у меня видеостриминговый сервер на эрланге без проблем раскидывает по 10 гигабит данных в сеть с чтением и перепаковкой. Процессорной работы НАМНОГО больше, чем в сторадже.
Поэтому ваша гипотеза о том, что VM эрланга не хватит по скорости для перекидывания данных в сторадже совершенно неверна, потому что основана на ваших домыслах, а не на фактах и проверках.
Это либо злонамеренная ложь, либо нехватка информации. Надеюсь, что второе.
Что касается скорости, то у меня видеостриминговый сервер на эрланге без проблем раскидывает по 10 гигабит данных в сеть с чтением и перепаковкой. Процессорной работы НАМНОГО больше, чем в сторадже.
Поэтому ваша гипотеза о том, что VM эрланга не хватит по скорости для перекидывания данных в сторадже совершенно неверна, потому что основана на ваших домыслах, а не на фактах и проверках.
> найти толкового C или C++ разработчика в разы проще, чем по Erlang
Это либо злонамеренная ложь, либо нехватка информации. Надеюсь, что второе.
Зашел на hh.ru: C++ — 615 вакансий, Erlang — 14 вакансий, кажется, что это дает уже достаточное представление о рынках труда по этим двум языкам.
Что касается скорости, то у меня видеостриминговый сервер на эрланге без проблем раскидывает по 10 гигабит данных в сеть с чтением и перепаковкой. Процессорной работы НАМНОГО больше, чем в сторадже.
Чтобы раздавать большие видео-файлы и нагрузить ими 10-гигабитный канал много усилий не надо (даже при условии, что происходит конвертация видео-потока в другой формат, чем занимается, опять же, скорее всего не Erlang, а модуль на C/C++ с использованием какого-нибудь ffmpeg/gstreamer/libav/etc) :)
Гораздо сложнее с процессорной точки зрения нагрузить эти же 10-100 гигабит с одной машины маленькими 1-2-килобайтными файлами, при условии, что на машине этих файлов десятки миллиардов. Вот на таких задачах я уже начинаю сильно сомневаться в конкурентоспособности Erlang.
> кажется, что это дает уже
Вы продолжаете рассуждать о вещах, которые вы не знаете. Вы лишь предполагаете, но не знаете.
Я знаю и знаю, что erlang разработчик существенно дешевле (в силу высшей производительности) и проще ищется.
> раздавать большие видео-файлы и нагрузить ими 10-гигабитный канал много усилий не надо… чем занимается, опять же, скорее всего не Erlang, а модуль на C/C++ с
и вы опять сели в лужу со своим незнанием =)
Видеостриминг — это когда большой файл на лету парсится, читается, из него выгружаются нужные куски данных, перепаковываются и отправляются с перепаковкой до последнего байта. Причем никаких модулей на C у нас нет, как бы вам это ни фантазировалось.
Такая мелкая халява, как раздача целого файла с диска по сравнению с этим — это детский лепет. Это я опять же, в отличие от вас, оцениваю по своему опыту, а не по предположениям. Дисковый сегментный кеш у нас потребляет существенно меньше ресурсов.
Так что ваша гипотеза о том, что софт на Erlang упрется в процессор на файловом сторадже пока что не имеет под собой никаких оснований кроме сильной веры в волшебную силу C++.
Вы продолжаете рассуждать о вещах, которые вы не знаете. Вы лишь предполагаете, но не знаете.
Я знаю и знаю, что erlang разработчик существенно дешевле (в силу высшей производительности) и проще ищется.
> раздавать большие видео-файлы и нагрузить ими 10-гигабитный канал много усилий не надо… чем занимается, опять же, скорее всего не Erlang, а модуль на C/C++ с
и вы опять сели в лужу со своим незнанием =)
Видеостриминг — это когда большой файл на лету парсится, читается, из него выгружаются нужные куски данных, перепаковываются и отправляются с перепаковкой до последнего байта. Причем никаких модулей на C у нас нет, как бы вам это ни фантазировалось.
Такая мелкая халява, как раздача целого файла с диска по сравнению с этим — это детский лепет. Это я опять же, в отличие от вас, оцениваю по своему опыту, а не по предположениям. Дисковый сегментный кеш у нас потребляет существенно меньше ресурсов.
Так что ваша гипотеза о том, что софт на Erlang упрется в процессор на файловом сторадже пока что не имеет под собой никаких оснований кроме сильной веры в волшебную силу C++.
Я знаю и знаю, что erlang разработчик существенно дешевле (в силу высшей производительности) и проще ищется.
Я свои доказательства привел, просьба вам также отойти от голословных обвинений и начать выражать свои мысли чуть более разумно.
Это я опять же, в отличие от вас, оцениваю по своему опыту, а не по предположениям.
Возможно, но вы пропустили пункт про десятки миллиардов файлов, превращающий задачу в гораздо более требовательную к cpu/io ресурсам. Взять один конкретный файл и каким угодно образом его нарезать сильно проще, чем найти тот единственный файл из десятков миллиардов и отдать его наружу. В любом случае, с вашей стороны все еще нет абсолютно ничего, кроме голословных предположений и обвинений в некомпетентности.
Аналогично не пользовался ни тем ни тем. Посмотрел документацию по LeoFS, понравилось:
* что есть поддержка S3 API;
не очень понравилось:
* просят (рекомендуют) держать на XFS,
* не понятно на счет балансировки и перераспределения на ближайшую ноду;
В остальном надо читать внимательней, ну и тестировать
Касательно Elliptics, хотелось бы поддержку S3 API, понравилось:
* можно использовать Nginx для отдачи + пересылка на ближайшую ноду,
* читабельные простые конфиги
* есть возможность формирования кэш ноды на быстрых носителях.
Ну и все же Elliptics тесно интегрируется с Cocaine, что тоже может быть полезно.
Собственно это все субъективно и что пришло в голову из прочтения документации по обоим продуктам.
* что есть поддержка S3 API;
не очень понравилось:
* просят (рекомендуют) держать на XFS,
* не понятно на счет балансировки и перераспределения на ближайшую ноду;
В остальном надо читать внимательней, ну и тестировать
Касательно Elliptics, хотелось бы поддержку S3 API, понравилось:
* можно использовать Nginx для отдачи + пересылка на ближайшую ноду,
* читабельные простые конфиги
* есть возможность формирования кэш ноды на быстрых носителях.
Ну и все же Elliptics тесно интегрируется с Cocaine, что тоже может быть полезно.
Собственно это все субъективно и что пришло в голову из прочтения документации по обоим продуктам.
Дополню, судя по слайдам, у LeoFS еще и средства для мониторинга и управления есть, это плюс.
А какой системой по теореме CAP является Elliptics? Насколько я понял, это eventual consistency, т.е. AP. А есть что-то вроде Mongo'вского WriteConcern.MAJORITY?
Да, все верно, Elliptics — это eventual consistency.
Есть более клевая штука, в Elliptics пользователь (администратор HTTP proxy, например) сам выбирает необходимый уровень надежности и может как писать с кворумом, требуя определенный процент успешных записей, так и писать без оглядки на количество успешно-записанных копий.
А есть что-то вроде Mongo'вского WriteConcern.MAJORITY?
Есть более клевая штука, в Elliptics пользователь (администратор HTTP proxy, например) сам выбирает необходимый уровень надежности и может как писать с кворумом, требуя определенный процент успешных записей, так и писать без оглядки на количество успешно-записанных копий.
А я по статье не очень понял, nginx-модуль можно без rift использовать?
Да, модуль всего-лишь предоставляет low-level доступ к данным в файловой системе в довольно общей форме, поэтому может использоваться не только с rift'ом.
а загружать объекты через nginx-модуль можно? или только раздача? если нет, в планах можно будет?
Судя по документации и примерам, то работа идет не через nginx, а напрямую с Rift-ом. При указании ему порта для на котором сидит nginx, при запросе на загрузку он дает 302ой редирект на NGINX и там уже начинается загрузка. Если смотреть на пример с музыкальным файлом. Поправьте если не прав.
Ну и в принципе никто не мешает настроить проксирование Nginx-ом запросов, это лишь вопрос правильно конфигурации ИМХО.
Ну и в принципе никто не мешает настроить проксирование Nginx-ом запросов, это лишь вопрос правильно конфигурации ИМХО.
НЛО прилетело и опубликовало эту надпись здесь
Я хорошо помню разговор с одним из авторов эллиптикса: если у тебя меньше чем три стойки в двух датацентрах, то отойди в сторону, мальчик, у нас взрослый продукт, не для тебя.
Вот я как ни посмотрю на эллиптикс, так у меня и не пропадает ощущение, что без трех стоек он не нужен, потому что начать им пользоваться непонятно как: безумно сложен в настройке.
Только вот им вообще пользоваться мне всё таки непонятно. Если нет поддержки S3 API, то как можно его проверить? Надо сразу затачиваться на неизвестную софтину с неизвестным уровнем поддержки и развития?
Вот я как ни посмотрю на эллиптикс, так у меня и не пропадает ощущение, что без трех стоек он не нужен, потому что начать им пользоваться непонятно как: безумно сложен в настройке.
Только вот им вообще пользоваться мне всё таки непонятно. Если нет поддержки S3 API, то как можно его проверить? Надо сразу затачиваться на неизвестную софтину с неизвестным уровнем поддержки и развития?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Elliptics от Яндекса. Как с его помощью создать своё отказоустойчивое хранилище