После трёх лет разработки состоялся (https://crate.io/releases/achievement-unlocked-cratedb-1-0/) релиз проекта CrateDB 1.0 (https://crate.io), в рамках которого развивается открытая, быстрая и масштабируемая СУБД с поддержкой выполнения SQL-запросов и встроенными возможностями полнотекстового поиска. Версия 1.0 позиционируется как первый выпуск, достигший должного уровня стабильности и пригодный для промышленного использования. Исходные тексты CrateDB написаны на языке Java и
распространяются (https://github.com/crate/crate) под лицензией Apache 2.0.
СУБД позволяет использовать SQL как для структурированных, так и для не структурированных данных. Запросы могут выполняться распределённо, охватывая данные, хранящиеся на нескольких узлах, при этом для таких запросов обеспечивается производительность, близкая к обработке в реальном режиме времени. CrateDB оптимально подходит для хранения и формирования выборок для различных автоматически генерируемых данных, таких как логи, результаты периодического опроса датчиков и параметры сетевого трафика.
Особенности и возможности CrateDB:
- Возможность (https://crate.io/docs/reference/protocols/postgres.html) подключения к СУБД с использованием бинарного протокола PostgreSQL. CrateDB на уровне протокола эмулирует PostgreSQL 9.5 и позволяет с некоторыми ограничениями (например, не поддерживаются транзакции) использовать написанное для PostgreSQL клиентское ПО;
- Встроенный управляющий web-интерфейс (http://localhost:4200/admin/) и CLI-клиент crash;
- Средства для обеспечения высокой доступности и масштабируемости - возможно распределённое хранение данных с шардингом на несколько узлов и хранением нескольких копий на разных узлах. Репликация выполняется автоматически, уровень дубликатов задаётся в конфигурации БД. В случае сбоя или вывода узла для обновления, хранимая на нём информация замещается данными с других узлов;- Хорошая масштабируемость - для расширения хранилища или увеличения производительности достаточно просто добавить в кластер СУБД дополнительные узлы и СУБД сама выполнит автоматическую ребалансировку данных. Для распараллеливания операций в CrateDB применяется ахитектура без разделения ресурсов (shared-nothing);
- Эффективная система кэширования полей, позволяющая выполнять запросы, в том числе с агрегатными функциями, слиянием таблиц и подзапросами, со скоростью обращения данным в оперативной памяти;
- Высокая производительность операций добавления данных (INSERT). На типовом оборудовании обеспечивается производительность на уровне 40 тысяч операций INSERT в секунду на один узел в кластере. Запросы выполняются с предсказуемой производительностью за считанные миллисекунды, независимо от наличия активности на запись;- Интерфейсы для определения схемы хранения данных и структуры метаданнных. Поддержка как реляционных данных, так и вложенных документов JSON и блобов. Возможность обращения к атрибутам JSON из SQL и хранение в форме блобов изображений, видео и прочих бинарных данных;
- Средства аналитики для выявления аномалий и тенденций во временных рядах (https://ru.wikipedia.org/wiki/%D0%92%D1%.... Для ускорения производительности и удобства работы поддерживается автоматическое партицирование данных за разные интервалы времени (каждый интервал представлен как виртуальная таблица);
- CrateDB не поддерживает ACID-транзакции и обеспечивает непротиворечивость на уровне строк через использование модели "read-after-write" и оптимистическое управление параллельной обработкой данных (OCC (https://en.wikipedia.org/wiki/Optimistic_concurrency_control) - Optimistic Concurrency Control), в котором для выявления и разрешения конфликтов используется внутреннее версионирование;
- Встроенные средства инкрементального резервного копирования БД, позволяющие сохранять снапшоты со срезом данных на текущий момент времени;
- Наличие условных (https://crate.io/docs/reference/sql/scalar.html#conditional-... и математических (https://crate.io/docs/reference/sql/scalar.html#mathematical... функций, а также типов для задания местоположения (geo_point и geo_shape) и функций для вычисления расстояний, пересечений и вхождений областей;
- Возможность создания узлов, доступных только на чтение (https://crate.io/docs/reference/configuration.html#read-only...- Поддержка подзапросов (вложенные SELECT);
select average_price from (
select avg(price) as average_price
from articles) as t
order by average_price;
- Поддержка внешних слияний (LEFT/RIGHT/FULL/CROSS JOIN (https://crate.io/docs/reference/sql/joins.html#left-outer-jo...
select e.name || ' ' || e.surname as employee, coalesce(d.name, '') as manager_of_department
from employees e left join departments d
on e.id = d.manager_id
order by e.id;- Поддержка определения полуструктурированных схем хранения с динамически добавляемыми в процессе работы полями:
create table demo (
name string,
obj object (dynamic) as (
age int
),
tags array (string));insert into demo (name, obj, tags) values
('Trillian',
{age = 39, gender='female'}, // поле gender явно не определено в схеме и создаётся динамически
['mathematician', 'astrophysicist']);select * from demo where obj['gender'] = 'female';
- Встроенные средства полнотекстового поиска на базе движка Lucene. Например, можно задавать вес для совпадений в определённых полях:
select title from wikipedia where match((title 1.5, text 1.0), 'Test')
URL: https://crate.io/releases/achievement-unlocked-cratedb-1-0/
Новость: http://www.opennet.dev/opennews/art.shtml?num=45707
> быстрая
> на языке Java«Ява не тормозит»©
Так она действительно не тормозит.
Только плашки оперативки подкидывай, подкидывай давай.. чего остановился?
У Java тормозит только гуй. Безгуйные приложения на Java сопоставимы с безгуйными приложениями на С++ и проседают в производительности по сравнению с ними всего в полтора раза.
>всего в полтора раза.полтора-два раза
> полтора-два разаМожет и 3 получиться. А сборщик мусора может все надолго клинить. Written once, profile evrywhere!
Там есть разные реализации сборщика. Он может работать параллельно и не тормозить остальных.
Да, к тому же он может вообще отключаться или даже выпиливаться из исходников JVM.
Правда как с этим жить - это отдельная история.
Подключи параллельный сборщик, задай максимальный интервал окна в несколько миллисекунд и будет тебе Soft RealTime счастье.
всё немного сложнее: тормозит запуск виртуальной машины, потом какое-то время уходит на прогрев кэшей и оптимизацию кода. как результат, настольные приложения работают невыносимо медленно, но серверные, которые запускаются один раз и работают годами считают на скорости C (ну почти). все неверующие могут поискать бенчмарки на хабре.
> тормозит запуск виртуальной машиныЗапусти hello world на жаве через time и узнай сколько миллисекунд на самом деле запускается jvm. Треск шаблона гарантирован.
> работают годами считают на скорости C (ну почти). все неверующие могут поискать бенчмарки на хабре.
Зачем хабр, если есть Benchmarks Game. Твое "почти" это в среднем в два раза на задачах, требующих сравнительно небольшого количества памяти. При этом кушает в среднем в 10 раз больше памяти. Но еще веселее становится, когда потребляемая память измеряется гигабайтами и неожиданно оказывается, что gc на таких объемах может очень сильно тормозить работу и разница в скорости куда больше двух раз.
Допускаю, что скорость бывает даже соизмерима, но только в идеальных условиях - когда уже по куску кода прошелся JIT (на него кстати тоже тратится время на первых стадиях после запуска приложения) и если не дергается GC.
Второе может быть достигнуто только если писать код специальным образом, грубо говоря в особом процедурном стиле, что слабо читаемо, и вообще говоря противоречит всем практикам энтерпрайзного программирования. Вся инфраструктура также сделана в духе ООП.
Иначе говоря, GC всегда будет при работе. Естеcтсвенно, при этом отжирая время процессора - впрочем, в обычном случае нефатально.
Стоит упомянуть случай, если повезло меньше, и код оказывался недружелюбным для GC. Тогда большие тормоза, фризы обеспечены, а бороться с этим зачастую нетривиально. Надо осмысливать архитектуру приложения, прикидывать жизненный цикл объектов, их связи, и рефакторить со всеми вытекающими.
Итого, в Jave в обмен на более простой и быстрый цикл разработки ПО мы получаем бомбу замедленного действия в виде GC. В энтерпрайзе это оправдано, обычное приложение до такой стадии развития не доживает, а если все же оказывается таким большим и ценным (т.е. проект уже можно считать успешным), гипотетически можно привелечь команду гуру и все поправить.
Вдогонку.
Зачем они принялись писать на БД на Java? Потому что проще, быстрее и дешевле. Если ресурсы ограничены, первого релиза на тех же плюсах можно и не дождаться.
Что будут делать, если проблемы с GC станут в полный рост? Думаю, в данный момент они особо не задумываются. Скорее всего будут давать советы как тюнить JVM (привет админам) и попутно переписывать критические куски в подходящей для GC манере.
Кстати, для справочки, большое ПО на Java обычно идет как минимум с предустановленными параметрами JVM в конфиге, а то и с кастомизированной виртуальной машиной.
>Зачем они принялись писать на БД на Java? Потому что проще, быстрее и дешевле.Отличная аналитика, бро! У людей, покупающих например IBM z13 за мегабакс на крутых сишников нет денег, вот они и довольствуются дешевыми жабистами 8))))
Кстати, у сурового челябинского программиста можно почитать как работает жаба на мегажелезе с кучей на десятки гигабайт. Обычно GC срабатывает раз в несколько часов на несколько сек. Я бы хотел сравнить данный показатель с быстрой сишечкой, но боюсь, что на ней никто ещё ПО такого уровня не написал.
На крутых сишников действительно нет денег, но просто там нужно 1000+ таких что-бы сначала всю инфраструктуру написали с нуля ( которая с java уже есть ), потом оттестили лет за 5, потом уже за нужные сервисы взялись :)
И при этом ещё нужно 1000+ бизнес-системных аналитиков такого же уровня, и планету на которой задачи(законодательство) не меняются хотя-бы в течении лет 5-ти :)p.s. Каждой задаче свой инструмент!
> Зачем они принялись писать на БД на Java?
> Что будут делать, если проблемы с GC станут в полный рост?Почему же создатели и эксплуатанты Cassandra, Hive, BigTable, Elasticsearch, OrientDB, RabbitMQ об этом не задумались... Вот глупые (тоном Задорнова)!
>еще веселее становится, когда потребляемая память измеряется гигабайтами и неожиданно оказывается, что gc на таких объемах может очень сильно тормозить работу и разница в скорости куда больше двух разВсе сишнеки знают, что GC в жабе тормозит проги с кучей на десятки гигабайт.
Насколько я знаю, подвисает на пару секунд.Но почему все сишники забывают, что на си такие проги вообще никто никогда не пишет, т.к. такой сложности прога глючит так сурово, что не может в рабочее состояние выйти. Падает раньше чем бенчмарк отрабатывает.
> Но почему все сишники забывают, что на си такие проги вообще никто
> никогда не пишет,Дорогой собрат по разуму, пишу вам из параллельной вселенной – увы, у нас неосиляторы Javы еще пишут ОСьки на десятки мульенов строк на своем Темном Наречии :(
> т.к. такой сложности прога глючит так сурово, что
> не может в рабочее состояние выйти. Падает раньше чем бенчмарк отрабатывает.
% uptime
07:19 60 дней 14:49, 2 пользователей,
Гм, что-то падение затянулось -- видимо, все же успели на выходе в рабочее состояние набрать первую космическую скорость )
>> настольные приложения работают невыносимо медленноПриложения назовёте?
Intel RAID Web Console 2 Utility пойдёт?
>> Intel RAID Web Console 2 Utility пойдёт?Это десктоп приложение? Швайн?
>>> Intel RAID Web Console 2 Utility пойдёт?
> Это десктоп приложение? Швайн?Забавная штука, аналогично АМД пошли, те тоже сервис с вэб мордой на управление встроенным в материнку, собственным софт. райдом делают :)
Правда у АМД не тормозило насколько помню :)
Ну да, ну да.. Про проблемы с GC не забывайте.
> на скорости C (ну почти). все неверующие могут поискать бенчмарки
> на хабре.Посмотрите лучше бенчмарки ScyllaDB и Cassandra. Все вопросы отпадут.
Кто такой "безгуйный", и на каком языке это написано?
Имеется ввиду соснольное аппликэйшен, сервис (демон), етц. Написано на языке твоего тела.
Не понятно, как они разруливают конфликты двух параллельных модифицирующих запросов для одних данных. На основе версий можно консистентно читать данные (пусть немного устаревшие), но как записывать мне не понятно. Для того и придуманы транзакции
Элементарно - они на это забивают. Данная БД предназначена для случаев, когда данных очень много и потерей или некорректностью части из них можно спокойно пренебречь
можно спокойно пренебречь всеми данными после сбоя данной субд
Мне сложно представить ситуации, когда можно использовать такие базы. Разве что для какого-нибудь кеша, но там, обычно, за глаза хватает key-value баз.Если данные помещаются в базу, значит они ценны. Сейчас даже статистику терять жалко. Она, скорее всего, как-то обрабатывается и анализируется, и говорить, что сегодня отчетов не будет, так как наша бд после сбоя находится в непонятном состоянии, как то глупо.
Да и как делать более или менее сложные запросы, без транзакций? Обычно делаешь селект, обрабатываешь результаты и делаешь абдейт. Даже если это будет один сложный SQL запрос с селектом и апдейтом, все равно внутри бд должно существовать некое понятие транзакций
>абдейтКстати, часто вижу такую необычную форму записи. Это какая-то шутка или обычная глупость уровня "андройд"?
Это безграмотное бидуро.
Как раз со статистикой - в самый раз. Не "говорить, что отчётов не будет", а просто самую малость упадёт их точность. Скорее всего - даже не упадёт, один хрен всё усреднится.То же касается логов - крайне редко там важна одна-единственная конкретная запись из миллионов. Вообще, если не считать финансовые БД небольшая доля потерь частенько вполне приемлема.
> Мне сложно представить ситуации, когда можно использовать такие базы.Посмотри use cases их сайте. И речь идет не о крупной потере в результате сбоя, а о потере или неточности отдельных записей из-за отстутсвия транзакций.
>а о потере или неточности отдельных записей из-за
> отстутсвия транзакций.Если у продукта А в БД вдруг стала цена от продукта Б (да мало-ли человек в двух табах нажал добавить товар в корзину, чисто гипотетически;) ), то ошибка конечно в конкретной строчке, но результат неверный совсем :).
Еще раз для танкистов, посмотри для чего ее применяют. Подсказка, для магазинов/складов/бухгалтерии/итд такие БД не подходят и никто не предлагает их использовать, но мир не ограничен этой сферой.
https://crate.io/docs/reference/sql/dml.html#updating-data
> If the same documents are updated concurrently an VersionConflictException might occur. Crate contains a retry logic that tries to resolve the conflict automatically.Если данные будут модифицироваться одновременно, то выбросит VersionConflictException, а затем попытается снова выполнить запрос.
> Crate heavily relies on Elasticsearch and Lucene for storage
> and cluster consensus.
> Every replica shard is updated synchronously with its primary and
> always carries the same information. Therefore it does not matter if
> the primary or a replica shard is accessed in terms of
> consistency. Only the refresh of the ``IndexReader`` affects
> consistency.Консистентна запись (insert, update, т.п.); консистентно получение данных с полным указанием primary key в WHERE.
Про консистентность тут написано: https://crate.io/docs/reference/architecture/storage_consist...
Вот тут собственно ответ:>CrateDB оптимально подходит для хранения и формирования выборок для различных автоматически генерируемых данных, таких как логи, результаты периодического опроса датчиков и параметры сетевого трафика.
Один источник - множество получателей. И никаких конфликтов. Самый простой и надежный способ.
> Вот тут собственно ответ:
>>CrateDB оптимально подходит для хранения и формирования выборок для различных автоматически генерируемых данных, таких как логи, результаты периодического опроса датчиков и параметры сетевого трафика.
> Один источник - множество получателей. И никаких конфликтов. Самый простой и
> надежный способ.А чем это плохо работает в текущих решениях?
Есть к примеру firebird :)
Скорость. Поинтересуйся, сколько транзакций в секунду может firebird.
Хотя надо сказать, что 40k insert без транзакций у сабжа тоже ни разу не впечатляют.
На сколько я помню внутри elasticsearch живёт, почему в новости нет кпоминания о этом?
как тут с brainsplit? раз данные хранятся в виде нескольких копий значит менять эту копию нужно на сервере ответственном за запись, что будет при его падении? при его восстановлении? вообщем как тут под CAP теорему подстраиваются?
таки железо уже с сотнями гигабайт уже выпускают, да и терабайтом тож. base in memo