Разработчик CloudBase, высокопроизводительного менеджера данных с открытым исходным кодом, компания Business.com объявила (http://cloudcomputing.sys-con.com/node/757629) о выходе под лицензией GPLv2 релиза CloudBase. Система спроектирована для работы на «обычном железе» и поддерживает распределенную сетевую архитектуру. Основное ее предназначение — это предоставление малобюджетным компаниям высокоэффективных сервисов бизнес анализа.
Построенная с использованием технологии Map-Reduce (http://ru.wikipedia.org/wiki/MapReduce), CloudBase может обрабатывать терабайтные и петабайтные массивы информации, и позволяет составлять запросы к обычным плоским текстовым log-файлам в формате ANSI SQL. Текущая реализация алгоритма Map-Reduce основана на базе наработок проекта Apache Hadoop (http://hadoop.apache.org/core/). CloudBase имеет в своем составе драйвер JDBC, что позволяет выбрать любую подходящую графическую оболочку, позволяющую формировать SQL-запросы.Среди других во...
URL: http://cloudcomputing.sys-con.com/node/757629
Новость: http://www.opennet.me/opennews/art.shtml?num=19041
т.е. это всетаки база данных или фс ?
Дело в том, что фс, со временем, все более и более приобретает черты СУБД. Я думаю, будущее за таким подходом. Или, по крайней мере, за специализированними фс, в которых сразу работаешь как в среде СУБД. Зачем, например, лишняя прослойка из ОС(которая тоже требует ресурсов), если от сервера требуются только функции СУБД?
>Дело в том, что фс, со временем, все более и более приобретает
>черты СУБД. Я думаю, будущее за таким подходом. Или, по крайней
>мере, за специализированними фс, в которых сразу работаешь как в среде
>СУБД. Зачем, например, лишняя прослойка из ОС(которая тоже требует ресурсов), если
>от сервера требуются только функции СУБД?Даже если СУБД не размещает свои данные на собственном разделе, содержимым которого и рулит, - а такая возможность есть в любой приличной СУБД Enterprise-класса - то всё равно накладные расходы из-за наличия "прочей" ОС пренебрежимо малы. Кроме разве что пограничных случаев, когда не используются запросы сложнее "SELECT * FROM table" - но тогда нафиг "навороченная" СУБД?
Если звучит неубедительно, давайте разберём, где возникают накладные расходы:
1. Переключение контекста (юзерспейс <-> ядро <-> юзерспейс в простейшем случае синхронного ввода-вывода);
2. Уровень абстракции ФС в ядре (более тонкий в случае работы с выделенным разделом, но всё равно есть);
3. Занятое другими процесами место в ОЗУ - меньше рабочие буферы/кэши;
4. Съедаемое другими процессами время CPU.Больше пока в голову ничего не пришло:). По первым двум пунктам можно составить тесты: задача не совсем тривиальная, но вполне реальная. Последние два пункта, думаю, очевидно пренебрежимо малы в случае если сервер действительно ориентирован только на работу СУБД; к тому же, к ФС они прямого отношения не имеют. Ну и, соответственно, нужно собрать статистику по тому, сколько времени у СУБД занимает собственно обработка запроса. По моему опыту разница между третьим и первыми двумя числами будет в несколько порядков...
Зато наличие (документированной и поддерживаемой) ОС предоставляет массу преимуществ, как-то:
1. Поддержка широкого спетра оборудования и обеспечение унифицированного интерфейса доступа к оному;
2. Готовые и общие для любых систем, построенных на базе этой ОС, средства для администрирования системы: мониторинг, установка обновлений, внесение изменений в конфигурацию и т.д.Экономия, обусловленная последними двумя пунктами, перекрывает во всех приходящих мне в голову случаях чуть большие аппаратные требования, обусловленные наличием ОС.
высокопроизводительный менеджер данных
"We developed CloudBase to drastically improve the speed and efficiency of transforming terabyte-scale web log files into actionable insights for improving user experience and business results," said Paul Dagum, Chief Scientist and Strategy Officer, R.H. Donnelley Interactive (RHDi).То есть главная и единственная задача - анализ лог-файлов??
А Вы действительно считаете, что это простая задача??? :)
Ну, и если с анализом логов того же апача все и так ясно, то как Вам такая задача:
прочесать _все_ логи со _всех_ серваков и просчитать корреляции событий, а по результатам вычленить, например, вяло текущий скан портов...
Легко. HP Operations Manager ;)
>А Вы действительно считаете, что это простая задача??? :)
>Ну, и если с анализом логов того же апача все и так
>ясно, то как Вам такая задача:
>прочесать _все_ логи со _всех_ серваков и просчитать корреляции событий, а по
>результатам вычленить, например, вяло текущий скан портов...Я не говорил, что это простая или тем более ненужная задача, либо что её не надо автоматизировать:). Просто из новости сложилось ощущение, что это полноценное как-бы-СУБД, стало интересно (в качестве общего развития пока что, а там чем чёрт не шутит). Логи анализировать - задача намного более узкая, согласитесь:).
Новость вышла информативнее оригинальной статьи - там даже ссылки на сайт проекта не было ;) Гугл, конечно, помогает, но, опять-таки, с документацией там туго. Как его завести-то, как логи подкладывать и т.д.?