Исходное сообщение
"Выпуск кластерной ФС Lustre 2.8" Отправлено Stax, 29-Мрт-16 15:10
Эти слова бесконечно далеки от конечного решения. Во-первых, с Cassandra связываться не будем - под такую нагрузку внедрять подобный NoSQL можно только вместе с людьми, которые будут его поддерживать. Mongo тут вообще не в тему - она не соответствует исходным требованиям, если их внимательно прочесть. Есть Hadoop и Hbase, но в голом виде их использовать также нельзя. Во-первых хранить много мелких объектов раздельно как "файлы" на Hadoop нельзя, он для этого не предназначен. Нужно их объединять группами в архивы и прочее, там свои заморочки. Т.к. файлы должны размазываться равномерно, архивы нужно постоянно менять, могут выплыть заморочки. Мы плотно работаем с HBase и хорошо представляем, сколько неприятностей кроется, если идти по этому пути :) Решаемых, но время, время... В HBase класть так просто тоже не выйдет. Слишком неравномерный размер объектов, слишком большой разброс. См. https://www.quora.com/Is-HBase-appropriate-for-indexed-blob-... и еще https://issues.apache.org/jira/browse/HBASE-11339 Hadoop/Hbase это такие штуки, которые могут начать себя КРАЙНЕ плохо вести, если с ними делать неправильные вещи. Поэтому делать что попало не стоит. Вообще какая-то прослойка над Hadoop - это вероятное решение, но пока неясно, какая именно и что проще внедрить. Решения с POSIX layer, при всем оверхеде, которые они несут, привлекательны тем, что строго разделяют проблемы самого хранения от проблем его использования. Т.к. с последним уже все отлажено, все проблемы, которые могут возникнуть - проблемы самого хранилища.