Мне нужна именно аналитика на полу-структурированных данных — если бы у меня все ложилось хорошо в реляционку, я бы монгу ни за что не поставил бы.
Не считаю код ужас-ужас, нормальный код. И совершенно нормальная схема работы паралельной СУБД — генерим один мастер-план запроса, затем раздаем его на кластер, каждый работает отдельно, выполняя физические операторы. И выполнять физические операторы — обычное дело, выигрыш от байткода мизерный, особенно когда можно потерять 20-100x производительности от плохой оптимизации запроса.
По тем же бенчам видно — Shark часто забивает Impala. При этом частенько всех мочит Амазон со своей ParAxel, который в свою очередь проигрывает устоявшимся решениям вроде Vertica или Neteeza (кстати Neteeza пошла гораздо дальше байткода и зашила кое-что в железо, только вот по слухам начинает все это чистить оттуда).
Про позиционирование: в классе СУБД для слабо-структурированных данных пока рулят XML-СУБД. но с ними замучаешься работать и бесплатные не особенно качественные. AsterixDB такую-же мощь принесет в мир JSON, но не сразу, естественно. Шардинг они уже сделали, осталось сделать репликацию, что не так долго должно занять.
По последнему вопросу — что-то вроде SQL dirty read.
Ну я бы не стал делать настолько далеко-идущие выводы, на основе одной функции SQL_MAX — она написана для обработки разнородных данных, их действительно надо проверять и промоутить, ничего не поделаешь. Ничего не стоит сделать оптимизированную функцию под один тип и подставлять ее в этих случаях (когда оптимизатор знает, что тип один для всех значений). А если мы ничего не знаем про типы данных, то как избежать Exception на неправильном типе? Никак.
Масштабирование уже есть, нет репликации для отказоустойчивости пока.
Насчет памяти — СУБД всегда управляет своей памятью, особенно в Яве нельзя память отдавать на откуп GC — все встанет колом.
Проект довольно молодой, естественно с большой исследовательской составляющей. Но язык запросов не свой — это просто упрощенная XQuery, алгебра тоже проверенная из XML СУБД, конечно свой парсер (у всех свой парсер). И в основном пишут не студенты, а 2 парня, которые ушли из Оракла, ну и аспиранты, которыми они руководят. А Постгресс как раз был одними аспирантами написан, и вот — допилили в конце концов до крутой системы.
В общем зная эту комманду, уверен, результат будет вполне себе промышленный. Вопрос времени.
Ну мир не делится на блоггеров и финансистов, уверен достаточно кейсов для Asterix. Я сам совсем не блогов юзаю монгу, у меня туча вложенных структур, которые постоянно чем-то пополняются и ломятся в базу разношерстные клиенты. При этом надо делать нормальные репорты, а с монго я замучился. Уже выгружаю все в Asterix и там пишу запросы на приятном QL. Но у меня нишевый кейс.
А так я вижу такую последовательность — подсели на монго именно из-за простоты, потом требуется более сложный функционал, но переходить на реляционку не хочется. Просто перегружаем данные в AsterixDB и продолжаем радостно существовать.
Со схемой можно еще справится таким путем, хотя у меня из разных языков в монгу лазают, и нужен тогда еще универсальный ORM.
А с запросами это как — грузим все данные в клиента и там пускаем запросы? А если надо сджоинить несколько коллекций? Сгруппировать тучу данных?
Если использовать AsterixDB как хранилище с простыми запросами, в перспективе будет масштабироваться на сотни терабайт-петабайты (нет планов делать ее кросс-дата-центр пока, так что в пределах одного ЦОДа). Подложка (Hyracks) тестировалась на больших кластерах (1700 ядер) очень успешно. Движок Hyracks намного эффективнее Hadoop, на TPC-подобном бенче на 2 порядка быстрее, так что полетит.
Но пока есть 2 серьезных затыка — нет репликации для отказоустойчивости (и отказоустойчивости тоже пока нет, при падении узла база ждет, чтобы узел был восстановлен); и нет нормального стриминга результатов запроса на клиент — результат складывается на сервере СУБД и отдается через REST. Так что при таком раскладе не стал бы огромные данные еще в ней держать. Сам храню порядка 50GB, но для сложных «аналитических» запросов.
Лично для меня это пока самые неприятные места Mongo. Хотя и скорость и объемы съедаемой памяти/диска тоже начинают нервировать. Опять же, AsterixDB эти проблемы решает, но это уже другая статья
Если использовать AsterixDB как хранилище с простыми запросами, в перспективе будет масштабироваться на сотни терабайт-петабайты (нет планов делать ее кросс-дата-центр пока, так что в пределах одного ЦОДа). Подложка (Hyracks) тестировалась на больших кластерах (1700 ядер) очень успешно. Движок Hyracks намного эффективнее Hadoop, на TPC-подобном бенче на 2 порядка быстрее, так что полетит.
Но пока есть 2 серьезных затыка — нет репликации для отказоустойчивости (и отказоустойчивости тоже пока нет, при падении узла база ждет, чтобы узел был восстановлен); и нет нормального стриминга результатов запроса на клиент — результат складывается на сервере СУБД и отдается через REST. Так что при таком раскладе не стал бы огромные данные еще в ней держать. Сам храню порядка 50GB, но для сложных «аналитических» запросов.
Не считаю код ужас-ужас, нормальный код. И совершенно нормальная схема работы паралельной СУБД — генерим один мастер-план запроса, затем раздаем его на кластер, каждый работает отдельно, выполняя физические операторы. И выполнять физические операторы — обычное дело, выигрыш от байткода мизерный, особенно когда можно потерять 20-100x производительности от плохой оптимизации запроса.
По тем же бенчам видно — Shark часто забивает Impala. При этом частенько всех мочит Амазон со своей ParAxel, который в свою очередь проигрывает устоявшимся решениям вроде Vertica или Neteeza (кстати Neteeza пошла гораздо дальше байткода и зашила кое-что в железо, только вот по слухам начинает все это чистить оттуда).
Про позиционирование: в классе СУБД для слабо-структурированных данных пока рулят XML-СУБД. но с ними замучаешься работать и бесплатные не особенно качественные. AsterixDB такую-же мощь принесет в мир JSON, но не сразу, естественно. Шардинг они уже сделали, осталось сделать репликацию, что не так долго должно занять.
По последнему вопросу — что-то вроде SQL dirty read.
Я призываю молодежь подключаться, если есть возможность :)
Масштабирование уже есть, нет репликации для отказоустойчивости пока.
Насчет памяти — СУБД всегда управляет своей памятью, особенно в Яве нельзя память отдавать на откуп GC — все встанет колом.
Проект довольно молодой, естественно с большой исследовательской составляющей. Но язык запросов не свой — это просто упрощенная XQuery, алгебра тоже проверенная из XML СУБД, конечно свой парсер (у всех свой парсер). И в основном пишут не студенты, а 2 парня, которые ушли из Оракла, ну и аспиранты, которыми они руководят. А Постгресс как раз был одними аспирантами написан, и вот — допилили в конце концов до крутой системы.
В общем зная эту комманду, уверен, результат будет вполне себе промышленный. Вопрос времени.
А так я вижу такую последовательность — подсели на монго именно из-за простоты, потом требуется более сложный функционал, но переходить на реляционку не хочется. Просто перегружаем данные в AsterixDB и продолжаем радостно существовать.
Вот синтетический пример:
-customer
-order
-order_line_item
сгруппировать кастомеров по регионам, внутри каждого сгруппировать orders по категории товара, подсчитать агрегаты на всех уровнях
А с запросами это как — грузим все данные в клиента и там пускаем запросы? А если надо сджоинить несколько коллекций? Сгруппировать тучу данных?
Но пока есть 2 серьезных затыка — нет репликации для отказоустойчивости (и отказоустойчивости тоже пока нет, при падении узла база ждет, чтобы узел был восстановлен); и нет нормального стриминга результатов запроса на клиент — результат складывается на сервере СУБД и отдается через REST. Так что при таком раскладе не стал бы огромные данные еще в ней держать. Сам храню порядка 50GB, но для сложных «аналитических» запросов.
Но пока есть 2 серьезных затыка — нет репликации для отказоустойчивости (и отказоустойчивости тоже пока нет, при падении узла база ждет, чтобы узел был восстановлен); и нет нормального стриминга результатов запроса на клиент — результат складывается на сервере СУБД и отдается через REST. Так что при таком раскладе не стал бы огромные данные еще в ней держать. Сам храню порядка 50GB, но для сложных «аналитических» запросов.