BerkeleyDb был всегда бесплатен. А на нем кажется весь DNS стоял.

boobyДа, "большие данные" бессмысленны, если нет алгоритмов, способных их обрабатывать за приемлемое время.

Я bigdata считаю изначально безсмысленным по своей сути. Это технологическая "отрыжка" нашего времени.
Появились дешевые хосты и хранилища - и сама предметная область обозначилась.

Ее нельзя было создать рисуя палочкой на песке или складывая камешки как делал Архимед.
Современное It - это на 99% просто приспосабливание имеющегося железа и сетей и CPU-можностей
под задачи. А когда задач нет - но есть железо - задачи придумываются.

Зачем скажите хранить данные internet of things? Построил по ним OLAP-кубы и грохнул исходные файлы.
Зачем хранить логи log4j вашего драгоценного приложения за 25 лет? Соберите статистические цифры.
Нарисуте графики. Грепните критические ерроры и все. И снова не нужна никакая биг-дата.

Andy_OLAPПроще хранить, чем удалить и потом в бэкапах искать. Собственно, сами bigdata - это и данные, и в каком-то смысле бэкап, и расположение информации на N серверах в M копиях (отказоустойчиво) - и все в одной упаковке.
У меня есть своя теория. О том что количество информации нужной человеку - величина постоянная.
А современные инфо-технологии - это просто некий белый шум. Они не сделали человека умнее.
Информированнее - да. Но что толку с этого. Он разучился сам делать свои выводы. Мозг разжижается.

Вобщем где-то у Савельева было на эту тему. И про строительство ИИ тоже.

Eugene NewОтсюда вывод - эти данные не для человека.

Мне все таки хотелось бы какой-нибудь примерчик увидеть, когда выкачивание всего на app-server и его там обработка выгоднее чем sql-запрос с последующей обработкой. Ну или о чем там мне говорят, т. к. я их до конца не понял, потому и прошу примерчик.

Я сходу сделаю сразу замечание. Ты нарисовал неправильный юзкейс. С бигдатой так не работают.
Ее (бигдату) собсно нельзя вообще сравнивать с DBMS. Как я уже где-то писал - это системы разного
класса по CAP.

Как грузовик с лимузином.

azsxавторВобщем где-то у Савельева было на эту тему. И про строительство ИИ тоже.
Скажите, пожалуйста, о чём это? Есть какая-то книга или конкретная статья?
Савельев - это не из It. Это бологии и института морфологии человека.

Насчет книг не скажу. Я в основном подписан на его видео-блоги в youtube.

Eugene Newmayton,
так я вообще не про бигдату. Слово большие было употреблено не в этом смысле.
Хотелось бы увидеть как работать без sql с теми объемами, с которыми прекрасно справляется sql, причем существенно быстрее.
Ну ... бери библиотечку наподобие Berkeley. Выбирай архитектуру хранения.
Загружай туда из CSV или из другого формата. Добавляй индексы.
И работай на сях. Дергай методы.

Вот как-то так.

Ну или вместо Berkeley можешь взять гугловый LevelDb или фейсбучный RocksDb.

Andy_OLAPmaytonПостроил по ним OLAP-кубы и грохнул исходные файлы.

А потом появляется новый источник и новое, достаточно простое измерение, которое можно "прикрутить" и к старым данным. И начинается геморой на ровном месте - достать место под старые данные, выгруженные из куба, затем вогнать в куб обратно вместе с новыми данными. И обычно запрос под место - это процедура, а куб нужен таки прямо сейчас. В том-то и весь цимес!

А про квалификацию тех, кто делает OLAP кубы - вот начали Вы данные всерьез смотреть, понравилось, грохнули исходные файлы, затем постоянный пользователь куба Вам говорит, что сделано неправильно, куб нужно переделать здесь, здесь и вот здесь - а исходных файлов уже нет.

Проще хранить, чем удалить и потом в бэкапах искать. Собственно, сами bigdata - это и данные, и в каком-то смысле бэкап, и расположение информации на N серверах в M копиях (отказоустойчиво) - и все в одной упаковке.
Замечание справедливое.

Но давайте предположим что owner информации - это вы. И никто вас не будет упрекать в том что вы грохнули свою
информацию. Если она не ваша - то грохать ничего не надо. А надо действовать согласно стратегии бэкапов
которая прината у вас в конторе. Старше оперативного срока - в архивный tablespace.
Старше - трех лет в external tables. Старше 10 лет - на стриммер. Разумеется это я все
придумал в качестве примера.

И еще в теме не хватает деталей о природе самой информации. Если это какая-то юридическая
и финансовая активность то наверное ничего удалять не надо.

Если это данные научных измерений (погода) то здесь я-бы предложил просто какую-то сжатую
схему хранения при которой у нас не будет избыточности и любой запрос может быть удовлетворен
с нужной точностью.